Re: [PATCH RFC] blk-integrity: fix slab-out-of-bounds in t10_pi_verify on namespace revalidation

On Mon, Jun 01, 2026 at 09:40:29AM +0200, Christoph Hellwig wrote:
> I don't think changing fundamental device properies such as the LBA
> or integrity tag size under a live device is a good model.  So instead
> of coming up with bandaids like this, we should probably just fail
> any such revalidation when there are openers instead of trying to deal
> with the fallout.

Agreed, and sorry for the long silence.  Samin and I are in the same
group and I am picking this up from him.  We are dropping the
blk-integrity patch rather than respinning it.

Before writing anything on the nvme side I would like to get the shape
right, because "fail the revalidation" can mean a few things and one of
them looks worse than the splat.

If a namespace really was reformatted out of band and we refuse to adopt
the new geometry, the host keeps issuing I/O with the old LBA format and
metadata size to a device that has already changed underneath it.  That
is silent corruption rather than a KASAN report.  So I assume refusing
the update has to be paired with taking the namespace out of service.
Did you have in mind

  (a) refuse the update and mark the namespace dead, like a surprise
      removal,
  (b) refuse only while the disk has openers and redo the revalidation
      on last close, or
  (c) something else?

Chao