Re: [RFC PATCH] scsi: target: detect XCOPY NAA descriptor conflicts

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

 




> On Aug 12, 2020, at 7:21 PM, David Disseldorp <ddiss@xxxxxxx> wrote:
> 
> LIO's XCOPY implementation currently only accepts IEEE NAA 0x83 type
> device descriptors for copy source and destination IDs. These IDs are
> automatically generated by spc_parse_naa_6h_vendor_specific() using
> *only* hexadecimal characters present in the user-configured
> vpd_unit_serial string, and advertised in the Device ID Page INQUIRY
> response.
> 
> spc_parse_naa_6h_vendor_specific() mapping can quite easily result in
> two devices with differing vpd_unit_serial strings sharing the same NAA
> ID. E.g.
> LUN0
> -> backstore device=/dev/sda, vpd_unit_serial=unitserialfirst
> LUN1
> -> backstore device=/dev/sdb, vpd_unit_serial=unitserialforth
> 
> In this case, both LUNs would advertise an NAA ID of:
> 0x01405eaf0000000000000000...
> Where 0x01405 corresponds to the OpenFabrics IEEE Company ID and 0xeaf
> are hex characters taken from vpd_unit_serial.
> 
> With the above example, an initiator wishing to copy data from LUN0 to
> LUN1 may issue an XCOPY request with a copy source and copy dest set
> to 0x01405eaf... and observe that (despite XCOPY success), no data has
> moved from LUN0 to LUN1. Instead LIO has processed the request using
> LUN0 as source and destination.
> 
> This change sees LIO fail XCOPY requests if the copy source or
> destination correspond to a non-unique NAA identifier.
> 
> Signed-off-by: David Disseldorp <ddiss@xxxxxxx>
> ---
> drivers/target/target_core_xcopy.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/target/target_core_xcopy.c b/drivers/target/target_core_xcopy.c
> index 44e15d7fb2f0..3ce5da4b3e81 100644
> --- a/drivers/target/target_core_xcopy.c
> +++ b/drivers/target/target_core_xcopy.c
> @@ -68,8 +68,14 @@ static int target_xcopy_locate_se_dev_e4_iter(struct se_device *se_dev,
> 	if (rc != 0)
> 		return 0;
> 
> -	info->found_dev = se_dev;
> 	pr_debug("XCOPY 0xe4: located se_dev: %p\n", se_dev);
> +	if (info->found_dev) {
> +		pr_warn("XCOPY 0xe4 descriptor conflict for se_dev %p and %p\n",
> +			info->found_dev, se_dev);
> +		target_undepend_item(&info->found_dev->dev_group.cg_item);
> +		return -ENOTUNIQ;
> +	}
> +	info->found_dev = se_dev;

Was it valid to copy to/from the same LUN? You would copy from/to different src/destinations on that LUN. Would your patch break that?





[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux