July 2019 - Linux-stable-mirror

[PATCH v2 1/7] media: hantro: Set DMA max segment size

by Ezequiel Garcia

From: Francois Buergisser <fbuergisser(a)chromium.org> The Hantro codec is typically used in platforms with an IOMMU, so we need to set a proper DMA segment size. Devices without an IOMMU will still fallback to default 64KiB segments. Cc: stable(a)vger.kernel.org Fixes: 775fec69008d3 ("media: add Rockchip VPU JPEG encoder driver") Signed-off-by: Francois Buergisser <fbuergisser(a)chromium.org> Signed-off-by: Ezequiel Garcia <ezequiel(a)collabora.com> --- drivers/staging/media/hantro/hantro_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c index b71a06e9159e..4eae1dbb1ac8 100644 --- a/drivers/staging/media/hantro/hantro_drv.c +++ b/drivers/staging/media/hantro/hantro_drv.c @@ -731,6 +731,7 @@ static int hantro_probe(struct platform_device *pdev) dev_err(vpu->dev, "Could not set DMA coherent mask.\n"); return ret; } + vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32)); for (i = 0; i < vpu->variant->num_irqs; i++) { const char *irq_name = vpu->variant->irqs[i].name; -- 2.22.0

5 years, 5 months

3
2
0 0

Re: [PATCH 2/7] can: rcar_canfd: fix possible IRQ storm on high load

by Nikita Yushchenko

> NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? I don't know. Maintainer did not respond, nor to original send nor to resend.

5 years, 5 months

2
1
0 0

patch "hpet: Fix division by zero in hpet_time_div()" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hpet: Fix division by zero in hpet_time_div() to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 0c7d37f4d9b8446956e97b7c5e61173cdb7c8522 Mon Sep 17 00:00:00 2001 From: Kefeng Wang <wangkefeng.wang(a)huawei.com> Date: Thu, 11 Jul 2019 21:27:57 +0800 Subject: hpet: Fix division by zero in hpet_time_div() The base value in do_div() called by hpet_time_div() is truncated from unsigned long to uint32_t, resulting in a divide-by-zero exception. UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2 division by zero CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561 ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20 0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0 Call Trace: [<ffffffff81ad7561>] __dump_stack lib/dump_stack.c:15 [inline] [<ffffffff81ad7561>] dump_stack+0xc1/0x120 lib/dump_stack.c:51 [<ffffffff81b8f25e>] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166 [<ffffffff81b900cb>] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262 [<ffffffff823560dd>] hpet_time_div drivers/char/hpet.c:572 [inline] [<ffffffff823560dd>] hpet_ioctl_common drivers/char/hpet.c:663 [inline] [<ffffffff823560dd>] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577 [<ffffffff81e63d56>] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676 [<ffffffff81711590>] vfs_ioctl fs/ioctl.c:43 [inline] [<ffffffff81711590>] file_ioctl fs/ioctl.c:470 [inline] [<ffffffff81711590>] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605 [<ffffffff81711eb4>] SYSC_ioctl fs/ioctl.c:622 [inline] [<ffffffff81711eb4>] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613 [<ffffffff82846003>] tracesys_phase2+0x90/0x95 The main C reproducer autogenerated by syzkaller, syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); memcpy((void*)0x20000100, "/dev/hpet\000", 10); syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0); syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000); Fix it by using div64_ul(). Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Zhang HongJun <zhanghongjun2(a)huawei.com> Cc: stable <stable(a)vger.kernel.org> Reviewed-by: Arnd Bergmann <arnd(a)arndb.de> Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/hpet.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c index 5c39f20378b8..9ac6671bb514 100644 --- a/drivers/char/hpet.c +++ b/drivers/char/hpet.c @@ -567,8 +567,7 @@ static inline unsigned long hpet_time_div(struct hpets *hpets, unsigned long long m; m = hpets->hp_tick_freq + (dis >> 1); - do_div(m, dis); - return (unsigned long)m; + return div64_ul(m, dis); } static int -- 2.22.0

5 years, 5 months

1
0
0 0

[PATCH] PCI: set BAR size bits correctly in Resize BAR control register

by Sumit Saxena

In Resize BAR control register, bits[8:12] represents size of BAR. As per PCIe specification, below is encoded values in register bits to actual BAR size table: Bits BAR size 0 1 MB 1 2 MB 2 4 MB 3 8 MB -- For 1 MB BAR size, BAR size bits should be set to 0 but incorrectly these bits are set to "1f". Latest megaraid_sas and mpt3sas adapters which support Resizable BAR with 1 MB BAR size fails to initialize during system resume from S3 sleep. Fix: Correctly set BAR size bits to "0" for 1MB BAR size. CC: stable(a)vger.kernel.org # v4.16+ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203939 Fixes: d3252ace0bc652a1a244455556b6a549f969bf99 ("PCI: Restore resized BAR state on resume") Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> --- drivers/pci/pci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 8abc843..b651f32 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1417,12 +1417,13 @@ static void pci_restore_rebar_state(struct pci_dev *pdev) for (i = 0; i < nbars; i++, pos += 8) { struct resource *res; - int bar_idx, size; + int bar_idx, size, order; pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl); bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX; res = pdev->resource + bar_idx; - size = order_base_2((resource_size(res) >> 20) | 1) - 1; + order = order_base_2((resource_size(res) >> 20) | 1); + size = order ? order - 1 : 0; ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE; ctrl |= size << PCI_REBAR_CTRL_BAR_SHIFT; pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl); -- 1.8.3.1

5 years, 5 months

1
1
0 0

patch "staging: android: ion: Bail out upon SIGKILL when allocating memory." added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: android: ion: Bail out upon SIGKILL when allocating memory. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 8f9e86ee795971eabbf372e6d804d6b8578287a7 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Date: Mon, 1 Jul 2019 19:55:19 +0900 Subject: staging: android: ion: Bail out upon SIGKILL when allocating memory. syzbot found that a thread can stall for minutes inside ion_system_heap_allocate() after that thread was killed by SIGKILL [1]. Let's check for SIGKILL before doing memory allocation. [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f… Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Cc: stable <stable(a)vger.kernel.org> Reported-by: syzbot <syzbot+8ab2d0f39fb79fe6ca40(a)syzkaller.appspotmail.com> Acked-by: Laura Abbott <labbott(a)redhat.com> Acked-by: Sumit Semwal <sumit.semwal(a)linaro.org> Link: https://lore.kernel.org/r/d088f188-5f32-d8fc-b9a0-0b404f7501cc@I-love.SAKUR… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/android/ion/ion_page_pool.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c index fd4995fb676e..f85ec5b16b65 100644 --- a/drivers/staging/android/ion/ion_page_pool.c +++ b/drivers/staging/android/ion/ion_page_pool.c @@ -8,11 +8,14 @@ #include <linux/list.h> #include <linux/slab.h> #include <linux/swap.h> +#include <linux/sched/signal.h> #include "ion.h" static inline struct page *ion_page_pool_alloc_pages(struct ion_page_pool *pool) { + if (fatal_signal_pending(current)) + return NULL; return alloc_pages(pool->gfp_mask, pool->order); } -- 2.22.0

5 years, 5 months

1
0
0 0

[git:media_tree/master] media: vivid: fix device init when no_error_inj=1 and fb disabled

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: vivid: fix device init when no_error_inj=1 and fb disabled Author: Guillaume Tucker <guillaume.tucker(a)collabora.com> Date: Wed Jul 24 11:19:22 2019 -0400 Add an extra condition to add the video output control class when the device has some hdmi outputs defined. This is required to then always be able to add the display present control, which is enabled when there are some hdmi outputs. This fixes the corner case where no_error_inj is enabled and the device has no frame buffer but some hdmi outputs, as otherwise the video output control class would be added anyway. Without this fix, the sanity checks fail in v4l2_ctrl_new() as name is NULL. Fixes: c533435ffb91 ("media: vivid: add display present control") Cc: stable(a)vger.kernel.org # for 5.3 Signed-off-by: Guillaume Tucker <guillaume.tucker(a)collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/platform/vivid/vivid-ctrls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/media/platform/vivid/vivid-ctrls.c b/drivers/media/platform/vivid/vivid-ctrls.c index fb9220e4e640..cb19a9a73092 100644 --- a/drivers/media/platform/vivid/vivid-ctrls.c +++ b/drivers/media/platform/vivid/vivid-ctrls.c @@ -1473,7 +1473,7 @@ int vivid_create_controls(struct vivid_dev *dev, bool show_ccs_cap, v4l2_ctrl_handler_init(hdl_vid_cap, 55); v4l2_ctrl_new_custom(hdl_vid_cap, &vivid_ctrl_class, NULL); v4l2_ctrl_handler_init(hdl_vid_out, 26); - if (!no_error_inj || dev->has_fb) + if (!no_error_inj || dev->has_fb || dev->num_hdmi_outputs) v4l2_ctrl_new_custom(hdl_vid_out, &vivid_ctrl_class, NULL); v4l2_ctrl_handler_init(hdl_vbi_cap, 21); v4l2_ctrl_new_custom(hdl_vbi_cap, &vivid_ctrl_class, NULL);

5 years, 5 months

1
0
0 0

[PATCH 0/3] Backport request for v4.14 to fix KASAN issues

by Matthieu Baerts

Hello, First, thank you for maintaining the stable branches! When testing our MPTCP out-of-tree kernel[1] with KASAN last week-end, we saw some new warnings, always the same trace and looking like that: [ 16.464577] ================================================================== [ 16.465448] BUG: KASAN: slab-out-of-bounds in strscpy+0x49d/0x590 [ 16.466171] Read of size 8 at addr ffff88803525f788 by task confd/330 [ 16.467114] [ 16.467313] CPU: 0 PID: 330 Comm: confd Not tainted 4.14.133-mptcp+ #2 [ 16.468071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011 [ 16.469016] Call Trace: [ 16.469318] dump_stack+0xa6/0x12e [ 16.469721] ? _atomic_dec_and_lock+0x1b2/0x1b2 [ 16.470255] ? radix_tree_lookup+0x10/0x10 [ 16.470764] ? strscpy+0x49d/0x590 [ 16.471299] print_address_description+0xa1/0x330 [ 16.471918] ? strscpy+0x49d/0x590 [ 16.472321] kasan_report+0x23f/0x350 [ 16.472751] strscpy+0x49d/0x590 [ 16.473135] ? strncpy+0xd0/0xd0 [ 16.473518] p9dirent_read+0x26b/0x510 [ 16.473977] ? unwind_next_frame+0xc97/0x1eb0 [ 16.474481] ? p9stat_read+0x440/0x440 [ 16.474945] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 16.475543] ? rcutorture_record_progress+0x10/0x10 [ 16.476123] ? kernel_text_address+0x111/0x120 [ 16.476656] ? __kernel_text_address+0xe/0x30 [ 16.477273] v9fs_dir_readdir_dotl+0x340/0x5b0 [ 16.477900] ? kasan_slab_free+0x12d/0x1a0 [ 16.478377] ? v9fs_dir_readdir+0x810/0x810 [ 16.478887] ? new_slab+0x29f/0x3b0 [ 16.479298] ? iterate_fd+0x300/0x300 [ 16.479728] ? do_filp_open+0x24a/0x3b0 [ 16.480177] ? SyS_getcwd+0x3b7/0x9f0 [ 16.480626] ? may_open_dev+0xc0/0xc0 [ 16.481056] ? get_unused_fd_flags+0x180/0x180 [ 16.481643] ? __up.isra.0+0x230/0x230 [ 16.482195] ? __fdget_pos+0x105/0x170 [ 16.482658] ? iterate_dir+0x171/0x5b0 [ 16.483097] iterate_dir+0x171/0x5b0 [ 16.483518] SyS_getdents+0x1dc/0x3a0 [ 16.483968] ? SyS_old_readdir+0x200/0x200 [ 16.484444] ? SyS_write+0x1c0/0x270 [ 16.484875] ? fillonedir+0x1a0/0x1a0 [ 16.485315] ? SyS_old_readdir+0x200/0x200 [ 16.485791] ? do_syscall_64+0x259/0xa90 [ 16.486258] do_syscall_64+0x259/0xa90 [ 16.486715] ? syscall_return_slowpath+0x340/0x340 [ 16.487320] ? do_page_fault+0x11f/0x400 [ 16.487849] ? __do_page_fault+0xe00/0xe00 [ 16.488305] ? __hrtick_start+0x2f0/0x2f0 [ 16.488752] ? __switch_to_asm+0x31/0x60 [ 16.489189] ? __switch_to_asm+0x31/0x60 [ 16.489626] ? __switch_to_asm+0x25/0x60 [ 16.490063] ? __switch_to_asm+0x31/0x60 [ 16.490500] ? __switch_to_asm+0x31/0x60 [ 16.490940] ? __switch_to_asm+0x31/0x60 [ 16.491377] ? __switch_to_asm+0x25/0x60 [ 16.491820] ? __switch_to_asm+0x31/0x60 [ 16.492305] ? __switch_to_asm+0x31/0x60 [ 16.492769] ? __switch_to_asm+0x31/0x60 [ 16.493306] ? __switch_to_asm+0x31/0x60 [ 16.493917] ? __switch_to_asm+0x31/0x60 [ 16.494402] ? __switch_to_asm+0x25/0x60 [ 16.494859] ? __switch_to_asm+0x31/0x60 [ 16.495344] ? __switch_to_asm+0x31/0x60 [ 16.495798] ? __switch_to_asm+0x31/0x60 [ 16.496283] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 16.496885] RIP: 0033:0x7f0bd5b26855 [ 16.497313] RSP: 002b:00007f0bd69d4d60 EFLAGS: 00000246 ORIG_RAX: 000000000000004e [ 16.498387] RAX: ffffffffffffffda RBX: 00007f0bb800a910 RCX: 00007f0bd5b26855 [ 16.499221] RDX: 0000000000008000 RSI: 00007f0bb800a910 RDI: 000000000000002c [ 16.500102] RBP: 00007f0bb800a910 R08: 00007f0bd69d4e10 R09: 0000000000008030 [ 16.500942] R10: 0000000000000076 R11: 0000000000000246 R12: ffffffffffffff70 [ 16.501780] R13: 0000000000000002 R14: 00007f0bb80008d0 R15: 000000000129cb44 [ 16.502641] [ 16.502819] Allocated by task 330: [ 16.503230] kasan_kmalloc+0xe4/0x170 [ 16.503799] __kmalloc+0xdd/0x1c0 [ 16.504259] p9pdu_readf+0xbb8/0x2940 [ 16.504707] p9dirent_read+0x174/0x510 [ 16.505154] v9fs_dir_readdir_dotl+0x340/0x5b0 [ 16.505694] iterate_dir+0x171/0x5b0 [ 16.506122] SyS_getdents+0x1dc/0x3a0 [ 16.506573] do_syscall_64+0x259/0xa90 [ 16.507031] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 16.507633] [ 16.507804] Freed by task 322: [ 16.508178] kasan_slab_free+0xac/0x1a0 [ 16.508741] kfree+0xcd/0x1e0 [ 16.509194] p9stat_free+0x32/0x200 [ 16.509633] v9fs_vfs_get_link+0x173/0x230 [ 16.510118] ovl_get_link+0x52/0x80 [ 16.510538] trailing_symlink+0x42c/0x5f0 [ 16.511034] path_lookupat+0x1b4/0xc30 [ 16.511481] filename_lookup+0x237/0x470 [ 16.511955] vfs_statx+0xb0/0x120 [ 16.512358] SyS_newstat+0x70/0xc0 [ 16.512759] do_syscall_64+0x259/0xa90 [ 16.513205] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 16.513807] [ 16.514041] The buggy address belongs to the object at ffff88803525f780 [ 16.514041] which belongs to the cache kmalloc-16 of size 16 [ 16.515645] The buggy address is located 8 bytes inside of [ 16.515645] 16-byte region [ffff88803525f780, ffff88803525f790) [ 16.516997] The buggy address belongs to the page: [ 16.517563] page:ffff88803f5407c0 count:1 mapcount:0 mapping: (null) index:0x0 [ 16.518504] flags: 0xc80000000100(slab) [ 16.519103] raw: 0000c80000000100 0000000000000000 0000000000000000 0000000180800080 [ 16.520066] raw: ffff88803f4fa900 0000000800000008 ffff888035c01b40 0000000000000000 [ 16.520981] page dumped because: kasan: bad access detected [ 16.521647] [ 16.521818] Memory state around the buggy address: [ 16.522413] ffff88803525f680: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc [ 16.523258] ffff88803525f700: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc [ 16.524118] >ffff88803525f780: 00 02 fc fc fb fb fc fc fb fb fc fc fb fb fc fc [ 16.525093] ^ [ 16.525591] ffff88803525f800: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc [ 16.526471] ffff88803525f880: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc [ 16.527323] ================================================================== We are running tests in different KVMs and using 9P for the root RO partition and others for a shared file system between VMs and the host: mount -t 9p outshare "${MOUNT_DIR}/overlay/out" -o trans=virtio,version=9p2000.L,access=0,rw Our out-of-tree kernel does not modify the FS part, nor net/9p. With Dominique from v9fs project, we analysed the issue[2]. At the end, it is confirmed that this KASAN warning is not related to our MPTCP modifications but due to a recent change in the v4.14 stable branch: 84693d060965 (9p: p9dirent_read: check network-provided name length). In this change backported by Sasha, strcpy() has been replaced by strscpy(). This is known to cause KASAN false-positives, see: 1a3241ff10d0 (lib/strscpy: Shut up KASAN false-positives in strscpy()). Note that this commit depends on the two parent ones. Could it then be possible to also backport these three commits please? The three commits apply without any issues. I followed the documention to propose these three commits to stable, the Option 3. Just for me for next time: is it easier for you to propose the patches like I did or to only mention the SHA from Linus GIT tree? - 1a3241ff10d0 (lib/strscpy: Shut up KASAN false-positives in strscpy()) - 7f1e541fc8d5 (compiler.h: Add read_word_at_a_time() function.) - bdb5ac801af3 (compiler.h, kasan: Avoid duplicating __read_once_size_nocheck()) Cheers, Matt [1] https://github.com/multipath-tcp/mptcp/ [2] https://sourceforge.net/p/v9fs/mailman/message/36718122/ Andrey Ryabinin (3): compiler.h, kasan: Avoid duplicating __read_once_size_nocheck() compiler.h: Add read_word_at_a_time() function. lib/strscpy: Shut up KASAN false-positives in strscpy() include/linux/compiler.h | 22 ++++++++++++++-------- lib/string.c | 2 +- 2 files changed, 15 insertions(+), 9 deletions(-) Cc: Dominique Martinet <asmadeus(a)codewreck.org> Cc: Sasha Levin <sashal(a)kernel.org> -- 2.20.1

5 years, 5 months

2
5
0 0

[PATCH] xhci: Fix crash if scatter gather is used with Immediate Data Transfer (IDT).

by Mathias Nyman

A second regression was found in the immediate data transfer (IDT) support which was added to 5.2 kernel IDT is used to transfer small amounts of data (up to 8 bytes) in the field normally used for data dma address, thus avoiding dma mapping. If the data was not already dma mapped, then IDT support assumed data was in urb->transfer_buffer, and did not take into accound that even small amounts of data (8 bytes) can be in a scatterlist instead. This caused a NULL pointer dereference when sg_dma_len() was used with non-dma mapped data. Solve this by not using IDT if scatter gather buffer list is used. Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support") Cc: <stable(a)vger.kernel.org> # v5.2 Reported-by: Maik Stohn <maik.stohn(a)seal-one.com> Tested-by: Maik Stohn <maik.stohn(a)seal-one.com> CC: Nicolas Saenz Julienne <nsaenzjulienne(a)suse.de> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 7a26496..f5c4144 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -2175,7 +2175,8 @@ static inline bool xhci_urb_suitable_for_idt(struct urb *urb) if (!usb_endpoint_xfer_isoc(&urb->ep->desc) && usb_urb_dir_out(urb) && usb_endpoint_maxp(&urb->ep->desc) >= TRB_IDT_MAX_SIZE && urb->transfer_buffer_length <= TRB_IDT_MAX_SIZE && - !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP)) + !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) && + !urb->num_sgs) return true; return false; -- 2.7.4

5 years, 5 months

1
0
0 0

patch "usb: wusbcore: fix unbalanced get/put cluster_id" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: wusbcore: fix unbalanced get/put cluster_id to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From f90bf1ece48a736097ea224430578fe586a9544c Mon Sep 17 00:00:00 2001 From: Phong Tran <tranmanphong(a)gmail.com> Date: Wed, 24 Jul 2019 09:06:01 +0700 Subject: usb: wusbcore: fix unbalanced get/put cluster_id syzboot reported that https://syzkaller.appspot.com/bug?extid=fd2bd7df88c606eea4ef There is not consitency parameter in cluste_id_get/put calling. In case of getting the id with result is failure, the wusbhc->cluster_id will not be updated and this can not be used for wusb_cluster_id_put(). Tested report https://groups.google.com/d/msg/syzkaller-bugs/0znZopp3-9k/oxOrhLkLEgAJ Reproduce and gdb got the details: 139 addr = wusb_cluster_id_get(); (gdb) n 140 if (addr == 0) (gdb) print addr $1 = 254 '\376' (gdb) n 142 result = __hwahc_set_cluster_id(hwahc, addr); (gdb) print result $2 = -71 (gdb) break wusb_cluster_id_put Breakpoint 3 at 0xffffffff836e3f20: file drivers/usb/wusbcore/wusbhc.c, line 384. (gdb) s Thread 2 hit Breakpoint 3, wusb_cluster_id_put (id=0 '\000') at drivers/usb/wusbcore/wusbhc.c:384 384 id = 0xff - id; (gdb) n 385 BUG_ON(id >= CLUSTER_IDS); (gdb) print id $3 = 255 '\377' Reported-by: syzbot+fd2bd7df88c606eea4ef(a)syzkaller.appspotmail.com Signed-off-by: Phong Tran <tranmanphong(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20190724020601.15257-1-tranmanphong@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/host/hwa-hc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/hwa-hc.c b/drivers/usb/host/hwa-hc.c index 09a8ebd95588..6968b9f2b76b 100644 --- a/drivers/usb/host/hwa-hc.c +++ b/drivers/usb/host/hwa-hc.c @@ -159,7 +159,7 @@ static int hwahc_op_start(struct usb_hcd *usb_hcd) return result; error_set_cluster_id: - wusb_cluster_id_put(wusbhc->cluster_id); + wusb_cluster_id_put(addr); error_cluster_id_get: goto out; -- 2.22.0

5 years, 5 months

1
0
0 0

patch "usb-storage: Add a limitation for blk_queue_max_hw_sectors()" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb-storage: Add a limitation for blk_queue_max_hw_sectors() to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From d74ffae8b8dd17eaa8b82fc163e6aa2076dc8fb1 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Date: Mon, 22 Jul 2019 19:58:25 +0900 Subject: usb-storage: Add a limitation for blk_queue_max_hw_sectors() This patch fixes an issue that the following error happens on swiotlb environment: xhci-hcd ee000000.usb: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1338 (slots) On the kernel v5.1, block settings of a usb-storage with SuperSpeed were the following so that the block layer will allocate buffers up to 64 KiB, and then the issue didn't happen. max_segment_size = 65536 max_hw_sectors_kb = 1024 After the commit 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary") is applied, the block settings are the following. So, the block layer will allocate buffers up to 1024 KiB, and then the issue happens: max_segment_size = 4294967295 max_hw_sectors_kb = 1024 To fix the issue, the usb-storage driver checks the maximum size of a mapping for the device and then adjusts the max_hw_sectors_kb if required. After this patch is applied, the block settings will be the following, and then the issue doesn't happen. max_segment_size = 4294967295 max_hw_sectors_kb = 256 Fixes: 09324d32d2a0 ("block: force an unlimited segment size on queues with a virt boundary") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Link: https://lore.kernel.org/r/1563793105-20597-1-git-send-email-yoshihiro.shimo… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/storage/scsiglue.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index 30790240aec6..05b80211290d 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -28,6 +28,8 @@ * status of a command. */ +#include <linux/blkdev.h> +#include <linux/dma-mapping.h> #include <linux/module.h> #include <linux/mutex.h> @@ -99,6 +101,7 @@ static int slave_alloc (struct scsi_device *sdev) static int slave_configure(struct scsi_device *sdev) { struct us_data *us = host_to_us(sdev->host); + struct device *dev = us->pusb_dev->bus->sysdev; /* * Many devices have trouble transferring more than 32KB at a time, @@ -128,6 +131,14 @@ static int slave_configure(struct scsi_device *sdev) blk_queue_max_hw_sectors(sdev->request_queue, 2048); } + /* + * The max_hw_sectors should be up to maximum size of a mapping for + * the device. Otherwise, a DMA API might fail on swiotlb environment. + */ + blk_queue_max_hw_sectors(sdev->request_queue, + min_t(size_t, queue_max_hw_sectors(sdev->request_queue), + dma_max_mapping_size(dev) >> SECTOR_SHIFT)); + /* * Some USB host controllers can't do DMA; they have to use PIO. * They indicate this by setting their dma_mask to NULL. For -- 2.22.0

5 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2019