| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When we fail to send a FSF request in 'zfcp_fsf_req_send()' when calling
'zfcp_qdio_send()' we try to remove the request object from our internal
hash table again to prevent keeping a stale memory reference. This removal
might still - very much theoretically - fail.
To store some evidence of when this happens add a new trace record for
this case; tag: 'fsrsrmf'.
We reuse the 'ZFCP_DBF_HBA_RES' trace ID for this, but mark all fields
other then the request ID with ~0, to make fairly obvious that these are
invalid values. This faking has to be done because we don't have a valid
request object at this point, and can not safely access any of the memory
of the old object - we just failed to find it in our hash table, so it
might be gone already.
Here is an example of a decoded trace record:
Timestamp : 2023-02-17-13:09:12:748140
Area : HBA
Subarea : 1
Level : -
Exception : 000003ff7ff500c2
CPU ID : 0011
Caller : 0x0
Record ID : 1
Tag : fsrsrmf
Request ID : 0x0000000080126ab6
Request status : 0xffffffff
FSF cmnd : 0xffffffff
FSF sequence no: 0xffffffff
FSF issued : 2042-09-18-01:53:47:370495
FSF stat : 0xffffffff
FSF stat qual : ffffffff ffffffff ffffffff ffffffff
Prot stat : 0xffffffff
Prot stat qual : ffffffff ffffffff ffffffff ffffffff
Port handle : 0xffffffff
LUN handle : 0xffffffff
This provides at least some basic evidence that this event happened, and
what object was affected.
Link: https://lore.kernel.org/r/99b8246b2d71b63fa4f9c56333e2037502f7f5af.1677000450.git.bblock@linux.ibm.com
Signed-off-by: Benjamin Block <[email protected]>
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We use different integer types throughout zfcp to store the FSF request ID
and related values; some places use 'unsigned long' and others 'u64'. On
s390x these are effectively the same type, but this might cause confusions
and is generally inconsistent.
The specification for the used hardware specifies this value as a 64-bit
number, and ultimately we use this value to communicate with the hardware,
so it makes sense to change the type of all these variables to 'u64' where
we can. The only exception being when we store it in the 'host_scribble'
field of a 'struct scsi_cmnd'; for this case we add a build time check to
make sure they are compatible.
Link: https://lore.kernel.org/r/9c9cbe5acc2b419a22dce2fed847e3db91b60201.1677000450.git.bblock@linux.ibm.com
Signed-off-by: Benjamin Block <[email protected]>
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The appropriate type for array indices is 'size_t' and the current
implementation in 'zfcp_reqlist.h' mixes 'int' and 'unsigned int' in
different places to access the hashtable buckets of our internal request
hash table.
To prevent any confusion, change all places to 'size_t'.
Link: https://lore.kernel.org/r/64afe93f6263c6b07815937826cd7d5fc4f1a674.1677000450.git.bblock@linux.ibm.com
Signed-off-by: Benjamin Block <[email protected]>
Reviewed-by: Steffen Maier <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Use scsi_execute_cmd() instead of open-coding it.
Link: https://lore.kernel.org/r/[email protected]
Cc: Mike Christie <[email protected]>
Cc: John Garry <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Do not set RQF_PM explicitly since scsi_alloc_request() sets it indirectly
if BLK_MQ_REQ_PM is set. The call chain for the code that sets RQF_PM is as
follows:
scsi_alloc_request()
blk_mq_alloc_request()
__blk_mq_alloc_requests()
blk_mq_rq_ctx_init()
if (data->flags & BLK_MQ_REQ_PM)
data->rq_flags |= RQF_PM;
Link: https://lore.kernel.org/r/[email protected]
Cc: Mike Christie <[email protected]>
Cc: John Garry <[email protected]>
Reviewed-by: John Garry <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Allow SCSI LLDs to specify SCMD_* flags.
Link: https://lore.kernel.org/r/[email protected]
Cc: Mike Christie <[email protected]>
Cc: John Garry <[email protected]>
Reviewed-by: John Garry <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Remove the repeated word "the" in comments.
[mkp: fixed additional typos in the changed lines]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bo Liu <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Remove the /proc/scsi/${proc_name} directory earlier to fix a race
condition between unloading and reloading kernel modules. This fixes a bug
introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in
the SCSI core").
Fix the following kernel warning:
proc_dir_entry 'scsi/scsi_debug' already registered
WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0
Call Trace:
proc_mkdir+0xb5/0xe0
scsi_proc_hostdir_add+0xb5/0x170
scsi_host_alloc+0x683/0x6c0
sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]
really_probe+0x159/0x540
__driver_probe_device+0xdc/0x230
driver_probe_device+0x4f/0x120
__device_attach_driver+0xef/0x180
bus_for_each_drv+0xe5/0x130
__device_attach+0x127/0x290
device_initial_probe+0x17/0x20
bus_probe_device+0x110/0x130
device_add+0x673/0xc80
device_register+0x1e/0x30
sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]
scsi_debug_init+0x64f/0x1000 [scsi_debug]
do_one_initcall+0xd7/0x470
do_init_module+0xe7/0x330
load_module+0x122a/0x12c0
__do_sys_finit_module+0x124/0x1a0
__x64_sys_finit_module+0x46/0x50
do_syscall_64+0x38/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Link: https://lore.kernel.org/r/[email protected]
Cc: Alan Stern <[email protected]>
Cc: Yi Zhang <[email protected]>
Cc: [email protected]
Fixes: 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core")
Reported-by: Yi Zhang <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix an incorrect reference to the scsi_remove_host() function in a source
code comment.
Link: https://lore.kernel.org/r/[email protected]
Fixes: b49493f99690 ("Fix a memory leak in scsi_host_dev_release()")
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Remove unneeded version.h include pointed out by 'make versioncheck'.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jesper Juhl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Remove unneeded version.h include pointed out by 'make versioncheck'.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jesper Juhl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Remove unneeded version.h include pointed out by 'make versioncheck'.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jesper Juhl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Commit c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic")
introduced an array mrioc->evtack_cmds but initialization of the array
elements was missed. They are just zero cleared. The function
mpi3mr_complete_evt_ack() refers host_tag field of the elements. Due to the
zero value of the host_tag field, the function calls clear_bit() for
mrico->evtack_cmds_bitmap with wrong bit index. This results in memory
access to invalid address and "BUG: KASAN: use-after-free". This BUG was
observed at eHBA-9600 firmware update to version 8.3.1.0. To fix it, add
the missing initialization of mrioc->evtack_cmds.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Fixes: c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic")
Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Acked-by: Sathya Prakash Veerichetty <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using
byte as unit. However, bitmap helper functions assume that bitmaps are
allocated using unsigned long as unit. This gap causes memory access beyond
the bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG
was observed at firmware download to eHBA-9600. Call trace indicated that
the out-of-bounds access happened in find_first_zero_bit() called from
mpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap.
To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use
number of bits, and call bitmap helper functions which take number of bits
as arguments. For memory allocation, call bitmap_zalloc() instead of
kzalloc() and krealloc(). For memory free, call bitmap_free() instead of
kfree(). For zero clear, call bitmap_clear() instead of memset().
Remove three fields for bitmap byte sizes in struct scmd_priv which are no
longer required. Replace the field dev_handle_bitmap_sz with
dev_handle_bitmap_bits to keep number of bits of removepend_bitmap across
resize.
Link: https://lore.kernel.org/r/[email protected]
Fixes: c5758fc72b92 ("scsi: mpi3mr: Gracefully handle online FW update operation")
Fixes: e844adb1fbdc ("scsi: mpi3mr: Implement SCSI error handler hooks")
Fixes: c1af985d27da ("scsi: mpi3mr: Add Event acknowledgment logic")
Fixes: 824a156633df ("scsi: mpi3mr: Base driver code")
Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
Acked-by: Sathya Prakash Veerichetty <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In the function mpi3mr_get_all_tgt_info(), devmap_info points to
alltgt_info->dmi then there is no need to memcpy() data from devmap_info to
alltgt_info->dmi. Remove the unnecessary memcpy(). This also allows to
remove the local variable 'rval' and the goto label 'out'.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Fixes: f5e6d5a34376 ("scsi: mpi3mr: Add support for driver commands")
Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
Acked-by: Sathya Prakash Veerichetty <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The function mpi3mr_get_all_tgt_info() has four issues:
1) It calculates valid entry length in alltgt_info assuming the header part
of the struct mpi3mr_device_map_info would equal to sizeof(u32). The
correct size is sizeof(u64).
2) When it calculates the valid entry length kern_entrylen, it excludes one
entry by subtracting 1 from num_devices.
3) It copies num_device by calling memcpy(). Substitution is enough.
4) It does not specify the calculated length to sg_copy_from_buffer().
Instead, it specifies the payload length which is larger than the
alltgt_info size. It causes "BUG: KASAN: slab-out-of-bounds".
Fix the issues by using the correct header size, removing the subtraction
from num_devices, replacing the memcpy() with substitution and specifying
the correct length to sg_copy_from_buffer().
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Fixes: f5e6d5a34376 ("scsi: mpi3mr: Add support for driver commands")
Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
Acked-by: Sathya Prakash Veerichetty <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Write only correct size (32 instead of 64 bytes).
Link: https://lore.kernel.org/r/[email protected]
Fixes: 42fc9fee116f ("scsi: mpi3mr: Add helper functions to manage device's port")
Signed-off-by: Tomas Henzl <[email protected]>
Acked-by: Sathya Prakash Veerichetty <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Nothing else defined MPI3_NVME_ENCAP_CMD_MAX, so the "command" buffer was
being defined as a fake flexible array of size 1. Replace this with a
proper flex array. Avoids this GCC 13 warning under -fstrict-flex-arrays=3:
In function 'fortify_memset_chk',
inlined from 'mpi3mr_build_nvme_sgl' at ../drivers/scsi/mpi3mr/mpi3mr_app.c:693:2,
inlined from 'mpi3mr_bsg_process_mpt_cmds.constprop' at ../drivers/scsi/mpi3mr/mpi3mr_app.c:1214:8:
../include/linux/fortify-string.h:430:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
430 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Link: https://lore.kernel.org/r/[email protected]
Cc: Sumit Saxena <[email protected]>
Cc: Himanshu Madhani <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Cc: kernel test robot <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The ipr_log_vpd_compact() function triggers a fortified memcpy() warning
about a potential string overflow with all versions of clang:
In file included from drivers/scsi/ipr.c:43:
In file included from include/linux/string.h:254:
include/linux/fortify-string.h:520:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
__write_overflow_field(p_size_field, size);
^
include/linux/fortify-string.h:520:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
2 errors generated.
I don't see anything actually wrong with the function, but this is the only
instance I can reproduce of the fortification going wrong in the kernel at
the moment, so the easiest solution may be to rewrite the function into
something that does not trigger the warning.
Instead of having a combined buffer for vendor/device/serial strings, use
three separate local variables and just truncate the whitespace
individually.
Link: https://lore.kernel.org/r/[email protected]
Cc: Kees Cook <[email protected]>
Fixes: 8cf093e275d0 ("[SCSI] ipr: Improved dual adapter errors")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Convert function ipr_probe_ioa_part2() to return void instead of int since
the current implementation always returns 0 to the caller. The
transformation also eliminates the dead code when calling
ipr_probe_ioa_part2() function. Issue identified using returnvar
Coccinelle semantic patch.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Deepak R Varma <[email protected]>
Acked-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
If a controller has DIX is enabled and an attached disk is formatted using
a protection type supported by the controller, a block integrity profile is
registered to enable protected transfers.
If the disk is subsequently reformatted to disable PI, and the controller
does not support DIX Type 0, this can lead to failures such as this:
[142829.032340] hisi_sas_v3_hw 0000:b4:04.0: erroneous completion iptt=2375 task=00000000bea0970c dev id=5 direct-attached phy4 addr=51c20dbaf642a000 CQ hdr: 0x1023 0x50947 0x0 0x20000 Error info: 0x0 0x0 0x4 0x0
[142829.073883] sas: Enter sas_scsi_recover_host busy: 1 failed: 1
[142829.079783] sas: sas_scsi_find_task: aborting task 0x00000000bea0970c
[142829.102342] sas: Internal abort: task to dev 51c20dbaf642a000 response: 0x0 status 0x5
[142829.110319] sas: sas_eh_handle_sas_errors: task 0x00000000bea0970c is done
[142829.117275] sd 7:0:5:0: [sdc] tag#2375 UNKNOWN(0x2003) Result: hostbyte=0x05 driverbyte=DRIVER_OK cmd_age=0s
[142829.127171] sd 7:0:5:0: [sdc] tag#2375 CDB: opcode=0x2a 2a 00 00 00 00 00 00 00 08 00
[142829.135059] I/O error, dev sdc, sector 0 op 0x1:(WRITE) flags 0x18800 phys_seg 1 prio class 2
This is because the block layer integrity profile is currently only set up
the first time a disk is discovered.
To address this, remove the first_scan check when configuring protection
information during revalidate. Also unregister the block integrity profile
if DIX is not supported with a given protection type.
[mkp: commit description + printk dedup]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Xingui Yang <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Since commit ce70fd9a551a ("scsi: core: Remove the cmd field from struct
scsi_request") sd_cdb_cache is unused. Remove it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Fengnan Chang <[email protected]>
Reviewed-by: John Garry <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
ufshcd_config_mcq() may change the can_queue value. The current code
invokes scsi_add_host() before ufshcd_config_mcq() so the tags are
limited to the original can_queue value.
Fix this by invoking scsi_add_host() after ufshcd_config_mcq().
Link: https://lore.kernel.org/r/8840cea4a57b46dabce18acc39afc50ab826330f.1676567593.git.quic_asutoshd@quicinc.com
Fixes: 2468da61ea09 ("scsi: ufs: core: mcq: Configure operation and runtime interface")
Signed-off-by: Asutosh Das <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following compilation error when CONFIG_PM is set to 'n':
drivers/ufs/host/ufs-mediatek.c: In function `ufs_mtk_runtime_suspend`:
drivers/ufs/host/ufs-mediatek.c:1623:8: error: implicit declaration of
function `ufshcd_runtime_suspend`; did you mean `ufs_mtk_runtime_suspend`?
[-Werror=implicit-function-declaration]
1623 | ret = ufshcd_runtime_suspend(dev);
| ^~~~~~~~~~~~~~~~~~~~~~
| ufs_mtk_runtime_suspend
drivers/ufs/host/ufs-mediatek.c: In function `ufs_mtk_runtime_resume`:
drivers/ufs/host/ufs-mediatek.c:1638:9: error: implicit declaration of function
`ufshcd_runtime_resume`; did you mean `ufs_mtk_runtime_resume`?
[-Werror=implicit-function-declaration]
1638 | return ufshcd_runtime_resume(dev);
| ^~~~~~~~~~~~~~~~~~~~~
| ufs_mtk_runtime_resume
At top level:
drivers/ufs/host/ufs-mediatek.c:1632:12: error: `ufs_mtk_runtime_resume`
defined but not used [-Werror=unused-function]
1632 | static int ufs_mtk_runtime_resume(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~
drivers/ufs/host/ufs-mediatek.c:1618:12: error: `ufs_mtk_runtime_suspend`
defined but not used [-Werror=unused-function]
1618 | static int ufs_mtk_runtime_suspend(struct device *dev)
Link: https://lore.kernel.org/r/[email protected]
Reported-by: k2ci <[email protected]>
Reported-by: Shida Zhang <[email protected]>
Signed-off-by: Yangtao Li <[email protected]>
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
During UFS initialization, devfreq initialization is asynchronous:
ufshcd_async_scan() calls ufshcd_add_lus(), which in turn initializes
devfreq for UFS. The simple ondemand governor is then loaded. If it is
built as a module, request_module() is called and throws a warning:
WARNING: CPU: 7 PID: 167 at kernel/kmod.c:136 __request_module+0x1e0/0x460
Modules linked in: crct10dif_ce llcc_qcom phy_qcom_qmp_usb ufs_qcom phy_qcom_snps_femto_v2 ufshcd_pltfrm phy_qcom_qmp_combo ufshcd_core phy_qcom_qmp_ufs qcom_wdt socinfo fuse ipv6
CPU: 7 PID: 167 Comm: kworker/u16:3 Not tainted 6.2.0-rc6-00009-g58706f7fb045 #1
Hardware name: Qualcomm SA8540P Ride (DT)
Workqueue: events_unbound async_run_entry_fn
pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __request_module+0x1e0/0x460
lr : __request_module+0x1d8/0x460
sp : ffff800009323b90
x29: ffff800009323b90 x28: 0000000000000000 x27: 0000000000000000
x26: ffff800009323d50 x25: ffff7b9045f57810 x24: ffff7b9045f57830
x23: ffffdc5a83e426e8 x22: ffffdc5ae80a9818 x21: 0000000000000001
x20: ffffdc5ae7502f98 x19: ffff7b9045f57800 x18: ffffffffffffffff
x17: 312f716572667665 x16: 642f7366752e3030 x15: 0000000000000000
x14: 000000000000021c x13: 0000000000005400 x12: ffff7b9042ed7614
x11: ffff7b9042ed7600 x10: 00000000636c0890 x9 : 0000000000000038
x8 : ffff7b9045f2c880 x7 : ffff7b9045f57c68 x6 : 0000000000000080
x5 : 0000000000000000 x4 : 8000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : ffffdc5ae5d382f0 x0 : 0000000000000001
Call trace:
__request_module+0x1e0/0x460
try_then_request_governor+0x7c/0x100
devfreq_add_device+0x4b0/0x5fc
ufshcd_async_scan+0x1d4/0x310 [ufshcd_core]
async_run_entry_fn+0x34/0xe0
process_one_work+0x1d0/0x320
worker_thread+0x14c/0x444
kthread+0x10c/0x110
ret_from_fork+0x10/0x20
This occurs because synchronous module loading from async is not
allowed. According to __request_module():
/*
* We don't allow synchronous module loading from async. Module
* init may invoke async_synchronize_full() which will end up
* waiting for this task which already is waiting for the module
* loading to complete, leading to a deadlock.
*/
Such a deadlock was experienced on the Qualcomm QDrive3/sa8540p-ride. With
DEVFREQ_GOV_SIMPLE_ONDEMAND=m, the boot hangs after the warning.
Fix both the warning and the deadlock by moving devfreq initialization out
of the async routine.
Tested on the sa8540p-ride by using fio to put the UFS under load, and
printing the trace generated by
/sys/kernel/tracing/events/ufs/ufshcd_clk_scaling events. The trace looks
similar with and without the change.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Adrien Thierry <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The TC G210 driver only supports devices declared in the device tree.
Hence make this driver dependent on CONFIG_OF. This patch fixes the
following compiler error:
drivers/ufs/host/tc-dwc-g210-pltfrm.c:36:34: error: ‘tc_dwc_g210_pltfm_match’ defined but not used [-Werror=unused-const-variable=]
36 | static const struct of_device_id tc_dwc_g210_pltfm_match[] = {
|
Link: https://lore.kernel.org/r/[email protected]
Cc: Joao Pinto <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Reviewed-by: Bean Huo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The LLDD and the stack currently process FPINs received from the fabric,
but the stack is not aware of any action taken by the driver to alleviate
congestion. The current interface between the driver and the SCSI stack is
limited to passing the notification mainly for statistics and heuristics.
The reaction to an FPIN could be handled either by the driver or by the
stack (marginal path and failover). Amend the interface to indicate if
action on an FPIN has already been reacted to by the LLDDs or not. Add an
additional flag to fc_host_fpin_rcv() to indicate if the FPIN has been
acknowledged/reacted to by the driver.
Also added a new event code FCH_EVT_LINK_FPIN_ACK to notify to the user
that the event has been acknowledged/reacted by the LLDD driver
Link: https://lore.kernel.org/r/[email protected]
Co-developed-by: Anil Gurumurthy <[email protected]>
Signed-off-by: Anil Gurumurthy <[email protected]>
Co-developed-by: Nilesh Javali <[email protected]>
Signed-off-by: Nilesh Javali <[email protected]>
Signed-off-by: Muneendra <[email protected]>
Reviewed-by: James Smart <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Reviewed-by: Ewan D. Milne <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
An enclosure with no components can't usefully be operated by the driver
(since effectively it has nothing to manage), so report the problem and
don't attach. Not attaching also fixes an oops which could occur if the
driver tries to manage a zero component enclosure.
[mkp: Switched to KERN_WARNING since this scenario is common]
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Reported-by: Ding Hui <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]
Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013
When edev->components is zero, accessing edev->component[0] members is
wrong.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Tomas Henzl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Sanitize possible desc_ptr out-of-bounds accesses in
ses_enclosure_data_process().
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Tomas Henzl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Sanitize possible addl_desc_ptr out-of-bounds accesses in
ses_enclosure_data_process().
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Tomas Henzl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x949/0xe30 [ses]
Read of size 1 at addr ffff88a1b043a451 by task systemd-udevd/3271
Checking after (and before in next loop) addl_desc_ptr[1] is sufficient, we
expect the size to be sanitized before first access to addl_desc_ptr[1].
Make sure we don't walk beyond end of page.
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Tomas Henzl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
If an error occurs, some memory may need to be freed, as in the other error
handling paths.
Before the commit in the Fixes tag, this test was done before the memory
allocation, so there was no issue.
Fixes: 16ed9d312b42 ("scsi: ufs: core: Remove ufshcd_map_desc_id_to_length()")
Link: https://lore.kernel.org/r/2c6e42205e5ec22e5e8c7c85c6deb8fde31c74da.1673781835.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In the UFS error handling flow, the host will send a device management cmd
(NOP OUT) to the device for link recovery. If this cmd times out and
clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and
return. hba->dev_cmd.complete struct is not set to NULL.
When this happens, if cmd has been completed by device, then we will call
complete() in __ufshcd_transfer_req_compl(). Because the complete struct is
allocated on the stack, the following crash will occur:
ipanic_die+0x24/0x38 [mrdump]
die+0x344/0x748
arm64_notify_die+0x44/0x104
do_debug_exception+0x104/0x1e0
el1_dbg+0x38/0x54
el1_sync_handler+0x40/0x88
el1_sync+0x8c/0x140
queued_spin_lock_slowpath+0x2e4/0x3c0
__ufshcd_transfer_req_compl+0x3b0/0x1164
ufshcd_trc_handler+0x15c/0x308
ufshcd_host_reset_and_restore+0x54/0x260
ufshcd_reset_and_restore+0x28c/0x57c
ufshcd_err_handler+0xeb8/0x1b6c
process_one_work+0x288/0x964
worker_thread+0x4bc/0xc7c
kthread+0x15c/0x264
ret_from_fork+0x10/0x30
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mason Zhang <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add check for dma_map_single() and return error if it fails in order to
avoid invalid DMA address.
Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jiasheng Jiang <[email protected]>
Reviewed-by: Jason Yan <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct report_log_lun_list.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://lore.kernel.org/r/Y+LJz/r6+UeLqnV3@work
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/204
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Acked-by: Don Brace <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add a forgotten kfree().
Fixes: dbec4c9040ed ("scsi: mpt3sas: lockless command submission")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Tomas Henzl <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Variable wwn is not used. Delete it.
drivers/scsi/qla2xxx/qla_init.c:1657:6: warning: variable 'wwn' set but not used.
Link: https://lore.kernel.org/r/[email protected]
Reported-by: Abaci Robot <[email protected]>
Signed-off-by: Jiapeng Chong <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the following kernel-doc warnings:
drivers/ufs/core/ufs-mcq.c:87: warning: Function parameter or member 'hba' not described in 'ufshcd_mcq_config_mac'
drivers/ufs/core/ufs-mcq.c:87: warning: Function parameter or member 'max_active_cmds' not described in 'ufshcd_mcq_config_mac'
drivers/ufs/core/ufs-mcq.c:107: warning: Function parameter or member 'hba' not described in 'ufshcd_mcq_req_to_hwq'
drivers/ufs/core/ufs-mcq.c:107: warning: Function parameter or member 'req' not described in 'ufshcd_mcq_req_to_hwq'
drivers/ufs/core/ufs-mcq.c:128: warning: Function parameter or member 'hba' not described in 'ufshcd_mcq_decide_queue_depth'
Link: https://lore.kernel.org/r/[email protected]
Fixes: 854f84e7feeb ("scsi: ufs: core: mcq: Find hardware queue to queue request")
Fixes: 2468da61ea09 ("scsi: ufs: core: mcq: Configure operation and runtime interface")
Fixes: 7224c806876e ("scsi: ufs: core: mcq: Calculate queue depth")
Cc: Asutosh Das <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add freeze, thaw, and restore callbacks for hibernate and restore
functionality.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Anjana Hari <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic at
once.
Link: https://lore.kernel.org/r/[email protected]
Cc: Karan Tilak Kumar <[email protected]>
Cc: Sesidhar Baddela <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The three DMA memory regions allocated for the host memory space are
documented to require alignment of 128, 1024, and 1024 respectively, but
the returned address is checked for PAGE_SIZE alignment.
In the case where these allocations are serviced by e.g. the Arm SMMU, the
size and alignment will be determined by its supported page sizes. In most
cases SZ_4K and a few larger sizes are available.
In the typical configuration this does not cause problems, but in the event
that the system PAGE_SIZE is increased beyond 4k, it's no longer reasonable
to expect that the allocation will be PAGE_SIZE aligned.
Limit the DMA alignment check to the actual alignment requirements written
in the comments in the code, to avoid the UFS core refusing to initialize
with such configuration.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Correct spelling problems for Documentation/scsi/ as reported by codespell.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
Cc: "James E.J. Bottomley" <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: [email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Correct spelling problems for Documentation/scsi/ ChangeLogs as reported by
codespell.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
Cc: "James E.J. Bottomley" <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: [email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Correct spelling problems for Documentation/target/ as reported by
codespell.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The aac_priv() helper assumes that the private cmd area immediately follows
struct scsi_cmnd. Allocate this space as part of scsicmd, else there is a
risk of heap overflow. Seen with GCC 13:
../drivers/scsi/aacraid/aachba.c: In function 'aac_probe_container':
../drivers/scsi/aacraid/aachba.c:841:26: warning: array subscript 16 is outside array bounds of 'void[392]' [-Warray-bounds=]
841 | status = cmd_priv->status;
| ^~
In file included from ../include/linux/resource_ext.h:11,
from ../include/linux/pci.h:40,
from ../drivers/scsi/aacraid/aachba.c:22:
In function 'kmalloc',
inlined from 'kzalloc' at ../include/linux/slab.h:720:9,
inlined from 'aac_probe_container' at ../drivers/scsi/aacraid/aachba.c:821:30:
../include/linux/slab.h:580:24: note: at offset 392 into object of size 392 allocated by 'kmalloc_trace'
580 | return kmalloc_trace(
| ^~~~~~~~~~~~~~
581 | kmalloc_caches[kmalloc_type(flags)][index],
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
582 | flags, size);
| ~~~~~~~~~~~~
Fixes: 76a3451b64c6 ("scsi: aacraid: Move the SCSI pointer to private command data")
Link: https://lore.kernel.org/r/[email protected]
Cc: Bart Van Assche <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Cc: Himanshu Madhani <[email protected]>
Cc: Adaptec OEM Raid Solutions <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Kees Cook <[email protected]>
Reviewed-by: Vegard Nossum <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Abel Vesa <[email protected]> says:
This patchset adds UFS HC support for the new Qualcomm SM8550 SoC.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Document the compatible string for the UFS found on SM8550.
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
On SM8550, depending on the Qunipro, we can run with G5 or G4. For now,
when the major version is 5 or above, we go with G5. Therefore, we need to
specifically tell UFS HC that.
Signed-off-by: Abel Vesa <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The newly added MSI support is mostly hidden inside of an #ifdef,
except for one line that now causes a build failure when MSI
is disabled:
drivers/ufs/host/ufs-qcom.c: In function 'ufs_qcom_remove':
drivers/ufs/host/ufs-qcom.c:1698:9: error: implicit declaration of function 'platform_msi_domain_free_irqs' [-Werror=i]
1698 | platform_msi_domain_free_irqs(hba->dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Above that, the symbol that guards the other call was recently removed, so
that is all dead code at the moment.
Remove the incorrect #ifdef and instead of a Kconfig dependency to only
allow building the driver when CONFIG_GENERIC_MSI_IRQ is enabled. This
symbol is always present when PCI_MSI or ARM_GIC_V3_ITS are enabled, both
of which should be present on kernels that can run on Qualcomm SoCs.
The 'select RESET_CONTROLLER' in combination with this dependency
unfortunately causes a dependency loop and this is a user-visible symbol,
so it's better to change both to 'depends on'.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 519b6274a777 ("scsi: ufs: qcom: Add MCQ ESI config vendor specific ops")
Fixes: 13e7accb81d6 ("genirq: Get rid of GENERIC_MSI_IRQ_DOMAIN")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Manivannan Sadhasivam <[email protected]>
Acked-by: Can Guo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|