On Wed, 2014-01-15 at 20:42 -0500, Martin K. Petersen wrote: > >>>>> "nab" == Nicholas A Bellinger <nab@xxxxxxxxxxxxxxx> writes: > > nab> The issue is that existing fs/bio-integrity.c code always assumes > nab> client/initiator mode, in that it will attempt to > nab> bio_integrity_generate() protection information in the submit_bio > nab> WRITE path, and bio_integrity_verify() of protection information in > nab> the bio_endio READ completion path. > > Only if the submit_bio() caller hasn't attached protection information > already. If you submit a bio with a bip already attached the block layer > will not generate/verify. > Mmm, missed that detail. So that would take care of the passthrough for the WRITE case then.. How about a passthrough on the READ completion side for target fabrics doing a hardware VERIFY..? Any preferences how this should work..? Also, for IBLOCK responses to properly generate GUARD + REFERENCE tag CHECK_CONDITION sense failures from an underlying device VERIFY failure, there will also need to be a way to propagate up the failure status through bio_endio(). I assume bio_integrity_payload is the proper place for adding something like this..? One other item from my TODO list for IBLOCK protection support is how to go about determining which DIF type to expose in the target, based upon what is currently enabled on the underlying struct block_device. I'm currently trying to deduce the protection type by looking at struct blk_integrity, but it would be helpful to make this explicit with bi->prot_type. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
