Bug 593669

The warning has been reported 4 times on kerneloops.org so far:

http://www.kerneloops.org/oops.php?number=3142224

> Oops 3142224 first showed up in kernel version 2.6.33.4-95.fc13.x86_64
> Oops 3142224 last showed up in version 2.6.33.4-95.fc13.i686.PAE
> 2.6.33.4 -- 4

Reported here, against the original bug this is supposed to fix:

https://bugzilla.kernel.org/show_bug.cgi?id=15906#c26

static int pin_sb_for_writeback(struct writeback_control *wbc,
                                struct inode *inode, struct super_block **psb)
{
        struct super_block *sb = inode->i_sb;

        /*
         * If this sb is already pinned, nothing more to do. If not and
         * *psb is non-NULL, unpin the old one first
         */
        if (sb == *psb)
                return 0;
        else if (*psb)
                unpin_sb_for_writeback(psb);

        /*
         * Caller must already hold the ref for this
         */
        if (wbc->sync_mode == WB_SYNC_ALL || wbc->sb_pinned) {
                WARN_ON(!rwsem_is_locked(&sb->s_umount));  <<----- here
                return 0;
        }

http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=e913fc825dc685a444cb4c1d0f9d32f372f5986

is what Jens had upstream, and I think 

http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=30fd1e551a730d942e91109762c942786be0ef7c

is the fix for the issue you see here...

> Even if the writeout itself isn't a data integrity operation, we need
> to ensure that the caller doesn't drop the sb umount sem before we
> have actually done the writeback.

Should be fixed in 2.6.33.4-106

*** Bug 594711 has been marked as a duplicate of this bug. ***

*** Bug 594914 has been marked as a duplicate of this bug. ***

Can we have -106 in testing, please?

same problem on my laptop.

Jesus, it's fixed in 2.6.33.4-106

(In reply to comment #10)
> Jesus, it's fixed in 2.6.33.4-106    

Yep, and having it testing would help :-)

I get this warning also, after resume from standby or hibernation. Reproducable on two machines.

I know that koji has packages with the fix, but I will wait until the new packages are included into official update process.

For example:
WARNING: at fs/fs-writeback.c:597 writeback_inodes_wb+0x229/0x380()
Hardware name: To Be Filled By O.E.M.
Modules linked in: tun w83627ehf hwmon_vid coretemp sunrpc ipv6 xfs exportfs uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ppdev snd_timer snd 3c59x wmi parport_pc i2c_nforce2 parport mii forcedeth soundcore microcode snd_page_alloc pata_acpi ata_generic usb_storage pata_amd nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: scsi_wait_scan]
Pid: 12031, comm: flush-8:0 Tainted: G        W  2.6.33.4-95.fc13.x86_64 #1
Call Trace:
[<ffffffff8104b558>] warn_slowpath_common+0x77/0x8f
[<ffffffff8104b57f>] warn_slowpath_null+0xf/0x11
[<ffffffff8111c3a7>] writeback_inodes_wb+0x229/0x380
[<ffffffff8111c63b>] wb_writeback+0x13d/0x1bc
[<ffffffff8109e283>] ? call_rcu_sched+0x10/0x12
[<ffffffff8109e28e>] ? call_rcu+0x9/0xb
[<ffffffff8111c7cf>] wb_do_writeback+0x69/0x14d
[<ffffffff8111c8ed>] bdi_writeback_task+0x3a/0xaa
[<ffffffff810d5cf8>] ? bdi_start_fn+0x0/0xd4
[<ffffffff810d5d64>] bdi_start_fn+0x6c/0xd4
[<ffffffff810d5cf8>] ? bdi_start_fn+0x0/0xd4
[<ffffffff810643c7>] kthread+0x7a/0x82
[<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
[<ffffffff8106434d>] ? kthread+0x0/0x82
[<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10

Testing 2.6.33.4-106 from koji, it *is* fixed.

Indeed kernel-2.6.33.4-106.fc13 fixed this bug. Many thanks.

kernel-2.6.33.5-112.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kernel-2.6.33.5-112.fc13

[BradS@EliteBook-6930p ~]$ uname -r
2.6.33.5-112.fc13.i686.PAE

The above from testing resolves the crashing on my laptop

Thanks

Not fixed in 112:

WARNING: at mm/highmem.c:444 debug_kmap_atomic+0xad/0x12a()
Hardware name: MM061                           
Modules linked in: nls_utf8 udf nfs lockd fscache nfs_acl auth_rpcgss fuse autofs4 sunrpc cpufreq_ondemand acpi_cpufreq ipv6 uinput snd_hda_codec_idt snd_hda_intel arc4 ecb snd_hda_codec snd_hwdep iwl3945 snd_seq snd_seq_device snd_pcm iwlcore snd_timer snd mac80211 dell_wmi soundcore iTCO_wdt dell_laptop cfg80211 sdhci_pci snd_page_alloc iTCO_vendor_support wmi sdhci rfkill mmc_core dcdbas i2c_i801 joydev microcode firewire_ohci firewire_core crc_itu_t i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: mii]
Pid: 0, comm: swapper Tainted: G        W  2.6.33.5-112.fc13.i686 #1
Call Trace:
[<c0436df5>] warn_slowpath_common+0x65/0x7c
[<c04aa451>] ? debug_kmap_atomic+0xad/0x12a
[<c0436e19>] warn_slowpath_null+0xd/0x10
[<c04aa451>] debug_kmap_atomic+0xad/0x12a
[<c04240a4>] kmap_atomic_prot+0x51/0xd2
[<f7e03f5d>] ? i915_error_object_create+0x5d/0xfa [i915]
[<c0424133>] kmap_atomic+0xe/0x10
[<f7e03f9f>] i915_error_object_create+0x9f/0xfa [i915]
[<f7e0432a>] i915_handle_error+0x330/0x813 [i915]
[<f7e049b3>] i915_driver_irq_handler+0xc7/0x2f4 [i915]
[<c0478d84>] handle_IRQ_event+0x52/0xf8
[<c047a5cf>] handle_fasteoi_irq+0x71/0xa4
[<c0404cd3>] handle_irq+0x3b/0x48
[<c0404558>] do_IRQ+0x41/0x9a
[<c0403830>] common_interrupt+0x30/0x38
[<c045007b>] ? update_target+0x3c/0xc0
[<c05f5075>] ? acpi_idle_enter_bm+0x251/0x282
[<c06c7676>] cpuidle_idle_call+0x6d/0xbf
[<c04024b8>] cpu_idle+0x91/0xad
[<c076c2a9>] start_secondary+0x1f5/0x233

Bojan,
that's a completely different stack trace than this BZ is about. Yours seems to originate from a bug in the graphics driver (i915) and it's not related to filesystem writeback.

(In reply to comment #18)

> that's a completely different stack trace than this BZ is about. Yours seems to
> originate from a bug in the graphics driver (i915) and it's not related to
> filesystem writeback.    

Not a kernel hacker - sorry. It looked like something similar, but I see now that the common thread is the warning functions, not the meat of it.

*** Bug 597339 has been marked as a duplicate of this bug. ***

kernel-2.6.33.5-112.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #18)

> that's a completely different stack trace than this BZ is about

Yeah, bug #597622.