Linux ext4 development ()

Torsten Hilbrich | 18 Jun 2012 07:59

Kernel 3.3.8 breaks accidental ext3 mount of extended partition

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 <at> redhat.com>
Date:   Fri May 11 16:34:10 2012 +0200

(Continue reading)

Jeff Moyer | 18 Jun 2012 21:03

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Torsten Hilbrich <torsten.hilbrich <at> secunet.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
>

(Continue reading)

Torsten Hilbrich | 19 Jun 2012 07:59

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 <at> secunet.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

(Continue reading)

Jeff Moyer | 19 Jun 2012 19:43

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Torsten Hilbrich <torsten.hilbrich <at> secunet.com> writes:

> 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

OK, got it to reproduce, thanks for the info.  The attached patch fixed
the problem for me.

Note, though, that the patch doesn't make sense to me.  blkdev_max_block

(Continue reading)

Torsten Hilbrich | 20 Jun 2012 08:14

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Am 19.06.2012 19:43, schrieb Jeff Moyer:

[...]

> diff --git a/fs/buffer.c b/fs/buffer.c
> index 838a9cf..769b30b 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
>  <at>  <at>  -930,7 +930,7  <at>  <at>  init_page_buffers(struct page *page, struct block_device *bdev,
>  			bh->b_blocknr = block;
>  			if (uptodate)
>  				set_buffer_uptodate(bh);
> -			if (block < end_block)
> +			if (block <= end_block)
>  				set_buffer_mapped(bh);
>  		}
>  		block++;

I can confirm that this patch fixes the problem for my test case too.
Here is the kernel output when performing the mount operation:

attempt to access beyond end of device
sda4: rw=0, want=4, limit=2
EXT3-fs (sda4): error: unable to read superblock

	Torsten

Jan Kara | 22 Jun 2012 02:12

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

On Tue 19-06-12 13:43:26, Jeff Moyer wrote:
> Torsten Hilbrich <torsten.hilbrich <at> secunet.com> writes:
> 
> > 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
> 
> OK, got it to reproduce, thanks for the info.  The attached patch fixed
> the problem for me.
>

(Continue reading)

Jeff Moyer | 22 Jun 2012 14:33

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Jan Kara <jack <at> suse.cz> writes:

>   I think it can have something to do with the fact that the partition size
> is not a multiple of 4k (i.e. expected block size)?

Ahh, yes.  Except that ext3 sets the blocksize to 1k by default.
However, I still can't explain why we don't get an error attempting to
access beyond the end of the device.  I'll keep digging on that.

>   BTW: blkdev_max_block() is a terrible name for something that intends to
> return size in blocks...

Fully agreed here, and I'll fix that up when I get my head completely
wrapped around this one.

Thanks for taking a look, Jan!

-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Marcos Mello | 20 Jun 2012 14:18

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Jeff Moyer <jmoyer <at> redhat.com> writes:

<snip>
> 
> 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?
> 

Probably the same problem:
http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Richard W.M. Jones | 25 Jun 2012 13:34

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

On Mon, Jun 18, 2012 at 07:59:30AM +0200, Torsten Hilbrich wrote:
> 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:

We just ran into what we think is the same problem.

Note that ext4 fails like this for any 1024 byte sized filesystem (of
zeroes) that you try to mount.  It's really nothing to do with
extended partitions.

Here is a very simple reproducer + stack trace:

  https://bugzilla.redhat.com/show_bug.cgi?id=835019#c4

I will try out the patch suggested later on in this thread.

Rich.

--

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org

(Continue reading)

Jeff Moyer | 25 Jun 2012 18:38

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

"Richard W.M. Jones" <rjones <at> redhat.com> writes:

> On Mon, Jun 18, 2012 at 07:59:30AM +0200, Torsten Hilbrich wrote:
>> 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:
>
> We just ran into what we think is the same problem.
>
> Note that ext4 fails like this for any 1024 byte sized filesystem (of
> zeroes) that you try to mount.  It's really nothing to do with
> extended partitions.
>
> Here is a very simple reproducer + stack trace:
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=835019#c4
>
> I will try out the patch suggested later on in this thread.

Please try the attached patch instead.  The patch I had originally
posted for this allowed marking the first buffer beyond EOD as
uptodate.  This isn't correct.  The patch I've attached below fixes the
infinite loop in __getblk_slow.

Cheers,
Jeff

(Continue reading)

Richard W.M. Jones | 25 Jun 2012 18:58

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

On Mon, Jun 25, 2012 at 12:38:03PM -0400, Jeff Moyer wrote:
> "Richard W.M. Jones" <rjones <at> redhat.com> writes:
> 
> > On Mon, Jun 18, 2012 at 07:59:30AM +0200, Torsten Hilbrich wrote:
> >> 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:
> >
> > We just ran into what we think is the same problem.
> >
> > Note that ext4 fails like this for any 1024 byte sized filesystem (of
> > zeroes) that you try to mount.  It's really nothing to do with
> > extended partitions.
> >
> > Here is a very simple reproducer + stack trace:
> >
> >   https://bugzilla.redhat.com/show_bug.cgi?id=835019#c4
> >
> > I will try out the patch suggested later on in this thread.
> 
> Please try the attached patch instead.  The patch I had originally
> posted for this allowed marking the first buffer beyond EOD as
> uptodate.  This isn't correct.  The patch I've attached below fixes the
> infinite loop in __getblk_slow.

Thanks Jeff.  I'm trying it now.

(Continue reading)

Richard W.M. Jones | 25 Jun 2012 21:32

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

On Mon, Jun 25, 2012 at 12:38:03PM -0400, Jeff Moyer wrote:
> Please try the attached patch instead.  The patch I had originally
> posted for this allowed marking the first buffer beyond EOD as
> uptodate.  This isn't correct.  The patch I've attached below fixes the
> infinite loop in __getblk_slow.

This patch appears to fix both problems, thanks.

Rich.

> Cheers,
> Jeff
> 
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 838a9cf..c7062c8 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
>  <at>  <at>  -1036,6 +1036,9  <at>  <at>  grow_buffers(struct block_device *bdev, sector_t block, int size)
>  static struct buffer_head *
>  __getblk_slow(struct block_device *bdev, sector_t block, int size)
>  {
> +	int ret;
> +	struct buffer_head *bh;
> +
>  	/* Size must be multiple of hard sectorsize */
>  	if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
>  			(size < 512 || size > PAGE_SIZE))) {
>  <at>  <at>  -1048,20 +1051,21  <at>  <at>  __getblk_slow(struct block_device *bdev, sector_t block, int size)
>  		return NULL;
>  	}

(Continue reading)

Jeff Moyer | 25 Jun 2012 22:04

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

"Richard W.M. Jones" <rjones <at> redhat.com> writes:

> On Mon, Jun 25, 2012 at 12:38:03PM -0400, Jeff Moyer wrote:
>> Please try the attached patch instead.  The patch I had originally
>> posted for this allowed marking the first buffer beyond EOD as
>> uptodate.  This isn't correct.  The patch I've attached below fixes the
>> infinite loop in __getblk_slow.
>
> This patch appears to fix both problems, thanks.

Thanks for testing, Rich!

-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Torsten Hilbrich | 26 Jun 2012 08:07

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Am 25.06.2012 18:38, schrieb Jeff Moyer:
> "Richard W.M. Jones" <rjones <at> redhat.com> writes:
> 
>> On Mon, Jun 18, 2012 at 07:59:30AM +0200, Torsten Hilbrich wrote:
>>> 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:
>>
>> We just ran into what we think is the same problem.
>>
>> Note that ext4 fails like this for any 1024 byte sized filesystem (of
>> zeroes) that you try to mount.  It's really nothing to do with
>> extended partitions.
>>
>> Here is a very simple reproducer + stack trace:
>>
>>   https://bugzilla.redhat.com/show_bug.cgi?id=835019#c4
>>
>> I will try out the patch suggested later on in this thread.
> 
> Please try the attached patch instead.  The patch I had originally
> posted for this allowed marking the first buffer beyond EOD as
> uptodate.  This isn't correct.  The patch I've attached below fixes the
> infinite loop in __getblk_slow.

This patch also fixes the ext3 mount problem on extented partition.

(Continue reading)

Jeff Moyer | 26 Jun 2012 15:02

Picon

Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Torsten Hilbrich <torsten.hilbrich <at> secunet.com> writes:

> Am 25.06.2012 18:38, schrieb Jeff Moyer:
>> "Richard W.M. Jones" <rjones <at> redhat.com> writes:
>> 
>>> On Mon, Jun 18, 2012 at 07:59:30AM +0200, Torsten Hilbrich wrote:
>>>> 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:
>>>
>>> We just ran into what we think is the same problem.
>>>
>>> Note that ext4 fails like this for any 1024 byte sized filesystem (of
>>> zeroes) that you try to mount.  It's really nothing to do with
>>> extended partitions.
>>>
>>> Here is a very simple reproducer + stack trace:
>>>
>>>   https://bugzilla.redhat.com/show_bug.cgi?id=835019#c4
>>>
>>> I will try out the patch suggested later on in this thread.
>> 
>> Please try the attached patch instead.  The patch I had originally
>> posted for this allowed marking the first buffer beyond EOD as
>> uptodate.  This isn't correct.  The patch I've attached below fixes the
>> infinite loop in __getblk_slow.
>

(Continue reading)

Return

Return to gmane.comp.file-systems.ext4.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane