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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 13 Feb 2014 16:18:31 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>, linux-ext4@...r.kernel.org
Subject: Re: kernel bug at fs/ext4/resize.c:409

On Thu, Feb 13, 2014 at 09:53:23AM -0500, Jon Bernard wrote:
> The image should be available here:
> 
> http://c5a6e06e970802d5126f-8c6b900f6923cc24b844c506080778ec.r72.cf1.rackcdn.com/fedora_resize_fails.qcow2

Thanks for the image.  I've been able to reproduce the problem, and
it's caused by the fact that the inode table is so large that it's
overflowing into a subsequent block group, and the resize code isn't
handling this.  Fixing this may be a bit tricky, since the flex_bg
online resize code is a big ugly at the moment, and needs some clean
up so this can be fixed properly.

Until that can be done --- one question: was there a deliberate reason
why the file system was created with parameters which allocate 32,752
inodes per block group?  That means that a bit over 8 megabytes of
inode table are being reserved for every 128 megabyte (32768 4k
blocks) block group, and that you have more inodes reserved than could
be used if the average file size is 4k or less.  In fact, the only way
you could run out of inodes is if you had huge numbers of devices,
sockets, small symlinks, or zero-length files in your file system.
This seems to be a bit of a waste of space, in all liklihood.

Don't get me wrong; we should be able to handle this case correctly,
and not trigger a BUG_ON, but this is why most people aren't seeing
this particular fault --- it requires a far greater number of inodes
than mke2fs would ever create by default, or that most system
administrators would try to deliberately specify, when creating the
file system.

I'll look and see what's the best way to fix up fs/ext4/resize.c in
the kernel.

Regards,

						- Ted
--
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