linux-kernel - Re: PROBLEM: ext4 resize2fs on-line resizing panic

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: Mon, 24 Jun 2024 11:26:58 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Alexander Coffin <alex.coffin@...icrobots.com>
Cc: Jan Kara <jack@...e.com>, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: ext4 resize2fs on-line resizing panic

On Sun, Jun 23, 2024 at 06:57:13PM -0700, Alexander Coffin wrote:
> [1.] One line summary of the problem:
> Using resize2fs on-line resizing on a specific ext4 partition is
> causing an Oops.
> 
> 
> [6.] Output of Oops.. message (if applicable) with symbolic information
>      resolved (see Documentation/admin-guide/bug-hunting.rst)
> 
> ```
> [  445.552287] ------------[ cut here ]------------
> [  445.552300] kernel BUG at fs/jbd2/journal.c:846!

Thanks for the bug report.  The BUG_ON is from the following assert in
jbd2_journal_next_log_block:

	J_ASSERT(journal->j_free > 1);

and it indicates that we ran out of space in the journal.  There are
mechanisms to make sure that this should never happen, and if the
journal is too small and the transaction couldn't be broken up, then
the operation (whether it is a resize or a file truncate or some other
operation) should have errored out, and not triggered a BUG.

We'll need to investigate further how to address this, but a
short-term workaround is to simply to make the journal size larger.
It looks like this is a very small file system, and so mke2fs will by
default use a smaller journal so that the overhead of the journal
doesn't overwhelm the usuable space for that small file system.  This
can result in a performance degredation, but that was considered an
acceptable tradeoff rather than users getting annoyed that there very
small file system had an unaccepted file system overhead of say, 75%
of the usable space.  Very often these small file systems was on
crapola devices such as USB thumb drives, where performance was going
to be a diaster anyway.  :-)

In practice, people have generally not tried to resize small file
systems like this, which is why we hadn't run into this situation
earlier.

Cheers,

					- Ted