- 19 Oct, 2021 11 commits
-
-
Stanley Chu authored
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/20211016005802.7729-2-stanley.chu@mediatek.comSigned-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bodo Stroesser authored
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/20211013171606.25197-1-bostroesser@gmail.comSigned-off-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
-
Varun Prakash authored
Enable Delayed ACK to reduce the number of TCP ACKs. Link: https://lore.kernel.org/r/1634135109-5044-1-git-send-email-varun@chelsio.comSigned-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Varun Prakash authored
Current value of max DataSegmentLength is 8K. T5/T6 adapters support DataSegmentLength upto 16K. Increase max DataSegmentLength. Link: https://lore.kernel.org/r/1634135087-4996-1-git-send-email-varun@chelsio.comSigned-off-by:
-
Ye Bin authored
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/20211013033913.2551004-3-yebin10@huawei.comAcked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
-
Ye Bin authored
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/20211013033913.2551004-2-yebin10@huawei.comAcked-by:
-
Colin Ian King authored
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/20211013182834.137410-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
MichelleJin authored
'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/20211015142006.540773-1-shjy180909@gmail.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
MichelleJin <shjy180909@gmail.com> Signed-off-by:
-
Tyrel Datwyler authored
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/1547089149-20577-1-git-send-email-tyreld@linux.vnet.ibm.comReviewed-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
Dan Carpenter authored
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: 76a4f7cc ("scsi: mpi3mr: Clean up mpi3mr_print_ioc_info()") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Martin Kepplinger authored
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/20211013075050.3870354-1-martin.kepplinger@puri.smReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by:
-
- 17 Oct, 2021 29 commits
-
-
Bart Van Assche authored
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/20211012233558.4066756-47-bvanassche@acm.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-46-bvanassche@acm.orgAcked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Bart Van Assche authored
This patch prepares for removal of the shost_attrs member from struct scsi_host_template. Link: https://lore.kernel.org/r/20211012233558.4066756-45-bvanassche@acm.orgAcked-by:
David Kershner <david.kershner@unisys.com> Acked-by:
-
Bart Van Assche authored
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/20211012233558.4066756-44-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-43-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-42-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-41-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
Since there is no definition for the qla2x00_host_attrs_dm array, remove its declaration. Link: https://lore.kernel.org/r/20211012233558.4066756-40-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-39-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-38-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-37-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-36-bvanassche@acm.orgAcked-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-35-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-34-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-33-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-32-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-31-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-30-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-29-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-29-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-28-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-27-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-26-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-25-bvanassche@acm.orgAcked-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-24-bvanassche@acm.orgAcked-by:
-
Bart Van Assche authored
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/20211012233558.4066756-23-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-22-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-21-bvanassche@acm.orgAcked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Bart Van Assche authored
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/20211012233558.4066756-20-bvanassche@acm.orgSigned-off-by:
-
