summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-08-18mm/memory.c: skip spurious TLB flush for retried page faultYang Shi
Recently we found regression when running will_it_scale/page_fault3 test on ARM64. Over 70% down for the multi processes cases and over 20% down for the multi threads cases. It turns out the regression is caused by commit 89b15332af7c ("mm: drop mmap_sem before calling balance_dirty_pages() in write fault"). The test mmaps a memory size file then write to the mapping, this would make all memory dirty and trigger dirty pages throttle, that upstream commit would release mmap_sem then retry the page fault. The retried page fault would see correct PTEs installed then just fall through to spurious TLB flush. The regression is caused by the excessive spurious TLB flush. It is fine on x86 since x86's spurious TLB flush is no-op. We could just skip the spurious TLB flush to mitigate the regression. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Xu Yu <xuyu@linux.alibaba.com> Debugged-by: Xu Yu <xuyu@linux.alibaba.com> Tested-by: Xu Yu <xuyu@linux.alibaba.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Yang Shi <shy828301@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-08-18ext4: change to use fallthrough macroShijie Luo
Change to use fallthrough macro in switch case. Signed-off-by: Shijie Luo <luoshijie1@huawei.com> Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/20200810114435.24182-1-luoshijie1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-08-18ext4: remove unused parameter of ext4_generic_delete_entry functionKyoungho Koo
The ext4_generic_delete_entry function does not use the parameter handle, so it can be removed. Signed-off-by: Kyoungho Koo <rnrudgh@gmail.com> Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/20200810080701.GA14160@koo-Z370-HD3 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-08-18mballoc: replace seq_printf with seq_putsXu Wang
seq_puts is a lot cheaper than seq_printf, so use that to print literal strings. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/20200810022158.9167-1-vulab@iscas.ac.cn Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-08-18ext4: optimize the implementation of ext4_mb_good_group()brookxu
It might be better to adjust the code in two places: 1. Determine whether grp is currupt or not should be placed first. 2. (cr<=2 && free <ac->ac_g_ex.fe_len)should may belong to the crx strategy, and it may be more appropriate to put it in the subsequent switch statement block. For cr1, cr2, the conditions in switch potentially realize the above judgment. For cr0, we should add (free <ac->ac_g_ex.fe_len) judgment, and then delete (free / fragments) >= ac->ac_g_ex.fe_len), because cr0 returns true by default. Signed-off-by: Chunguang Xu <brookxu@tencent.com> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/e20b2d8f-1154-adb7-3831-a9e11ba842e9@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-08-18ext4: delete invalid comments near ext4_mb_check_limits()brookxu
These comments do not seem to be related to ext4_mb_check_limits(), it may be invalid. Signed-off-by: Chunguang Xu <brookxu@tencent.com> Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com> Link: https://lore.kernel.org/r/c49faf0c-d5d5-9c51-6911-9e0ff57c6bfa@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-08-18ext4: fix typos in ext4_mb_regular_allocator() commentbrookxu
Fix typos in ext4_mb_regular_allocator() comment Signed-off-by: Chunguang Xu <brookxu@tencent.com> Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/d6514145-73b3-808b-ec5a-a8be27c51f9c@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-08-18Revert "HID: usbhid: do not sleep when opening device"Jiri Kosina
This reverts commit d3132792285859253c466354fd8d54d1fe0ba786. This patch causes a regression with quite a few devices, as probing fails because of the race where the first IRQ is dropped on the floor (after hid_device_io_start() happens, but before the 50ms timeout passess), and report descriptor never gets parsed and populated. As this is just a boot time micro-optimization, let's revert the patch for 5.9 now, and fix this properly eventually for next merge window. Link: https://bugzilla.kernel.org/show_bug.cgi?id=208935 Reported-by: Johannes Hirte <johannes.hirte@datenkhaos.de> Reported-by: Marius Zachmann <mail@mariuszachmann.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-08-18libbpf: Fix build on ppc64le architectureAndrii Nakryiko
On ppc64le we get the following warning: In file included from btf_dump.c:16:0: btf_dump.c: In function ‘btf_dump_emit_struct_def’: ../include/linux/kernel.h:20:17: error: comparison of distinct pointer types lacks a cast [-Werror] (void) (&_max1 == &_max2); \ ^ btf_dump.c:882:11: note: in expansion of macro ‘max’ m_sz = max(0LL, btf__resolve_size(d->btf, m->type)); ^~~ Fix by explicitly casting to __s64, which is a return type from btf__resolve_size(). Fixes: 702eddc77a90 ("libbpf: Handle GCC built-in types for Arm NEON") Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200818164456.1181661-1-andriin@fb.com
2020-08-18dt-bindings: Use Shawn Guo's preferred e-mail for i.MX bindingsFabio Estevam
Use Shawn Guo's kernel.org address for the i.MX related bindings as per the MAINTAINERS entries. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20200818111245.17047-1-festevam@gmail.com Signed-off-by: Rob Herring <robh@kernel.org>
2020-08-18RDMA/usnic: Fix spelling mistake "transistion" -> "transition"Colin Ian King
There is a spelling mistake in a usnic_err error message. Fix it. Link: https://lore.kernel.org/r/20200805141459.23069-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-18RDMA/hns: Fix spelling mistake "epmty" -> "empty"Colin Ian King
There is a spelling mistake in a dev_dbg message. Fix it. Link: https://lore.kernel.org/r/20200805141111.22804-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-18drm/msm: add shutdown support for display platform_driverKrishna Manikandan
Define shutdown callback for display drm driver, so as to disable all the CRTCS when shutdown notification is received by the driver. This change will turn off the timing engine so that no display transactions are requested while mmu translations are getting disabled during reboot sequence. Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org> Changes in v2: - Remove NULL check from msm_pdev_shutdown (Stephen Boyd) - Change commit text to reflect when this issue was uncovered (Sai Prakash Ranjan) Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-08-18bfq: fix blkio cgroup leakage v4Dmitry Monakhov
Changes from v1: - update commit description with proper ref-accounting justification commit db37a34c563b ("block, bfq: get a ref to a group when adding it to a service tree") introduce leak forbfq_group and blkcg_gq objects because of get/put imbalance. In fact whole idea of original commit is wrong because bfq_group entity can not dissapear under us because it is referenced by child bfq_queue's entities from here: -> bfq_init_entity() ->bfqg_and_blkg_get(bfqg); ->entity->parent = bfqg->my_entity -> bfq_put_queue(bfqq) FINAL_PUT ->bfqg_and_blkg_put(bfqq_group(bfqq)) ->kmem_cache_free(bfq_pool, bfqq); So parent entity can not disappear while child entity is in tree, and child entities already has proper protection. This patch revert commit db37a34c563b ("block, bfq: get a ref to a group when adding it to a service tree") bfq_group leak trace caused by bad commit: -> blkg_alloc -> bfq_pq_alloc -> bfqg_get (+1) ->bfq_activate_bfqq ->bfq_activate_requeue_entity -> __bfq_activate_entity ->bfq_get_entity ->bfqg_and_blkg_get (+1) <==== : Note1 ->bfq_del_bfqq_busy ->bfq_deactivate_entity+0x53/0xc0 [bfq] ->__bfq_deactivate_entity+0x1b8/0x210 [bfq] -> bfq_forget_entity(is_in_service = true) entity->on_st_or_in_serv = false <=== :Note2 if (is_in_service) return; ==> do not touch reference -> blkcg_css_offline -> blkcg_destroy_blkgs -> blkg_destroy -> bfq_pd_offline -> __bfq_deactivate_entity if (!entity->on_st_or_in_serv) /* true, because (Note2) return false; -> bfq_pd_free -> bfqg_put() (-1, byt bfqg->ref == 2) because of (Note2) So bfq_group and blkcg_gq will leak forever, see test-case below. ##TESTCASE_BEGIN: #!/bin/bash max_iters=${1:-100} #prep cgroup mounts mount -t tmpfs cgroup_root /sys/fs/cgroup mkdir /sys/fs/cgroup/blkio mount -t cgroup -o blkio none /sys/fs/cgroup/blkio # Prepare blkdev grep blkio /proc/cgroups truncate -s 1M img losetup /dev/loop0 img echo bfq > /sys/block/loop0/queue/scheduler grep blkio /proc/cgroups for ((i=0;i<max_iters;i++)) do mkdir -p /sys/fs/cgroup/blkio/a echo 0 > /sys/fs/cgroup/blkio/a/cgroup.procs dd if=/dev/loop0 bs=4k count=1 of=/dev/null iflag=direct 2> /dev/null echo 0 > /sys/fs/cgroup/blkio/cgroup.procs rmdir /sys/fs/cgroup/blkio/a grep blkio /proc/cgroups done ##TESTCASE_END: Fixes: db37a34c563b ("block, bfq: get a ref to a group when adding it to a service tree") Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-08-18EDAC/{i7core,sb,pnd2,skx}: Fix error event severityTony Luck
IA32_MCG_STATUS.RIPV indicates whether the return RIP value pushed onto the stack as part of machine check delivery is valid or not. Various drivers copied a code fragment that uses the RIPV bit to determine the severity of the error as either HW_EVENT_ERR_UNCORRECTED or HW_EVENT_ERR_FATAL, but this check is reversed (marking errors where RIPV is set as "FATAL"). Reverse the tests so that the error is marked fatal when RIPV is not set. Reported-by: Gabriele Paoloni <gabriele.paoloni@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20200707194324.14884-1-tony.luck@intel.com
2020-08-18mei: hdcp: fix mei_hdcp_verify_mprime() input parameterTomas Winkler
wired_cmd_repeater_auth_stream_req_in has a variable length array at the end. we use struct_size() overflow macro to determine the size for the allocation and sending size. This also fixes bug in case number of streams is > 0 in the original submission. This bug was not triggered as the number of streams is always one. Fixes: c56967d674e3 (mei: hdcp: Replace one-element array with flexible-array member) Fixes: 0a1af1b5c18d (misc/mei/hdcp: Verify M_prime) Cc: <stable@vger.kernel.org> # v5.1+: c56967d674e3 (mei: hdcp: Replace one-element array with flexible-array member) Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200818075406.2532605-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18tty: serial: imx: add dependence and build for earlyconFugang Duan
Add the earlycon dependence and add earlycon Makefile support to allow to build the driver. Fixes: 699cc4dfd140 ("tty: serial: imx: add imx earlycon driver") Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Link: https://lore.kernel.org/r/20200810060652.3436-1-fugang.duan@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18serial: samsung: Removes the IRQ not found warningTamseel Shams
In few older Samsung SoCs like s3c2410, s3c2412 and s3c2440, UART IP is having 2 interrupt lines. However, in other SoCs like s3c6400, s5pv210, exynos5433, and exynos4210 UART is having only 1 interrupt line. Due to this, "platform_get_irq(platdev, 1)" call in the driver gives the following false-positive error: "IRQ index 1 not found" on newer SoC's. This patch adds the condition to check for Tx interrupt only for the those SoC's which have 2 interrupt lines. Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Tamseel Shams <m.shams@samsung.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200810030021.45348-1-m.shams@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18serial: 8250: change lock order in serial8250_do_startup()Sergey Senozhatsky
We have a number of "uart.port->desc.lock vs desc.lock->uart.port" lockdep reports coming from 8250 driver; this causes a bit of trouble to people, so let's fix it. The problem is reverse lock order in two different call paths: chain #1: serial8250_do_startup() spin_lock_irqsave(&port->lock); disable_irq_nosync(port->irq); raw_spin_lock_irqsave(&desc->lock) chain #2: __report_bad_irq() raw_spin_lock_irqsave(&desc->lock) for_each_action_of_desc() printk() spin_lock_irqsave(&port->lock); Fix this by changing the order of locks in serial8250_do_startup(): do disable_irq_nosync() first, which grabs desc->lock, and grab uart->port after that, so that chain #1 and chain #2 have same lock order. Full lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.4.39 #55 Not tainted ====================================================== swapper/0/0 is trying to acquire lock: ffffffffab65b6c0 (console_owner){-...}, at: console_lock_spinning_enable+0x31/0x57 but task is already holding lock: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&irq_desc_lock_class){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d __irq_get_desc_lock+0x65/0x89 __disable_irq_nosync+0x3b/0x93 serial8250_do_startup+0x451/0x75c uart_startup+0x1b4/0x2ff uart_port_activate+0x73/0xa0 tty_port_open+0xae/0x10a uart_open+0x1b/0x26 tty_open+0x24d/0x3a0 chrdev_open+0xd5/0x1cc do_dentry_open+0x299/0x3c8 path_openat+0x434/0x1100 do_filp_open+0x9b/0x10a do_sys_open+0x15f/0x3d7 kernel_init_freeable+0x157/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d serial8250_console_write+0xa7/0x2a0 console_unlock+0x3b7/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 register_console+0x336/0x3a4 uart_add_one_port+0x51b/0x5be serial8250_register_8250_port+0x454/0x55e dw8250_probe+0x4dc/0x5b9 platform_drv_probe+0x67/0x8b really_probe+0x14a/0x422 driver_probe_device+0x66/0x130 device_driver_attach+0x42/0x5b __driver_attach+0xca/0x139 bus_for_each_dev+0x97/0xc9 bus_add_driver+0x12b/0x228 driver_register+0x64/0xed do_one_initcall+0x20c/0x4a6 do_initcall_level+0xb5/0xc5 do_basic_setup+0x4c/0x58 kernel_init_freeable+0x13f/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #0 (console_owner){-...}: __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 console_lock_spinning_enable+0x51/0x57 console_unlock+0x25d/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 ret_from_intr+0x0/0x1d cpuidle_enter_state+0x12f/0x1fd cpuidle_enter+0x2e/0x3d do_idle+0x1ce/0x2ce cpu_startup_entry+0x1d/0x1f start_kernel+0x406/0x46a secondary_startup_64+0xa4/0xb0 other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &irq_desc_lock_class Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&irq_desc_lock_class); lock(&port_lock_key); lock(&irq_desc_lock_class); lock(console_owner); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba #1: ffffffffab65b5c0 (console_lock){+.+.}, at: console_trylock_spinning+0x20/0x181 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.39 #55 Hardware name: XXXXXX Call Trace: <IRQ> dump_stack+0xbf/0x133 ? print_circular_bug+0xd6/0xe9 check_noncircular+0x1b9/0x1c3 __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 ? console_lock_spinning_enable+0x31/0x57 console_lock_spinning_enable+0x51/0x57 ? console_lock_spinning_enable+0x31/0x57 console_unlock+0x25d/0x528 ? console_trylock+0x18/0x4e vprintk_emit+0x111/0x17f ? lock_acquire+0x203/0x258 printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 common_interrupt+0xf/0xf </IRQ> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Fixes: 768aec0b5bcc ("serial: 8250: fix shared interrupts issues with SMP and RT kernels") Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Raul Rangel <rrangel@google.com> BugLink: https://bugs.chromium.org/p/chromium/issues/detail?id=1114800 Link: https://lore.kernel.org/lkml/CAHQZ30BnfX+gxjPm1DUd5psOTqbyDh4EJE=2=VAMW_VDafctkA@mail.gmail.com/T/#u Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200817022646.1484638-1-sergey.senozhatsky@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18serial: stm32: avoid kernel warning on absence of optional IRQHolger Assmann
stm32_init_port() of the stm32-usart may trigger a warning in platform_get_irq() when the device tree specifies no wakeup interrupt. The wakeup interrupt is usually a board-specific GPIO and the driver functions correctly in its absence. The mainline stm32mp151.dtsi does not specify it, so all mainline device trees trigger an unnecessary kernel warning. Use of platform_get_irq_optional() avoids this. Fixes: 2c58e56096dd ("serial: stm32: fix the get_irq error case") Signed-off-by: Holger Assmann <h.assmann@pengutronix.de> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200813152757.32751-1-h.assmann@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18serial: pl011: Fix oops on -EPROBE_DEFERLukas Wunner
If probing of a pl011 gets deferred until after free_initmem(), an oops ensues because pl011_console_match() is called which has been freed. Fix by removing the __init attribute from the function and those it calls. Commit 10879ae5f12e ("serial: pl011: add console matching function") introduced pl011_console_match() not just for early consoles but regular preferred consoles, such as those added by acpi_parse_spcr(). Regular consoles may be registered after free_initmem() for various reasons, one being deferred probing, another being dynamic enablement of serial ports using a DeviceTree overlay. Thus, pl011_console_match() must not be declared __init and the functions it calls mustn't either. Stack trace for posterity: Unable to handle kernel paging request at virtual address 80c38b58 Internal error: Oops: 8000000d [#1] PREEMPT SMP ARM PC is at pl011_console_match+0x0/0xfc LR is at register_console+0x150/0x468 [<80187004>] (register_console) [<805a8184>] (uart_add_one_port) [<805b2b68>] (pl011_register_port) [<805b3ce4>] (pl011_probe) [<80569214>] (amba_probe) [<805ca088>] (really_probe) [<805ca2ec>] (driver_probe_device) [<805ca5b0>] (__device_attach_driver) [<805c8060>] (bus_for_each_drv) [<805c9dfc>] (__device_attach) [<805ca630>] (device_initial_probe) [<805c90a8>] (bus_probe_device) [<805c95a8>] (deferred_probe_work_func) Fixes: 10879ae5f12e ("serial: pl011: add console matching function") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v4.10+ Cc: Aleksey Makarov <amakarov@marvell.com> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Christopher Covington <cov@codeaurora.org> Link: https://lore.kernel.org/r/f827ff09da55b8c57d316a1b008a137677b58921.1597315557.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18serial: pl011: Don't leak amba_ports entry on driver register errorLukas Wunner
pl011_probe() calls pl011_setup_port() to reserve an amba_ports[] entry, then calls pl011_register_port() to register the uart driver with the tty layer. If registration of the uart driver fails, the amba_ports[] entry is not released. If this happens 14 times (value of UART_NR macro), then all amba_ports[] entries will have been leaked and driver probing is no longer possible. (To be fair, that can only happen if the DeviceTree doesn't contain alias IDs since they cause the same entry to be used for a given port.) Fix it. Fixes: ef2889f7ffee ("serial: pl011: Move uart_register_driver call to device") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.15+ Cc: Tushar Behera <tushar.behera@linaro.org> Link: https://lore.kernel.org/r/138f8c15afb2f184d8102583f8301575566064a6.1597316167.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18serial: 8250_exar: Fix number of ports for Commtech PCIe cardsValmer Huhn
The following in 8250_exar.c line 589 is used to determine the number of ports for each Exar board: nr_ports = board->num_ports ? board->num_ports : pcidev->device & 0x0f; If the number of ports a card has is not explicitly specified, it defaults to the rightmost 4 bits of the PCI device ID. This is prone to error since not all PCI device IDs contain a number which corresponds to the number of ports that card provides. This particular case involves COMMTECH_4222PCIE, COMMTECH_4224PCIE and COMMTECH_4228PCIE cards with device IDs 0x0022, 0x0020 and 0x0021. Currently the multiport cards receive 2, 0 and 1 port instead of 2, 4 and 8 ports respectively. To fix this, each Commtech Fastcom PCIe card is given a struct where the number of ports is explicitly specified. This ensures 'board->num_ports' is used instead of the default 'pcidev->device & 0x0f'. Fixes: d0aeaa83f0b0 ("serial: exar: split out the exar code from 8250_pci") Signed-off-by: Valmer Huhn <valmer.huhn@concurrent-rt.com> Tested-by: Valmer Huhn <valmer.huhn@concurrent-rt.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200813165255.GC345440@icarus.concurrent-rt.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18tty: serial: qcom_geni_serial: Drop __init from qcom_geni_console_setupJohn Stultz
When booting with heavily modularized config, the serial console may not be able to load until after init when modules that satisfy needed dependencies have time to load. Unfortunately, as qcom_geni_console_setup is marked as __init, the function may have been freed before we get to run it, causing boot time crashes such as: [ 6.469057] Unable to handle kernel paging request at virtual address ffffffe645d4e6cc [ 6.481623] Mem abort info: [ 6.484466] ESR = 0x86000007 [ 6.487557] EC = 0x21: IABT (current EL), IL = 32 bits [ 6.492929] SET = 0, FnV = 0g [ 6.496016] EA = 0, S1PTW = 0 [ 6.499202] swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008151e000 [ 6.501286] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, TX]: gear=[3, 3], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 [ 6.505977] [ffffffe645d4e6cc] pgd=000000017df9f003, p4d=000000017df9f003, pud=000000017df9f003, pmd=000000017df9c003, pte=0000000000000000 [ 6.505990] Internal error: Oops: 86000007 [#1] PREEMPT SMP [ 6.505995] Modules linked in: zl10353 zl10039 zl10036 zd1301_demod xc5000 xc4000 ves1x93 ves1820 tuner_xc2028 tuner_simple tuner_types tua9001 tua6100 1 [ 6.506152] isl6405 [ 6.518104] ufshcd-qcom 1d84000.ufshc: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 [ 6.530549] horus3a helene fc2580 fc0013 fc0012 fc0011 ec100 e4000 dvb_pll ds3000 drxk drxd drx39xyj dib9000 dib8000 dib7000p dib7000m dib3000mc dibx003 [ 6.624271] CPU: 7 PID: 148 Comm: kworker/7:2 Tainted: G W 5.8.0-mainline-12021-g6defd37ba1cd #3455 [ 6.624273] Hardware name: Thundercomm Dragonboard 845c (DT) [ 6.624290] Workqueue: events deferred_probe_work_func [ 6.624296] pstate: 40c00005 (nZcv daif +PAN +UAO BTYPE=--) [ 6.624307] pc : qcom_geni_console_setup+0x0/0x110 [ 6.624316] lr : try_enable_new_console+0xa0/0x140 [ 6.624318] sp : ffffffc010843a30 [ 6.624320] x29: ffffffc010843a30 x28: ffffffe645c3e7d0 [ 6.624325] x27: ffffff80f8022180 x26: ffffffc010843b28 [ 6.637937] x25: 0000000000000000 x24: ffffffe6462a2000 [ 6.637941] x23: ffffffe646398000 x22: 0000000000000000 [ 6.637945] x21: 0000000000000000 x20: ffffffe6462a5ce8 [ 6.637952] x19: ffffffe646398e38 x18: ffffffffffffffff [ 6.680296] x17: 0000000000000000 x16: ffffffe64492b900 [ 6.680300] x15: ffffffe6461e9d08 x14: 69202930203d2064 [ 6.680305] x13: 7561625f65736162 x12: 202c363331203d20 [ 6.696434] x11: 0000000000000030 x10: 0101010101010101 [ 6.696438] x9 : 4d4d20746120304d x8 : 7f7f7f7f7f7f7f7f [ 6.707249] x7 : feff4c524c787373 x6 : 0000000000008080 [ 6.707253] x5 : 0000000000000000 x4 : 8080000000000000 [ 6.707257] x3 : 0000000000000000 x2 : ffffffe645d4e6cc [ 6.744223] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 102400000 (-34) [ 6.744966] x1 : fffffffefe74e174 x0 : ffffffe6462a5ce8 [ 6.753580] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 102400000 (-34) [ 6.761634] Call trace: [ 6.761639] qcom_geni_console_setup+0x0/0x110 [ 6.761645] register_console+0x29c/0x2f8 [ 6.767981] Bluetooth: hci0: Frame reassembly failed (-84) [ 6.775252] uart_add_one_port+0x438/0x500 [ 6.775258] qcom_geni_serial_probe+0x2c4/0x4a8 [ 6.775266] platform_drv_probe+0x58/0xa8 [ 6.855359] really_probe+0xec/0x398 [ 6.855362] driver_probe_device+0x5c/0xb8 [ 6.855367] __device_attach_driver+0x98/0xb8 [ 7.184945] bus_for_each_drv+0x74/0xd8 [ 7.188825] __device_attach+0xec/0x148 [ 7.192705] device_initial_probe+0x24/0x30 [ 7.196937] bus_probe_device+0x9c/0xa8 [ 7.200816] deferred_probe_work_func+0x7c/0xb8 [ 7.205398] process_one_work+0x20c/0x4b0 [ 7.209456] worker_thread+0x48/0x460 [ 7.213157] kthread+0x14c/0x158 [ 7.216432] ret_from_fork+0x10/0x18 [ 7.220049] Code: bad PC value [ 7.223139] ---[ end trace 73f3b21e251d5a70 ]--- Thus this patch removes the __init avoiding crash in such configs. Cc: Andy Gross <agross@kernel.org> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: linux-serial@vger.kernel.org Suggested-by: Saravana Kannan <saravanak@google.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200811025044.70626-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18serial: qcom_geni_serial: Fix recent kdb hangDouglas Anderson
The commit e42d6c3ec0c7 ("serial: qcom_geni_serial: Make kgdb work even if UART isn't console") worked pretty well and I've been doing a lot of debugging with it. However, recently I typed "dmesg" in kdb and then held the space key down to scroll through the pagination. My device hung. This was repeatable and I found that it was introduced with the aforementioned commit. It turns out that there are some strange boundary cases in geni where in some weird situations it will signal RX_LAST but then will put 0 in RX_LAST_BYTE. This means that the entire last FIFO entry is valid. This weird corner case is handled in qcom_geni_serial_handle_rx() where you can see that we only honor RX_LAST_BYTE if RX_LAST is set _and_ RX_LAST_BYTE is non-zero. If either of these is not true we use BYTES_PER_FIFO_WORD (4) for the size of the last FIFO word. Let's fix kgdb. While at it, also use the proper #define for 4. Fixes: e42d6c3ec0c7 ("serial: qcom_geni_serial: Make kgdb work even if UART isn't console") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Link: https://lore.kernel.org/r/20200806221904.1.I4455ff86f0ef5281c2a0cd0a4712db614548a5ca@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18vt_ioctl: change VT_RESIZEX ioctl to check for error return from vc_resize()George Kennedy
vc_resize() can return with an error after failure. Change VT_RESIZEX ioctl to save struct vc_data values that are modified and restore the original values in case of error. Signed-off-by: George Kennedy <george.kennedy@oracle.com> Cc: stable <stable@vger.kernel.org> Reported-by: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/1596213192-6635-2-git-send-email-george.kennedy@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18fbcon: prevent user font height or width change from causing potential ↵George Kennedy
out-of-bounds access Add a check to fbcon_resize() to ensure that a possible change to user font height or user font width will not allow a font data out-of-bounds access. NOTE: must use original charcount in calculation as font charcount can change and cannot be used to determine the font data allocated size. Signed-off-by: George Kennedy <george.kennedy@oracle.com> Cc: stable <stable@vger.kernel.org> Reported-by: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/1596213192-6635-1-git-send-email-george.kennedy@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18vt: defer kfree() of vc_screenbuf in vc_do_resize()Tetsuo Handa
syzbot is reporting UAF bug in set_origin() from vc_do_resize() [1], for vc_do_resize() calls kfree(vc->vc_screenbuf) before calling set_origin(). Unfortunately, in set_origin(), vc->vc_sw->con_set_origin() might access vc->vc_pos when scroll is involved in order to manipulate cursor, but vc->vc_pos refers already released vc->vc_screenbuf until vc->vc_pos gets updated based on the result of vc->vc_sw->con_set_origin(). Preserving old buffer and tolerating outdated vc members until set_origin() completes would be easier than preventing vc->vc_sw->con_set_origin() from accessing outdated vc members. [1] https://syzkaller.appspot.com/bug?id=6649da2081e2ebdc65c0642c214b27fe91099db3 Reported-by: syzbot <syzbot+9116ecc1978ca3a12f43@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1596034621-4714-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18kconfig: qconf: remove unused colNrMasahiro Yamada
This is not used at all. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-18kconfig: qconf: fix the popup menu in the ConfigInfoView windowMasahiro Yamada
I do not know when ConfigInfoView::createStandardContextMenu() is called. Because QTextEdit::createStandardContextMenu() is not virtual, ConfigInfoView::createStandardContextMenu() cannot override it. Even if right-click the ConfigInfoView window, the "Show Debug Info" menu does not show up. Build up the menu in the constructor, and invoke it from the contextMenuEvent(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-18kconfig: qconf: fix signal connection to invalid slotsMasahiro Yamada
If you right-click in the ConfigList window, you will see the following messages in the console: QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:888 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:897 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:906 QObject::connect: (sender name: 'config') Right, there is no such slot in QAction. I think this is a typo of setChecked. Due to this bug, when you toggled the menu "Option->Show Name/Range/Data" the state of the context menu was not previously updated. Fix this. Fixes: d5d973c3f8a9 ("Port xconfig to Qt5 - Put back some of the old implementation(part 2)") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-18genksyms: keywords: Use __restrict not _restrictJoe Perches
Use the proper form of the RESTRICT keyword. Quote the comments properly too. Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-18kbuild: remove redundant patterns in filter/filter-outMasahiro Yamada
The '%' in filter/filter-out matches to any number of any characters, including empty string. So, '%config' matches to 'config', and '%install' to 'install'. Drop the redundant patterns. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-18extract-cert: add static to local dataMasahiro Yamada
Fix the following warning from sparse: scripts/extract-cert.c:74:5: warning: symbol 'kbuild_verbose' was not declared. Should it be static? Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-08-18speakup: only build serialio when ISA is enabledSamuel Thibault
Drivers using serialio were already made available in Kconfig only under the ISA condition. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Link: https://lore.kernel.org/r/20200804160659.7y76sdseow43lfms@function Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18speakup: Fix wait_for_xmitr for ttyio caseSamuel Thibault
This was missed while introducing the tty-based serial access. The only remaining use of wait_for_xmitr with tty-based access is in spk_synth_is_alive_restart to check whether the synth can be restarted. With tty-based this is up to the tty layer to cope with the buffering etc. so we can just say yes. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Link: https://lore.kernel.org/r/20200804160637.x3iycau5izywbgzl@function Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18USB: Fix device driver raceBastien Nocera
When a new device with a specialised device driver is plugged in, the new driver will be modprobe()'d but the driver core will attach the "generic" driver to the device. After that, nothing will trigger a reprobe when the modprobe()'d device driver has finished initialising, as the device has the "generic" driver attached to it. Trigger a reprobe ourselves when new specialised drivers get registered. Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available") Signed-off-by: Bastien Nocera <hadess@hadess.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200818110445.509668-3-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18USB: Also match device drivers using the ->match vfuncBastien Nocera
We only ever used the ID table matching before, but we should also support open-coded match functions. Fixes: 88b7381a939de ("USB: Select better matching USB drivers when available") Signed-off-by: Bastien Nocera <hadess@hadess.net> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200818110445.509668-1-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: host: xhci-tegra: fix tegra_xusb_get_phy()JC Kuo
tegra_xusb_get_phy() should take input argument "name". Signed-off-by: JC Kuo <jckuo@nvidia.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200811092553.657762-1-jckuo@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: host: xhci-tegra: otg usb2/usb3 port initJC Kuo
tegra_xusb_init_usb_phy() should initialize "otg_usb2_port" and "otg_usb3_port" with -EINVAL because "0" is a valid value represents usb2 port 0 or usb3 port 0. Signed-off-by: JC Kuo <jckuo@nvidia.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200811093143.699541-1-jckuo@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: hcd: Fix use after free in usb_hcd_pci_remove()Andy Shevchenko
On the removal stage we put a reference to the controller structure and if it's not used anymore it gets freed, but later we try to dereference a pointer to a member of that structure. Copy necessary field to a temporary variable to avoid use after free. Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices") Reported-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/linux-usb/30a8c4ca-64c2-863b-cfcd-0970599c0ba3@huawei.com/ Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200814182218.71957-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: typec: ucsi: Hold con->lock for the entire duration of ucsi_register_port()Hans de Goede
Commit 081da1325d35 ("usb: typec: ucsi: displayport: Fix a potential race during registration") made the ucsi code hold con->lock in ucsi_register_displayport(). But we really don't want any interactions with the connector to run before the port-registration process is fully complete. This commit moves the taking of con->lock from ucsi_register_displayport() into ucsi_register_port() to achieve this. Cc: stable@vger.kernel.org Fixes: 081da1325d35 ("usb: typec: ucsi: displayport: Fix a potential race during registration") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-5-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: typec: ucsi: Rework ppm_lock handlingHans de Goede
The ppm_lock really only needs to be hold during 2 functions: ucsi_reset_ppm() and ucsi_run_command(). Push the taking of the lock down into these 2 functions, renaming ucsi_run_command() to ucsi_send_command() which was an existing wrapper already taking the lock for its callers. This simplifies things for the callers and removes the difference between ucsi_send_command() and ucsi_run_command() which has led to various locking bugs in the past. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-4-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: typec: ucsi: Fix 2 unlocked ucsi_run_command callsHans de Goede
Fix 2 unlocked ucsi_run_command calls: 1. ucsi_handle_connector_change() contains one ucsi_send_command() call, which takes the ppm_lock for it; and one ucsi_run_command() call which relies on the caller have taking the ppm_lock. ucsi_handle_connector_change() does not take the lock, so the second (ucsi_run_command) calls should also be ucsi_send_command(). 2. ucsi_get_pdos() gets called from ucsi_handle_connector_change() which does not hold the ppm_lock, so it also must use ucsi_send_command(). This commit also adds a WARN_ON(!mutex_is_locked(&ucsi->ppm_lock)); to ucsi_run_command() to avoid similar problems getting re-introduced in the future. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: typec: ucsi: Fix AB BA lock inversionHans de Goede
Lockdep reports an AB BA lock inversion between ucsi_init() and ucsi_handle_connector_change(): AB order: 1. ucsi_init takes ucsi->ppm_lock (it runs with that locked for the duration of the function) 2. usci_init eventually end up calling ucsi_register_displayport, which takes ucsi_connector->lock BA order: 1. ucsi_handle_connector_change work is started, takes ucsi_connector->lock 2. ucsi_handle_connector_change calls ucsi_send_command which takes ucsi->ppm_lock The ppm_lock really only needs to be hold during 2 functions: ucsi_reset_ppm() and ucsi_run_command(). This commit fixes the AB BA lock inversion by making ucsi_init drop the ucsi->ppm_lock before it starts registering ports; and replacing any ucsi_run_command() calls after this point with ucsi_send_command() (which is a wrapper around run_command taking the lock while handling the command). Some of the replacing of ucsi_run_command with ucsi_send_command in the helpers used during port registration also fixes a number of code paths after registration which call ucsi_run_command() without holding the ppm_lock: 1. ucsi_altmode_update_active() call in ucsi/displayport.c 2. ucsi_register_altmodes() call from ucsi_handle_connector_change() (through ucsi_partner_change()) Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200809141904.4317-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usbip: Implement a match function to fix usbipM. Vefa Bicakci
Commit 88b7381a939d ("USB: Select better matching USB drivers when available") introduced the use of a "match" function to select a non-generic/better driver for a particular USB device. This unfortunately breaks the operation of usbip in general, as reported in the kernel bugzilla with bug 208267 (linked below). Upon inspecting the aforementioned commit, one can observe that the original code in the usb_device_match function used to return 1 unconditionally, but the aforementioned commit makes the usb_device_match function use identifier tables and "match" virtual functions, if either of them are available. Hence, this commit implements a match function for usbip that unconditionally returns true to ensure that usbip is functional again. This change has been verified to restore usbip functionality, with a v5.7.y kernel on an up-to-date version of Qubes OS 4.0, which uses usbip to redirect USB devices between VMs. Thanks to Jonathan Dieter for the effort in bisecting this issue down to the aforementioned commit. Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available") Link: https://bugzilla.kernel.org/show_bug.cgi?id=208267 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1856443 Link: https://github.com/QubesOS/qubes-issues/issues/5905 Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com> Cc: <stable@vger.kernel.org> # 5.7 Cc: Valentina Manea <valentina.manea.m@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Bastien Nocera <hadess@hadess.net> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20200810160017.46002-1-m.v.b@runbox.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18usb: renesas-xhci: remove version checkVinod Koul
Some devices in wild are reporting bunch of firmware versions, so remove the check for versions in driver Reported by: Anastasios Vacharakis <vacharakis@gmail.com> Reported by: Glen Journeay <journeay@gmail.com> Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208911 Signed-off-by: Vinod Koul <vkoul@kernel.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200818071739.789720-1-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18USB: lvtest: return proper error code in probeEvgeny Novikov
lvs_rh_probe() can return some nonnegative value from usb_control_msg() when it is less than "USB_DT_HUB_NONVAR_SIZE + 2" that is considered as a failure. Make lvs_rh_probe() return -EINVAL in this case. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200805090643.3432-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18USB: cdc-acm: rework notification_buffer resizingTom Rix
Clang static analysis reports this error cdc-acm.c:409:3: warning: Use of memory after it is freed acm_process_notification(acm, (unsigned char *)dr); There are three problems, the first one is that dr is not reset The variable dr is set with if (acm->nb_index) dr = (struct usb_cdc_notification *)acm->notification_buffer; But if the notification_buffer is too small it is resized with if (acm->nb_size) { kfree(acm->notification_buffer); acm->nb_size = 0; } alloc_size = roundup_pow_of_two(expected_size); /* * kmalloc ensures a valid notification_buffer after a * use of kfree in case the previous allocation was too * small. Final freeing is done on disconnect. */ acm->notification_buffer = kmalloc(alloc_size, GFP_ATOMIC); dr should point to the new acm->notification_buffer. The second problem is any data in the notification_buffer is lost when the pointer is freed. In the normal case, the current data is accumulated in the notification_buffer here. memcpy(&acm->notification_buffer[acm->nb_index], urb->transfer_buffer, copy_size); When a resize happens, anything before notification_buffer[acm->nb_index] is garbage. The third problem is the acm->nb_index is not reset on a resizing buffer error. So switch resizing to using krealloc and reassign dr and reset nb_index. Fixes: ea2583529cd1 ("cdc-acm: reassemble fragmented notifications") Signed-off-by: Tom Rix <trix@redhat.com> Cc: stable <stable@vger.kernel.org> Acked-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200801152154.20683-1-trix@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18USB: quirks: Add no-lpm quirk for another Raydium touchscreenKai-Heng Feng
There's another Raydium touchscreen needs the no-lpm quirk: [ 1.339149] usb 1-9: New USB device found, idVendor=2386, idProduct=350e, bcdDevice= 0.00 [ 1.339150] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1.339151] usb 1-9: Product: Raydium Touch System [ 1.339152] usb 1-9: Manufacturer: Raydium Corporation ... [ 6.450497] usb 1-9: can't set config #1, error -110 BugLink: https://bugs.launchpad.net/bugs/1889446 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200731051622.28643-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-12 16:53:14 +0000