On Tue, Dec 04, 2018 at 11:12:36AM +0100, David Disseldorp wrote: > The vendor_id attribute will allow for the modification of the T10 > Vendor Identification string returned in inquiry responses. Its value > can be viewed and modified via the ConfigFS path at: > target/core/$backstore/$name/wwn/vendor_id > > "LIO-ORG" remains the default value, which is set when the backstore > device is enabled. > > Signed-off-by: David Disseldorp <dd...@suse.de> > Reviewed-by: Bryant G. Ly <b...@catalogicsoftware.com> > Reviewed-by: Lee Duncan <ldun...@suse.com> > Reviewed-by: Hannes Reinecke <h...@suse.com> > --- > drivers/target/target_core_configfs.c | 48 > +++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > diff --git a/drivers/target/target_core_configfs.c > b/drivers/target/target_core_configfs.c > index 34872f24e8bf..67303c3f9cb4 100644 > --- a/drivers/target/target_core_configfs.c > +++ b/drivers/target/target_core_configfs.c > + > + /* Assume ASCII encoding. Strip any newline added from userspace. */ > + BUILD_BUG_ON(sizeof(dev->t10_wwn.vendor) != INQUIRY_VENDOR_LEN + 1); > + strlcpy(dev->t10_wwn.vendor, strstrip(buf), > + sizeof(dev->t10_wwn.vendor)); > +
Should we allow non-ASCII characters? It's okay to strip final newline for convenience. A simple loop would ensure the rest is conformant to SPC. EINVAL can be returned otherwise. And for fuzzy purposes there could be a special backstore that does all sorts of nasty things. According to SPC 4.3.1: ASCII data fields shall contain only ASCII printable characters (i.e., code values 20h to 7Eh) and may be terminated with one or more ASCII null (00h) characters. 3.3.10 shall keyword indicating a mandatory requirement Note 1 to entry: Designers are required to implement all such interoperability with other products that conform to this standard. Thank you, Roman
