Re: [PATCH 2/3] md: only consult skip_sync_blocks when 'j' is in the bitmap's domain

[Mykola Marzhan]

> There is already a patchset to support llbitmap reshape for raid10 and raid5:
>
> [PATCH v2 00/20] md/md-llbitmap: support reshape for RAID10 and RAID5 -
> Yu Kuai <https://lore.kernel.org/linux-raid/cover.1782282042.git.yukuai@xxxxxxxxxx/>
>
> Before this set, reshape for raid10 or raid5 is not safe. Kernel panic or
> data lost is observed. Please check if your problems still exist with this set.

I applied your v2 (all 20, clean on 0e35b9b6ec0f) and re-ran the test.
The problem still happens.

raid10 near-2, four members, lockless bitmap, no --assume-clean.
Write a region while healthy, fail and remove one member, rewrite the
same region while degraded, add a spare, then check whether the rebuilt
spare physically holds the degraded-era pattern:

  base                        spare does NOT have it
  base + this patch           spare has it
  base + your 20              spare does NOT have it
  base + your 20 + this patch spare has it

The mirror partner holds the pattern in all four runs, so the region
really did land on that mirror pair.

Only two of the 20 touch llbitmap_skip_sync_blocks():

  11/20 returns 0 for MD_RECOVERY_RESHAPE.  That is the reshape case,
        which this patch also excludes.

  10/20 adds "p >= llbitmap->chunks".  That bound does not fire here:
        raid10 recovery walks per-device offsets, which are always below
        the array-space bound, so p stays in range and simply addresses
        the wrong chunk.

Nothing in the series changes the md_do_sync() call site, so recovery
still consults the hook with an offset raid10's bitmap cannot interpret.

The two are independent.  Your series applies first and this one on top;
the only conflict is context in md.h and the raid5 personality tables.

Mykola