While testing llbitmap we found two bugs with the same root cause:
the bitmap superblock's state field is untrusted input, but both
bitmap loaders copy it into runtime flags unmasked.  A single wrong
bit on disk -- which pre-v4.15 kernels wrote themselves, and which
corruption or an external write can plant today -- can brick an
array (patch 1, classic bitmap: assemble fails with -EIO) or
silently disable its bitmap for the array's lifetime (patch 2,
llbitmap).  Patch 3 fixes a kmap_local ordering violation in the
llbitmap superblock reader (hardening; no observable bug on
production configs, hence no stable tag).  Patch 4 adds the events
counters to the "kicking non-fresh" warning so a kicked member can
be judged from dmesg alone.

Testing: patches 1-2 verified with their in-message dd reproducers
on unpatched and patched kernels (state field forged on every
member); patch 3 by build and inspection; patch 4's warning format
exercised during a non-fresh assemble.  The series builds W=1-clean
and applies to current master and to md-7.2.  Independent of the
raid10-recovery series posted separately.

The patches were developed with AI assistance (see the Assisted-by
trailers); all code was human-reviewed and tested as described above.

Mykola Marzhan (4):
  md/md-bitmap: mask sb->state on load to drop runtime-only bits
  md/md-llbitmap: mask sb->state on load to drop runtime-only bits
  md/md-llbitmap: unmap sb page before freeing it
  md: include events counters when kicking non-fresh device

 drivers/md/md-bitmap.c   |  9 +++++++--
 drivers/md/md-llbitmap.c | 12 ++++++++++--
 drivers/md/md.c          | 25 +++++++++++++++++++++++--
 3 files changed, 40 insertions(+), 6 deletions(-)


base-commit: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
-- 
2.43.0