All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mykola Marzhan" <mykola@meshstor.io>
Cc: linux-raid@vger.kernel.org, yukuai@fygo.io, linux-pci@vger.kernel.org
Subject: Re: [PATCH v6 06/12] md/raid1,raid10: keep REQ_NOMERGE on narrow_write_error() retry clones
Date: Sun, 26 Jul 2026 12:09:02 +0000	[thread overview]
Message-ID: <20260726120903.67B291F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260726113229.2154269-7-mykola@meshstor.io>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unconditional assignment to `wbio->bi_opf` destroys all request flags cloned from the master bio, leading to potential data corruption.
--

--- Patch [6]: [PATCH v6 06/12] md/raid1,raid10: keep REQ_NOMERGE on narrow_write_error() retry clones ---
commit 333e1430f8770afc53cf111be8c36899e6c4c5e3
Author: Mykola Marzhan <mykola@meshstor.io>

md/raid1,raid10: keep REQ_NOMERGE on narrow_write_error() retry clones

This commit restores REQ_NOMERGE on P2PDMA retry clones in
narrow_write_error() to prevent member queues from improperly merging
segments.

> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index f07edeac6e5a3..19c4dec450de0 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
[ ... ]
> @@ -2561,6 +2561,9 @@ static void narrow_write_error(struct r1bio *r1_bio, int i)
>  		}
>  
>  		wbio->bi_opf = REQ_OP_WRITE;

[Severity: High]
This isn't a bug introduced by this patch, but does this assignment
unintentionally overwrite all request flags?

Since bio_alloc_clone() copies the original bi_opf, setting it directly to
REQ_OP_WRITE zeroes out the upper 24 flag bits, which drops flags like
REQ_FUA and REQ_PREFLUSH.

Could this result in data corruption on power loss if the original write
requested forced unit access?

> +		/* Keep P2PDMA retry bios unmergeable, like the original */
> +		if (md_bio_is_p2pdma(wbio))
> +			wbio->bi_opf |= REQ_NOMERGE;
>  		wbio->bi_iter.bi_sector = r1_bio->sector;
>  		wbio->bi_iter.bi_size = r1_bio->sectors << 9;
>  
[ ... ]
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 5b63175fb3826..428bddddfe71d 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
[ ... ]
> @@ -2823,6 +2823,9 @@ static void narrow_write_error(struct r10bio *r10_bio, int i)
>  		wbio->bi_iter.bi_sector = wsector +
>  				   choose_data_offset(r10_bio, rdev);
>  		wbio->bi_opf = REQ_OP_WRITE;

[Severity: High]
This is the same pre-existing issue as in raid1.c. Does overwriting bi_opf
drop critical data integrity flags like REQ_FUA cloned from the master bio?

> +		/* Keep P2PDMA retry bios unmergeable, like the original */
> +		if (md_bio_is_p2pdma(wbio))
> +			wbio->bi_opf |= REQ_NOMERGE;
>  
>  		if (submit_bio_wait(wbio) &&
>  		    !rdev_set_badblocks(rdev, wsector, sectors, 0)) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260726113229.2154269-1-mykola@meshstor.io?part=6

  reply	other threads:[~2026-07-26 12:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26 11:32 [PATCH v6 00/12] block,md,nvme: correct handling of unsupported P2PDMA transfers Mykola Marzhan
2026-07-26 11:32 ` [PATCH v6 01/12] block: add BLK_STS_P2PDMA for unsupported peer-to-peer transfers Mykola Marzhan
2026-07-26 12:06   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 02/12] md: ensure REQ_NOMERGE is set on P2PDMA bios Mykola Marzhan
2026-07-26 11:59   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 03/12] md/raid1: serialize non-write-behind writes on CollisionCheck rdevs Mykola Marzhan
2026-07-26 12:10   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 04/12] md/raid1: don't use write-behind for P2PDMA bios Mykola Marzhan
2026-07-26 12:01   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 05/12] md/raid1,raid10: factor out raid1_write_error() helper Mykola Marzhan
2026-07-26 11:57   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 06/12] md/raid1,raid10: keep REQ_NOMERGE on narrow_write_error() retry clones Mykola Marzhan
2026-07-26 12:09   ` sashiko-bot [this message]
2026-07-26 11:32 ` [PATCH v6 07/12] md/raid1,raid10: skip futile retries on P2PDMA mapping failures Mykola Marzhan
2026-07-26 12:03   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 08/12] md/raid1,raid10: set IO_BLOCKED in case of BLK_STS_P2PDMA Mykola Marzhan
2026-07-26 12:06   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 09/12] nvme-rdma: use ib_dma_map_sgtable_attrs() Mykola Marzhan
2026-07-26 12:01   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 10/12] nvme-rdma: return BLK_STS_P2PDMA for unsupported P2P transfers Mykola Marzhan
2026-07-26 12:10   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 11/12] nvme-rdma: ratelimit the map-failure error message Mykola Marzhan
2026-07-26 11:53   ` sashiko-bot
2026-07-26 11:32 ` [PATCH v6 12/12] nvme-rdma: factor out the scatterlist DMA mapping helper Mykola Marzhan
2026-07-26 12:02   ` 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=20260726120903.67B291F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.