>>>>> "Alberto" == Alberto Bertogli <albertito@xxxxxxxxxxxxxx> writes: Alberto> While at it, I found that bio_integrity_clone() does not clone Alberto> neither bip_buf nor bip_size, which already copies the bvec, Alberto> which should have the same data because it's allocated in Alberto> bio_integrity_prep(). Alberto> Is there any reason I'm missing why they shouldn't be copied in Alberto> bio_integrity_clone(), as illustrated in the following patch? Yes. The bip_buf is strictly an internal housekeeping construct. It contains a pointer to the kernel buffer that contains the protection information if the protection was added by the block layer itself (via bio_integrity_prep()). However, that's not always the case. The protection information may be passed down from a filesystem or (eventually) a userland application. So the bip_buf is for use by the top-level of the block layer exclusively. The bip_vec is what you want to use for accessing the actual protection information. Also, the cloned bio may be truncated or split. In that case the bip_buf isn't going to match the data bvec. So in any case blindly cloning bip_buf isn't going to work. Right now the integrity vector itself is cloned together with the bio because of the way the block layer works (advancing bvec offset for partial completion). However, I'm brewing on a patch that gets rid of that so we can avoid cloning the vector and thus cut down on memory allocations as the I/O goes through each remapping layer. With my patch in place the bip_vec becomes immutable and bip_buf will go away. I took a quick look at your DM patch last week and I didn't see any reason why it couldn't hook into the block integrity infrastructure. Take a look at drivers/scsi/sd_dif.c for clues on how to do that. Let me know if you have questions... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html