Re: [PATCH v2 6/7] md/raid1,raid10: skip futile retries on P2PDMA mapping failures

On 2026-07-21 11:50, Mykola Marzhan wrote:
> I have split it in v3 into a raid1 patch and a raid10 patch.
> I am not sure about separate "introduce the bit" patches.
> R1BIO_P2PDMA and R10BIO_P2PDMA are entries in the two personalities'
> with own r*bio state enums.
> The commit messages are shorter now.

That helps a bit, thanks.


> An early return doesn't work here: on a mapping failure the
> function must still fall through to set R1BIO_WriteError, so the
> completion path runs the (single, whole-range) retry and records
> the bad range -- only WantReplacement and the FailFast md_error()
> are skipped.  v3 folds the two tests into one branch now,
> which reads better and keeps the fall-through. Please check v3.

The early return works if you create a helper.

> I compared the two sides after splitting: the P2PDMA handling is
> symmetric, and the remaining differences are pre-existing
> personality differences rather than missed fixes.
> A shared helper would be heavier than the two open-coded branches,
> so I kept it per-personality.

Yeah, I still think it's a bit of a mess so I dug into it a bit more
myself.

I realized the real problem in this patch set was reusing
BLK_STS_TARGET. I think I may have used that a long time ago and those
paths have since been removed. Using it here doesn't quite make sense
because we end up with those awkward checks (is P2PDMA enabled *and* the
error is a BLK_STS_TARGET). I don't think that can ever really be
correct here seeing something could, in theory return BLK_STS_TARGET for
another reason even when P2PDMA is enabled. So that should be cleaned up.

Instead, I think it makes more sense to introduce a new BLK_STS_P2PDMA
error and use that. Then we don't need to know if a transaction is
P2PDMA when processing the result which simplifies patch 6 and 7
significantly.

I created a basic sketch which demonstrates what I'm thinking here:

https://github.com/lsgunth/linux blk-sts-p2p-err

Feel free to run with that.

(Note: I omitted the narrow_write_error() from the sketch because I
didn't dig into it enough to understand it. It'll need to be added to
this, preferably cleaning up the tabbing style a bit.)

Logan