From: Dmitry Bogdanov <d.bogdanov@yadro.com>
To: Martin Petersen <martin.petersen@oracle.com>,
<target-devel@vger.kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Mike Christie <michael.christie@oracle.com>,
<linux-scsi@vger.kernel.org>, <linux@yadro.com>,
Dmitry Bogdanov <d.bogdanov@yadro.com>
Subject: [PATCH v4 0/5] scsi: target: make RTPI an TPG identifier
Date: Tue, 21 Feb 2023 19:06:18 +0300 [thread overview]
Message-ID: <20230221160622.7283-1-d.bogdanov@yadro.com> (raw)
The patchset based on 6.3/scsi-queue.
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_group's), which is common to scenario with
multiple HBAs or multiple iSCSI/FC targets, it's possible to have two
backstores (se_device's) 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.
Changelog:
v4:
move rtpi file from tpg_n/attrib to tpgt_n folder (drop 4th patch)
use unused variable
make se_tpg.tpg_rtpi variable u16 again
revert occasional rename
v3:
make variable static
change core_ prefix to target_
split to tpg_enable/tpg_disable functions
v2:
use XArray for tracking RTPI instead of linked list
do not allow to change RTPI on enabled target port
drop not needed patches
Dmitry Bogdanov (2):
scsi: target: core: Add RTPI field to target port
scsi: target: core: Add RTPI attribute for target port
Roman Bolshakov (2):
scsi: target: core: Use RTPI from target port
scsi: target: core: Drop device-based RTPI
drivers/target/target_core_alua.c | 4 +-
drivers/target/target_core_device.c | 43 +-----------
drivers/target/target_core_fabric_configfs.c | 44 ++++++++++--
drivers/target/target_core_internal.h | 3 +-
drivers/target/target_core_pr.c | 8 +--
drivers/target/target_core_spc.c | 2 +-
drivers/target/target_core_stat.c | 6 +-
drivers/target/target_core_tpg.c | 71 ++++++++++++++++++--
include/target/target_core_base.h | 7 +-
9 files changed, 120 insertions(+), 68 deletions(-)
--
2.25.1
next reply other threads:[~2023-02-21 16:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 16:06 Dmitry Bogdanov [this message]
2023-02-21 16:06 ` [PATCH v4 1/4] scsi: target: core: Add RTPI field to target port Dmitry Bogdanov
2023-02-21 16:06 ` [PATCH v4 2/4] scsi: target: core: Use RTPI from " Dmitry Bogdanov
2023-02-21 16:06 ` [PATCH v4 3/4] scsi: target: core: Drop device-based RTPI Dmitry Bogdanov
2023-02-21 16:06 ` [PATCH v4 4/4] scsi: target: core: Add RTPI attribute for target port Dmitry Bogdanov
2023-02-22 21:41 ` Mike Christie
2023-03-01 8:32 ` Dmitry Bogdanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230221160622.7283-1-d.bogdanov@yadro.com \
--to=d.bogdanov@yadro.com \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@yadro.com \
--cc=martin.petersen@oracle.com \
--cc=michael.christie@oracle.com \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).