From: "Shengzhuo Wei" <me@cherr.cc>
To: "liubaolin" <liubaolin12138@163.com>
Cc: "Shengzhuo Wei" <me@cherr.cc>,
"Namjae Jeon" <linkinjeon@kernel.org>,
"Hyunchul Lee" <hyc.lee@gmail.com>, <ntfs@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
<stable@vger.kernel.org>
Subject: Re: [PATCH] ntfs: wait for bitmap folio writeback before modifying it
Date: Thu, 29 Oct 2026 14:17:56 +0800 [thread overview]
Message-ID: <auLlFEHMZvANXUvU@kernel> (raw)
In-Reply-To: <374bf856-f880-4fa2-abec-c4b2a063bf57@163.com>
On 2026-10-29 10:07, liubaolin wrote:
> Hi Shengzhuo,
> Could this deadlock during MFT bitmap
> expansion?ntfs_mft_bitmap_extend_allocation_nolock() can recurse into MFT
> record allocation while holding mftbmp_ni->runlist.lock.
>
> With L being that lock, could we get the following interleaving?
> A and B are $MFT::$BITMAP folios; B is outside the cached iomap.
> Time flows downwards.
>
> Writeback Bitmap expansion
> --------- ----------------
> lock A
> set PG_writeback(A)
> map A (take/release L)
> add A to wpc->wb_ctx
> unlock A
> [BIO still unsubmitted]
> take L
> extend bitmap mapping pairs
> need another extent record
> ntfs_mft_record_alloc()
> mft_bitmap_alloc_free_rec()
> lock A
> folio_wait_writeback(A)
> [wait for A's I/O, holding L]
>
> lock B
> set PG_writeback(B)
> ntfs_writeback_range(B)
> __ntfs_write_iomap_begin()
> down_write(L)
> [blocked on L]
>
> Cannot reach iomap_add_to_ioend()
> to submit A's pending BIO. Cannot release L until
> A's writeback completes.
>
> ntfs_writeback_range() obtains the next mapping before
> iomap_add_to_ioend() can submit the pending BIO.
> Would we need to submit that BIO before taking the mapping locks?
>
> Thanks,
> Baolin.
>
Hi Baolin,
Thanks for the analysis. I checked the paths and agree with you.
Following your suggestion, I prepared a change to submit the pending
ioend before obtaining a new mapping in ntfs_writeback_range(), clearing
wpc->wb_ctx even on error to avoid resubmission. I plan to make this a
prerequisite for v2, retaining all six waits.
One concern is that submitting at mapping boundaries may reduce BIO
aggregation, including for ordinary file writeback. The change has
passed object builds, but has not been runtime- or performance-tested.
Does this approach look reasonable to you?
Thanks,
Shengzhuo
next prev parent reply other threads:[~2026-10-29 6:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 20:09 Shengzhuo Wei
2026-10-29 2:07 ` liubaolin
2026-10-29 6:17 ` Shengzhuo Wei [this message]
2026-10-29 7:12 ` liubaolin
2026-10-30 2:57 ` Hyunchul Lee
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=auLlFEHMZvANXUvU@kernel \
--to=me@cherr.cc \
--cc=hyc.lee@gmail.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liubaolin12138@163.com \
--cc=ntfs@lists.linux.dev \
--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
all inboxes | Powered by JetHome®