| Message ID | x49r4t3z6s4.fsf@segfault.boston.devel.redhat.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Mon, Jun 25, 2012 at 12:38:03PM -0400, Jeff Moyer wrote: > "Richard W.M. Jones" <rjones@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. 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.
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 W.M. Jones" <rjones@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 25.06.2012 18:38, schrieb Jeff Moyer: > "Richard W.M. Jones" <rjones@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. Torsten -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Torsten Hilbrich <torsten.hilbrich@secunet.com> writes: > Am 25.06.2012 18:38, schrieb Jeff Moyer: >> "Richard W.M. Jones" <rjones@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. Great news, thanks for testing, guys! I'll follow up with another patch posting this morning. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; } /*