From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: stable@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 4.19 5.4 5.10 5.15 6.1 6.6 6.7] nilfs2: fix potential bug in end_buffer_async_write
Date: Wed, 21 Feb 2024 09:48:21 +0100 [thread overview]
Message-ID: <2024022113-gong-underdone-ac9c@gregkh> (raw)
In-Reply-To: <20240220212928.5611-1-konishi.ryusuke@gmail.com>
On Wed, Feb 21, 2024 at 06:29:28AM +0900, Ryusuke Konishi wrote:
> commit 5bc09b397cbf1221f8a8aacb1152650c9195b02b upstream.
>
> According to a syzbot report, end_buffer_async_write(), which handles the
> completion of block device writes, may detect abnormal condition of the
> buffer async_write flag and cause a BUG_ON failure when using nilfs2.
>
> Nilfs2 itself does not use end_buffer_async_write(). But, the async_write
> flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
> with race condition of competition between segments for dirty blocks") as
> a means of resolving double list insertion of dirty blocks in
> nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
> resulting crash.
>
> This modification is safe as long as it is used for file data and b-tree
> node blocks where the page caches are independent. However, it was
> irrelevant and redundant to also introduce async_write for segment summary
> and super root blocks that share buffers with the backing device. This
> led to the possibility that the BUG_ON check in end_buffer_async_write
> would fail as described above, if independent writebacks of the backing
> device occurred in parallel.
>
> The use of async_write for segment summary buffers has already been
> removed in a previous change.
>
> Fix this issue by removing the manipulation of the async_write flag for
> the remaining super root block buffer.
>
> Link: https://lkml.kernel.org/r/20240203161645.4992-1-konishi.ryusuke@gmail.com
> Fixes: 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks")
> Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
> Reported-by: syzbot+5c04210f7c7f897c1e7f@syzkaller.appspotmail.com
> Closes: https://lkml.kernel.org/r/00000000000019a97c05fd42f8c8@google.com
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Now queued up, thanks.
greg k-h
prev parent reply other threads:[~2024-02-21 8:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 21:29 [PATCH 4.19 5.4 5.10 5.15 6.1 6.6 6.7] nilfs2: fix potential bug in end_buffer_async_write Ryusuke Konishi
2024-02-21 8:48 ` Greg Kroah-Hartman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2024022113-gong-underdone-ac9c@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=konishi.ryusuke@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox