linux-ext4 - Re: kernel bug at fs/ext4/resize.c:409

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Feb 2014 09:53:23 -0500
From:	Jon Bernard <jbernard@...ion.com>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	linux-ext4@...r.kernel.org, Theodore Ts'o <tytso@....edu>
Subject: Re: kernel bug at fs/ext4/resize.c:409

* Dmitry Monakhov <dmonakhov@...nvz.org> wrote:
> On Thu, 6 Feb 2014 16:08:44 -0500, Jon Bernard <jbernard@...ion.com> wrote:
> Non-text part: multipart/mixed
> > * Theodore Ts'o <tytso@....edu> wrote:
> > > On Mon, Feb 03, 2014 at 01:26:34PM -0500, Jon Bernard wrote:
> > > > Hello all,
> > > > 
> > > > A coworker is seeing the following bug when attempting to resize a root
> > > > volume (during init by calling resizefs) from 1GB to the size of the
> > > > underlying partition size of 20GB.
> > > > 
> > > > If the partition size is changed (to i.e. 10GB), the bug seems to not
> > > > trigger.  I have access to this machine, if there are any experiments
> > > > that would provide more useful information - please let me know.
> > > 
> > > Here are three questions to start:
> > > 
> > > 1)  What kernel version was this oops coming from?
> > 
> > 3.12.9-301.fc20.x86_64
> > 
> > > 2)  Could you please send me the output of dumpe2fs of the file system?
> > 
> > Dump attached.
> > 
> > > 3)  Can you reproduce the problem?
> > 
> > It happens every time with this particular filesystem image.  A new
> > image built with slightly different variables (size, contents, etc)
> > usually yields a filesystem that behaves correctly.  But once they have
> > a bad one, it breaks on resize every time.
> > 
> > Let me know if I can provide any other information.  I have access to
> > the machine for some time, so I can run a modified kernel or module and
> > post results if that would help.
> > 
> > Thanks,
> > 
> Yepp..  same BUGON was recently triggered by one of our customers
> on ovzkernel kernel which is based on RHEL6's (2.6.32) kernel:
> Resize the image /vz/private/2345.private_temporary-XXXX/root.hdd to
> 536870912K
> resize2fs 1.42.3 (14-May-2012)
> Filesystem at /dev/ploop15153p1 is mounted on
> /vz/private/2345.private_temporary-XXXX/root.hdd/root.hds.mnt; on-line
> resizing required
> old_desc_blocks = 1, new_desc_blocks = 32
> <4>[ 1043.647040] ------------[ cut here ]------------
> <2>[ 1043.647067] kernel BUG at fs/ext4/resize.c:375!
> 
> But after that image was destroyed, and we can not reproduce this bug at
> the moment.
> 
> Can you please share image created via e2image and blkimage size:
> #e2image -r /dev/$YOUR_DEV - | bzip2 > img.e2i.bz2
> #blockdev --getsz /dev/$YOUR_DEV
> and resize2fs arguments.

The image should be available here:

http://c5a6e06e970802d5126f-8c6b900f6923cc24b844c506080778ec.r72.cf1.rackcdn.com/fedora_resize_fails.qcow2

The md5sum is: 267fd37e3a5e1c4d50bd133dd2835c98

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