linux-kernel - Re: [PATCH 3/3] ext4: fix a potential assertion failure due to improperly dirtied buffer

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] [day] [month] [year] [list]

Message-ID: <CANubcdWgSxFzWWw9hOJTpEwE8ajLDC6bVGGqDBjQJs8iqqkTyQ@mail.gmail.com>
Date: Fri, 30 Aug 2024 10:03:10 +0800
From: Stephen Zhang <starzhangzsd@...il.com>
To: Jan Kara <jack@...e.cz>
Cc: tytso@....edu, adilger.kernel@...ger.ca, jack@...e.com, 
	ebiggers@...nel.org, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, 
	zhangshida@...inos.cn, Baolin Liu <liubaolin@...inos.cn>
Subject: Re: [PATCH 3/3] ext4: fix a potential assertion failure due to
 improperly dirtied buffer

Jan Kara <jack@...e.cz> 于2024年8月29日周四 17:30写道：
>
> On Thu 29-08-24 16:54:07, zhangshida wrote:
> > From: Shida Zhang <zhangshida@...inos.cn>
> >
> > On an old kernel version(4.19, ext3, data=journal, pagesize=64k),
> > an assertion failure will occasionally be triggered by the line below:
> > -----------
> > jbd2_journal_commit_transaction
> > {
> > ...
> > J_ASSERT_BH(bh, !buffer_dirty(bh));
> > /*
> > * The buffer on BJ_Forget list and not jbddirty means
> > ...
> > }
> > -----------
> >
> > The same condition may also be applied to the lattest kernel version.
> >
> > When blocksize < pagesize and we truncate a file, there can be buffers in
> > the mapping tail page beyond i_size. These buffers will be filed to
> > transaction's BJ_Forget list by ext4_journalled_invalidatepage() during
> > truncation. When the transaction doing truncate starts committing, we can
> > grow the file again. This calls __block_write_begin() which allocates new
> > blocks under these buffers in the tail page we go through the branch:
> >
> >                         if (buffer_new(bh)) {
> >                                 clean_bdev_bh_alias(bh);
> >                                 if (folio_test_uptodate(folio)) {
> >                                         clear_buffer_new(bh);
> >                                         set_buffer_uptodate(bh);
> >                                         mark_buffer_dirty(bh);
> >                                         continue;
> >                                 }
> >                                 ...
> >                         }
> >
> > Hence buffers on BJ_Forget list of the committing transaction get marked
> > dirty and this triggers the jbd2 assertion.
> >
> > Teach ext4_block_write_begin() to properly handle files with data
> > journalling by avoiding dirtying them directly. Instead of
> > folio_zero_new_buffers() we use ext4_journalled_zero_new_buffers() which
> > takes care of handling journalling. We also don't need to mark new uptodate
> > buffers as dirty in ext4_block_write_begin(). That will be either done
> > either by block_commit_write() in case of success or by
> > folio_zero_new_buffers() in case of failure.
> >
> > Reported-by: Baolin Liu <liubaolin@...inos.cn>
> > Suggested-by: Jan Kara <jack@...e.cz>
> > Signed-off-by: Shida Zhang <zhangshida@...inos.cn>
>
> One small comment below but regardless whether you decide to address it or
> not, feel free to add:
>
> Reviewed-by: Jan Kara <jack@...e.cz>
>
> > @@ -1083,11 +1090,22 @@ int ext4_block_write_begin(struct folio *folio, loff_t pos, unsigned len,
> >                       err = get_block(inode, block, bh, 1);
> >                       if (err)
> >                               break;
> > +                     /*
> > +                      * We may be zeroing partial buffers or all new
> > +                      * buffers in case of failure. Prepare JBD2 for
> > +                      * that.
> > +                      */
> > +                     if (should_journal_data)
> > +                             do_journal_get_write_access(handle, inode, bh);
>
> Thanks for adding comments! I also mentioned this hunk can be moved inside
> the if (buffer_new(bh)) check below to make it more obvious that this is
> indeed about handling of newly allocated buffers. But this is just a nit
> and the comment explains is well enough so I don't insist.
>

Feel free to tell me if you have other issues/nits/ideas.
Because even with your detailed explanation, I may take it in a wrong way. :p

And Thanks for your patience.

-Stephen

> >                       if (buffer_new(bh)) {
> >                               if (folio_test_uptodate(folio)) {
> > -                                     clear_buffer_new(bh);
> > +                                     /*
> > +                                      * Unlike __block_write_begin() we leave
> > +                                      * dirtying of new uptodate buffers to
> > +                                      * ->write_end() time or
> > +                                      * folio_zero_new_buffers().
> > +                                      */
> >                                       set_buffer_uptodate(bh);
> > -                                     mark_buffer_dirty(bh);
> >                                       continue;
> >                               }
> >                               if (block_end > to || block_start < from)
>
> Thanks!
>
>                                                                 Honza
>
> --
> Jan Kara <jack@...e.com>
> SUSE Labs, CR