Merge patch series "scsi: target: make RTPI an TPG identifier"

Dmitry Bogdanov <d.bogdanov@yadro.com> says:

SAM-5 4.6.5.2 (Relative Port Identifier attribute) defines the attribute as
unique across SCSI target ports:

  The Relative Port Identifier attribute identifies a SCSI target port or a
  SCSI initiator port relative to other SCSI ports in a SCSI target device
  and any SCSI initiator devices contained within that SCSI target device. A
  SCSI target device may assign relative port identifiers to its SCSI target
  ports and any SCSI initiator ports. If relative port identifiers are
  assigned, the SCSI target device shall assign each of its SCSI target
  ports and any SCSI initiator ports a unique relative port identifier from
  1 to 65 535. SCSI target ports and SCSI initiator ports share the same
  number space.

In the current TCM implementation, auto-incremented lun_rtpi weakly follows
the model outlined by SAM-5 and SPC-4. In case of multiple SCSI target
ports (se_portal_groups), which is common to scenario with multiple HBAs or
multiple iSCSI/FC targets, it's possible to have two backstores (se_devices)
with different values of lun_rtpi on the same SCSI target port.

Similar issue happens during re-export. If a LUN of a backstore is removed
from a target port and added again to the same target port, RTPI is
incremented again and will be different from the first time.

The two issues happen because each se_device increments RTPI for its own
LUNs independently.

The behaviour means that a SCSI application client can't reliably make any
sense of RTPI values reported by a LUN as it's not really related to SCSI
target ports. A conforming target implementation must ensure that RTPI field
is unique per port. The patchset resolves the issue.

Make RTPI be part of se_tpg instead of se_lun. Make it configurable.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>