Created attachment 46722 [details] Full dmesg output with oopses on floppy use Since: 2.6.38-rc1 Last working: 2.6.37 Fedora 14 x86_64 My system has a legacy 3.5-inches floppy drive (NOT an USB floppy) salvaged from an old computer. For this floppy drive, I added a line to /etc/fstab like this: /dev/fd0 /mnt/floppy auto defaults,users,noauto 0 0 This setup worked correctly under 2.6.37. Since 2.6.38-rc1, whenever I run "mount /mnt/floppy", the mount command completes with apparently no errors, but the drive is not actually mounted at all. It does not appear in the output of "df", and there are no contents under /mnt/floppy. Repeating the mount command does not work at all. If I then run (as root) the command "mount /dev/fd0u1440 /mnt/floppy", the mount really succeeds and I can see the contents of the floppy drive. However, when I try to unmount /dev/fd0u1440, I get the following WARN_ON messages: [ 2834.996302] ------------[ cut here ]------------ [ 2834.996314] WARNING: at fs/block_dev.c:1426 blkdev_put+0x8f/0x114() [ 2834.996318] Hardware name: OEM [ 2834.996321] Modules linked in: vfat fat usb_storage uas fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc deflate zlib_deflate ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_x86_64 twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel tunnel6 af_key vboxnetadp vboxnetflt vboxdrv hwmon_vid coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf capi capifs kernelcapi nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel ppdev snd_hda_codec parport_pc iTCO_wdt iTCO_vendor_support r8169 parport i2c_i801 snd_hwdep mii snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc microcode floppy pcspkr i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 2834.996469] Pid: 3443, comm: umount Not tainted 2.6.38-rc3 #1 [ 2834.996473] Call Trace: [ 2834.996482] [<ffffffff810515ef>] ? warn_slowpath_common+0x85/0x9d [ 2834.996488] [<ffffffff81051621>] ? warn_slowpath_null+0x1a/0x1c [ 2834.996494] [<ffffffff8114f0a9>] ? blkdev_put+0x8f/0x114 [ 2834.996501] [<ffffffff8112671b>] ? kill_block_super+0x65/0x6a [ 2834.996507] [<ffffffff81126984>] ? deactivate_locked_super+0x26/0x46 [ 2834.996513] [<ffffffff811274b1>] ? deactivate_super+0x3a/0x3e [ 2834.996519] [<ffffffff8113d00a>] ? mntput_no_expire+0xd0/0xd5 [ 2834.996525] [<ffffffff8113db6f>] ? sys_umount+0x2e9/0x317 [ 2834.996532] [<ffffffff8112db09>] ? path_put+0x22/0x27 [ 2834.996539] [<ffffffff8100ac82>] ? system_call_fastpath+0x16/0x1b [ 2834.996544] ---[ end trace 2c364f9280e3c23f ]--- [ 2834.996547] ------------[ cut here ]------------ [ 2834.996552] WARNING: at fs/block_dev.c:1383 __blkdev_put+0x6d/0x150() [ 2834.996556] Hardware name: OEM [ 2834.996558] Modules linked in: vfat fat usb_storage uas fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc deflate zlib_deflate ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_x86_64 twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel tunnel6 af_key vboxnetadp vboxnetflt vboxdrv hwmon_vid coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf capi capifs kernelcapi nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel ppdev snd_hda_codec parport_pc iTCO_wdt iTCO_vendor_support r8169 parport i2c_i801 snd_hwdep mii snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc microcode floppy pcspkr i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 2834.996692] Pid: 3443, comm: umount Tainted: G W 2.6.38-rc3 #1 [ 2834.996696] Call Trace: [ 2834.996702] [<ffffffff810515ef>] ? warn_slowpath_common+0x85/0x9d [ 2834.996708] [<ffffffff81051621>] ? warn_slowpath_null+0x1a/0x1c [ 2834.996713] [<ffffffff8114ef37>] ? __blkdev_put+0x6d/0x150 [ 2834.996720] [<ffffffff8114f125>] ? blkdev_put+0x10b/0x114 [ 2834.996725] [<ffffffff8112671b>] ? kill_block_super+0x65/0x6a [ 2834.996731] [<ffffffff81126984>] ? deactivate_locked_super+0x26/0x46 [ 2834.996737] [<ffffffff811274b1>] ? deactivate_super+0x3a/0x3e [ 2834.996743] [<ffffffff8113d00a>] ? mntput_no_expire+0xd0/0xd5 [ 2834.996748] [<ffffffff8113db6f>] ? sys_umount+0x2e9/0x317 [ 2834.996754] [<ffffffff8112db09>] ? path_put+0x22/0x27 [ 2834.996761] [<ffffffff8100ac82>] ? system_call_fastpath+0x16/0x1b [ 2834.996765] ---[ end trace 2c364f9280e3c240 ]--- fs/block_dev.c:1426 blkdev_put resolves to: WARN_ON_ONCE(--bdev->bd_contains->bd_holders < 0); fs/block_dev.c:1383 __blkdev_put resolves to: WARN_ON_ONCE(bdev->bd_holders); After this "mount /mnt/floppy" complains about the device being busy, but no content appears under /mnt/floppy. The command "mount /dev/fd0u1440 /mnt/floppy/" still works, but unmounting it again produces the WARN_ON. Also, either "mkfs.vfat /dev/fd0" or "mkfs.vfat /dev/fd0u1440" complain about being unable to open the floppy device. If I reboot and then try to run "mkfs.vfat /dev/fd0", it appears to run normally. However, "mkfs.vfat /dev/fd0u1440" again triggers the oopses. The same happens if I try with mkfs.ext2, so it does not seem to be an issue with a particular filesystem. I have tried to bisect this, but I get a weird bisect log. It seems that "[18b022eb117e7f70c191267551ff865f278a9258] Merge branch 'for-2.6.38' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into topic/asoc" was the first bad commit, but that commit has nothing to do with filesystems or block devices. I would suspect of "[b2034d474b7e1e8578bd5c2977024b51693269d9] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6" but that one appears to be good. I have had no issues at all with USB sticks formatted with FAT filesystems.
Created attachment 46732 [details] Kernel configuration used to compile affected kernel
Created attachment 46742 [details] Full contents of /etc/fstab file
Full attempt at bisecting bug: git bisect start # good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37 git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5 # bad: [c56eb8fb6dccb83d9fe62fd4dc00c834de9bc470] Linux 2.6.38-rc1 git bisect bad c56eb8fb6dccb83d9fe62fd4dc00c834de9bc470 # good: [ecacc6c70cf77a52a22af66c879873202522d6ce] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 git bisect good ecacc6c70cf77a52a22af66c879873202522d6ce # good: [55065bc52795faae549abfb912aacc622dd63876] Merge branch 'kvm-updates/2.6.38' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect good 55065bc52795faae549abfb912aacc622dd63876 # bad: [dc8e7e3ec60bd5ef7868aa88755e9d4c948dc5cc] Merge branch 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6 git bisect bad dc8e7e3ec60bd5ef7868aa88755e9d4c948dc5cc # bad: [66dc918d42eaaa9afe42a47d07526765162017a9] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 git bisect bad 66dc918d42eaaa9afe42a47d07526765162017a9 # good: [18b022eb117e7f70c191267551ff865f278a9258] Merge branch 'for-2.6.38' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into topic/asoc git bisect good 18b022eb117e7f70c191267551ff865f278a9258 # good: [27d189c02ba25851973c8582e419c0bded9f7e5b] Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 git bisect good 27d189c02ba25851973c8582e419c0bded9f7e5b # good: [e38302f78284e3e80ffc2eef54001fce7d183bd4] Merge branch 'topic/misc' into for-linus git bisect good e38302f78284e3e80ffc2eef54001fce7d183bd4 # good: [9ecf639a9686c9c7e3fd2cd72817ca490c658e6f] Gfs2: fail if we try to use hole punch git bisect good 9ecf639a9686c9c7e3fd2cd72817ca490c658e6f # good: [70c673a48072ff73425b82800479e66f918b8718] Merge branch 'fix/hda' into topic/hda git bisect good 70c673a48072ff73425b82800479e66f918b8718 # good: [393004b2ea49524ee41a562cae8db67f50f372a5] ALSA: hda: Disable 4/6 channels on some NVIDIA GPUs. git bisect good 393004b2ea49524ee41a562cae8db67f50f372a5 # good: [80c678526d7da73bde4d46a4622449c2b3c88409] ALSA: hda - Fix NULL-derefence with a single mic in STAC auto-mic detection git bisect good 80c678526d7da73bde4d46a4622449c2b3c88409 # good: [6db9a0f326d3144d790d9479309df480a8f562e4] Merge branch 'topic/asoc' into for-linus git bisect good 6db9a0f326d3144d790d9479309df480a8f562e4 # good: [b2034d474b7e1e8578bd5c2977024b51693269d9] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 git bisect good b2034d474b7e1e8578bd5c2977024b51693269d9
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 7 Feb 2011 17:21:42 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=28522 > > Summary: Unable to mount FAT-formatted floppy on /dev/fd0, plus > WARN_ON when using /dev/fd0u1440 > Product: IO/Storage > Version: 2.5 > Kernel Version: 2.6.37-rc3 I assume that's meant to be 2.6.38-rc3, and that this is a post-2.6.37 regression? It's this: WARN_ON_ONCE(bdev->bd_holders); > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Block Layer > AssignedTo: axboe@kernel.dk > ReportedBy: avillaci@ceibo.fiec.espol.edu.ec > Regression: Yes > > > Created an attachment (id=46722) > --> (https://bugzilla.kernel.org/attachment.cgi?id=46722) > Full dmesg output with oopses on floppy use > > Since: 2.6.38-rc1 > Last working: 2.6.37 > > Fedora 14 x86_64 > > My system has a legacy 3.5-inches floppy drive (NOT an USB floppy) salvaged > from an old computer. For this floppy drive, I added a line to /etc/fstab > like > this: > /dev/fd0 /mnt/floppy auto defaults,users,noauto 0 0 > This setup worked correctly under 2.6.37. Since 2.6.38-rc1, whenever I run > "mount /mnt/floppy", the mount command completes with apparently no errors, > but > the drive is not actually mounted at all. It does not appear in the output of > "df", and there are no contents under /mnt/floppy. Repeating the mount > command > does not work at all. If I then run (as root) the command "mount > /dev/fd0u1440 > /mnt/floppy", the mount really succeeds and I can see the contents of the > floppy drive. However, when I try to unmount /dev/fd0u1440, I get the > following > WARN_ON messages: > > [ 2834.996302] ------------[ cut here ]------------ > [ 2834.996314] WARNING: at fs/block_dev.c:1426 blkdev_put+0x8f/0x114() > [ 2834.996318] Hardware name: OEM > [ 2834.996321] Modules linked in: vfat fat usb_storage uas fuse ebtable_nat > ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc deflate > zlib_deflate > ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_x86_64 > twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd > aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 > xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro > xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel > tunnel6 af_key vboxnetadp vboxnetflt vboxdrv hwmon_vid coretemp sunrpc > cpufreq_ondemand acpi_cpufreq freq_table mperf capi capifs kernelcapi > nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 > ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel > ppdev snd_hda_codec parport_pc iTCO_wdt iTCO_vendor_support r8169 parport > i2c_i801 snd_hwdep mii snd_seq snd_seq_device snd_pcm snd_timer snd soundcore > snd_page_alloc microcode floppy pcspkr i915 drm_kms_helper drm i2c_algo_bit > i2c_core video [last unloaded: scsi_wait_scan] > [ 2834.996469] Pid: 3443, comm: umount Not tainted 2.6.38-rc3 #1 > [ 2834.996473] Call Trace: > [ 2834.996482] [<ffffffff810515ef>] ? warn_slowpath_common+0x85/0x9d > [ 2834.996488] [<ffffffff81051621>] ? warn_slowpath_null+0x1a/0x1c > [ 2834.996494] [<ffffffff8114f0a9>] ? blkdev_put+0x8f/0x114 > [ 2834.996501] [<ffffffff8112671b>] ? kill_block_super+0x65/0x6a > [ 2834.996507] [<ffffffff81126984>] ? deactivate_locked_super+0x26/0x46 > [ 2834.996513] [<ffffffff811274b1>] ? deactivate_super+0x3a/0x3e > [ 2834.996519] [<ffffffff8113d00a>] ? mntput_no_expire+0xd0/0xd5 > [ 2834.996525] [<ffffffff8113db6f>] ? sys_umount+0x2e9/0x317 > [ 2834.996532] [<ffffffff8112db09>] ? path_put+0x22/0x27 > [ 2834.996539] [<ffffffff8100ac82>] ? system_call_fastpath+0x16/0x1b > [ 2834.996544] ---[ end trace 2c364f9280e3c23f ]--- > [ 2834.996547] ------------[ cut here ]------------ > [ 2834.996552] WARNING: at fs/block_dev.c:1383 __blkdev_put+0x6d/0x150() > [ 2834.996556] Hardware name: OEM > [ 2834.996558] Modules linked in: vfat fat usb_storage uas fuse ebtable_nat > ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc deflate > zlib_deflate > ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_x86_64 > twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd > aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 > xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro > xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel > tunnel6 af_key vboxnetadp vboxnetflt vboxdrv hwmon_vid coretemp sunrpc > cpufreq_ondemand acpi_cpufreq freq_table mperf capi capifs kernelcapi > nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 > ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel > ppdev snd_hda_codec parport_pc iTCO_wdt iTCO_vendor_support r8169 parport > i2c_i801 snd_hwdep mii snd_seq snd_seq_device snd_pcm snd_timer snd soundcore > snd_page_alloc microcode floppy pcspkr i915 drm_kms_helper drm i2c_algo_bit > i2c_core video [last unloaded: scsi_wait_scan] > [ 2834.996692] Pid: 3443, comm: umount Tainted: G W 2.6.38-rc3 #1 > [ 2834.996696] Call Trace: > [ 2834.996702] [<ffffffff810515ef>] ? warn_slowpath_common+0x85/0x9d > [ 2834.996708] [<ffffffff81051621>] ? warn_slowpath_null+0x1a/0x1c > [ 2834.996713] [<ffffffff8114ef37>] ? __blkdev_put+0x6d/0x150 > [ 2834.996720] [<ffffffff8114f125>] ? blkdev_put+0x10b/0x114 > [ 2834.996725] [<ffffffff8112671b>] ? kill_block_super+0x65/0x6a > [ 2834.996731] [<ffffffff81126984>] ? deactivate_locked_super+0x26/0x46 > [ 2834.996737] [<ffffffff811274b1>] ? deactivate_super+0x3a/0x3e > [ 2834.996743] [<ffffffff8113d00a>] ? mntput_no_expire+0xd0/0xd5 > [ 2834.996748] [<ffffffff8113db6f>] ? sys_umount+0x2e9/0x317 > [ 2834.996754] [<ffffffff8112db09>] ? path_put+0x22/0x27 > [ 2834.996761] [<ffffffff8100ac82>] ? system_call_fastpath+0x16/0x1b > [ 2834.996765] ---[ end trace 2c364f9280e3c240 ]--- > > fs/block_dev.c:1426 blkdev_put resolves to: > WARN_ON_ONCE(--bdev->bd_contains->bd_holders < 0); > > fs/block_dev.c:1383 __blkdev_put resolves to: > WARN_ON_ONCE(bdev->bd_holders); > > After this "mount /mnt/floppy" complains about the device being busy, but no > content appears under /mnt/floppy. The command "mount /dev/fd0u1440 > /mnt/floppy/" still works, but unmounting it again produces the WARN_ON. > Also, > either "mkfs.vfat /dev/fd0" or "mkfs.vfat /dev/fd0u1440" complain about being > unable to open the floppy device. > > If I reboot and then try to run "mkfs.vfat /dev/fd0", it appears to run > normally. However, "mkfs.vfat /dev/fd0u1440" again triggers the oopses. The > same happens if I try with mkfs.ext2, so it does not seem to be an issue with > a > particular filesystem. > > I have tried to bisect this, but I get a weird bisect log. It seems that > "[18b022eb117e7f70c191267551ff865f278a9258] Merge branch 'for-2.6.38' of > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into > topic/asoc" was the first bad commit, but that commit has nothing to do with > filesystems or block devices. I would suspect of > "[b2034d474b7e1e8578bd5c2977024b51693269d9] Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6" but that one > appears to be good. > > I have had no issues at all with USB sticks formatted with FAT filesystems.
(resend, cc'ing the reporter) (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 7 Feb 2011 17:21:42 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=28522 > > Summary: Unable to mount FAT-formatted floppy on /dev/fd0, plus > WARN_ON when using /dev/fd0u1440 > Product: IO/Storage > Version: 2.5 > Kernel Version: 2.6.37-rc3 I assume that's meant to be 2.6.38-rc3, and that this is a post-2.6.37 regression? It's this: WARN_ON_ONCE(bdev->bd_holders); > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Block Layer > AssignedTo: axboe@kernel.dk > ReportedBy: avillaci@ceibo.fiec.espol.edu.ec > Regression: Yes > > > Created an attachment (id=46722) > --> (https://bugzilla.kernel.org/attachment.cgi?id=46722) > Full dmesg output with oopses on floppy use > > Since: 2.6.38-rc1 > Last working: 2.6.37 > > Fedora 14 x86_64 > > My system has a legacy 3.5-inches floppy drive (NOT an USB floppy) salvaged > from an old computer. For this floppy drive, I added a line to /etc/fstab > like > this: > /dev/fd0 /mnt/floppy auto defaults,users,noauto 0 0 > This setup worked correctly under 2.6.37. Since 2.6.38-rc1, whenever I run > "mount /mnt/floppy", the mount command completes with apparently no errors, > but > the drive is not actually mounted at all. It does not appear in the output of > "df", and there are no contents under /mnt/floppy. Repeating the mount > command > does not work at all. If I then run (as root) the command "mount > /dev/fd0u1440 > /mnt/floppy", the mount really succeeds and I can see the contents of the > floppy drive. However, when I try to unmount /dev/fd0u1440, I get the > following > WARN_ON messages: > > [ 2834.996302] ------------[ cut here ]------------ > [ 2834.996314] WARNING: at fs/block_dev.c:1426 blkdev_put+0x8f/0x114() > [ 2834.996318] Hardware name: OEM > [ 2834.996321] Modules linked in: vfat fat usb_storage uas fuse ebtable_nat > ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc deflate > zlib_deflate > ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_x86_64 > twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd > aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 > xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro > xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel > tunnel6 af_key vboxnetadp vboxnetflt vboxdrv hwmon_vid coretemp sunrpc > cpufreq_ondemand acpi_cpufreq freq_table mperf capi capifs kernelcapi > nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 > ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel > ppdev snd_hda_codec parport_pc iTCO_wdt iTCO_vendor_support r8169 parport > i2c_i801 snd_hwdep mii snd_seq snd_seq_device snd_pcm snd_timer snd soundcore > snd_page_alloc microcode floppy pcspkr i915 drm_kms_helper drm i2c_algo_bit > i2c_core video [last unloaded: scsi_wait_scan] > [ 2834.996469] Pid: 3443, comm: umount Not tainted 2.6.38-rc3 #1 > [ 2834.996473] Call Trace: > [ 2834.996482] [<ffffffff810515ef>] ? warn_slowpath_common+0x85/0x9d > [ 2834.996488] [<ffffffff81051621>] ? warn_slowpath_null+0x1a/0x1c > [ 2834.996494] [<ffffffff8114f0a9>] ? blkdev_put+0x8f/0x114 > [ 2834.996501] [<ffffffff8112671b>] ? kill_block_super+0x65/0x6a > [ 2834.996507] [<ffffffff81126984>] ? deactivate_locked_super+0x26/0x46 > [ 2834.996513] [<ffffffff811274b1>] ? deactivate_super+0x3a/0x3e > [ 2834.996519] [<ffffffff8113d00a>] ? mntput_no_expire+0xd0/0xd5 > [ 2834.996525] [<ffffffff8113db6f>] ? sys_umount+0x2e9/0x317 > [ 2834.996532] [<ffffffff8112db09>] ? path_put+0x22/0x27 > [ 2834.996539] [<ffffffff8100ac82>] ? system_call_fastpath+0x16/0x1b > [ 2834.996544] ---[ end trace 2c364f9280e3c23f ]--- > [ 2834.996547] ------------[ cut here ]------------ > [ 2834.996552] WARNING: at fs/block_dev.c:1383 __blkdev_put+0x6d/0x150() > [ 2834.996556] Hardware name: OEM > [ 2834.996558] Modules linked in: vfat fat usb_storage uas fuse ebtable_nat > ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc deflate > zlib_deflate > ctr camellia cast5 rmd160 crypto_null ccm serpent blowfish twofish_x86_64 > twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic cryptd > aes_x86_64 aes_generic ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 > xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro > xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm_ipcomp xfrm6_tunnel > tunnel6 af_key vboxnetadp vboxnetflt vboxdrv hwmon_vid coretemp sunrpc > cpufreq_ondemand acpi_cpufreq freq_table mperf capi capifs kernelcapi > nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 > ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_realtek snd_hda_intel > ppdev snd_hda_codec parport_pc iTCO_wdt iTCO_vendor_support r8169 parport > i2c_i801 snd_hwdep mii snd_seq snd_seq_device snd_pcm snd_timer snd soundcore > snd_page_alloc microcode floppy pcspkr i915 drm_kms_helper drm i2c_algo_bit > i2c_core video [last unloaded: scsi_wait_scan] > [ 2834.996692] Pid: 3443, comm: umount Tainted: G W 2.6.38-rc3 #1 > [ 2834.996696] Call Trace: > [ 2834.996702] [<ffffffff810515ef>] ? warn_slowpath_common+0x85/0x9d > [ 2834.996708] [<ffffffff81051621>] ? warn_slowpath_null+0x1a/0x1c > [ 2834.996713] [<ffffffff8114ef37>] ? __blkdev_put+0x6d/0x150 > [ 2834.996720] [<ffffffff8114f125>] ? blkdev_put+0x10b/0x114 > [ 2834.996725] [<ffffffff8112671b>] ? kill_block_super+0x65/0x6a > [ 2834.996731] [<ffffffff81126984>] ? deactivate_locked_super+0x26/0x46 > [ 2834.996737] [<ffffffff811274b1>] ? deactivate_super+0x3a/0x3e > [ 2834.996743] [<ffffffff8113d00a>] ? mntput_no_expire+0xd0/0xd5 > [ 2834.996748] [<ffffffff8113db6f>] ? sys_umount+0x2e9/0x317 > [ 2834.996754] [<ffffffff8112db09>] ? path_put+0x22/0x27 > [ 2834.996761] [<ffffffff8100ac82>] ? system_call_fastpath+0x16/0x1b > [ 2834.996765] ---[ end trace 2c364f9280e3c240 ]--- > > fs/block_dev.c:1426 blkdev_put resolves to: > WARN_ON_ONCE(--bdev->bd_contains->bd_holders < 0); > > fs/block_dev.c:1383 __blkdev_put resolves to: > WARN_ON_ONCE(bdev->bd_holders); > > After this "mount /mnt/floppy" complains about the device being busy, but no > content appears under /mnt/floppy. The command "mount /dev/fd0u1440 > /mnt/floppy/" still works, but unmounting it again produces the WARN_ON. > Also, > either "mkfs.vfat /dev/fd0" or "mkfs.vfat /dev/fd0u1440" complain about being > unable to open the floppy device. > > If I reboot and then try to run "mkfs.vfat /dev/fd0", it appears to run > normally. However, "mkfs.vfat /dev/fd0u1440" again triggers the oopses. The > same happens if I try with mkfs.ext2, so it does not seem to be an issue with > a > particular filesystem. > > I have tried to bisect this, but I get a weird bisect log. It seems that > "[18b022eb117e7f70c191267551ff865f278a9258] Merge branch 'for-2.6.38' of > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into > topic/asoc" was the first bad commit, but that commit has nothing to do with > filesystems or block devices. I would suspect of > "[b2034d474b7e1e8578bd5c2977024b51693269d9] Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6" but that one > appears to be good. > > I have had no issues at all with USB sticks formatted with FAT filesystems.
Reply-To: avillaci@fiec.espol.edu.ec El 07/02/11 18:18, Andrew Morton escribió: > (resend, cc'ing the reporter) > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Mon, 7 Feb 2011 17:21:42 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > >> https://bugzilla.kernel.org/show_bug.cgi?id=28522 >> >> Summary: Unable to mount FAT-formatted floppy on /dev/fd0, plus >> WARN_ON when using /dev/fd0u1440 >> Product: IO/Storage >> Version: 2.5 >> Kernel Version: 2.6.37-rc3 > I assume that's meant to be 2.6.38-rc3, and that this is a post-2.6.37 > regression? > Yes, it is. For medical reasons, I will be be away from keyboard for two weeks, so I will not be able to test patches. Sorry.
Reply-To: avillaci@fiec.espol.edu.ec El 07/02/11 19:28, Alex Villacís Lasso escribió: > El 07/02/11 18:18, Andrew Morton escribió: >> (resend, cc'ing the reporter) >> >> (switched to email. Please respond via emailed reply-to-all, not via the >> bugzilla web interface). >> >> On Mon, 7 Feb 2011 17:21:42 GMT >> bugzilla-daemon@bugzilla.kernel.org wrote: >> >>> https://bugzilla.kernel.org/show_bug.cgi?id=28522 >>> >>> Summary: Unable to mount FAT-formatted floppy on /dev/fd0, plus >>> WARN_ON when using /dev/fd0u1440 >>> Product: IO/Storage >>> Version: 2.5 >>> Kernel Version: 2.6.37-rc3 >> I assume that's meant to be 2.6.38-rc3, and that this is a post-2.6.37 >> regression? >> > Yes, it is. > > For medical reasons, I will be be away from keyboard for two weeks, so I will > not be able to test patches. Sorry. > Leave from keyboard cancelled, at least until next week. So I can test patches now.
Hello, On Mon, Feb 07, 2011 at 03:18:40PM -0800, Andrew Morton wrote: > I assume that's meant to be 2.6.38-rc3, and that this is a post-2.6.37 > regression? > > It's this: > > WARN_ON_ONCE(bdev->bd_holders); Interesting. That means someone is doing one extra blkdev_put() with EXCL set. I tried to reproduce the problem but my floppy drive is completely dead and with harddrive it worked fine regardless of the filesystem. Can you reproduce the problem without the fstab entry? Thanks.
On Wed, Feb 09, 2011 at 10:37:38AM +0100, Tejun Heo wrote: > I tried to reproduce the problem but my floppy drive is completely > dead and with harddrive it worked fine regardless of the filesystem. > Can you reproduce the problem without the fstab entry? Borrowed a floppy drive and tried but I can't reproduce it. Can you please trigger the problem without the fstab entry and let me know the command sequence? Thanks.
Reply-To: avillaci@fiec.espol.edu.ec El 09/02/11 04:54, bugzilla-daemon@bugzilla.kernel.org escribió: > https://bugzilla.kernel.org/show_bug.cgi?id=28522 > > > > > > --- Comment #9 from Tejun Heo<tj@kernel.org> 2011-02-09 09:54:00 --- > On Wed, Feb 09, 2011 at 10:37:38AM +0100, Tejun Heo wrote: >> I tried to reproduce the problem but my floppy drive is completely >> dead and with harddrive it worked fine regardless of the filesystem. >> Can you reproduce the problem without the fstab entry? > Borrowed a floppy drive and tried but I can't reproduce it. Can you > please trigger the problem without the fstab entry and let me know the > command sequence? > > Thanks. > I have just checked. The no-mount issue does not present itself when I run "mount /dev/fd0 /mnt/floppy" after removing the fstab entry. Also, unmounting /dev/fd0 after this does not trigger the oops. However, the whole point of the fstab entry was to be able to mount the floppy without switching to root. So this is still a bug.
On Monday, February 14, 2011, Alex Villacís Lasso wrote: > El 12/02/11 18:05, Rafael J. Wysocki escribió: > > This message has been generated automatically as a part of a summary report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.37. Please verify if it still should be listed and let the > tracking team > > know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28522 > > Subject : Unable to mount FAT-formatted floppy on /dev/fd0, > plus WARN_ON when using /dev/fd0u1440 > > Submitter : Alex Villacis Lasso<avillaci@ceibo.fiec.espol.edu.ec> > > Date : 2011-02-07 17:21 (6 days old) > > > > > > > Still present in 2.6.38-rc4.
Still present in 2.6.38-rc8.
Still present in 2.6.39-rc1
On Wednesday, April 20, 2011, Alex Villacís Lasso wrote: > El 17/04/11 08:52, Rafael J. Wysocki escribió: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.37 and 2.6.38. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.37 and 2.6.38. Please verify if it still should > > be listed and let the tracking team know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28522 > > Subject : Unable to mount FAT-formatted floppy on /dev/fd0, > plus WARN_ON when using /dev/fd0u1440 > > Submitter : Alex Villacis Lasso<avillaci@ceibo.fiec.espol.edu.ec> > > Date : 2011-02-07 17:21 (70 days old) > > > > > > > Still present in 2.6.39-rc4.
Still present in 2.6.39.
Reply-To: avillaci@fiec.espol.edu.ec El 25/05/11 10:22, bugzilla-daemon@bugzilla.kernel.org escribió: > https://bugzilla.kernel.org/show_bug.cgi?id=28522 > > > > > > --- Comment #15 from Alex Villacis Lasso<avillaci@ceibo.fiec.espol.edu.ec> > 2011-05-25 15:22:25 --- > Still present in 2.6.39. > I have discovered something important: it seems that the bug results from an interaction between an userspace daemon, the mount command, and the kernel. The program udisks-daemon (part of the udisks package in Fedora) is unmounting /dev/fd0 as soon as the ordinary user mounts it. I can tell that, because 1) running "mount /mnt/floppy;ls /mnt/floppy" shows content in /mnt/floppy right befure udisks-daemon unmounts the floppy, 2) running GNOME exhibits the bug, but running IceWM does not (because GNOME autostarts udisks-daemon) unless a GNOME program is started from IceWM 3) killing udisks-daemon restores proper mount behavior. However, I think this is still a kernel bug because the stock Fedora kernel (kernel-2.6.35.13-91.fc14.x86_64) does not exhibit the bug, and neither does vanilla 2.6.37 kernel. Also, userspace should never be able to trigger the WARN_ON under any circumstance. The command "udisks --mount /dev/fd0" does work properly, with or without the fstab entry.
Reply-To: avillaci@fiec.espol.edu.ec El 26/05/11 18:34, bugzilla-daemon@bugzilla.kernel.org escribió: > https://bugzilla.kernel.org/show_bug.cgi?id=28522 > > > > > > --- Comment #16 from Anonymous Emailer<anonymous@kernel-bugs.osdl.org> > 2011-05-26 23:34:18 --- > Reply-To: avillaci@fiec.espol.edu.ec > > El 25/05/11 10:22, bugzilla-daemon@bugzilla.kernel.org escribió: >> https://bugzilla.kernel.org/show_bug.cgi?id=28522 >> >> >> >> >> >> --- Comment #15 from Alex Villacis Lasso<avillaci@ceibo.fiec.espol.edu.ec> >> 2011-05-25 15:22:25 --- >> Still present in 2.6.39. >> > I have discovered something important: it seems that the bug results from an > interaction between an userspace daemon, the mount command, and the kernel. > The > program udisks-daemon (part of the udisks package in Fedora) is unmounting > /dev/fd0 as soon as the > ordinary user mounts it. I can tell that, because 1) running "mount > /mnt/floppy;ls /mnt/floppy" shows content in /mnt/floppy right befure > udisks-daemon unmounts the floppy, 2) running GNOME exhibits the bug, but > running IceWM does not (because GNOME > autostarts udisks-daemon) unless a GNOME program is started from IceWM 3) > killing udisks-daemon restores proper mount behavior. However, I think this > is > still a kernel bug because the stock Fedora kernel > (kernel-2.6.35.13-91.fc14.x86_64) does not exhibit > the bug, and neither does vanilla 2.6.37 kernel. Also, userspace should never > be able to trigger the WARN_ON under any circumstance. > > The command "udisks --mount /dev/fd0" does work properly, with or without the > fstab entry. > While figuring out the details about the mounting via udisks, I made a new bisection, for the WARN_ON when unmounting floppy devices other than /dev/fd0. I got as a result the following commit: commit 6a027eff62f6ae32d49f2ae5dadd6f4eee1ddae2 Author: Tejun Heo <tj@kernel.org> Date: Sat Nov 13 11:55:17 2010 +0100 block: reorganize claim/release implementation With claim/release rolled into blkdev_get/put(), there's no reason to keep bd_abort/finish_claim(), __bd_claim() and bd_release() as separate functions. It only makes the code difficult to follow. Collapse them into blkdev_get/put(). This will ease future changes around claim/release. Signed-off-by: Tejun Heo <tj@kernel.org> The bisection log follows: git bisect start # good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37 git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5 # bad: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38 git bisect bad 521cb40b0c44418a4fd36dc633f575813d59a43d # good: [5943a268002fce97885f2ca08827ff1b0312068c] Merge branch 'timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip git bisect good 5943a268002fce97885f2ca08827ff1b0312068c # bad: [7d209c8110ecd49db46da786437485e8ef67f414] alpha: kill off alpha_do_IRQ git bisect bad 7d209c8110ecd49db46da786437485e8ef67f414 # good: [b2034d474b7e1e8578bd5c2977024b51693269d9] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 git bisect good b2034d474b7e1e8578bd5c2977024b51693269d9 # bad: [cb9ef8d5e394f70db64bda79c20d3569a20d2574] fs/fs-writeback.c: fix sync_inodes_sb() return value kernel-doc git bisect bad cb9ef8d5e394f70db64bda79c20d3569a20d2574 # good: [6db9a0f326d3144d790d9479309df480a8f562e4] Merge branch 'topic/asoc' into for-linus git bisect good 6db9a0f326d3144d790d9479309df480a8f562e4 # bad: [810b492375f4aed5ce222982054adc0394a4bd33] dm ioctl: suppress needless warning messages git bisect bad 810b492375f4aed5ce222982054adc0394a4bd33 # good: [d20056032e20061db6583f517a4d3ea4492a94f1] Merge branch 'rmobile-latest' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 git bisect good d20056032e20061db6583f517a4d3ea4492a94f1 # bad: [81c5e2ae33c4b19e53966b427e33646bf6811830] Merge branch 'for-2.6.38/event-handling' into for-2.6.38/core git bisect bad 81c5e2ae33c4b19e53966b427e33646bf6811830 # bad: [77ea887e433ad8389d416826936c110fa7910f80] implement in-kernel gendisk events handling git bisect bad 77ea887e433ad8389d416826936c110fa7910f80 # good: [d07335e51df0c6dec202d315fc4f1f7e100eec4e] block: Rename "block_remap" tracepoint to "block_bio_remap" to clarify the event. git bisect good d07335e51df0c6dec202d315fc4f1f7e100eec4e # bad: [d4d77629953eabd3c14f6fa5746f6b28babfc55f] block: clean up blkdev_get() wrappers and their users git bisect bad d4d77629953eabd3c14f6fa5746f6b28babfc55f # good: [e09b457bdb7e8d23fc54dcef0930ac697d8de895] block: simplify holder symlink handling git bisect good e09b457bdb7e8d23fc54dcef0930ac697d8de895 # bad: [6a027eff62f6ae32d49f2ae5dadd6f4eee1ddae2] block: reorganize claim/release implementation git bisect bad 6a027eff62f6ae32d49f2ae5dadd6f4eee1ddae2 # good: [e525fd89d380c4a94c0d63913a1dd1a593ed25e7] block: make blkdev_get/put() handle exclusive access git bisect good e525fd89d380c4a94c0d63913a1dd1a593ed25e7
Created attachment 60442 [details] Kernel message log for linux-3.0.0-rc1 The situation has gotten worse in 3.0.0-rc1. Mounting /dev/fd0 directly as root, I get a WARNING at drivers/block/floppy.c:1041 saying something about floppy_disable_hlt() scheduled for removal. It seems that floppy access is normal. When attempting to mount /dev/fd0u1440 I get a null pointer oops, the mount command is killed, and I am unable to use the floppy drive again by /dev/fd0 or /dev/fd0u1440 until the machine is rebooted. Attached kernel log shows both kernel traces.
With 3.0.0-rc2 the situation is back to the previous state. I still get the WARN_ON bisected at comment #17. I no longer get the null pointer oops reported at #18.
Created attachment 61392 [details] Traces with parameter dump for blkdev_get and blkdev_put I have added a WARN at the beginning of blkdev_get and blkdev_put in order to show the trace for both functions, as well as the parameters they are receiving. The attached file shows the traces for the floppy block device. The last two traces in the file are the ones of the original bug report. Does this help?
Created attachment 61442 [details] claim-debug.patch Sorry about lack of response. Was traveling. Can you please apply the attached patch, trigger the problem and attach the full dmesg output? Thanks.
Created attachment 61532 [details] dmesg output after debugging patch claim-debug Done. dmesg attached.
Just in case, the sequence of commands that trigger the bug are: mount /dev/fd0u1440 /mnt/floppy/ sleep 1 df ls -l /mnt/floppy sleep 1 umount /mnt/floppy/
Created attachment 61632 [details] fix-claiming-for-floppy-aliases.patch Can you please test whether this patch fixes the problem? Thanks.
(In reply to comment #24) > Created an attachment (id=61632) [details] > fix-claiming-for-floppy-aliases.patch > > Can you please test whether this patch fixes the problem? > > Thanks. Yes, it does fix the problem. From the comment in the patch, I understand this is because the driver somehow allocates multiple block_device structs to represent the same drive. Is this correct? Is this, therefore, a bug in floppy.c , or should it be a valid case?
(In reply to comment #25) > Yes, it does fix the problem. Great. > From the comment in the patch, I understand this > is because the driver somehow allocates multiple block_device structs to > represent the same drive. Is this correct? Yes, more or less. > Is this, therefore, a bug in floppy.c , or should it be a valid case? I don't know. It's a peculiar thing which is somewhere between broken and too smart. O_EXCL open has always been broken at any rate. Given that it's on its way out, I think restoring it to the same level of breakage as before and letting it wither away is a reasonable approach. Thanks.
Patch posted. http://article.gmane.org/gmane.linux.kernel/1154214 Thanks.
Nice. Patch : http://article.gmane.org/gmane.linux.kernel/1154214
A patch referencing this bug report has been merged in v3.0-rc5: commit d4c208b86b8be4254eba0e74071496e599f94639 Author: Tejun Heo <tj@kernel.org> Date: Mon Jun 13 12:45:48 2011 +0200 block: use the passed in @bdev when claiming if partno is zero