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 <[email protected]>
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.
This problem was found and debugged with an amd64 build of the linux kernel. The native ext3 support was used:
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
I will rewrite the application causing this issue to check the file system type before trying to mount the partition to work around this problem for now.
Torsten
Torsten Hilbrich <[email protected]> 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 <[email protected]>
> 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?
Thanks,
Jeff
Am 18.06.2012 21:03, schrieb Jeff Moyer:
> Torsten Hilbrich <[email protected]> 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 <[email protected]>
>> 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
Torsten Hilbrich <[email protected]> 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
returns i_size_read(blkdev_inode) >> block_size. This should be the
*size* of the block device, not the max block. The code in
fs/block_device.c uses the return value in two different ways!
static int
blkdev_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh, int create)
{
if (iblock >= blkdev_max_block(I_BDEV(inode))) {
Here, the return value from blkdev_max_block is interpreted as the size
of the device, so actually max_block + 1.
static int
blkdev_get_blocks(struct inode *inode, sector_t iblock,
struct buffer_head *bh, int create)
{
sector_t end_block = blkdev_max_block(I_BDEV(inode));
unsigned long max_blocks = bh->b_size >> inode->i_blkbits;
if ((iblock + max_blocks) > end_block) {
Here, the return value is treated as the maximum addressable block
number. Given the fact that I had to modify init_page_buffers to treat
the return value from blkdev_max_block as the maximum addressable block,
I clearly have something wrong with my logic. Nick, Jens, care to set
my head straight?
Cheers,
Jeff
diff --git a/fs/buffer.c b/fs/buffer.c
index 838a9cf..769b30b 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -930,7 +930,7 @@ 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++;
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
> @@ -930,7 +930,7 @@ 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
On Tue 19-06-12 13:43:26, Jeff Moyer wrote:
> Torsten Hilbrich <[email protected]> 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
> returns i_size_read(blkdev_inode) >> block_size. This should be the
> *size* of the block device, not the max block. The code in
> fs/block_device.c uses the return value in two different ways!
>
> static int
> blkdev_get_block(struct inode *inode, sector_t iblock,
> struct buffer_head *bh, int create)
> {
> if (iblock >= blkdev_max_block(I_BDEV(inode))) {
>
> Here, the return value from blkdev_max_block is interpreted as the size
> of the device, so actually max_block + 1.
>
> static int
> blkdev_get_blocks(struct inode *inode, sector_t iblock,
> struct buffer_head *bh, int create)
> {
> sector_t end_block = blkdev_max_block(I_BDEV(inode));
> unsigned long max_blocks = bh->b_size >> inode->i_blkbits;
>
> if ((iblock + max_blocks) > end_block) {
>
> Here, the return value is treated as the maximum addressable block
> number. Given the fact that I had to modify init_page_buffers to treat
> the return value from blkdev_max_block as the maximum addressable block,
> I clearly have something wrong with my logic. Nick, Jens, care to set
> my head straight?
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)?
BTW: blkdev_max_block() is a terrible name for something that intends to
return size in blocks...
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Jan Kara <[email protected]> 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
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
"Richard W.M. Jones" <[email protected]> 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
diff --git a/fs/buffer.c b/fs/buffer.c
index 838a9cf..c7062c8 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1036,6 +1036,9 @@ 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))) {
@@ -1048,20 +1051,21 @@ __getblk_slow(struct block_device *bdev, sector_t block, int size)
return NULL;
}
- for (;;) {
- struct buffer_head * bh;
- int ret;
+retry:
+ bh = __find_get_block(bdev, block, size);
+ if (bh)
+ return bh;
+ ret = grow_buffers(bdev, block, size);
+ if (ret == 0) {
+ free_more_memory();
+ goto retry;
+ } else if (ret > 0) {
bh = __find_get_block(bdev, block, size);
if (bh)
return bh;
-
- ret = grow_buffers(bdev, block, size);
- if (ret < 0)
- return NULL;
- if (ret == 0)
- free_more_memory();
}
+ return NULL;
}
/*
On Mon, Jun 25, 2012 at 12:38:03PM -0400, Jeff Moyer wrote:
> "Richard W.M. Jones" <[email protected]> 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.
We also found a related bug in isofs:
https://bugzilla.redhat.com/show_bug.cgi?id=835084
So I will check whether your patches fixes that one too.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
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
> @@ -1036,6 +1036,9 @@ 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))) {
> @@ -1048,20 +1051,21 @@ __getblk_slow(struct block_device *bdev, sector_t block, int size)
> return NULL;
> }
>
> - for (;;) {
> - struct buffer_head * bh;
> - int ret;
> +retry:
> + bh = __find_get_block(bdev, block, size);
> + if (bh)
> + return bh;
>
> + ret = grow_buffers(bdev, block, size);
> + if (ret == 0) {
> + free_more_memory();
> + goto retry;
> + } else if (ret > 0) {
> bh = __find_get_block(bdev, block, size);
> if (bh)
> return bh;
> -
> - ret = grow_buffers(bdev, block, size);
> - if (ret < 0)
> - return NULL;
> - if (ret == 0)
> - free_more_memory();
> }
> + return NULL;
> }
>
> /*
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
"Richard W.M. Jones" <[email protected]> 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
Am 25.06.2012 18:38, schrieb Jeff Moyer:
> "Richard W.M. Jones" <[email protected]> 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.
Torsten
Torsten Hilbrich <[email protected]> writes:
> Am 25.06.2012 18:38, schrieb Jeff Moyer:
>> "Richard W.M. Jones" <[email protected]> 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.
Great news, thanks for testing, guys! I'll follow up with another patch
posting this morning.
Cheers,
Jeff