IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property()/of_find_property() functions for reading properties.
Convert reading boolean properties to of_property_read_bool().
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230310144723.1544999-1-robh@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Dmitry Bogdanov <d.bogdanov@yadro.com> says:
The patchset is based on 6.4/scsi-staging branch.
The first 11 patches are just a refactoring to reduce code duplication
in fabric drivers. They make several callouts be optional in fabric
ops. Make a default implementation of the optional ops and remove
such implementations in the fabric drivers.
The last patch is a new virtual remote fabric driver. It has a
valueble sence with patchset "scsi: target: make RTPI an TPG
identifier" to configure RPTI on remote/tpgt_x same as on tpgt_y on
other nodes in a storage cluster. That allows to report the same ports
in RTPG from each node and to have a clusterwide tpg/acl/lun view in
kernel.
Link: https://lore.kernel.org/r/20230313181110.20566-1-d.bogdanov@yadro.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Create virtual remote target module.
This can be used to see a whole ACL/LUN/TPG configuration from all nodes in
storage cluster. For example, it permits setting up remote ports in ALUA
port groups. To report all ports in a cluster in REPORT TARGET PORT GROUP
command.
Suggested-by: Konstantin Shelekhin <k.shelekhin@yadro.com>
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20230313181110.20566-13-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove callouts that are identical to the default implementations in TCM
Core.
Acked-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20230313181110.20566-10-d.bogdanov@yadro.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove callouts that are identical to the default implementations in TCM
Core.
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20230313181110.20566-8-d.bogdanov@yadro.com
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove callouts that are identical to the default implementations in TCM
Core.
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20230313181110.20566-3-d.bogdanov@yadro.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
There are several callouts in target fabric ops that most of fabric drivers
fill with a function returning the same value.
Stop requiring such callouts to exist in the ops, fill them in TCM Core.
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20230313181110.20566-2-d.bogdanov@yadro.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
John Garry <john.g.garry@oracle.com> says:
This series contains a bunch of minor improvements to the driver. I
have another bunch waiting with more major changes.
Most of the changes are quite straightforward, and the only patches of
note are as follows:
- Fix the command abort feature, enabled with host option
SDEBUG_OPT_CMD_ABORT.
- Drop driver count of queued commands per device.
- Add poll mode completions to statistics. We already have poll mode
callback call count, so maybe it was intentional to omit poll mode
from the statistics.
Link: https://lore.kernel.org/r/20230313093114.1498305-1-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently commands completed via poll mode are not included in the
statistics gathering for deferred completions and missed CPUs.
Poll mode completions should be treated the same as other deferred
completion types, so add poll mode completions to the statistics.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-12-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The command abort feature allows us to test aborting a command which has
timed-out.
The idea is that for specific commands we just don't call scsi_done() and
allow the request to timeout, which ensures SCSI EH kicks-in we try to
abort the command.
Since commit 4a0c6f432d15 ("scsi: scsi_debug: Add new defer type for
mq_poll") this does not seem to work. The issue is that we clear the
sd_dp->aborted flag in schedule_resp() before the completion callback has
run. When the completion callback actually runs, it calls scsi_done() as
normal as sd_dp->aborted unset. This is all very racy.
Fix by not clearing sd_dp->aborted in schedule_resp(). Also move the call
to blk_abort_request() from schedule_resp() to sdebug_q_cmd_complete(),
which makes the code have a more logical sequence.
I also note that this feature only works for commands which are classed as
"SDEG_RES_IMMED_MASK", but only practically triggered with prior RW
commands. So for my experiment I need to run fio to trigger the error on
the "nth" command (see inject_on_this_cmd()), and then run something like
sg_sync to queue a command to actually trigger the abort.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-11-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In schedule_resp(), under certain conditions we check whether the
per-device queue is full (num_in_q == queue depth - 1) and we may inject a
"task set full" (TSF) error if it is.
However how we read num_in_q is racy - many threads may see the same "queue
is full" value (and also issue a TSF).
There is per-queue locking in reading per-device num_in_q, but that would
not help.
Replace how we read num_in_q at this location with a call to
scsi_device_busy(). Calling scsi_device_busy() is likewise racy (as reading
num_in_q), so nothing lost or gained. Calling scsi_device_busy() is also
slow as it needs to read all bits in the per-device budget bitmap, but we
can live with that since we're just a simulator and it's only under a
certain configs which we would see this.
Also move the "task set full" print earlier as it would only be called now
under this condition. However, previously it may not have been called -
like returning early - but keep it simple and always call it.
At this point we can drop sdebug_dev_info.num_in_q - it is difficult to
maintain properly and adds extra normal case command processing.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-10-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The per-device num_in_q value cannot exceed the device queue depth, so drop
the check.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-9-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The check for device pointer for the SCSI command is unnecessary, so drop
it.
The only caller is scsi_try_host_reset() -> eh_host_reset_handler(), and
there that pointer cannot be NULL.
Indeed, there is already code later in the same function which does not
check the device pointer for the SCSI command.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-8-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The checks for SCSI cmnd, SCSI device, and SCSI host are unnecessary, so
drop them. Likewise, drop the NULL check for sdbg_host.
The only caller is scsi_try_bus_reset() -> eh_bus_reset_handler(), and
there those pointers cannot be NULL.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-7-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The checks for SCSI cmnd, SCSI device, and SCSI host are unnecessary, so
drop them. Likewise, drop the NULL check for sdbg_host.
The only caller is scsi_try_target_reset() -> eh_target_reset_handler(),
and there those pointers cannot be NULL.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-6-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The SCSI cmnd pointer arg would never be NULL, so drop the check. In
addition, its SCSI device pointer would never be NULL (so drop that check
also).
The only caller is scsi_try_bus_device_reset(), and the command and its
device pointer could not be NULL when calling eh_device_reset_handler()
there.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-5-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The SCSI cmnd pointer arg would never be NULL, so drop the check. In
addition, its SCSI device pointer would never be NULL.
The only caller is scsi_send_eh_cmnd() -> scsi_abort_eh_cmnd() ->
scsi_try_to_abort_cmd() -> scsi_try_to_abort_cmd(), and in the origin of
that chain those pointers cannot be NULL.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-4-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In sdebug_device_create(), the devip->sdbg_host pointer is needlessly set
twice, so stop doing that.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-3-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This driver stores just a pointer to the driver host structure in
host->hostdata[]. Most other drivers actually have the driver host
structure allocated in host->hostdata[], but this driver is different as we
allocate that memory separately before allocating the shost memory.
However there is no need to allocate this memory only in host->hostdata[]
when we can already look up the driver host structure from shost->dma_dev,
so add a macro for this - shost_to_sdebug_host(). Rename to_sdebug_host()
-> dev_to_sdebug_host() to avoid ambiguity.
Also remove a check for !sdbg_host in find_build_dev_info(), as this cannot
be true. Other similar checks will be later removed.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://lore.kernel.org/r/20230313093114.1498305-2-john.g.garry@oracle.com
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We don't have outstanding_reqs bitmap in MCQ mode. Considering that the
queue depth may increase beyond 64 in the future, rework ufshcd_print_trs()
to get rid of bitmap usage so that we can print trs for pending requests in
both SDB and MCQ mode.
Signed-off-by: Ziqi Chen <quic_ziqichen@quicinc.com>
Link: https://lore.kernel.org/r/1678865517-43139-1-git-send-email-quic_ziqichen@quicinc.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
It is important for the SCSI core to know the residual byte count. Hence,
extract the residual byte count from the UFS response and pass it to the
SCSI core. A few examples of the output of a debugging patch that has been
applied on top of this patch:
[ 1.937750] cmd 0x12: len = 255; resid = 241
[ ... ]
[ 1.993400] cmd 0xa0: len = 4096; resid = 4048
[ ... ]
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20230314205844.313519-1-bvanassche@acm.org
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Neither UFS host controllers nor UFS devices require a ten second delay
after a host reset or after a bus reset. Hence this patch.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20230314205822.313447-1-bvanassche@acm.org
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
smatch reports several warnings:
drivers/scsi/be2iscsi/be_main.c:148:1: warning:
symbol 'dev_attr_beiscsi_log_enable' was not declared. Should it be static?
drivers/scsi/be2iscsi/be_main.c:158:1: warning:
symbol 'dev_attr_beiscsi_drvr_ver' was not declared. Should it be static?
drivers/scsi/be2iscsi/be_main.c:159:1: warning:
symbol 'dev_attr_beiscsi_adapter_family' was not declared. Should it be static?
drivers/scsi/be2iscsi/be_main.c:160:1: warning:
symbol 'dev_attr_beiscsi_fw_ver' was not declared. Should it be static?
drivers/scsi/be2iscsi/be_main.c:161:1: warning:
symbol 'dev_attr_beiscsi_phys_port' was not declared. Should it be static?
drivers/scsi/be2iscsi/be_main.c:162:1: warning:
symbol 'dev_attr_beiscsi_active_session_count' was not declared. Should it be static?
drivers/scsi/be2iscsi/be_main.c:164:1: warning:
symbol 'dev_attr_beiscsi_free_session_count' was not declared. Should it be static ?
These variables are only used in be_main.c, so should be static.
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20230314005157.536918-1-trix@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bjorn Helgaas <helgaas@kernel.org> says:
Since f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is native"),
which appeared in v6.0, the PCI core has enabled PCIe error reporting for
all devices during enumeration.
Remove driver code to do this and remove unnecessary includes of
<linux/aer.h> from several other drivers.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native"), the PCI core does this for all devices during enumeration,
so the driver doesn't need to do it itself.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this only controls ERR_* Messages from the device. An ERR_*
Message may cause the Root Port to generate an interrupt, depending on the
AER Root Error Command register managed by the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-11-helgaas@kernel.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: Manish Rangankar <mrangankar@marvell.com>
Cc: GR-QLogic-Storage-Upstream@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native"), the PCI core does this for all devices during enumeration,
so the driver doesn't need to do it itself.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this only controls ERR_* Messages from the device. An ERR_*
Message may cause the Root Port to generate an interrupt, depending on the
AER Root Error Command register managed by the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-10-helgaas@kernel.org
Cc: Nilesh Javali <njavali@marvell.com>
Cc: GR-QLogic-Storage-Upstream@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native"), the PCI core does this for all devices during enumeration,
so the driver doesn't need to do it itself.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this only controls ERR_* Messages from the device. An ERR_*
Message may cause the Root Port to generate an interrupt, depending on the
AER Root Error Command register managed by the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-9-helgaas@kernel.org
Cc: Sathya Prakash <sathya.prakash@broadcom.com>
Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
Cc: MPT-FusionLinux.pdl@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native"), the PCI core does this for all devices during enumeration,
so the driver doesn't need to do it itself.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this only controls ERR_* Messages from the device. An ERR_*
Message may cause the Root Port to generate an interrupt, depending on the
AER Root Error Command register managed by the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-8-helgaas@kernel.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Commit 105a3dbc7452 ("hpsa: clean up driver init") added a comment about
pci_disable_pcie_error_reporting(), but hpsa has never called either
pci_enable_pcie_error_reporting() or pci_disable_pcie_error_reporting().
Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is
native"), the PCI core is responsible for managing PCIe device error
reporting.
Remove the comment about pci_disable_pcie_error_reporting().
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-7-helgaas@kernel.org
Cc: Don Brace <don.brace@microchip.com>
Cc: storagedev@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native"), the PCI core does this for all devices during enumeration,
so the driver doesn't need to do it itself.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this only controls ERR_* Messages from the device. An ERR_*
Message may cause the Root Port to generate an interrupt, depending on the
AER Root Error Command register managed by the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-5-helgaas@kernel.org
Cc: Anil Gurumurthy <anil.gurumurthy@qlogic.com>
Cc: Sudarsana Kalluru <sudarsana.kalluru@qlogic.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native"), the PCI core does this for all devices during enumeration,
so the driver doesn't need to do it itself.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this only controls ERR_* Messages from the device. An ERR_*
Message may cause the Root Port to generate an interrupt, depending on the
AER Root Error Command register managed by the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-4-helgaas@kernel.org
Cc: Ketan Mukadam <ketan.mukadam@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since commit f26e58bf6f54 ("PCI/AER: Enable error reporting when
AER is native"), the PCI core does this for all devices during enumeration,
so the driver doesn't need to do it itself.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver.
Note that this only controls ERR_* Messages from the device. An ERR_*
Message may cause the Root Port to generate an interrupt, depending on the
AER Root Error Command register managed by the AER service driver.
Also remove pci_disable_pcie_error_reporting() from the .error_detected()
path, which was added by commit 5c63f7f710bd ("aacraid: Added EEH support")
but looks unnecessary. Error reporting will be disabled by the device
reset and will be re-enabled by the pci_restore_state() in
aac_pci_slot_reset().
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-2-helgaas@kernel.org
Cc: Adaptec OEM Raid Solutions <aacraid@microsemi.com>
Cc: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
Cc: Tomas Henzl <thenzl@redhat.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
chenxiang <chenxiang66@hisilicon.com> says:
To support IO_URING IOPOLL support for hisi_sas, we need to:
- Add and fill mq_poll interface to poll queue;
- Ensure internal I/Os (including internal abort I/Os) are delivered and
completed through non-iopoll queue (queue 0);
Sending internal abort commands to non-poll queue actually requires to
sending the abort command to every queue. This carries a a risk. Make iopoll
support module parameter "experimental".
I have tested performance on v3 hw with different modes as follows. 4K
READs and 4K WRITEs both see an improvement when enabling poll mode:
4K READ 4K RANDREAD 4K WRITE 4K RANDWRITE
interrupt + libaio 1770k 1316k 1197k 831k
interrupt + io_uring 1848k 1390k 1238k 857k
iopoll + io_uring 2117k 1364k 1874k 849k
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently we sync irq to avoid freeing task before using task in I/O
completion. After adding io_uring support, we need to do something similar
for poll queues. As the process of CQ entries on poll queue are protected
by spinlock cq->lock, we can use spin_lock() + spin_unlock() on cq->lock to
make sure that CQ entries are processed to completion and then the complete
queue is synced.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Link: https://lore.kernel.org/r/1678169355-76215-4-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add a module parameter to set how many queues are used for iopoll. Also
fill the interface mq_poll. For internal I/Os from libsas and libata we use
non-iopoll queue (queue 0) to deliver and complete them. But for internal
abort I/Os, just don't send them for poll queues.
There is still a risk associated as this sends internal abort commands to
non-iopoll queues which actually requires sending an internal abort command
to every queue. As a result, make the module parameter as "experimental"
for now.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Link: https://lore.kernel.org/r/1678169355-76215-3-git-send-email-chenxiang66@hisilicon.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Put the work of processing cq slots in a separate function,
complete_v3_hw(), which can then be used by cq_thread_v3_hw() and other
functions when adding poll support.
Co-developed-by: John Garry <john.garry@huawei.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Link: https://lore.kernel.org/r/1678169355-76215-2-git-send-email-chenxiang66@hisilicon.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
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>
RELATIVE TARGET PORT IDENTIFIER can be read and configured via configfs:
$ echo 0x10 > $TARGET/tpgt_N/rtpi
RTPI can be changed only on disabled target ports.
Co-developed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20230301084512.21956-5-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
