On Thu, Nov 14, 2024 at 09:33:05PM +0000, Verma, Vishal L wrote: > I suspect this isn't actually needed, since the btt never generated its > own protection payload. See the /* Already protected? */ case in > bio_integrity_prep() - I think that's the only case we were trying to > account for - i.e. 'some other layer' set the integrity payload, and > we're just passing it on to it's right spot in pmem, and reading it > back. The btt itself doesn't ever try to generate and set a protection > payload of its own. > > If you look at the original flow in > 41cd8b70c37ace40077c8d6ec0b74b983178c192, btt never actually wants to > call bio_integrity_prep and allocate the bip - if it has to do that, > that's treated as an error. > > Since some of the reworks then to eliminate bio_integrity_enabled, and > other block level changes, this has changed to actually allocating bip > and continuing instead of erroring, but coincidentially since we assign > bip before the allocation (i.e. NULL as you point out), any future > steps nicely ignore it, but if it was set by another subsystem, things > should still 'work' - as in bio_integrity_prep() would return true, and > bip would be non-NULL, and would get written/read as needed, and this > is the happy path. > > Does this makes sense or am I missing something?
One of us might be missing something. :) The only upper layers I find that pass an integrity payload to the lower level driver are the scsi and nvme targets. It may make sense to use btt as the backend for those, but is that the only use case this was trying to enable? Or is there some other path I didn't find?
