Am 18.06.2012 21:03, schrieb Jeff Moyer: > Torsten Hilbrich writes: > >> Hello, >> >> a software that tries to mount each existing partition as ext3 file >> system started to fail when updating from v3.3.7 to v3.3.8. >> >> The applications then hangs-up in the mount syscall, here is a >> snapshot of its stack at this moment: >> >> [] __cond_resched+0x2a/0x40 >> [] __getblk+0x1bf/0x270 >> [] __bread+0x13/0xb0 >> [] ext3_fill_super+0x132/0x1b00 >> [] mount_bdev+0x1aa/0x1f0 >> [] ext3_mount+0x15/0x20 >> [] mount_fs+0x43/0x1a0 >> [] vfs_kern_mount+0x72/0x100 >> [] do_kern_mount+0x52/0x110 >> [] do_mount+0x25a/0x7d0 >> [] sys_mount+0x98/0xf0 >> [] system_call_fastpath+0x16/0x1b >> >> The expected behaviour (which was still there in v3.3.7) is that the >> mount syscall fails because the partition contains no valid ext3 file >> system. >> >> I have create more snapshot of the stack in the following pastebin: >> http://pastebin.com/99x9EpnM >> >> Using bisecting I found the following commit to be the cause of the issue: >> >> commit 3735b0a1d73af536484ddefef4d8438dd468c4a6 >> Author: Jeff Moyer >> Date: Fri May 11 16:34:10 2012 +0200 >> >> block: don't mark buffers beyond end of disk as mapped >> >> commit 080399aaaf3531f5b8761ec0ac30ff98891e8686 upstream. >> >> Reverting this commit brought back the desired behaviour of the mount >> syscall failing because of invalid superblock. >> >> It seems to be that ext3_fill_super is unable to read the super block >> because there is no blocked for an extended partition. >> >> The same issue can be found in v3.4, where the upstream commit >> (080399aa) was released. > > I am unable to reproduce this behaviour. Can you give more information > about your storage configuration? What is the partition layout, which > partition are you trying to mount, and are you using the standard mount > command to try to mount it? Is there anything else you can provide that > would help me reproduce the problem? The system where I reproduced the problem upstream is an amd64 based ubuntu 12.04 installation. I used both v3.3.8 and v3.4 for reproducing. The partition layout is the following: ====================================================================== Disk /dev/sda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x1669c708 Device Boot Start End Blocks Id System /dev/sda1 * 63 86285114 43142526 83 Linux /dev/sda2 216797175 234436544 8819685 82 Linux swap / Solaris /dev/sda3 86285115 87088364 401625 83 Linux /dev/sda4 87088426 216797174 64854374+ 5 Extended /dev/sda5 87088428 91104614 2008093+ 83 Linux /dev/sda6 91104678 216797174 62846248+ 8e Linux LVM Partition table entries are not in disk order ====================================================================== The extented partition is /dev/sda4 in this example. NOTE: The software which triggered the problem is really dumb, it tries to mount each block devices and assumes that any mount for a non-ext3 fs will simply fail. I perform the following steps to trigger the problem: - boot into the test kernel (with serial console and init=/bin/bash) - mount -o ro -t ext3 /dev/sda4 /mnt This mount call will hang up with stack traces shown above and in the pastebin entry. I will append the complete kernel configuration for the v3.4 build as attachment to this mail (kernel.config). I also attached the kernels log output (ext3-mount-bug.log). At the end of the log you will find the outputs of SysRq show-backtrace-all-active-cpus (line 665), show-blocked-tasks (line 744, which is empty), and show-task-states (line 746). Starting at line 1362 is the output for the mount command a few seconds after starting the command. I hope, these information help in identifying the problem. Torsten