| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Add MCQ hardware queue ID in the existing trace event ufshcd_command().
Signed-off-by: Ziqi Chen <quic_ziqichen@quicinc.com>
Link: https://lore.kernel.org/r/1678866271-49601-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>
|
|
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>
|
|
Use %ptTs instead of open-coded variant to print contents of time64_t type
in human readable form.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230314145813.66112-1-andriy.shevchenko@linux.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>
|
|
If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
freed, which will cause following memleak:
unreferenced object 0xffff88810b2c6980 (size 32):
comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............
backtrace:
[<0000000098f3a26d>] alua_activate+0xb0/0x320
[<000000003b529641>] scsi_dh_activate+0xb2/0x140
[<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]
[<000000007adc9ace>] process_one_work+0x3c5/0x730
[<00000000c457a985>] worker_thread+0x93/0x650
[<00000000cb80e628>] kthread+0x1ba/0x210
[<00000000a1e61077>] ret_from_fork+0x22/0x30
Fix the problem by freeing 'qdata' in error path.
Fixes: 625fe857e4fa ("scsi: scsi_dh_alua: Check scsi_device_get() return value")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20230315062154.668812-1-yukuai1@huaweicloud.com
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
A system hang was observed with the following call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1
Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022
RIP: 0010:__wake_up_common+0x55/0x190
Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d
40 e8 48 8d 43 08 48 89 04 24 48 89 c6\
49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31
ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d
RSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082
RAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018
RBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8
R10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0
Call Trace:
<TASK>
__wake_up_common_lock+0x83/0xd0
qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx]
__nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc]
nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc]
nvme_fc_delete_association+0x1bf/0x220 [nvme_fc]
? nvme_remove_namespaces+0x9f/0x140 [nvme_core]
nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core]
nvme_sysfs_delete+0x5f/0x70 [nvme_core]
kernfs_fop_write_iter+0x12b/0x1c0
vfs_write+0x2a3/0x3b0
ksys_write+0x5f/0xe0
do_syscall_64+0x5c/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
? exit_to_user_mode_loop+0xd0/0x130
? exit_to_user_mode_prepare+0xec/0x100
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f815cd3eb97
The IOCB counts are out of order and that would block any commands from
going out and subsequently hang the system. Synchronize the IOCB count to
be in correct order.
Fixes: 5f63a163ed2f ("scsi: qla2xxx: Fix exchange oversubscription for management commands")
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Link: https://lore.kernel.org/r/20230313043711.13500-3-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: John Meneghini <jmeneghi@redhat.com>
Tested-by: Lin Li <lilin@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
While adding and removing the controller, the following call trace was
observed:
WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50
CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1
RIP: 0010:dma_free_attrs+0x33/0x50
Call Trace:
qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx]
qla2x00_abort_srb+0x8e/0x250 [qla2xxx]
? ql_dbg+0x70/0x100 [qla2xxx]
__qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx]
qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx]
qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx]
qla2x00_remove_one+0x364/0x400 [qla2xxx]
pci_device_remove+0x36/0xa0
__device_release_driver+0x17a/0x230
device_release_driver+0x24/0x30
pci_stop_bus_device+0x68/0x90
pci_stop_and_remove_bus_device_locked+0x16/0x30
remove_store+0x75/0x90
kernfs_fop_write_iter+0x11c/0x1b0
new_sync_write+0x11f/0x1b0
vfs_write+0x1eb/0x280
ksys_write+0x5f/0xe0
do_syscall_64+0x5c/0x80
? do_user_addr_fault+0x1d8/0x680
? do_syscall_64+0x69/0x80
? exc_page_fault+0x62/0x140
? asm_exc_page_fault+0x8/0x30
entry_SYSCALL_64_after_hwframe+0x44/0xae
The command was completed in the abort path during driver unload with a
lock held, causing the warning in abort path. Hence complete the command
without any lock held.
Reported-by: Lin Li <lilin@redhat.com>
Tested-by: Lin Li <lilin@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Link: https://lore.kernel.org/r/20230313043711.13500-2-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: John Meneghini <jmeneghi@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Xiaomi Poco F1 (qcom/sdm845-xiaomi-beryllium*.dts) comes with a SKhynix
H28U74301AMR UFS. The sd_read_cpr() operation leads to a 120 second
timeout, making the device bootup very slow:
[ 121.457736] sd 0:0:0:1: [sdb] tag#23 timing out command, waited 120s
Setting the BLIST_SKIP_VPD_PAGES allows the device to skip the failing
sd_read_cpr operation and boot normally.
Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
Link: https://lore.kernel.org/r/20230313041402.39330-1-joelselvaraj.oss@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Enable"
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>
|
|
<linux/aer.h> is unused, so remove it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-6-helgaas@kernel.org
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>
|
|
<linux/aer.h> is unused, so remove it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307182842.870378-3-helgaas@kernel.org
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>
|
|
Add device attribute experimental_iopoll_q_cnt to indicate how many iopoll
queues are used for v3 hw.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Link: https://lore.kernel.org/r/1678169355-76215-5-git-send-email-chenxiang66@hisilicon.com
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>
|
|
The code is not needed since target port-based RTPI allocation replaced it.
Reviewed-by: Christoph Hellwig <hch@lst.de>
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-4-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Replace all references to RTPI from LUN field to se_portal_group field. It
introduces consistent reporting of RTPI for all LUNs and all target ports.
Reviewed-by: Christoph Hellwig <hch@lst.de>
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-3-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
SAM-5 4.6.5.2 (Relative Port Identifier attribute) defines the attribute as
unique across SCSI target ports.
The change introduces RTPI attribute to se_portal group. The value is
unique across all enabled SCSI target ports. It also limits number of SCSI
target ports to 65535.
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://lore.kernel.org/r/20230301084512.21956-2-d.bogdanov@yadro.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Justin Tee <justin.tee@broadcom.com> says:
Update lpfc to revision 14.2.0.11
This patch set contains bug fixes for buffer overflow, resource
management, discovery, and HBA error status handling.
The patches were cut against Martin's 6.3/scsi-queue tree.
Justin Tee (10):
lpfc: Protect against potential lpfc_debugfs_lockstat_write buffer overflow
lpfc: Reorder freeing of various dma buffers and their list removal
lpfc: Fix lockdep warning for rx_monitor lock when unloading driver
lpfc: Record LOGO state with discovery engine even if aborted
lpfc: Defer issuing new PLOGI if received RSCN before completing REG_LOGIN
lpfc: Correct used_rpi count when devloss tmo fires with no recovery
lpfc: Skip waiting for register ready bits when in unrecoverable state
lpfc: Revise lpfc_error_lost_link reason code evaluation logic
lpfc: Update lpfc version to 14.2.0.11
lpfc: Copyright updates for 14.2.0.11 patches
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Update copyrights to 2023 for files modified in the 14.2.0.11 patch set.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-11-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Update lpfc version to 14.2.0.11.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-10-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Extended status reason code errors should mask off the IOERR_PARAM_MASK
before checking strict equalities for IOERR values.
Update the lpfc_error_lost_link() routine as such.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-9-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
During tolerance tests that force an HBA to become unresponsive, rmmod
hangs resulting in the inability to remove the driver.
The lpfc_pci_remove_one_s4() routine attempts to submit a clean up mailbox
command via the lpfc_sli4_post_sync_mbox() routine, but ends up waiting
forever for a mailbox register to set its ready bit. Because the HBA is in
an unrecoverable and unresponsive state, the ready bit will never be set.
Create a new routine called lpfc_sli4_unrecoverable_port(), which checks a
port status register's error notification bits.
Use the lpfc_sli4_unrecoverable_port() routine in ready bit check routines
to early return error if port is deemed unrecoverable.
Also, when the lpfc_handle_eratt_s4() handler detects an unrecoverable
state, call the lpfc_sli4_offline_eratt() routine to kick off flushing
outstanding I/O.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-8-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
A fabric controller can sometimes send an RDP request right before a link
down event. Because of this outstanding RDP request, the driver does not
remove the last reference count on its ndlp causing a potential leak of RPI
resources when devloss tmo fires.
In lpfc_cmpl_els_rsp(), modify the NPIV clause to always allow the
lpfc_drop_node() routine to execute when not registered with SCSI
transport.
This relaxes the contraint that an NPIV ndlp must be in a specific state in
order to call lpfc_drop node. Logic is revised such that the
lpfc_drop_node() routine is always called to ensure the last ndlp decrement
occurs.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-7-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
When mapped to a target with multiple virtual ports, a link bounce
sometimes results in unsuccessful rediscovery of all of the target's
virtual ports. This is because a succession of repeat RSCNs for the
virtual target ports leaves ndlps in the REG_LOGIN state with the
NLP_REG_LOGIN_SEND flag set. With NLP_REG_LOGIN_SEND set, during the next
PLOGI, the driver will UNREG_RPI. When UNREG_RPI is processed, the driver
can be in the middle of PRLI_ISSUE or MAPPED state resulting in an illegal
state transition by the discovery engine and stalling.
Fix by calling the discovery state machine with DEVICE_RECOVERY event
during RSCN processing. This will set the NLP_IGNR_REG_CMPL bit and
prevent the old REG_LOGIN state from advancing. Then for the new PLOGI
issue, add the check for the NLP_IGNR_REG_CMPL bit to delay issuing the new
PLOGI until the queued REG_LOGIN and UNREG_LOGIN have been processed.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-6-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
A target vendor array reboot in P2P topology can sometimes result in
unsuccessful rediscovery.
Rework the lpfc_cmpl_els_logo() routine such that when the LOGO completes
as a failure because of driver abort, the LOGO state is still recorded with
the discovery state machine.
This is a small rework to set LOGO completion without forcing a device
removal state change.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-5-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Lockdep enabled kernels report a theoretical deadlock state where the
cmf_timer interrupt occurs while the rx_monitor ring is being destroyed.
During rmmod, the cmf_timer is cancelled prior to the
lpfc_rx_monitor_destroy_ring call. This actually eliminates the need to
take the rx_monitor ring lock in lpfc_rx_monitor_destroy_ring. Thus, just
remove lock/unlock of rx_monitor in lpfc_rx_monitor_destroy_ring.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-4-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Code sections where DMA resources are freed before list removal are
reworked to ensure item removal before being freed.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20230301231626.9621-3-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
A static code analysis tool flagged the possibility of buffer overflow when
using copy_from_user() for a debugfs entry.
Currently, it is possible that copy_from_user() copies more bytes than what
would fit in the mybuf char array. Add a min() restriction check between
sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect
against buffer overflow.
Link: https://lore.kernel.org/r/20230301231626.9621-2-justintee8345@gmail.com
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Like commit c4f135d64382 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
Commit 4d4109d0eb69 ("[SCSI] mpt fusion: Power Management fixes for MPT SAS
PCI-E controllers") added flush_scheduled_work() call into
mptscsih_suspend(). As of commit 4d4109d0eb69, there were several
schedule{,_delayed}_work() calls where flush_scheduled_work() from
mptscsih_suspend() meant to wait for completion. However, which work items
this flush_scheduled_work() call was for was not explained.
Then, schedule_work("struct mptsas_hotplug_event"->work) and
schedule_work(MPT_ADAPTER->sas_persist_task) have been removed by commit
3eb0822c6740 ("[SCSI] mpt fusion: Firmware event implementation using
seperate WorkQueue"), and schedule_work("struct
mptsas_send_discovery_event"->work) has been removed by commit f9c34022eae9
("[SCSI] mpt fusion: SAS topology scan changes, expander events").
There still remains schedule_work("struct work_queue_wrapper"->work) call
in mptspi.c and schedule_delayed_work("struct mpt_lan_priv"->work) call in
mptlan.c , but I guess that these are not work items which commit
4d4109d0eb69 meant to wait for completion because these are not per
MPT_ADAPTER work items. If my guess is correct, we no longer need to call
flush_scheduled_work() from mptscsih_suspend().
Link: https://lore.kernel.org/r/0b9ebcfb-b647-1381-0653-b54528a64a86@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
MPT_ADAPTER->sas_persist_task is no longer used since commit 3eb0822c6740
("[SCSI] mpt fusion: Firmware event implementation using seperate
WorkQueue").
Link: https://lore.kernel.org/r/b2ca2164-5347-8ec1-d8b6-3225df864173@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The variable 'internal_page_offset' is not used. Delete it.
drivers/scsi/be2iscsi/be_cmds.c:1176:6: warning: variable 'internal_page_offset' set but not used.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4011
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230209035224.90327-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Multi Circular Queue doesn't use outstanding_reqs. However, the UFS clock
scaling functions use outstanding_reqs to determine if there are requests
pending. When MCQ is enabled, this check always returns false.
Hence use active_reqs to check if there are pending requests.
Fixes: eacb139b77ff ("scsi: ufs: core: mcq: Enable multi-circular queue")
Signed-off-by: Asutosh Das <quic_asutoshd@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/a24e0d646aac70eae0fc5e05fac0c58bb7e6e680.1678317160.git.quic_asutoshd@quicinc.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
scsi_proc_hostdir_rm() decreases a reference counter and hence must only be
called once per host that is removed. This change does not require a
scsi_add_host_with_dma() change since scsi_add_host_with_dma() will return
0 (success) if scsi_proc_host_add() is called.
Fixes: fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier")
Cc: John Garry <john.g.garry@oracle.com>
Reported-by: John Garry <john.g.garry@oracle.com>
Link: https://lore.kernel.org/all/ed6b8027-a9d9-1b45-be8e-df4e8c6c4605@oracle.com/
Reported-by: syzbot+645a4616b87a2f10e398@syzkaller.appspotmail.com
Link: https://lore.kernel.org/linux-scsi/000000000000890fab05f65342b6@google.com/
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20230307214428.3703498-1-bvanassche@acm.org
Tested-by: John Garry <john.g.garry@oracle.com>
Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Some storage, such as AIX VDASD (virtual storage) and IBM 2076 (front
end), fail as a result of commit c92a6b5d6335 ("scsi: core: Query VPD
size before getting full page").
That commit changed getting SCSI VPD pages so that we now read just
enough of the page to get the actual page size, then read the whole
page in a second read. The problem is that the above mentioned
hardware returns zero for the page size, because of a firmware
error. In such cases, until the firmware is fixed, this new blacklist
flag says to revert to the original method of reading the VPD pages,
i.e. try to read a whole buffer's worth on the first try.
[mkp: reworked somewhat]
Fixes: c92a6b5d6335 ("scsi: core: Query VPD size before getting full page")
Reported-by: Martin Wilck <mwilck@suse.com>
Suggested-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Lee Duncan <lduncan@suse.com>
Link: https://lore.kernel.org/r/20220928181350.9948-1-leeman.duncan@gmail.com
Tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Add a missing resource clean up in .remove.
Fixes: e22bae30667a ("scsi: mpi3mr: Add expander devices to STL")
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Link: https://lore.kernel.org/r/20230302234336.25456-7-thenzl@redhat.com
Acked-by: Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
