- 22 May, 2021 1 commit
-
-
Arnd Bergmann authored
commit 396a66aa upstream. gcc-11 warns about mismatched prototypes here: arch/x86/lib/msr-smp.c:255:51: error: argument 2 of type ‘u32 *’ {aka ‘unsigned int *’} declared as a pointer [-Werror=array-parameter=] 255 | int rdmsr_safe_regs_on_cpu(unsigned int cpu, u32 *regs) | ~~~~~^~~~ arch/x86/include/asm/msr.h:347:50: note: previously declared as an array ‘u32[8]’ {aka ‘unsigned int[8]’} GCC is right here - fix up the types. [ mingo: Twiddled the changelog. ] Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210322164541.912261-1-arnd@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 May, 2021 39 commits
-
-
Greg Kroah-Hartman authored
Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Jason Self <jason@bluehome.net> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Hulk Robot <hulkrobot@huawei.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210517140242.729269392@linuxfoundation.org Signed-off-by:
-
Kuninori Morimoto authored
commit a4856e15 upstream. commit 66c705d0 ("SoC: rsnd: add interrupt support for SSI BUSIF buffer") adds __rsnd_ssi_interrupt() checks for BUSIF status, but is using "break" at for loop. This means it is not checking all status. Let's check all BUSIF status. Fixes: commit 66c705d0 ("SoC: rsnd: add interrupt support for SSI BUSIF buffer") Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/874kgh1jsw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Christoph Hellwig authored
commit 53fe2a30 upstream. Do not call nvme_configure_apst when the controller is not live, given that nvme_configure_apst will fail due the lack of an admin queue when the controller is being torn down and nvme_set_latency_tolerance is called from dev_pm_qos_hide_latency_tolerance. Fixes: 510a405d ("nvme: fix memory leak for power latency tolerance") Reported-by:
Peng Liu <liupeng17@lenovo.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Keith Busch <kbusch@kernel.org> Signed-off-by:
-
Paweł Chmiel authored
commit 34138a59 upstream. This clock must be always enabled to allow access to any registers in fsys1 CMU. Until proper solution based on runtime PM is applied (similar to what was done for Exynos5433), mark that clock as critical so it won't be disabled. It was observed on Samsung Galaxy S6 device (based on Exynos7420), where UFS module is probed before pmic used to power that device. In this case defer probe was happening and that clock was disabled by UFS driver, causing whole boot to hang on next CMU access. Fixes: 753195a7 ("clk: samsung: exynos7: Correct CMU_FSYS1 clocks names") Signed-off-by:
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/linux-clk/20201024154346.9589-1-pawel.mikolaj.chmiel@gmail.com [s.nawrocki: Added comment in the code] Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Jonathon Reinhart authored
commit 2671fa4d upstream. These sysctls point to global variables: - NF_SYSCTL_CT_MAX (&nf_conntrack_max) - NF_SYSCTL_CT_EXPECT_MAX (&nf_ct_expect_max) - NF_SYSCTL_CT_BUCKETS (&nf_conntrack_htable_size_user) Because their data pointers are not updated to point to per-netns structures, they must be marked read-only in a non-init_net ns. Otherwise, changes in any net namespace are reflected in (leaked into) all other net namespaces. This problem has existed since the introduction of net namespaces. The current logic marks them read-only only if the net namespace is owned by an unprivileged user (other than init_user_ns). Commit d0febd81 ("netfilter: conntrack: re-visit sysctls in unprivileged namespaces") "exposes all sysctls even if the namespace is unpriviliged." Since we need to mark them readonly in any case, we can forego the unprivileged user check altogether. Fixes: d0febd81 ("netfilter: conntrack: re-visit sysctls in unprivileged namespaces") Signed-off-by:
Jonathon Reinhart <Jonathon.Reinhart@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Greg Kroah-Hartman authored
commit b4104180 upstream. syzbot can trigger the WARN() in init_uevent_argv() which isn't the nicest as the code does properly recover and handle the error. So change the WARN() call to pr_warn() and provide some more information on what the buffer size that was needed. Link: https://lore.kernel.org/r/20201107082206.GA19079@kroah.com Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: linux-kernel@vger.kernel.org Reported-by: syzbot+92340f7b2b4789907fdb@syzkaller.appspotmail.com Signed-off-by:
-
Badhri Jagan Sridharan authored
commit 374157ff upstream. "usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply" introduced a regression for req_out_volt and req_op_curr calculation. req_out_volt should consider the newly calculated max voltage instead of previously accepted max voltage by the port partner. Likewise, req_op_curr should consider the newly calculated max current instead of previously accepted max current by the port partner. Fixes: e3a07202 ("usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply") Reviewed-by:
Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20210415050121.1928298-1-badhri@google.com Signed-off-by:
-
Ard Biesheuvel authored
commit 10fce53c upstream The early ATAGS/DT mapping code uses SECTION_SHIFT to mask low order bits of R2, and decides that no ATAGS/DTB were provided if the resulting value is 0x0. This means that on systems where DRAM starts at 0x0 (such as Raspberry Pi), no explicit mapping of the DT will be created if R2 points into the first 1 MB section of memory. This was not a problem before, because the decompressed kernel is loaded at the base of DRAM and mapped using sections as well, and so as long as the DT is referenced via a virtual address that uses the same translation (the linear map, in this case), things work fine. However, commit 7a1be318 ("9012/1: move device tree mapping out of linear region") changes this, and now the DT is referenced via a virtual address that is disjoint from the linear mapping of DRAM, and so we need the early code to create the DT mapping unconditionally. So let's create the early DT mapping for any value of R2 != 0x0. Reported-by:
"kernelci.org bot" <bot@kernelci.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Ard Biesheuvel authored
commit fc2933c1 upstream Commit 149a3ffe62b9dbc3 ("9012/1: move device tree mapping out of linear region") created a permanent, read-only section mapping of the device tree blob provided by the firmware, and added a set of macros to get the base and size of the virtually mapped FDT based on the physical address. However, while the mapping code uses the SECTION_SIZE macro correctly, the macros use PMD_SIZE instead, which means something entirely different on ARM when using short descriptors, and is therefore not the right quantity to use here. So replace PMD_SIZE with SECTION_SIZE. While at it, change the names of the macro and its parameter to clarify that it returns the virtual address of the start of the FDT, based on the physical address in memory. Tested-by:
Joel Stanley <joel@jms.id.au> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Ard Biesheuvel authored
commit 7a1be318 upstream On ARM, setting up the linear region is tricky, given the constraints around placement and alignment of the memblocks, and how the kernel itself as well as the DT are placed in physical memory. Let's simplify matters a bit, by moving the device tree mapping to the top of the address space, right between the end of the vmalloc region and the start of the the fixmap region, and create a read-only mapping for it that is independent of the size of the linear region, and how it is organized. Since this region was formerly used as a guard region, which will now be populated fully on LPAE builds by this read-only mapping (which will still be able to function as a guard region for stray writes), bump the start of the [underutilized] fixmap region by 512 KB as well, to ensure that there is always a proper guard region here. Doing so still leaves ample room for the fixmap space, even with NR_CPUS set to its maximum value of 32. Tested-by:
Nicolas Pitre <nico@fluxnic.net> Signed-off-by:
-
Ard Biesheuvel authored
commit e9a2f8b5 upstream Before moving the DT mapping out of the linear region, let's prepare for this change by removing all the phys-to-virt translations of the __atags_pointer variable, and perform this translation only once at setup time. Tested-by:
-
Eric Biggers authored
commit 3c031542 upstream. f2fs didn't properly clean up if verity failed to be enabled on a file: - It left verity metadata (pages past EOF) in the page cache, which would be exposed to userspace if the file was later extended. - It didn't truncate the verity metadata at all (either from cache or from disk) if an error occurred while setting the verity bit. Fix these bugs by adding a call to truncate_inode_pages() and ensuring that we truncate the verity metadata (both from cache and from disk) in all error paths. Also rework the code to cleanly separate the success path from the error paths, which makes it much easier to understand. Finally, log a message if f2fs_truncate() fails, since it might otherwise fail silently. Reported-by:
Yunlei He <heyunlei@hihonor.com> Fixes: 95ae251f ("f2fs: add fs-verity support") Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Lukasz Luba authored
commit fef05776 upstream. The tz->lock must be hold during the looping over the instances in that thermal zone. This lock was missing in the governor code since the beginning, so it's hard to point into a particular commit. CC: stable@vger.kernel.org # 4.4+ Signed-off-by:
Lukasz Luba <lukasz.luba@arm.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210422153624.6074-2-lukasz.luba@arm.com Signed-off-by:
-
Maciej W. Rozycki authored
commit 25ab14cb upstream. Remove the inline asm with a DIVU instruction from `__div64_32' and use plain C code for the intended DIVMOD calculation instead. GCC is smart enough to know that both the quotient and the remainder are calculated with single DIVU, so with ISAs up to R5 the same instruction is actually produced with overall similar code. For R6 compiled code will work, but separate DIVU and MODU instructions will be produced, which are also interlocked, so scalar implementations will likely not perform as well as older ISAs with their asynchronous MD unit. Likely still faster then the generic algorithm though. This removes a compilation error for R6 however where the original DIVU instruction is not supported anymore and the MDU accumulator registers have been removed and consequently GCC complains as to a constraint it cannot find a register for: In file included from ./include/linux/math.h:5, from ./include/linux/kernel.h:13, from mm/page-writeback.c:15: ./include/linux/math64.h: In function 'div_u64_rem': ./arch/mips/include/asm/div64.h:76:17: error: inconsistent operand constraints in an 'asm' 76 | __asm__("divu $0, %z1, %z2" \ | ^~~~~~~ ./include/asm-generic/div64.h:245:25: note: in expansion of macro '__div64_32' 245 | __rem = __div64_32(&(n), __base); \ | ^~~~~~~~~~ ./include/linux/math64.h:91:22: note: in expansion of macro 'do_div' 91 | *remainder = do_div(dividend, divisor); | ^~~~~~ This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0404s from 1.0445s with R3400 @40MHz. The module's MIPS I machine code has also shrunk by 12 bytes or 3 instructions. Signed-off-by:
Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Maciej W. Rozycki authored
commit c1d337d4 upstream. We already check the high part of the divident against zero to avoid the costly DIVU instruction in that case, needed to reduce the high part of the divident, so we may well check against the divisor instead and set the high part of the quotient to zero right away. We need to treat the high part the divident in that case though as the remainder that would be calculated by the DIVU instruction we avoided. This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0445s and 0.2619s from 1.0668s and 0.2629s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz. Signed-off-by:
-
Maciej W. Rozycki authored
commit c49f71f6 upstream. Our current MIPS platform `__div64_32' handler is inactive, because it is incorrectly only enabled for 64-bit configurations, for which generic `do_div' code does not call it anyway. The handler is not suitable for being called from there though as it only calculates 32 bits of the quotient under the assumption the 64-bit divident has been suitably reduced. Code for such reduction used to be there, however it has been incorrectly removed with commit c21004cd ("MIPS: Rewrite <asm/div64.h> to work with gcc 4.4.0."), which should have only updated an obsoleted constraint for an inline asm involving $hi and $lo register outputs, while possibly wiring the original MIPS variant of the `do_div' macro as `__div64_32' handler for the generic `do_div' implementation Correct the handler as follows then: - Revert most of the commit referred, however retaining the current formatting, except for the final two instructions of the inline asm sequence, which the original commit missed. Omit the original 64-bit parts though. - Rename the original `do_div' macro to `__div64_32'. Use the combined `x' constraint referring to the MD accumulator as a whole, replacing the original individual `h' and `l' constraints used for $hi and $lo registers respectively, of which `h' has been obsoleted with GCC 4.4. Update surrounding code accordingly. We have since removed support for GCC versions before 4.9, so no need for a special arrangement here; GCC has supported the `x' constraint since forever anyway, or at least going back to 1991. - Rename the `__base' local variable in `__div64_32' to `__radix' to avoid a conflict with a local variable in `do_div'. - Actually enable this code for 32-bit rather than 64-bit configurations by qualifying it with BITS_PER_LONG being 32 instead of 64. Include <asm/bitsperlong.h> for this macro rather than <linux/types.h> as we don't need anything else. - Finally include <asm-generic/div64.h> last rather than first. This has passed correctness verification with test_div64 and reduced the module's average execution time down to 1.0668s and 0.2629s from 2.1529s and 0.5647s respectively for an R3400 CPU @40MHz and a 5Kc CPU @160MHz. For a reference 64-bit `do_div' code where we have the DDIVU instruction available to do the whole calculation right away averages at 0.0660s for the latter CPU. Fixes: c21004cd ("MIPS: Rewrite <asm/div64.h> to work with gcc 4.4.0.") Reported-by:
Huacai Chen <chenhuacai@kernel.org> Signed-off-by:
-
Maciej W. Rozycki authored
commit 193ced4a upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by:
-
Matthew Wilcox (Oracle) authored
commit 9ddb3c14 upstream. 32-bit architectures which expect 8-byte alignment for 8-byte integers and need 64-bit DMA addresses (arm, mips, ppc) had their struct page inadvertently expanded in 2019. When the dma_addr_t was added, it forced the alignment of the union to 8 bytes, which inserted a 4 byte gap between 'flags' and the union. Fix this by storing the dma_addr_t in one or two adjacent unsigned longs. This restores the alignment to that of an unsigned long. We always store the low bits in the first word to prevent the PageTail bit from being inadvertently set on a big endian platform. If that happened, get_user_pages_fast() racing against a page which was freed and reallocated to the page_pool could dereference a bogus compound_head(), which would be hard to trace back to this cause. Link: https://lkml.kernel.org/r/20210510153211.1504886-1-willy@infradead.org Fixes: c25fff71 ("mm: add dma_addr_t to struct page") Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Tested-by:
Matteo Croce <mcroce@linux.microsoft.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thomas Gleixner authored
commit 594b27e6 upstream. Nothing prevents the following: pvclock_gtod_notify() queue_work(system_long_wq, &pvclock_gtod_work); ... remove_module(kvm); ... work_queue_run() pvclock_gtod_work() <- UAF Ditto for any other operation on that workqueue list head which touches pvclock_gtod_work after module removal. Cancel the work in kvm_arch_exit() to prevent that. Fixes: 16e8d74d ("KVM: x86: notifier for clocksource changes") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Message-Id: <87czu4onry.ffs@nanos.tec.linutronix.de> Cc: stable@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Oliver Neukum authored
commit 18abf874 upstream. We have a cycle of callbacks scheduling works which submit URBs with those callbacks. This needs to be blocked, stopped and unblocked to untangle the circle. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20210426092622.20433-1-oneukum@suse.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Colin Ian King authored
commit af0e1871 upstream. The lux_val returned from tsl2583_get_lux can potentially be zero, so check for this to avoid a division by zero and an overflowed gain_trim_val. Fixes clang scan-build warning: drivers/iio/light/tsl2583.c:345:40: warning: Either the condition 'lux_val<0' is redundant or there is division by zero at line 345. [zerodivcond] Fixes: ac4f6eee ("staging: iio: TAOS tsl258x: Device driver") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Dmitry Osipenko authored
commit f73c7307 upstream. The raw temperature value is a 16-bit signed integer. The sign casting is missing in the code, which results in a wrong temperature reported by userspace tools, fix it. Cc: stable@vger.kernel.org Fixes: 3904b28e ("iio: gyro: Add driver for the MPU-3050 gyroscope") Datasheet: https://www.cdiweb.com/datasheets/invensense/mpu-3000a.pdf Tested-by: Maxim Schwalm <maxim.schwalm@gmail.com> # Asus TF700T Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Asus TF201 Reported-by:
Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by:
Andy Shevchenko <Andy.Shevchenko@gmail.com> Reviewed-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Link: https://lore.kernel.org/r/20210423020959.5023-1-digetx@gmail.com Signed-off-by:
-
Sandeep Singh authored
commit 3c128781 upstream. One of AMD xhci controller require reset on resume. Occasionally AMD xhci controller does not respond to Stop endpoint command. Once the issue happens controller goes into bad state and in that case controller needs to be reset. Cc: <stable@vger.kernel.org> Signed-off-by:
Sandeep Singh <sandeep.singh@amd.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210512080816.866037-6-mathias.nyman@linux.intel.com Signed-off-by:
-
Christophe JAILLET authored
commit dda32c00 upstream. 'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be submitted in interrupt context" (see comment related to 'usb_submit_urb()' in 'drivers/usb/core/urb.c') So this flag should be used in all the calling chain. Up to now, 'xhci_check_maxpacket()' which is only called from 'xhci_urb_enqueue()', uses GFP_KERNEL. Be safe and pass the mem_flags to this function as well. Fixes: ddba5cd0 ("xhci: Use command structures when queuing commands on the command ring") Cc: <stable@vger.kernel.org> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Wesley Cheng authored
commit 18ffa988 upstream. If an error is received when issuing a start or update transfer command, the error handler will stop all active requests (including the current USB request), and call dwc3_gadget_giveback() to notify function drivers of the requests which have been stopped. Avoid returning an error for kick transfer during EP queue, to remove duplicate cleanup operations on the request being queued. Fixes: 8d99087c ("usb: dwc3: gadget: Properly handle failed kick_transfer") cc: stable@vger.kernel.org Signed-off-by:
Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1620410119-24971-1-git-send-email-wcheng@codeaurora.org Signed-off-by:
-
Chunfeng Yun authored
commit 975f94c7 upstream. This may happen if the port becomes resume status exactly when usb_port_resume() gets port status, it still need provide a TRSMCRY time before access the device. CC: <stable@vger.kernel.org> Reported-by:
Tianping Fang <tianping.fang@mediatek.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210512020738.52961-1-chunfeng.yun@mediatek.com Signed-off-by:
-
Phil Elwell authored
commit 75a41ce4 upstream. The dwc2 gadget support maps and unmaps DMA buffers as necessary. When mapping and unmapping it uses the direction of the endpoint to select the direction of the DMA transfer, but this fails for Control OUT transfers because the unmap occurs after the endpoint direction has been reversed for the status phase. A possible solution would be to unmap the buffer before the direction is changed, but a safer, less invasive fix is to remember the buffer direction independently of the endpoint direction. Fixes: fe0b94ab ("usb: dwc2: gadget: manage ep0 state in software") Acked-by:
Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Phil Elwell <phil@raspberrypi.com> Link: https://lore.kernel.org/r/20210506112200.2893922-1-phil@raspberrypi.com Signed-off-by:
-
Maximilian Luz authored
commit ca09b1be upstream. On some devices (specifically the SC8180x based Surface Pro X with QCOM04A6) HC halt / xhci_halt() times out during boot. Manually binding the xhci-hcd driver at some point later does not exhibit this behavior. To work around this, double XHCI_MAX_HALT_USEC, which also resolves this issue. Cc: <stable@vger.kernel.org> Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by:
-
Ferry Toth authored
commit 04357faf upstream. On Intel Merrifield LPM is causing host to reset port after a timeout. By disabling LPM entirely this is prevented. Fixes: 066c0959 ("usb: dwc3: pci: Enable extcon driver for Intel Merrifield") Reviewed-by:
Ferry Toth <ftoth@exalondelft.nl> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210425150947.5862-1-ftoth@exalondelft.nl Signed-off-by:
-
Marcel Hamer authored
commit e17b02d4 upstream. When extcon is used in combination with dwc3, it is assumed that the dwc3 registers are untouched and as such are only configured if VBUS is valid or ID is tied to ground. In case VBUS is not valid or ID is floating, the registers are not configured as such during driver initialization, causing a wrong default state during boot. If the registers are not in a default state, because they are for instance touched by a boot loader, this can cause for a kernel error. Signed-off-by:
Marcel Hamer <marcel@solidxs.se> Link: https://lore.kernel.org/r/20210427122118.1948340-1-marcel@solidxs.se Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Christoph Hellwig authored
commit 1cea335d upstream. bio completions can race when a page spans more than one file system block. Add a spinlock to synchronize marking the page uptodate. Fixes: 9dc55f13 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") Reported-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 630ef623 ] If a tag set is shared across request queues (e.g. SCSI LUNs) then the block layer core keeps track of the number of active request queues in tags->active_queues. blk_mq_tag_busy() and blk_mq_tag_idle() update that atomic counter if the hctx flag BLK_MQ_F_TAG_QUEUE_SHARED is set. Make sure that blk_mq_exit_queue() calls blk_mq_tag_idle() before that flag is cleared by blk_mq_del_queue_tag_set(). Cc: Christoph Hellwig <hch@infradead.org> Cc: Ming Lei <ming.lei@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Fixes: 0d2602ca ("blk-mq: improve support for shared tags maps") Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20210513171529.7977-1-bvanassche@acm.org Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Sun Ke authored
[ Upstream commit 79ebe911 ] Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c8 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750] ____sys_sendmsg+0x1da/0x320 [ 656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put(). Fixes: e9e006f5 ("nbd: fix max number of supported devs") Signed-off-by:
Sun Ke <sunke32@huawei.com> Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20210512114331.1233964-2-sunke32@huawei.com Signed-off-by:
-
Omar Sandoval authored
[ Upstream commit efed9a33 ] __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bou...
-
Christophe JAILLET authored
[ Upstream commit 0c8bd174 ] If 'acpi_device_set_name()' fails, we must free 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak. Fixes: eb50aaf9 ("ACPI: scan: Use unique number for instance_no") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Eddie James authored
[ Upstream commit 5216dff2 ] The poll rate limiter time was initialized at zero. This breaks the comparison in time_after if jiffies is large. Switch to storing the next update time rather than the previous time, and initialize the time when the device is probed. Fixes: c10e753d ("hwmon (occ): Add sensor types and versions") Signed-off-by:
Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210429151336.18980-1-eajames@linux.ibm.com Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit a60a3436 ] 'retval' is known to be -ENODEV here. This is a hard-coded default error code which is not useful in the error message. Moreover, another error message is printed at the end of the error handling path. The corresponding error code (-ENOMEM) is more informative. So remove simplify the first error message. While at it, also remove the useless initialization of 'retval'. Fixes: 7d50195f ("usb: host: Faraday fotg210-hcd driver") Signed-off-by:
-
Dinghao Liu authored
[ Upstream commit a2fa9242 ] When lidar_write_control() fails, a pairing PM usage counter decrement is needed to keep the counter balanced. Fixes: 4ac4e086 ("iio: pulsedlight-lidar-lite: add runtime PM") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by:
-
Ville Syrjälä authored
commit 4819d16d upstream. Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size() can in fact return <4KiB, which leads to div-by-zero here. Avoid that. Not sure i915_gem_object_get_tile_row_size() is entirely sane anyway since it doesn't account for the different tile layouts on i8xx/i915... I'm not able to hit this before commit 6846895f ("drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT") and it looks like I also need to run recent version of Mesa. With those in place xonotic trips on this quite easily on my 85x. Cc: stable@vger.kernel.org Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421153401.13847-2-ville.syrjala@linux.intel.com (cherry picked from commit ed52c62d ) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
