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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux