| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This test is checking the wrong variable. It should be testing "res".
The "sdeb_zbc_model" variable is an enum (unsigned in this situation)
and we never assign negative values to it.
[mkp: fixed commit desc issue reported by Doug]
Link: https://lore.kernel.org/r/20200509100408.GA5555@mwanda
Fixes: 9267e0eb41fe ("scsi: scsi_debug: Add ZBC module parameter")
Acked-by: Douglas Gilbert <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
At the moment we allocate and register the Scsi_Host object corresponding
to a zfcp adapter (FCP device) very early in the life cycle of the adapter
- even before we fully discover and initialize the underlying
firmware/hardware. This had the advantage that we could already use the
Scsi_Host object, and fill in all its information during said discover and
initialize.
Due to commit 737eb78e82d5 ("block: Delay default elevator initialization")
(first released in v5.4), we noticed a regression that would prevent us
from using any storage volume if zfcp is configured with support for DIF or
DIX (zfcp.dif=1 || zfcp.dix=1). Doing so would result in an illegal memory
access as soon as the first request is sent with such an configuration. As
example for a crash resulting from this:
scsi host0: scsi_eh_0: sleeping
scsi host0: zfcp
qdio: 0.0.1900 ZFCP on SC 4bd using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA: W AP
scsi 0:0:0:0: scsi scan: INQUIRY pass 1 length 36
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0000000000000000 TEID: 0000000000000483
Fault in home space mode while using kernel ASCE.
AS:0000000035c7c007 R3:00000001effcc007 S:00000001effd1000 P:000000000000003d
Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: ...
CPU: 1 PID: 783 Comm: kworker/u760:5 Kdump: loaded Not tainted 5.6.0-rc2-bb-next+ #1
Hardware name: ...
Workqueue: scsi_wq_0 fc_scsi_scan_rport [scsi_transport_fc]
Krnl PSW : 0704e00180000000 000003ff801fcdae (scsi_queue_rq+0x436/0x740 [scsi_mod])
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0fffffffffffffff 0000000000000000 0000000187150120 0000000000000000
000003ff80223d20 000000000000018e 000000018adc6400 0000000187711000
000003e0062337e8 00000001ae719000 0000000187711000 0000000187150000
00000001ab808100 0000000187150120 000003ff801fcd74 000003e0062336a0
Krnl Code: 000003ff801fcd9e: e310a35c0012 lt %r1,860(%r10)
000003ff801fcda4: a7840010 brc 8,000003ff801fcdc4
#000003ff801fcda8: e310b2900004 lg %r1,656(%r11)
>000003ff801fcdae: d71710001000 xc 0(24,%r1),0(%r1)
000003ff801fcdb4: e310b2900004 lg %r1,656(%r11)
000003ff801fcdba: 41201018 la %r2,24(%r1)
000003ff801fcdbe: e32010000024 stg %r2,0(%r1)
000003ff801fcdc4: b904002b lgr %r2,%r11
Call Trace:
[<000003ff801fcdae>] scsi_queue_rq+0x436/0x740 [scsi_mod]
([<000003ff801fcd74>] scsi_queue_rq+0x3fc/0x740 [scsi_mod])
[<00000000349c9970>] blk_mq_dispatch_rq_list+0x390/0x680
[<00000000349d1596>] blk_mq_sched_dispatch_requests+0x196/0x1a8
[<00000000349c7a04>] __blk_mq_run_hw_queue+0x144/0x160
[<00000000349c7ab6>] __blk_mq_delay_run_hw_queue+0x96/0x228
[<00000000349c7d5a>] blk_mq_run_hw_queue+0xd2/0xe0
[<00000000349d194a>] blk_mq_sched_insert_request+0x192/0x1d8
[<00000000349c17b8>] blk_execute_rq_nowait+0x80/0x90
[<00000000349c1856>] blk_execute_rq+0x6e/0xb0
[<000003ff801f8ac2>] __scsi_execute+0xe2/0x1f0 [scsi_mod]
[<000003ff801fef98>] scsi_probe_and_add_lun+0x358/0x840 [scsi_mod]
[<000003ff8020001c>] __scsi_scan_target+0xc4/0x228 [scsi_mod]
[<000003ff80200254>] scsi_scan_target+0xd4/0x100 [scsi_mod]
[<000003ff802d8b96>] fc_scsi_scan_rport+0x96/0xc0 [scsi_transport_fc]
[<0000000034245ce8>] process_one_work+0x458/0x7d0
[<00000000342462a2>] worker_thread+0x242/0x448
[<0000000034250994>] kthread+0x15c/0x170
[<0000000034e1979c>] ret_from_fork+0x30/0x38
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<000003ff801fbc36>] scsi_add_cmd_to_list+0x9e/0xa8 [scsi_mod]
Kernel panic - not syncing: Fatal exception: panic_on_oops
While this issue is exposed by the commit named above, this is only by
accident. The real issue exists for longer already - basically since it's
possible to use blk-mq via scsi-mq, and blk-mq pre-allocates all requests
for a tag-set during initialization of the same. For a given Scsi_Host
object this is done when adding the object to the midlayer
(`scsi_add_host()` and such). In `scsi_mq_setup_tags()` the midlayer
calculates how much memory is required for a single scsi_cmnd, and its
additional data, which also might include space for additional protection
data - depending on whether the Scsi_Host has any form of protection
capabilities (`scsi_host_get_prot()`).
The problem is now thus, because zfcp does this step before we actually
know whether the firmware/hardware has these capabilities, we don't set any
protection capabilities in the Scsi_Host object. And so, no space is
allocated for additional protection data for requests in the Scsi_Host
tag-set.
Once we go through discover and initialize the FCP device firmware/hardware
fully (this is done via the firmware commands "Exchange Config Data" and
"Exchange Port Data") we find out whether it actually supports DIF and DIX,
and we set the corresponding capabilities in the Scsi_Host object (in
`zfcp_scsi_set_prot()`). Now the Scsi_Host potentially has protection
capabilities, but the already allocated requests in the tag-set don't have
any space allocated for that.
When we then trigger target scanning or add scsi_devices manually, the
midlayer will use requests from that tag-set, and before sending most
requests, it will also call `scsi_mq_prep_fn()`. To prepare the scsi_cmnd
this function will check again whether the used Scsi_Host has any
protection capabilities - and now it potentially has - and if so, it will
try to initialize the assumed to be preallocated structures and thus it
causes the crash, like shown above.
Before delaying the default elevator initialization with the commit named
above, we always would also allocate an elevator for any scsi_device before
ever sending any requests - in contrast to now, where we do it after
device-probing. That elevator in turn would have its own tag-set, and that
is initialized after we went through discovery and initialization of the
underlying firmware/hardware. So requests from that tag-set can be
allocated properly, and if used - unless the user changes/disabled the
default elevator - this would hide the underlying issue.
To fix this for any configuration - with or without an elevator - we move
the allocation and registration of the Scsi_Host object for a given FCP
device to after the first complete discovery and initialization of the
underlying firmware/hardware. By doing that we can make all basic
properties of the Scsi_Host known to the midlayer by the time we call
`scsi_add_host()`, including whether we have any protection capabilities.
To do that we have to delay all the accesses that we would have done in the
past during discovery and initialization, and do them instead once we are
finished with it. The previous patches ramp up to this by fencing and
factoring out all these accesses, and make it possible to re-do them later
on. In addition we make also use of the diagnostic buffers we recently
added with
commit 92953c6e0aa7 ("scsi: zfcp: signal incomplete or error for sync exchange config/port data")
commit 7e418833e689 ("scsi: zfcp: diagnostics buffer caching and use for exchange port data")
commit 088210233e6f ("scsi: zfcp: add diagnostics buffer for exchange config data")
(first released in v5.5), because these already cache all the information
we need for that "re-do operation" - the information cached are always
updated during xconf or xport data, so it won't be stale.
In addition to the move and re-do, this patch also updates the
function-documentation of `zfcp_scsi_adapter_register()` and changes how it
reports if a Scsi_Host object already exists. In that case future
recovery-operations can skip this step completely and behave much like they
would do in the past - zfcp does not release a once allocated Scsi_Host
object unless the corresponding FCP device is deconstructed completely.
Link: https://lore.kernel.org/r/030dd6da318bbb529f0b5268ec65cebcd20fc0a3.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When setting an adapter online for the first time, we also create a couple
of entries for it in the sysfs device tree. This is also true even if the
adapter has not yet ever gone successfully through exchange config and
exchange port data.
When moving the scsi host object allocation and registration to after the
first exchange config and exchange port data, this make the `port_rescan`
attribute susceptible to invalid pointer-dereferences of the shost field
before the adapter is fully initialized.
When written to, it schedules a `scan_work` item that will in turn make use
of the associated fibre channel host object to check the topology used for
this FCP device.
Because scanning for remote ports can't be done successfully without
completing exchange config and exchange port data first, we can simply
fence `port_rescan`, and so prevent the illegal access.
As with cases where we can't get a reference to the adapter, we also return
-ENODEV here. Applications need to handle that errno today already.
After a successful allocation of the scsi host object nothing changes in
the work flow.
Link: https://lore.kernel.org/r/ef65366d309993ca91b6917727590ca7ca166c8f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Common status flags that all main objects - adapter, port, and unit -
support are propagated to sub-objects when set or cleared. For instance,
when setting the status ZFCP_STATUS_COMMON_ERP_INUSE for an adapter object,
we will propagate this to all its child ports and units - same for when
clearing a common status flag.
Units of an adapter object are enumerated via __shost_for_each_device()
over the scsi host object of the corresponding adapter.
Once we move the scsi host object allocation and registration to after the
first exchange config and exchange port data, this won't be possible for
cases where we set or clear common statuses during the very first adapter
recovery.
But since we won't have any port or unit objects yet at that point of time,
we can just fence the status propagation for cases where the scsi host
object is not yet set in the adapter object. It won't change any effective
status propagations, but will prevent us from dereferencing invalid
pointers.
For any later point in the work flow the scsi host object will be set and
thus nothing is changed then.
Link: https://lore.kernel.org/r/f51fe5f236a1e3d1ce53379c308777561bfe35e1.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When doing the very first adapter recovery - initialization - for a FCP
device in a point-to-point topology we also allocate the port object
corresponding to the attached remote port, and trigger a port recovery for
it that will run after the adapter recovery finished.
Right now this happens right after we finished with the exchange config
data command, and uses the fibre channel host object corresponding to the
FCP device to determine whether a point-to-point topology is used.
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this use of the fc_host object is not
possible anymore at that point in the work flow.
But the allocation and recovery trigger doesn't have notable side-effects
on the following exchange port data processing, so we can move those to
after xport data, and thus also to after the scsi host object allocation,
once we move it. Then the fc_host object can be used again, like it is now.
For any further adapter recoveries this doesn't change anything, because at
that point the port object already exists and recovery is triggered
elsewhere for existing port objects.
Link: https://lore.kernel.org/r/73e5d4ac21e2b37bf0c3ca8e530bc5a5c6e74f8f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When receiving a notification that a FCP device lost its local link we
usually update the fibre channel host object which represents that FCP
device to reflect that.
This notification/information can also surface when the FCP device is
running through adapter recovery (exchange config and exchange port data
return incomplete).
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, and this happens during the very first
adapter recovery, these updates can not be done until after the scsi host
object is allocated.
Reorder the fc_host updates in zfcp_fsf_fc_host_link_down() so that they
only happen after a check of whether the scsi host object is already
allocated or not.
During the first adapter recovery this will cause the skip of these updates
if a link-down condition is detected, but we can repeat them after we
allocated the scsi host object, if necessary.
For any further link-down handling the only changes in the work flow are
the slightly reordered assignments in zfcp_fsf_fc_host_link_down().
Link: https://lore.kernel.org/r/f841f2cda61dcd7b8549910c44e1831927459edf.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When executing exchange port data for a FCP device for the first time, or
after an adapter recovery, we update several properties of the fibre
channel host object which represents that FCP device.
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this is not possible for the former case.
Move all these update into separate, and fenced function that first checks
whether the scsi host object already exists or not, before making the
updates.
During the first ever exchange port data in the adapter life cycle this
will make the exchange port data handler skip over this update step, but we
can repeat it later, after we allocated the scsi host object.
For any further recovery of that adapter the work flow is only changed
slightly because then the scsi host object already exists and we don't free
it until we release the adapter completely at the end of its life cycle.
Link: https://lore.kernel.org/r/ae454c2dc6da0b02907c489af91d0b211d331825.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When executing exchange config data for a FCP device for the first time, or
after an adapter recovery, we update several properties of the scsi host or
fibre channel host object that represent that FCP device.
When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this is not possible for the former case.
Move all these update into separate, and fenced function that first checks
whether the scsi host object already exists or not, before making the
updates.
During the first ever exchange config data in the adapter life cycle this
will make the exchange config data handler skip over this update step, but
we can repeat it later, after we allocated the scsi host object.
For any further recovery of that adapter the work flow is only changed
slightly because then the scsi host object already exists and we don't free
it until we release the adapter completely at the end of its life cycle.
Link: https://lore.kernel.org/r/5fc3f4d38d4334f7aa595497c6f7865fb1102e0f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When establishing and activating the QDIO queue pair for a FCP device for
the first time, or after an adapter recovery, we publish some of its
characteristics to the scsi host object representing that FCP device.
When moving the scsi host object allocation and registration to after the
first exchange config and exchange port data, this is not possible for the
former case - QDIO open for the first time - because that happens before
exchange config and exchange port data.
Move the scsi host object update into a fenced function that checks whether
the object already exists or not. This way we can repeat that step later,
once we are past the allocation.
Once the first recovery succeeds we don't release the scsi host object
anymore, so further recoveries do work as before.
Link: https://lore.kernel.org/r/a214ebf508f71e3690113e3e90edab1cea0e24e3.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Benjamin Block <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following versioncheck warning:
drivers/scsi/mpt3sas/mpt3sas_debugfs.c:16:1: unused including <linux/version.h>
Link: https://lore.kernel.org/r/[email protected]
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Samuel Zou <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix following warning from Smatch static analyser:
drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->hpr_lookup' double freed
drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->internal_lookup' double freed
Link: https://lore.kernel.org/r/[email protected]
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Suganath Prabu S <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Chandrakanth Patil <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When TM command times out, driver invokes the controller reset. Post reset,
driver re-fires pended TM commands which leads to firmware crash.
Post controller reset, return pended TM commands back to OS.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Sumit Saxena <[email protected]>
Signed-off-by: Chandrakanth Patil <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
__BIG_ENDIAN_BITFIELD macro
MFI_BIG_ENDIAN macro used in drivers structure bitfield to check the CPU
big endianness is undefined which would break the code on big endian
machine. __BIG_ENDIAN_BITFIELD kernel macro should be used in places of
MFI_BIG_ENDIAN macro.
Link: https://lore.kernel.org/r/[email protected]
Fixes: a7faf81d7858 ("scsi: megaraid_sas: Set no_write_same only for Virtual Disk")
Cc: <[email protected]> # v5.6+
Signed-off-by: Shivasharan S <[email protected]>
Signed-off-by: Chandrakanth Patil <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
As blk_queue_virt_boundary() API in slave_configure ensures that no IOs
will come with holes/gaps. Hence, code logic to detect the holes/gaps in IO
buffer is not required.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sumit Saxena <[email protected]>
Signed-off-by: Chandrakanth Patil <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver currently assigns a pre-defined queue depth when the
firmware-provided device queue depth is greater than the controller queue
depth.
Use the controller queue depth if the reported target queue depth is too
large.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Chandrakanth Patil <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Small cleanup as below items,
1. Use ufshcd_is_wb_allowed() directly instead of ufshcd_wb_sup() since
ufshcd_wb_sup() just returns the result of ufshcd_is_wb_allowed().
2. In ufshcd_suspend(), "else if (!ufshcd_is_runtime_pm(pm_op)) can be
simplified to "else" since both have the same meaning.
This patch does not change any functionality.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Enable WriteBooster capability on MediaTek UFS platforms.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
According to UFS specification, there are two WriteBooster mode of
operations: "LU dedicated buffer" mode and "shared buffer" mode. In the
"LU dedicated buffer" mode, the WriteBooster Buffer is dedicated to a
logical unit.
If the device supports the "LU dedicated buffer" mode, this mode is
configured by setting bWriteBoosterBufferType to 00h. The logical unit
WriteBooster Buffer size is configured by setting the
dLUNumWriteBoosterBufferAllocUnits field of the related Unit
Descriptor. Only a value greater than zero enables the WriteBooster feature
in the logical unit.
Modify ufshcd_wb_probe() as above description to support LU Dedicated
buffer mode.
Note that according to UFS 3.1 specification, the valid value of
bDeviceMaxWriteBoosterLUs parameter in Geometry Descriptor is 1, which
means at most one LUN can have WriteBooster buffer in "LU dedicated buffer
mode". Therefore this patch supports only one LUN with WriteBooster
enabled. All WriteBooster related sysfs nodes are specifically mapped to
the LUN with WriteBooster enabled in LU Dedicated buffer mode.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
For preparation of LU Dedicated buffer mode support on WriteBooster
feature, "index" parameter shall be added and allowed to be specified by
callers.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Can Guo <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add fixup_dev_quirk vops in MediaTek UFS platforms and provide an initial
vendor-specific device quirk table.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Export ufs_fixup_device_setup() to allow vendors to re-use it for fixing
device quriks on specified UFS hosts.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Some UFS deivces may have required device quirks or have non-standard
features which are enabled only on specified UFS hosts or for special
customers.
To not "pollute" common device quirk list, i.e. ufs_fixups table, for those
devices mentioned above, introduce "fixup_dev_quirks" vops to allow vendors
to fix or modify device quirks accordingly.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The WriteBooster feature can be supported by some pre-3.1 UFS devices by
upgrading firmware.
To enable WriteBooster feature in such devices, introduce a device quirk to
relax the entrance condition of ufshcd_wb_probe() to allow host driver to
check those devices' WriteBooster capability.
WriteBooster feature can be available if below all conditions are
satisfied,
1. Host enables WriteBooster capability
2. UFS 3.1 device or UFS pre-3.1 device with quirk
UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled
3. The device descriptor shall have DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP
field
4. WriteBooster support is specified in above field
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The variable rc is being initialized with a value that is never read and it
is being updated later with a new value. The initialization is redundant
and can be removed.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Addresses-Coverity: ("Unused value")
|
|
The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these ones is a flexible array member[1][2], introduced in
C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this
change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in which
the sizeof operator is being incorrectly/erroneously applied to zero-length
arrays and the result is zero. Such instances may be hiding some bugs. So,
this work (flexible-array member conversions) will also help to get
completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Link: https://lore.kernel.org/r/20200507192550.GA16683@embeddedor
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these ones is a flexible array member[1][2], introduced in
C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this
change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in which
the sizeof operator is being incorrectly/erroneously applied to zero-length
arrays and the result is zero. Such instances may be hiding some bugs. So,
this work (flexible-array member conversions) will also help to get
completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Link: https://lore.kernel.org/r/20200507192147.GA16206@embeddedor
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Jason Yan <[email protected]>
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
uctrl and udev are unused after commit 9632a6b4b747 ("scsi: qedi: Move LL2
producer index processing in BH.")
Remove them.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Lee Duncan <[email protected]>
Signed-off-by: Xie XiuQi <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following sparse warning:
drivers/scsi/bfa/bfad_bsg.c:140:1: warning: symbol
'bfad_iocmd_ioc_get_stats' was not declared. Should it be static?
Link: https://lore.kernel.org/r/[email protected]
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We use tcm_loop with tape emulations running on tcmu.
In case application reads a short tape block with a longer READ, or a long
tape block with a short READ, according to SCC spec data has to be
tranferred _and_ sensebytes with ILI set and information field containing
the residual count. Similar problem also exists when using fixed block
size in READ.
Up to now tcm_loop is not prepared to handle sensebytes if input data is
provided, as in tcm_loop_queue_data_in() it only sets SAM_STAT_GOOD and, if
necessary, the residual count.
To fix the bug, the same handling for sensebytes as present in
tcm_loop_queue_status() must be done in tcm_loop_queue_data_in() also.
After adding this handling, the two function now are nearly identical, so I
created a single function with two wrappers.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bodo Stroesser <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix coccicheck warning which recommends to use memdup_user().
This patch fixes the following coccicheck warning:
drivers/scsi/aacraid/commctrl.c:516:15-22: WARNING opportunity for memdup_user
Link: https://lore.kernel.org/r/[email protected]
Fixes: 4645df1035b3 ("[PATCH] aacraid: swapped kmalloc args.")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zou Wei <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Update lpfc version to 12.8.0.1
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The MDS diagnostic enablement bit for the adapter interface is incorrect in
the driver header.
Correct the bit position for the SET_FEATURE MDS bit.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Running make C=1 M=drivers/scsi/lpfc triggers sparse warnings
Correct the code generating the following errors:
- Incompatible address space assignment without proper conversion.
- Deference of usespace and per-cpu pointers.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In an audit of lockdep calls in the driver, there are multiple lockdep
checks in successive calling layers. E.g. a routine checks, and then calls
a lower routine that also checks, and so on. Calling sequences result in
many redundant checks.
Refine the code to remove lower-level lockdep checks. Update comments on
the lock, correcting a few places where lock object in comment was
incorrect.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
By default, the driver attempts to allocate a hdwq per logical cpu in order
to provide good cpu affinity. Some systems have extremely high cpu counts
and this can significantly raise memory consumption.
In testing on x86 platforms (non-AMD) it is found that sharing of a hdwq by
a physical cpu and its HT cpu can occur with little performance
degredation. By sharing, the hdwq count can be halved, significantly
reducing the memory overhead.
Change the default behavior of the driver on non-AMD x86 platforms to
share a hdwq by the cpu and its HT cpu.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Implementation of a previous patch added a condition to an if check that
always end up with the if test being true. Execution of the else clause was
inadvertently negated. The additional condition check was incorrect and
unnecessary after the other modifications had been done in that patch.
Remove the check from the if series.
Link: https://lore.kernel.org/r/[email protected]
Fixes: b95b21193c85 ("scsi: lpfc: Fix loss of remote port after devloss due to lack of RPIs")
Cc: <[email protected]> # v5.4+
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The lldd rebinds the ndlp with rport during a nvme rport registration (via
nvme_fc_register_remoteport). If rport & ndlp pointers are same as the
previous one, the lldd will re-use the ndlp and rport association without
re-initialization. This assumption is incorrect. The lldd should be
ignorant of whether the returned rport pointer is new or not, and should
always assume it is new.
Remove the re-binding code, always assumes that rport pointer received from
transport is a new pointer.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
A previous change introduced the atomic use of queue_claimed flag for eq's
and cq's. The code works fine, but the clearing of the queue_claimed flag
is not atomic.
Change queue_claimed = 0 into xchg(&queue_claimed, 0) to be consistent for
change under atomicity.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Dick Kennedy <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Currently in tcmu reservation commands are handled by core's pr
implementation (default) or completely rejected (emulate_pr set to 0). We
additionally want to be able to do full reservation handling in
userspace. Therefore we need a way to set TRANSPORT_FLAG_PASSTHROUGH_PGR.
The inverted flag is displayed by attribute pgr_support. Since we moved
the flag from transport/backend to se_device in the previous commit, we now
can make it changeable per device by allowing to write the attribute. The
new field transport_flags_changeable in transport/backend is used to reject
writing if not allowed for a backend.
Regarding ALUA we also want to be able to passthrough commands to userspace
in tcmu. Therefore we need TRANSPORT_FLAG_PASSTHROUGH_ALUA to be
changeable, because by setting it we can switch off all ALUA checks in
core. So we also set TRANSPORT_FLAG_PASSTHROUGH_ALUA in tcmu's
transport_flags_changeable.
Of course, ALUA and reservation handling in userspace will work only, if
session/nexus information is sent to userspace along with every
command. This will be object of a patch series announced by Mike Christie.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Bodo Stroesser <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
pgr_support and alua_support device attributes show the inverted value of
the transport_flags:
* TRANSPORT_FLAG_PASSTHROUGH_PGR
* TRANSPORT_FLAG_PASSTHROUGH_ALUA
These attributes are per device, while the flags are per backend. Rename
the transport_flags in backend/transport to transport_flags_default and use
this value to initialize the new transport_flags field in the se_device
structure.
Now data and attribute both are per se_device.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Bodo Stroesser <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
tcmu has not set TRANSPORT_FLAG_PASSTHROUGH_PGR. Therefore the in-core pr
emulation is active by default, but there are some attributes for
configuration missing. Add them.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Bodo Stroesser <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In commit b49d6f788530 ("scsi: target: add emulate_pr backstore attr to
toggle PR support") the new attribute emulate_pr was added.
passthrough_parse_cdb() uses the attribute's value to distinguish whether
reservation commands should be rejected or not. But the new attribute was
not added to passthrough_attrib_attrs, so in pscsi and tcmu - the users of
passthrough_parse_cdb() - the attribute is not available to change parser's
behavior.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Bodo Stroesser <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
By default DIF Type 1, DIF Type 2 & DIF Type 3 will be enabled. Also,
users can enable either DIF Type 1 or DIF Type 2 or DIF Type 3 or in any
combination using the prot_mask module parameter.
However, when the user provides a prot_mask module parameter value of zero,
then the driver is not disabling the DIF. Instead it enables all three
types.
Modify the driver to disable the DIF support if the user provides a
prot_mask module parameter value of zero.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Updated maintainers list for MPT DRIVERS
Link: https://lore.kernel.org/r/1588056428-29369-1-git-send-email-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Information needed to debug driver problems and firmware faults is stored
in the IOC’s MPT3SAS_ADAPTER data structure. Parameters such as IOCFacts,
IOC flags (related to sge, MSI-X, error recovery etc.), performance mode
type, TMs, internal commands reply status, etc. are present.
For debugging purposes, it is therefore helpful to be able to capture this
information so that the fault can be analyzed. Export the MPT3SAS_ADAPTER
data structure in debugfs. The data is available in:
/sys/kernel/debug/mpt3sas/scsi_hostX/ioc_dump
Link: https://lore.kernel.org/r/1588056322-29227-1-git-send-email-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following coccicheck warning:
drivers/scsi/mpt3sas/mpt3sas_base.c:7202:1-19: WARNING: Assignment of
0/1 to bool variable
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following coccicheck warning:
drivers/scsi/vmw_pvscsi.c:911:2-18: WARNING: Assignment of 0/1 to bool
variable
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following coccicheck warning:
drivers/scsi/fnic/fnic_scsi.c:2627:5-36: WARNING: Comparison of 0/1 to
bool variable
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following coccicheck warning:
drivers/scsi/qedi/qedi_main.c:1309:5-25: WARNING: Comparison of 0/1 to
bool variable
drivers/scsi/qedi/qedi_main.c:1315:5-25: WARNING: Comparison of 0/1 to
bool variable
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Manish Rangankar <[email protected]>
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|