Re: [RFC PATCH] bio-integrity: Copy bip_buf and bip_size in bio_integrity_clone()

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "Alberto" == Alberto Bertogli <albertito@blitiri.com.ar> 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