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

On Tue, Jul 21, 2026 at 05:38:53PM -0600, Logan Gunthorpe wrote:
> 
> 
> 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.

I had thoughts about this series too. It seems best to avoid
the P2P path entirely unless all legs support P2P.

Can the md/raid code determine P2P support in advance?

Thanks