Bug 28522 - Unable to mount FAT-formatted floppy on /dev/fd0, plus WARN_ON when using /dev/fd0u1440
Summary: Unable to mount FAT-formatted floppy on /dev/fd0, plus WARN_ON when using /de...
Status: CLOSED CODE_FIX
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Block Layer (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Jens Axboe
URL:
Keywords:
Depends on:
Blocks: 27352
  Show dependency tree
 
Reported: 2011-02-07 17:21 UTC by Alex Villacis Lasso
Modified: 2011-06-28 07:54 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.37-rc3
Tree: Mainline
Regression: Yes


Attachments
Full dmesg output with oopses on floppy use (60.81 KB, text/plain)
2011-02-07 17:21 UTC, Alex Villacis Lasso
Details
Kernel configuration used to compile affected kernel (112.32 KB, text/plain)
2011-02-07 17:22 UTC, Alex Villacis Lasso
Details
Full contents of /etc/fstab file (1.06 KB, text/plain)
2011-02-07 17:22 UTC, Alex Villacis Lasso
Details
Kernel message log for linux-3.0.0-rc1 (72.47 KB, text/plain)
2011-06-01 17:05 UTC, Alex Villacis Lasso
Details
Traces with parameter dump for blkdev_get and blkdev_put (10.77 KB, text/plain)
2011-06-10 04:21 UTC, Alex Villacis Lasso
Details
claim-debug.patch (1.49 KB, patch)
2011-06-10 10:12 UTC, Tejun Heo
Details | Diff
dmesg output after debugging patch claim-debug (86.11 KB, text/plain)
2011-06-11 01:49 UTC, Alex Villacis Lasso
Details
fix-claiming-for-floppy-aliases.patch (784 bytes, patch)
2011-06-12 09:49 UTC, Tejun Heo
Details | Diff

Description Alex Villacis Lasso 2011-02-07 17:21:41 UTC
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.
Comment 1 Alex Villacis Lasso 2011-02-07 17:22:21 UTC
Created attachment 46732 [details]
Kernel configuration used to compile affected kernel
Comment 2 Alex Villacis Lasso 2011-02-07 17:22:45 UTC
Created attachment 46742 [details]
Full contents of /etc/fstab file
Comment 3 Alex Villacis Lasso 2011-02-07 17:23:57 UTC
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
Comment 4 Andrew Morton 2011-02-07 23:19:11 UTC
(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.
Comment 5 Andrew Morton 2011-02-07 23:19:59 UTC
(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.
Comment 6 Anonymous Emailer 2011-02-08 01:00:59 UTC
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.
Comment 7 Anonymous Emailer 2011-02-08 21:25:38 UTC
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.
Comment 8 Tejun Heo 2011-02-09 09:38:34 UTC
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.
Comment 9 Tejun Heo 2011-02-09 09:54:00 UTC
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.
Comment 10 Anonymous Emailer 2011-02-10 15:28:43 UTC
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.
Comment 11 Rafael J. Wysocki 2011-02-14 22:20:35 UTC
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.
Comment 12 Alex Villacis Lasso 2011-03-15 15:36:59 UTC
Still present in 2.6.38-rc8.
Comment 13 Alex Villacis Lasso 2011-04-01 17:41:24 UTC
Still present in 2.6.39-rc1
Comment 14 Rafael J. Wysocki 2011-04-20 20:32:58 UTC
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.
Comment 15 Alex Villacis Lasso 2011-05-25 15:22:25 UTC
Still present in 2.6.39.
Comment 16 Anonymous Emailer 2011-05-26 23:34:18 UTC
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.
Comment 17 Anonymous Emailer 2011-05-31 16:25:05 UTC
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
Comment 18 Alex Villacis Lasso 2011-06-01 17:05:09 UTC
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.
Comment 19 Alex Villacis Lasso 2011-06-08 01:35:11 UTC
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.
Comment 20 Alex Villacis Lasso 2011-06-10 04:21:23 UTC
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?
Comment 21 Tejun Heo 2011-06-10 10:12:26 UTC
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.
Comment 22 Alex Villacis Lasso 2011-06-11 01:49:09 UTC
Created attachment 61532 [details]
dmesg output after debugging patch claim-debug

Done. dmesg attached.
Comment 23 Alex Villacis Lasso 2011-06-11 02:50:32 UTC
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/
Comment 24 Tejun Heo 2011-06-12 09:49:28 UTC
Created attachment 61632 [details]
fix-claiming-for-floppy-aliases.patch

Can you please test whether this patch fixes the problem?

Thanks.
Comment 25 Alex Villacis Lasso 2011-06-13 01:03:14 UTC
(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?
Comment 26 Tejun Heo 2011-06-13 10:29:08 UTC
(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.
Comment 27 Tejun Heo 2011-06-13 10:45:40 UTC
Patch posted.

  http://article.gmane.org/gmane.linux.kernel/1154214

Thanks.
Comment 28 Florian Mickler 2011-06-13 19:54:58 UTC
Nice. 

Patch : http://article.gmane.org/gmane.linux.kernel/1154214
Comment 29 Florian Mickler 2011-06-28 07:51:15 UTC
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

Note You need to log in before you can comment on or make changes to this bug.