Description of problem: This warning showed up while I was playing with mock: ------------[ cut here ]------------ WARNING: at fs/fs-writeback.c:597 writeback_inodes_wb+0x229/0x380() Hardware name: Satellite Pro A210 Modules linked in: fuse ipt_MASQUERADE iptable_nat nf_nat bridge stp llc cpufreq_ondemand powernow_k8 freq_table xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_amd kvm uinput snd_hda_codec_realtek arc4 ecb snd_hda_intel snd_hda_codec ath5k sdhci_pci snd_hwdep sdhci mac80211 mmc_core snd_seq video snd_seq_device ath snd_pcm edac_core shpchp snd_timer edac_mce_amd k8temp output cfg80211 r8169 snd rfkill soundcore joydev i2c_piix4 mii snd_page_alloc microcode aes_x86_64 aes_generic xts gf128mul dm_crypt ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t pata_atiixp radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] Pid: 3614, comm: flush-253:4 Not tainted 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 ---[ end trace b3be65b91ddd972b ]--- Version-Release number of selected component (if applicable): kernel-2.6.33.4-95.fc13.x86_64 How reproducible: not sure how repeatable it is Steps to Reproduce: What I did was basically: mock -r fedora-13-i386 --init mock -r fedora-13-i386 --shell Actual results: After a few seconds abrt notified me of the kernel warning. Expected results: No kernel WARNINGs. Additional info: I'm using ext4 on a dm-crypt'd LV. fs-writeback.c was modified recently by: * Sun May 09 2010 Kyle McMartin <kyle> - fs-explicitly-pass-in-whether-sb-is-pinned-or-not.patch (rhbz#588930)
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.