FC address format inconsitency

[dwsuse]

@hreinecke reports:

Doing a discovery on FC works:

# nvme discover --transport=fc --host-traddr=nn-0x200000109bec9d94:pn-0x100000109bec9d94 --traddr=nn-0x200070b7e422ae87:pn-0x100070b7e422ae87
Discovery Log Number of Records 2, Generation counter 6
=====Discovery Log Entry 0======
trtype:  fc
adrfam:  fibre-channel
subtype: current discovery subsystem
treq:    not specified, sq flow control disable supported
portid:  1
trsvcid: 
subnqn:  nqn.2014-08.org.nvmexpress.discovery
traddr:  nn-0x200070b7e422ae87,pn-0x100070b7e422ae87
eflags:  none
=====Discovery Log Entry 1======
trtype:  fc
adrfam:  fibre-channel
subtype: nvme subsystem
treq:    not specified, sq flow control disable supported
portid:  1
trsvcid: 
subnqn:  nqn.blktests-1
traddr:  nn-0x200070b7e422ae87,pn-0x100070b7e422ae87
eflags:  none

But when calling 'connect-all', the 'traddr' string from the discovery log page is used as-is for the 'connect' command. The kernel, however, expects the 'traddr' string to be of the format 'nn-0x:pn-0x' (note the colon), and consequently the in-kernel parser fails with the error message:

nvme_fabrics: unknown parameter or missing value 'pn-0x100070b7e422ae87' in ctrl creation request

I also noticed that the output of nvme list -v prints:

traddr=nn-0x58ccf090c92006da:pn-0x58ccf091492806da,host_traddr=nn-0x20000024ff7fa448:pn-0x21000024ff7fa448

I suppose s/host_traddr/host-traddr/ would be better.

[dwsuse]

There is not much post processing involved, only a chopping off some whitespaces:

static void sanitize_discovery_log_entry(struct nvmf_disc_log_entry *e)
{
	strchomp(e->trsvcid, sizeof(e->trsvcid));
	strchomp(e->traddr, sizeof(e->traddr));
}

After the sanitize step, I didn't find any further code which does anything with the traddr string. nvme-cli just prints the entry from the discovery log page

A quick test with nvme-fc shows:

root@dolin:~ # nvme --version
nvme version 3.0-a.3 (git 3.0.a.3)
libnvme version 3.0-a.3 (git 3.0.a.3)

# nvme discover -t fc --traddr=nn-0x58ccf090c92006da:pn-0x58ccf091492806da --host-traddr=nn-0x20000024ff7fa448:pn-0x21000024ff7fa448
[...]
=====Discovery Log Entry 9======
trtype:  fc
adrfam:  fibre-channel
subtype: nvme subsystem
treq:    not specified
portid:  4224
trsvcid: none
subnqn:  nqn.1988-11.com.dell:powerstore:00:f03028e73ef7D032D81E
traddr:  nn-0x58ccf090c92006da:pn-0x58ccf091492a06da
eflags:  none
=====Discovery Log Entry
[...]

Nothing wrong with this setup. AlsoI've checked the kernel code and nothing in there which could explain.

Anyway, adding some more sanitizing to the above function is possible, though I really wonder where is coming from.

[dwsuse]

I found by accident one possible source for the wrong formatting.

   # udevadm info -a -p /sys/class/nvme/nvme0

   looking at device '/devices/virtual/nvme-fabrics/ctl/nvme0':
     KERNEL=="nvme0"
     SUBSYSTEM=="nvme"
     DRIVER==""
     ATTR{address}=="traddr=nn-0x201700a09890f5bf:pn-0x201800a09890f5bf,host_traddr=nn-0x200000109b579ef3:pn-0x100000109b579ef3"

[edit: nope, it's traddr=...,host_traddr and traddr is valid.]