[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FE0155A.6010404@secunet.com>
Date: Tue, 19 Jun 2012 07:59:54 +0200
From: Torsten Hilbrich <torsten.hilbrich@...unet.com>
To: Jeff Moyer <jmoyer@...hat.com>
CC: linux-ext4@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition
Am 18.06.2012 21:03, schrieb Jeff Moyer:
> Torsten Hilbrich <torsten.hilbrich@...unet.com> 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:
>>
>> [<ffffffff81060c6a>] __cond_resched+0x2a/0x40
>> [<ffffffff81134b3f>] __getblk+0x1bf/0x270
>> [<ffffffff811362b3>] __bread+0x13/0xb0
>> [<ffffffff81182222>] ext3_fill_super+0x132/0x1b00
>> [<ffffffff8110891a>] mount_bdev+0x1aa/0x1f0
>> [<ffffffff8117ffc5>] ext3_mount+0x15/0x20
>> [<ffffffff81107fc3>] mount_fs+0x43/0x1a0
>> [<ffffffff81123102>] vfs_kern_mount+0x72/0x100
>> [<ffffffff81123882>] do_kern_mount+0x52/0x110
>> [<ffffffff8112519a>] do_mount+0x25a/0x7d0
>> [<ffffffff811257a8>] sys_mount+0x98/0xf0
>> [<ffffffff814f3e92>] 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 <jmoyer@...hat.com>
>> 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
View attachment "kernel.config" of type "text/plain" (89323 bytes)
View attachment "ext3-mount-bug.log" of type "text/x-log" (72020 bytes)
Powered by blists - more mailing lists