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]
Message-ID: <87ikx5trb4.fsf@linux.dev>
Date: Tue, 16 Jul 2024 14:11:27 +0100
From: Luis Henriques <luis.henriques@...ux.dev>
To: Jan Kara <jack@...e.cz>
Cc: Andreas Dilger <adilger@...ger.ca>,  Wang Jianjian
 <wangjianjian0@...mail.com>,  "wangjianjian (C)"
 <wangjianjian3@...wei.com>,  Theodore Ts'o <tytso@....edu>,  Harshad
 Shirwadkar <harshadshirwadkar@...il.com>,  linux-ext4@...r.kernel.org,
  linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] jbd2: make '0' an invalid transaction sequence

On Tue, Jul 16 2024, Jan Kara wrote:

> On Fri 12-07-24 10:53:02, Luis Henriques wrote:
>> Since there's code (in fast-commit) that already handles a '0' tid as a
>> special case, it's better to ensure that jbd2 never sets it to that value
>> when journal->j_transaction_sequence increment wraps.
>> 
>> Suggested-by: Andreas Dilger <adilger@...ger.ca>
>> Signed-off-by: Luis Henriques (SUSE) <luis.henriques@...ux.dev>
>
> Well, sadly it isn't so simple. If nothing else, journal replay
> (do_one_pass()) will get broken by the skipped tid as we do check:
>
>                 if (sequence != next_commit_ID) {
>                         brelse(bh);
>                         break;
>                 }
>
> So we'd abort journal replay too early. Secondly, there's also code
> handling journal replay in libext2fs which would need to be checked and
> fixed up. Finally, I've found code in mballoc which alternates between two
> lists based on tid & 1, so this logic would get broken by skipping 0 tid
> as well.
>
> Overall, I think we might be better off to go and fix places that assume
> tid 0 is not valid. I can see those assumptions in:
>
> ext4_fc_mark_ineligible()
> ext4_wait_for_tail_page_commit()
> __jbd2_log_wait_for_space()
> jbd2_journal_shrink_checkpoint_list()
>
> Now I don't see it as urgent to fix all these right now. Just for this
> series let's not add another place making tid 0 special. Later we can fixup
> the other places...

Yikes!  Looks like I haven't done my homework -- I should have caught at
least one of the three breakages you point out.  Obviously, because I've
seen this assumption in different places, I thought it would be OK.

Anyway, thanks a lot for point this out, Jan.  I'll add a new TODO to my
list to start looking at other places that need to be fixed.

Cheers,
-- 
Luís

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ