Re: [PATCH v3 17/21] md/raid10: split reshape bios before bitmap accounting
[email protected] Tue, 28 Jul 2026 09:15:40 +0000
| Newsgroups | org.kernel.vger.linux-raid |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Missing `md_write_end()` when `mddev_bio_split_at_reshape_offset()` fails on a write bio, leaking `mddev->writes_pending` reference count. - [High] Mempool exhaustion deadlock due to double bio allocation from `conf->bio_split` without a rescuer thread. -- --- Patch [17]: [PATCH v3 17/21] md/raid10: split reshape bios before bitmap accounting --- commit f435d38ffb898e662e1e9b6225ad90d266d26363 Author: Yu Kuai <[email protected]> md/raid10: split reshape bios before bitmap accounting This patch updates raid10 to use the shared mddev_bio_split_at_reshape_offset() helper. This ensures that RAID10 submits only one-side bios to llbitmap during reshape operations. > diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c > index e50e4adee389f..fd364a2e2fd98 100644 > --- a/drivers/md/raid10.c > +++ b/drivers/md/raid10.c > @@ -1911,6 +1911,12 @@ static bool raid10_make_request(struct mddev *mddev, struct bio *bio) > sectors = chunk_sects - > (bio->bi_iter.bi_sector & > (chunk_sects - 1)); > + > + bio = mddev_bio_split_at_reshape_offset(mddev, bio, §ors, > + &conf->bio_split); [Severity: High] Could this lead to a mempool exhaustion deadlock if bad blocks are present? This splits the bio using conf->bio_split, and passes the split bio down to __make_request(). If there are bad blocks that restrict the sector count further, the lower level routines perform a second split using the exact same bio_set: drivers/md/raid10.c:raid10_write_request() { ... bio = bio_submit_split_bioset(bio, r10_bio->sectors, &conf->bio_split); ... } Since conf->bio_split lacks a rescuer thread, would two concurrent I/Os that both cross a chunk boundary and hit a bad block exhaust the pool and stall indefinitely? > + if (!bio) > + return true; [Severity: High] Does this early return leak the mddev->writes_pending reference? Earlier in raid10_make_request(), we call md_write_start() which increments the writes_pending count for write bios: drivers/md/raid10.c:raid10_make_request() { ... md_write_start(mddev, bio); ... } If the bio is an atomic write that cannot be split, mddev_bio_split_at_reshape_offset() returns NULL. When we return true here, we bypass the md_write_end() cleanup at the end of the function, which might hang the array when it is later suspended or stopped. > + > if (!__make_request(mddev, bio, sectors)) > md_write_end(mddev); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=17