Re: [PATCH 1/1] scsi: target: core: Add 8Fh VPD page

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

 



On Fri, Aug 13, 2021 at 04:52:55PM +0200, David Disseldorp wrote:
> Hi Sergey,
> 
> On Thu, 29 Jul 2021 23:19:43 +0300, Sergey Samoylenko wrote:
> 
> > The 8Fh VPD page announces the capabilities supported by
> > the TCM XCOPY manager. It helps to expand the coverage of
> > the third-party copy manager with SCSI testing utilities.
> 
> Please list which initiators use this VPD page, if you know of any.
> Also, is there any test coverage for this? I don't see anything in
> libiscsi...
> 

Hi David,

ESXi is one of the hosts that inspects Third Party Copy VPD Page.
Windows detects ODX support using the page [1][2].

The page is also used by libiscsi to detect presence and features of
copy manager as was agreed with Bart in the PR [3]:

"Implementing REPORT SUPPORTED OPERATION CODES in LIO would require more
work than implementing the third-party copy VPD page.

I'm fine with relying on the third-party copy VPD page, or in other
words, to skip the copy offloading tests if that page is not supported.

There are plans to implement XCOPY support in the Linux kernel sd
driver. If nobody else volunteers I plan to work on this myself. I'm
considering to only support SCSI targets that support the third-party
copy VPD page. Or in other words, we will need support for that VPD page
anyway."

1. https://www.slideshare.net/CalvinChen5/a-joint-effort-of-the-storage-industry
2. http://sg.danny.cz/sg/ddpt_xcopy_odx.html
3. https://github.com/sahlberg/libiscsi/pull/353

> > Reviewed-by: Konstantin Shelekhin <k.shelekhin@xxxxxxxxx>
> > Reviewed-by: Dmitry Bogdanov <d.bogdanov@xxxxxxxxx>
> > Reviewed-by: Anastasia Kovaleva <a.kovaleva@xxxxxxxxx>
> > Signed-off-by: Sergey Samoylenko <s.samoylenko@xxxxxxxxx>
> > ---
> >  drivers/target/target_core_spc.c | 230 ++++++++++++++++++++++++++++++-
> >  1 file changed, 226 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
> > index 22703a0dbd07..169341712b10 100644
> > --- a/drivers/target/target_core_spc.c
> > +++ b/drivers/target/target_core_spc.c
> ...
> > +/* Third-party Copy VPD page */
> > +static sense_reason_t
> > +spc_emulate_evpd_8f(struct se_cmd *cmd, unsigned char *buf)
> > +{
> > +	struct se_device *dev = cmd->se_dev;
> > +	int off;
> > +	u16 page_len;
> > +
> > +	if (!dev->dev_attrib.emulate_3pc)
> > +		return TCM_INVALID_CDB_FIELD;
> > +
> > +	/*
> > +	 * Since the Third-party copy manager in TCM is quite simple
> > +	 * and supports only two commands, the function sets
> > +	 * many descriptor parameters as constants.
> > +	 *
> > +	 * As the Copy manager supports the EXTENDED COPY(LID1) command,
> > +	 * the Third-party Copy VPD page should include five mandatory
> > +	 * Third-party copy descriptors. Its are:
> > +	 *   0001h - Supported Commands
> > +	 *   0004h - Parameter Data
> > +	 *   0008h - Supported Descriptors
> > +	 *   000Ch - Supported CSCD Descriptor IDs
> > +	 *   8001h - General Copy Operations
> > +	 *
> > +	 * See spc4 section 7.8.17
> > +	 */
> > +
> > +	off = 4;
> > +
> > +	/* fill descriptors */
> > +	off += spc_evpd_8f_encode_supp_cmds(&buf[off]);
> > +	off += spc_evpd_8f_encode_param_data(&buf[off]);
> > +	off += spc_evpd_8f_encode_supp_descrs(&buf[off]);
> > +	off += spc_evpd_8f_encode_supp_cscd_descr_id(&buf[off]);
> > +	off += spc_evpd_8f_encode_general_copy_ops(&buf[off]);
> 
> This looks risky in terms of buf overrun. I think it'd be good to pass
> a @remaining or @buf_end param to these helper functions.
> 

It's doable but would require to change the signature of all existing
VPD handlers. SE_INQUIRY_BUF is hardcoded to 1kb but it's also capped by
EDTL to avoid buffer overruns:

  memcpy(rbuf, buf, min_t(u32, SE_INQUIRY_BUF, cmd->data_length));

Regards,
Roman



[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