From: sashiko-bot@kernel.org
To: "Mykola Marzhan" <mykola@meshstor.io>
Cc: linux-pci@vger.kernel.org, yukuai@fygo.io, linux-raid@vger.kernel.org
Subject: Re: [PATCH 3/6] md/raid1: don't use write-behind for P2PDMA bios
Date: Sat, 18 Jul 2026 16:58:37 +0000 [thread overview]
Message-ID: <20260718165838.6BC5F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260718162547.448892-4-mykola@meshstor.io>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] P2PDMA bios bypass write-behind but fail to serialize against outstanding write-behind I/O, leading to silent data corruption on write-mostly devices.
--
--- Patch [3]: [PATCH 3/6] md/raid1: don't use write-behind for P2PDMA bios ---
commit bbb98e00f3bb1bd5712cfce20170706425ddb589
Author: Mykola Marzhan <mykola@meshstor.io>
md/raid1: don't use write-behind for P2PDMA bios
alloc_behind_master_bio() copies the bio's data with bio_copy_data(),
a CPU copy. P2PDMA pages are peer device (BAR) memory; generic code
must not assume CPU load/store access to them is safe or fast on
every architecture, and bouncing peer memory through the CPU defeats
the point of a peer-to-peer transfer.
Skip write-behind for P2PDMA bios: they are written directly to all
members, including write-mostly ones.
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index afe2ca96ad8c2..57f64e8901024 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1575,9 +1575,12 @@ static bool raid1_write_request(struct mddev *mddev, struct bio *bio,
> /*
> * The write-behind io is only attempted on drives marked as
> * write-mostly, which means we could allocate write behind
> - * bio later.
> + * bio later. P2PDMA bios are excluded: write-behind copies
> + * the data with bio_copy_data(), a CPU copy that cannot be
> + * assumed safe or fast on P2PDMA (device BAR) pages.
> */
> - if (!is_discard && rdev && test_bit(WriteMostly, &rdev->flags))
> + if (!is_discard && rdev && test_bit(WriteMostly, &rdev->flags) &&
> + !md_bio_is_p2pdma(bio))
> write_behind = true;
>
[Severity: Critical]
This is a pre-existing issue, but by excluding P2PDMA bios from
write-behind, does this expose them to silent data corruption due to
missing serialization checks?
When a normal write to a sector uses write-behind, it can be acknowledged
to the caller once fast devices complete, leaving the write-behind bio
in-flight to the write-mostly device.
If a subsequent P2PDMA write is issued to the same sector, this patch
explicitly disables write-behind for it. Because of this,
r1_bio->behind_master_bio remains NULL, and execution falls into the else
branch further down in raid1_write_request():
drivers/md/raid1.c:raid1_write_request() {
...
if (r1_bio->behind_master_bio) {
mbio = bio_alloc_clone(rdev->bdev,
r1_bio->behind_master_bio,
GFP_NOIO, &mddev->bio_set);
if (test_bit(CollisionCheck, &rdev->flags))
wait_for_serialization(rdev, r1_bio);
...
} else {
mbio = bio_alloc_clone(rdev->bdev, bio, GFP_NOIO,
&mddev->bio_set);
if (test_bit(MD_SERIALIZE_POLICY, &mddev->flags))
wait_for_serialization(rdev, r1_bio);
}
...
}
Because the else branch skips the CollisionCheck test,
wait_for_serialization() is bypassed (unless MD_SERIALIZE_POLICY is globally
set). Can the block layer then reorder these concurrent requests, overwriting
the newer P2PDMA data with the older in-flight write-behind data?
> r1_bio->bios[i] = NULL;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718162547.448892-1-mykola@meshstor.io?part=3
next prev parent reply other threads:[~2026-07-18 16:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 16:25 [PATCH 0/6] block,md,nvme: correct handling of unsupported P2PDMA transfers Mykola Marzhan
2026-07-18 16:25 ` [PATCH 1/6] blk-mq-dma: restore BLK_STS_TARGET for unsupported P2P transfers Mykola Marzhan
2026-07-18 16:53 ` sashiko-bot
2026-07-18 16:25 ` [PATCH 2/6] md: ensure REQ_NOMERGE is set on P2PDMA bios Mykola Marzhan
2026-07-18 16:50 ` sashiko-bot
2026-07-18 16:25 ` [PATCH 3/6] md/raid1: don't use write-behind for " Mykola Marzhan
2026-07-18 16:58 ` sashiko-bot [this message]
2026-07-18 16:25 ` [PATCH 4/6] md/raid1,raid10: keep REQ_NOMERGE on narrow_write_error() retry clones Mykola Marzhan
2026-07-18 16:58 ` sashiko-bot
2026-07-18 16:25 ` [PATCH 5/6] md/raid1,raid10: skip futile retries on P2PDMA mapping failures Mykola Marzhan
2026-07-18 17:07 ` sashiko-bot
2026-07-18 16:25 ` [PATCH 6/6] nvme-rdma: return BLK_STS_TARGET for unsupported P2P transfers Mykola Marzhan
2026-07-18 17:12 ` sashiko-bot
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=20260718165838.6BC5F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=mykola@meshstor.io \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yukuai@fygo.io \
/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