| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
An error is detected with the following report when unloading the driver:
"KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"
The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the
flag is not cleared upon completion of the login.
This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set
to LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used
as an rpi_ids array index.
Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
lpfc_mbx_cmpl_fc_reg_login().
Link: https://lore.kernel.org/r/[email protected]
Co-developed-by: Justin Tee <[email protected]>
Signed-off-by: Justin Tee <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Applications determine loop support in part by querying the 'pls' sysfs
node. Reporting of 'pls' (Private Loop Support) is derived from the
descriptor returned by the COMMON_GET_SLI4_PARAMETERS mailbox command,
which is issued during initialization or after a reset.
The value of this field may change if there is a dynamic SFP change. The
driver currently will not pick up the change as there was no reset
scenario.
Rework to commonize the sending of the COMMON_GET_SLI4_PARAMETERS
command. Add the calling of the routine after receipt of an async event
indicating an SFP change.
Link: https://lore.kernel.org/r/[email protected]
Co-developed-by: Justin Tee <[email protected]>
Signed-off-by: Justin Tee <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
A prior patch introduced HBA_NEEDS_CFG_PORT flag logic, but in
lpfc_sli_brdrestart_s3() code path, right after HBA_NEEDS_CFG_PORT is set,
the phba->hba_flag is cleared in lpfc_sli_brdreset().
Fix by calling lpfc_sli_chipset_init() to wait for successful restart of
the HBA in lpfc_host_reset_handler() after lpfc_sli_brdrestart().
lpfc_sli_chipset_init() sets the HBA_NEEDS_CFG_PORT flag so that the
lpfc_sli_hba_setup() routine from lpfc_online() will execute
lpfc_sli_config_port() initialization step when the brdrestart is
successful.
Link: https://lore.kernel.org/r/[email protected]
Fixes: d2f2547efd39 ("scsi: lpfc: Fix auto sli_mode and its effect on CONFIG_PORT for SLI3")
Co-developed-by: Justin Tee <[email protected]>
Signed-off-by: Justin Tee <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
driver_resource_setup()
In cases when lpfc_enable_pci_dev() fails, lpfc_printf_log() with
LOG_TRACE_EVENT set will call lpfc_dmp_dbg() which uses the
phba->port_list_lock.
However, phba->port_list_lock does not get initialized until
lpfc_setup_driver_resource_phase1(). Thus, any initialization routine with
LOG_TRACE_EVENT log message prior to lpfc_setup_driver_resource_phase1()
will crash.
Revert LOG_TRACE_EVENT back to LOG_INIT for all log messages in routines
prior to lpfc_setup_driver_resource_phase1().
Link: https://lore.kernel.org/r/[email protected]
CC: Zheyu Ma <[email protected]>
Co-developed-by: Justin Tee <[email protected]>
Signed-off-by: Justin Tee <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
PA_PWRMODEUSERDATA0 -> DL_FC0PROTTIMEOUTVAL
PA_PWRMODEUSERDATA1 -> DL_TC0REPLAYTIMEOUTVAL
PA_PWRMODEUSERDATA2 -> DL_AFC0REQTIMEOUTVAL
Link: https://lore.kernel.org/r/[email protected]
Fixes: a967ddb22d94 ("scsi: ufs: ufs-exynos: Apply vendor-specific values for three timeouts")
Cc: Alim Akhtar <[email protected]>
Cc: Kiwoong Kim <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Alim Akhtar <[email protected]>
Reviewed-by: Avri Altman <[email protected]>
Signed-off-by: Chanho Park <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
UFS drivers that probe defer will end up leaking memory allocated for clk
and regulator names via kstrdup() because the structure that is holding
this memory is allocated via devm_* variants which will be freed during
probe defer but the names are never freed.
Use same devm_* variant of kstrdup to free the memory allocated to name
when driver probe defers.
Kmemleak found around 11 leaks on Qualcomm Dragon Board RB5:
unreferenced object 0xffff66f243fb2c00 (size 128):
comm "kworker/u16:0", pid 7, jiffies 4294893319 (age 94.848s)
hex dump (first 32 bytes):
63 6f 72 65 5f 63 6c 6b 00 76 69 72 74 75 61 6c core_clk.virtual
2f 77 6f 72 6b 71 75 65 75 65 2f 73 63 73 69 5f /workqueue/scsi_
backtrace:
[<000000006f788cd1>] slab_post_alloc_hook+0x88/0x410
[<00000000cfd1372b>] __kmalloc_track_caller+0x138/0x230
[<00000000a92ab17b>] kstrdup+0xb0/0x110
[<0000000037263ab6>] ufshcd_pltfrm_init+0x1a8/0x500
[<00000000a20a5caa>] ufs_qcom_probe+0x20/0x58
[<00000000a5e43067>] platform_probe+0x6c/0x118
[<00000000ef686e3f>] really_probe+0xc4/0x330
[<000000005b18792c>] __driver_probe_device+0x88/0x118
[<00000000a5d295e8>] driver_probe_device+0x44/0x158
[<000000007e83f58d>] __device_attach_driver+0xb4/0x128
[<000000004bfa4470>] bus_for_each_drv+0x68/0xd0
[<00000000b89a83bc>] __device_attach+0xec/0x170
[<00000000ada2beea>] device_initial_probe+0x14/0x20
[<0000000079921612>] bus_probe_device+0x9c/0xa8
[<00000000d268bf7c>] deferred_probe_work_func+0x90/0xd0
[<000000009ef64bfa>] process_one_work+0x29c/0x788
unreferenced object 0xffff66f243fb2c80 (size 128):
comm "kworker/u16:0", pid 7, jiffies 4294893319 (age 94.848s)
hex dump (first 32 bytes):
62 75 73 5f 61 67 67 72 5f 63 6c 6b 00 00 00 00 bus_aggr_clk....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
With this patch no memory leaks are reported.
Link: https://lore.kernel.org/r/[email protected]
Fixes: aa4976130934 ("ufs: Add regulator enable support")
Fixes: c6e79dacd86f ("ufs: Add clock initialization support")
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
sched_clock() is not meant to be used in portable driver code, and assuming
a particular clock frequency is not how this is meant to be used. It also
causes a build failure because of a missing header inclusion:
drivers/scsi/ufs/ufs-mediatek.c:321:12: error: implicit declaration of function 'sched_clock' [-Werror,-Wimplicit-function-declaration]
timeout = sched_clock() + retry_ms * 1000000UL;
A better interface to use here ktime_get_mono_fast_ns(), which works mostly
like ktime_get() but is safe to use inside of a suspend callback.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 9561f58442e4 ("scsi: ufs: mediatek: Support vops pre suspend to disable auto-hibern8")
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Commit a264cf5e81c7 ("scsi: ibmvfc: Fix command state accounting and stale
response detection") introduced a regression in detecting duplicate
responses. This was observed in test where a command was sent to the VIOS
and completed before ibmvfc_send_event() set the active flag to 1, which
resulted in the atomic_dec_if_positive() call in ibmvfc_handle_crq()
thinking this was a duplicate response, which resulted in scsi_done() not
getting called, so we then hit a SCSI command timeout for this command once
the timeout expires. This simply ensures the active flag gets set prior to
making the hcall to send the command to the VIOS, in order to close this
window.
Link: https://lore.kernel.org/r/[email protected]
Fixes: a264cf5e81c7 ("scsi: ibmvfc: Fix command state accounting and stale response detection")
Cc: [email protected]
Acked-by: Tyrel Datwyler <[email protected]>
Signed-off-by: Brian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This symbol is not used outside of mpt3sas_ctl.c, mark it static.
Fixes the following sparse warning:
drivers/scsi/mpt3sas/mpt3sas_ctl.c:3988:18: warning: symbol
'mpt3sas_dev_attrs' was not declared. Should it be static?
Link: https://lore.kernel.org/r/[email protected]
Fixes: 1bb3ca27d2ca ("scsi: mpt3sas: Switch to attribute groups")
Reported-by: Abaci Robot <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Jiapeng Chong <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add 22.5 Gbps link rate definitions.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: John Garry <[email protected]>
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Just use the %pg format specifier instead.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Use the memcpy_{from,to}_bvec() helpers instead of open coding them.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Implement the ->restore() PM operation and set the link to off, which will
force a full reset and restore. This ensures that Host Performance Booster
is reset after suspend-to-disk.
The Host Performance Booster feature caches logical-to-physical mapping
information in the host memory. After suspend-to-disk, such information is
not valid, so a full reset and restore is needed.
A full reset and restore is done if the SPM level is 5 or 6, but not for
other SPM levels, so this change fixes those cases.
A full reset and restore also restores base address registers, so that code
is removed.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Avri Altman <[email protected]>
Signed-off-by: Adrian Hunter <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The sgl is freed in the target stack in target_release_cmd_kref() before
calling qlt_free_cmd() but there is an unmap of sgl in qlt_free_cmd() that
causes a panic if sgl is not yet DMA unmapped:
NIP dma_direct_unmap_sg+0xdc/0x180
LR dma_direct_unmap_sg+0xc8/0x180
Call Trace:
ql_dbg_prefix+0x68/0xc0 [qla2xxx] (unreliable)
dma_unmap_sg_attrs+0x54/0xf0
qlt_unmap_sg.part.19+0x54/0x1c0 [qla2xxx]
qlt_free_cmd+0x124/0x1d0 [qla2xxx]
tcm_qla2xxx_release_cmd+0x4c/0xa0 [tcm_qla2xxx]
target_put_sess_cmd+0x198/0x370 [target_core_mod]
transport_generic_free_cmd+0x6c/0x1b0 [target_core_mod]
tcm_qla2xxx_complete_free+0x6c/0x90 [tcm_qla2xxx]
The sgl may be left unmapped in error cases of response sending. For
instance, qlt_rdy_to_xfer() maps sgl and exits when session is being
deleted keeping the sgl mapped.
This patch removes use-after-free of the sgl and ensures that the sgl is
unmapped for any command that was not sent to firmware.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Dmitry Bogdanov <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of
qla2x00_process_els()"), intended to change:
bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN
to:
bsg_job->request->msgcode != FC_BSG_RPT_ELS
but changed it to:
bsg_job->request->msgcode == FC_BSG_RPT_ELS
instead.
Change the == to a != to avoid leaking the fcport structure or freeing
unallocated memory.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()")
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Joy Gu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver probing function should return < 0 for failure, otherwise
kernel will treat value > 0 as success.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Himanshu Madhani <[email protected]>
Signed-off-by: Zheyu Ma <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We never checked for errors on add_disk() as this function returned
void. Now that this is fixed, use the shiny new error handling.
Just put the cdrom kref and have the unwinding be done by
sr_kref_release().
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Acked-by: Martin K. Petersen <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We never checked for errors on add_disk() as this function returned
void. Now that this is fixed, use the shiny new error handling.
As with the error handling for device_add() we follow the same logic and
just put the device so that cleanup is done via the scsi_disk_release().
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Acked-by: Martin K. Petersen <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When userspace changes the LUN's ALUA group, it will set the LUN's group to
NULL then to the new group. Before the new group is set,
target_alua_state_check() will return 0 and allow the I/O to execute. This
has us skip the NULL stage, and just swap in the new group.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We are only holding the lun_tg_pt_gp_lock in target_alua_state_check() to
make sure tg_pt_gp is not freed from under us while we copy the state,
delay, ID values. We can instead use RCU here to access the tg_pt_gp.
With this patch IOPs can increase up to 10% for jobs like:
fio --filename=/dev/sdX --direct=1 --rw=randrw --bs=4k \
--ioengine=libaio --iodepth=64 --numjobs=N
when there are multiple sessions (running that fio command to each /dev/sdX
or using multipath and there are over 8 paths), or more than 8 queues for
the loop or vhost with multiple threads case and numjobs > 8.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We can't free the tg_pt_gp in core_alua_set_tg_pt_gp_id() because it's
still accessed via configfs. Its release must go through the normal
configfs/refcount process.
The max alua_tg_pt_gps_count check should probably have been done in
core_alua_allocate_tg_pt_gp(), but with the current code userspace could
have created 0x0000ffff + 1 groups, but only set the id for 0x0000ffff.
Then it could have deleted a group with an ID set, and then set the ID for
that extra group and it would work ok.
It's unlikely, but just in case this patch continues to allow that type of
behavior, and just fixes the kfree() while in use bug.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This patch fixes the following bugs:
1. If there are multiple ordered cmds queued and multiple simple cmds
completing, target_restart_delayed_cmds() could be called on different
CPUs and each instance could start a ordered cmd. They could then run in
different orders than they were queued.
2. target_restart_delayed_cmds() and target_handle_task_attr() can race
where:
1. target_handle_task_attr() has passed the simple_cmds == 0 check.
2. transport_complete_task_attr() then decrements simple_cmds to 0.
3. transport_complete_task_attr() runs target_restart_delayed_cmds() and
it does not see any cmds on the delayed_cmd_list.
4. target_handle_task_attr() adds the cmd to the delayed_cmd_list.
The cmd will then end up timing out.
3. If we are sent > 1 ordered cmds and simple_cmds == 0, we can execute
them out of order, because target_handle_task_attr() will hit that
simple_cmds check first and return false for all ordered cmds sent.
4. We run target_restart_delayed_cmds() after every cmd completion, so if
there is more than 1 simple cmd running, we start executing ordered cmds
after that first cmd instead of waiting for all of them to complete.
5. Ordered cmds are not supposed to start until HEAD OF QUEUE and all older
cmds have completed, and not just simple.
6. It's not a bug but it doesn't make sense to take the delayed_cmd_lock
for every cmd completion when ordered cmds are almost never used. Just
replacing that lock with an atomic increases IOPs by up to 10% when
completions are spread over multiple CPUs and there are multiple
sessions/ mqs/thread accessing the same device.
This patch moves the queued delayed handling to a per device work to
serialze the cmd executions for each device and adds a new counter to track
HEAD_OF_QUEUE and SIMPLE cmds. We can then check the new counter to
determine when to run the work on the completion path.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We can race where target_handle_task_attr() has put the cmd on the
delayed_cmd_list. Then target_restart_delayed_cmds() has removed it and set
CMD_T_SENT, but then target_execute_cmd() now clears that bit.
This patch moves the clearing to before we've put the cmd on the list.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Lee Duncan <[email protected]>
Signed-off-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix the location of delay for ref-clk gating and ungating in
ufs_mtk_setup_ref_clk().
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Peter Wang <[email protected]>
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add proper header for using sched_clock().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Introduce default delay time for gating or ungating reference clock instead
of ambiguous magic numbers.
The defined value is suitable for all current MediaTek UFS platforms.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Stanley Chu <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Tcmu populates the data area (used for communication with userspace) with
pages that are allocated by calling alloc_page(GFP_NOIO). Therefore
previous content of the allocated pages is exposed to user space. Avoid
this by adding __GFP_ZERO flag.
Zeroing the pages does (nearly) not affect tcmu throughput, because
allocated pages are re-used for the data transfers of later SCSI cmds.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bodo Stroesser <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Enable Delayed ACK to reduce the number of TCP ACKs.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Varun Prakash <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Current value of max DataSegmentLength is 8K. T5/T6 adapters support
DataSegmentLength upto 16K. Increase max DataSegmentLength.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Varun Prakash <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The following issue was observed running syzkaller:
BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline]
BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815
CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe4/0x14a lib/dump_stack.c:118
print_address_description+0x73/0x280 mm/kasan/report.c:253
kasan_report_error mm/kasan/report.c:352 [inline]
kasan_report+0x272/0x370 mm/kasan/report.c:410
memcpy+0x1f/0x50 mm/kasan/kasan.c:302
memcpy include/linux/string.h:377 [inline]
sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021
resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772
schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429
scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835
scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896
scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034
__blk_run_queue_uncond block/blk-core.c:464 [inline]
__blk_run_queue+0x1a4/0x380 block/blk-core.c:484
blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78
sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847
sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716
sg_write+0x64/0xa0 drivers/scsi/sg.c:622
__vfs_write+0xed/0x690 fs/read_write.c:485
kill_bdev:block_device:00000000e138492c
vfs_write+0x184/0x4c0 fs/read_write.c:549
ksys_write+0x107/0x240 fs/read_write.c:599
do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
We get 'alen' from command its type is int. If userspace passes a large
length we will get a negative 'alen'.
Switch n, alen, and rlen to u32.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Douglas Gilbert <[email protected]>
Signed-off-by: Ye Bin <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The following warning was observed running syzkaller:
[ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;
[ 3813.830724] program syz-executor not setting count and/or reply_len properly
[ 3813.836956] ==================================================================
[ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0
[ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549
[ 3813.846612] Call Trace:
[ 3813.846995] dump_stack+0x108/0x15f
[ 3813.847524] print_address_description+0xa5/0x372
[ 3813.848243] kasan_report.cold+0x236/0x2a8
[ 3813.849439] check_memory_region+0x240/0x270
[ 3813.850094] memcpy+0x30/0x80
[ 3813.850553] sg_copy_buffer+0x157/0x1e0
[ 3813.853032] sg_copy_from_buffer+0x13/0x20
[ 3813.853660] fill_from_dev_buffer+0x135/0x370
[ 3813.854329] resp_readcap16+0x1ac/0x280
[ 3813.856917] schedule_resp+0x41f/0x1630
[ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0
[ 3813.862699] scsi_dispatch_cmd+0x330/0x950
[ 3813.863329] scsi_request_fn+0xd8e/0x1710
[ 3813.863946] __blk_run_queue+0x10b/0x230
[ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400
[ 3813.865220] sg_common_write.isra.0+0xe61/0x2420
[ 3813.871637] sg_write+0x6c8/0xef0
[ 3813.878853] __vfs_write+0xe4/0x800
[ 3813.883487] vfs_write+0x17b/0x530
[ 3813.884008] ksys_write+0x103/0x270
[ 3813.886268] __x64_sys_write+0x77/0xc0
[ 3813.886841] do_syscall_64+0x106/0x360
[ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9
This issue can be reproduced with the following syzkaller log:
r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0)
r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00')
open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)
r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782)
write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)
In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass
the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This
leads to OOB in sg_copy_buffer().
To solve this issue, define alloc_len as u32.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Douglas Gilbert <[email protected]>
Signed-off-by: Ye Bin <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The variable retval is being initialized with a value that is never read,
it is being updated immediately afterwards. The assignment 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")
|
|
'netdev->priv_flags & IFF_BONDING && netdev->flags & IFF_MASTER' is defined
as netif_is_bond_master() in netdevice.h. Replace it to clean up code.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Lee Duncan <[email protected]>
Signed-off-by: MichelleJin <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
initialize_event_pool()
During driver probe we allocate a dma region for our event pool.
Currently, zero is passed for the gfp_flags parameter. Driver probe
callbacks are run in process context and we hold no locks so we can sleep
here if necessary.
Fix by passing GFP_KERNEL explicitly to dma_alloc_coherent().
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Brian King <[email protected]>
Signed-off-by: Tyrel Datwyler <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
I intended to move from snprintf() to scnprintf() in the previous patch but
I messed up and did not do that. The result of my bug is that it this
function could trigger a WARN() if the buffer is too large.
Link: https://lore.kernel.org/r/20211013083005.GA8592@kili
Fixes: 76a4f7cc5973 ("scsi: mpi3mr: Clean up mpi3mr_print_ioc_info()")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
For SD cardreaders it is extremely common not to have a cache.
Consequently, the following messages do not point to a real error one could
try to fix but rather describe how the disk works:
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
Print these messages as warnings instead of errors.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin Kepplinger <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
After commit ed4246d37f3b ("scsi: sd: REQUEST SENSE for
BLIST_IGN_MEDIA_CHANGE devices in runtime_resume()"), the following crash
was observed.
static int sd_resume_runtime(struct device *dev)
{
struct scsi_disk *sdkp = dev_get_drvdata(dev);
struct scsi_device *sdp = sdkp->device; // sdkp == NULL and crash
if (sdp->ignore_media_change) {
...
}
It is possible for sdkp to be NULL in sd_resume_runtime(). To fix this
crash, follow sd_resume() to test if sdkp is NULL before dereferencing it.
Crash:
[ 4.695171][ T151] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
[ 4.696591][ T151] Mem abort info:
[ 4.697919][ T151] ESR = 0x96000005
[ 4.699692][ T151] EC = 0x25: DABT (current EL), IL = 32 bits
[ 4.701990][ T151] SET = 0, FnV = 0
[ 4.702513][ T151] EA = 0, S1PTW = 0
[ 4.704431][ T151] FSC = 0x05: level 1 translation fault
[ 4.705254][ T151] Data abort info:
[ 4.705806][ T151] ISV = 0, ISS = 0x00000005
[ 4.706484][ T151] CM = 0, WnR = 0
[ 4.707048][ T151] [0000000000000008] user address but active_mm is swapper
[ 4.710577][ T151] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 4.832361][ T151] Kernel Offset: 0x12acc80000 from 0xffffffc010000000
[ 4.833254][ T151] PHYS_OFFSET: 0x40000000
[ 4.833814][ T151] pstate: 80400005 (Nzcv daif +PAN -UAO)
[ 4.834546][ T151] pc : sd_resume_runtime+0x20/0x14c
[ 4.835227][ T151] lr : scsi_runtime_resume+0x84/0xe4
[ 4.835916][ T151] sp : ffffffc0110db8d0
[ 4.836450][ T151] x29: ffffffc0110db8d0 x28: 0000000000000001
[ 4.837258][ T151] x27: ffffff80c0bd1ac0 x26: ffffff80c0bd1ad0
[ 4.838063][ T151] x25: ffffff80cea7e448 x24: ffffffd2bf961000
[ 4.838867][ T151] x23: ffffffd2be69f838 x22: ffffffd2bd9dfb4c
[ 4.839670][ T151] x21: 0000000000000000 x20: ffffff80cea7e000
[ 4.840474][ T151] x19: ffffff80cea7e260 x18: ffffffc0110dd078
[ 4.841277][ T151] x17: 00000000658783d9 x16: 0000000051469dac
[ 4.842081][ T151] x15: 00000000b87f6327 x14: 0000000068fd680d
[ 4.842885][ T151] x13: ffffff80c0bd2470 x12: ffffffd2bfa7f5f0
[ 4.843688][ T151] x11: 0000000000000078 x10: 0000000000000001
[ 4.844492][ T151] x9 : 00000000000000b1 x8 : ffffffd2be69f88c
[ 4.845295][ T151] x7 : ffffffd2bd9e0e5c x6 : 0000000000000000
[ 4.846099][ T151] x5 : 0000000000000080 x4 : 0000000000000001
[ 4.846902][ T151] x3 : 68fd680dfe4ebe5e x2 : 0000000000000003
[ 4.847706][ T151] x1 : ffffffd2bf7f9380 x0 : ffffff80cea7e260
[ 4.856708][ T151] die+0x16c/0x59c
[ 4.857191][ T151] __do_kernel_fault+0x1e8/0x210
[ 4.857833][ T151] do_page_fault+0xa4/0x654
[ 4.858418][ T151] do_translation_fault+0x6c/0x1b0
[ 4.859083][ T151] do_mem_abort+0x68/0x10c
[ 4.859655][ T151] el1_abort+0x40/0x64
[ 4.860182][ T151] el1h_64_sync_handler+0x54/0x88
[ 4.860834][ T151] el1h_64_sync+0x7c/0x80
[ 4.861395][ T151] sd_resume_runtime+0x20/0x14c
[ 4.862025][ T151] scsi_runtime_resume+0x84/0xe4
[ 4.862667][ T151] __rpm_callback+0x1f4/0x8cc
[ 4.863275][ T151] rpm_resume+0x7e8/0xaa4
[ 4.863836][ T151] __pm_runtime_resume+0xa0/0x110
[ 4.864489][ T151] sd_probe+0x30/0x428
[ 4.865016][ T151] really_probe+0x14c/0x500
[ 4.865602][ T151] __driver_probe_device+0xb4/0x18c
[ 4.866278][ T151] driver_probe_device+0x60/0x2c4
[ 4.866931][ T151] __device_attach_driver+0x228/0x2bc
[ 4.867630][ T151] __device_attach_async_helper+0x154/0x21c
[ 4.868398][ T151] async_run_entry_fn+0x5c/0x1c4
[ 4.869038][ T151] process_one_work+0x3ac/0x590
[ 4.869670][ T151] worker_thread+0x320/0x758
[ 4.870265][ T151] kthread+0x2e8/0x35c
[ 4.870792][ T151] ret_from_fork+0x10/0x20
Link: https://lore.kernel.org/r/[email protected]
Fixes: ed4246d37f3b ("scsi: sd: REQUEST SENSE for BLIST_IGN_MEDIA_CHANGE devices in runtime_resume()")
Cc: Stanley Chu <[email protected]>
Reviewed-by: Martin Kepplinger <[email protected]>
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Miles Chen <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
When scanning devices through the 'scan' attribute in sysfs, the user will
observe duplicate device entries in lsscsi command output.
Set the shost's max_channel to zero to avoid this.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 824a156633df ("scsi: mpi3mr: Base driver code")
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
All SCSI drivers have been converted to use shost_groups and sdev_groups
instead of shost_attrs or sdev_attrs. Hence remove shost_attrs and
sdev_attrs. Additionally, remove the 'lld_attr_group' members and also
the scsi_convert_dev_attrs() function.
Link: https://lore.kernel.org/r/[email protected]
Cc: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Benjamin Block <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This patch prepares for removal of the shost_attrs member from struct
scsi_host_template.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: David Kershner <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Additionally, remove qla_insert_tgt_attrs() and replace it with
qla_host_attr_is_visible().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Since there is no definition for the qla2x00_host_attrs_dm array, remove
its declaration.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
struct device supports attribute groups directly but does not support
struct device_attribute directly. Hence switch to attribute groups.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Jack Wang <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|