13 Dec, 2019
27 commits
-
There's an issue with deferred requests through drain, where if we do
need to defer, we're not copying over the sqe_submit state correctly.
This can result in using uninitialized data when we then later go and
submit the deferred request, like this check in __io_submit_sqe():if (unlikely(s->index >= ctx->sq_entries))
return -EINVAL;with 's' being uninitialized, we can randomly fail this check. Fix this
by copying sqe_submit state when we defer a request.Because it was fixed as part of a cleanup series in mainline, before
anyone realized we had this issue. That removed the separate states
of ->index vs ->submit.sqe. That series is not something I was
comfortable putting into stable, hence the much simpler addition.
Here's the patch in the series that fixes the same issue:commit cf6fd4bd559ee61a4454b161863c8de6f30f8dca
Author: Pavel Begunkov
Date: Mon Nov 25 23:14:39 2019 +0300io_uring: inline struct sqe_submit
Reported-by: Andres Freund
Reported-by: Tomáš Chaloupka
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit aa4c3967756c6c576a38a23ac511be211462a6b7 upstream.
Christophe reports that current master fails building on powerpc with
this error:CC fs/io_uring.o
fs/io_uring.c: In function ‘loop_rw_iter’:
fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’
[-Werror=implicit-function-declaration]
iovec.iov_base = kmap(iter->bvec->bv_page)
^
fs/io_uring.c:1628:19: warning: assignment makes pointer from integer
without a cast [-Wint-conversion]
iovec.iov_base = kmap(iter->bvec->bv_page)
^
fs/io_uring.c:1643:4: error: implicit declaration of function ‘kunmap’
[-Werror=implicit-function-declaration]
kunmap(iter->bvec->bv_page);
^which is caused by a missing highmem.h include. Fix it by including
it.Fixes: 311ae9e159d8 ("io_uring: fix dead-hung for non-iter fixed rw")
Reported-by: Christophe Leroy
Tested-by: Christophe Leroy
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit eb59bd17d2fa6e5e84fba61a5ebdea984222e6d5 upstream.
If a filesystem returns negative inode sizes, future reads on the file were
causing the cpu to spin on truncate_pagecache.Create a helper to validate the attributes. This now does two things:
- check the file mode
- check if the file size fits in i_size without overflowingReported-by: Arijit Banerjee
Fixes: d8a5ba45457e ("[PATCH] FUSE - core")
Cc: # v2.6.14
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit 8aab336b14c115c6bf1d4baeb9247e41ed9ce6de upstream.
Make sure filesystem is not returning a bogus number of bytes written.
Fixes: ea9b9907b82a ("fuse: implement perform_write")
Cc: # v2.6.26
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit c634da718db9b2fac201df2ae1b1b095344ce5eb upstream.
When adding a new hard link, make sure that i_nlink doesn't overflow.
Fixes: ac45d61357e8 ("fuse: fix nlink after unlink")
Cc: # v3.4
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit f1ebdeffc6f325e30e0ddb9f7a70f1370fa4b851 upstream.
exit_aio() is sometimes stuck in wait_for_completion() after aio is issued
with direct IO and the task receives a signal.The reason is failure to call ->ki_complete() due to a leaked reference to
fuse_io_priv. This happens in fuse_async_req_send() if
fuse_simple_background() returns an error (e.g. -EINTR).In this case the error value is propagated via io->err, so return success
to not confuse callers.This issue is tracked as a virtio-fs issue:
https://gitlab.com/virtio-fs/qemu/issues/14Reported-by: Masayoshi Mizuma
Fixes: 45ac96ed7c36 ("fuse: convert direct_io to simple api")
Cc: # v5.4
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit 441cdbd5449b4923cd413d3ba748124f91388be9 upstream.
We should never return -ERESTARTSYS to userspace, transform it into
-EINTR.Cc: stable@vger.kernel.org # v5.3+
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 311ae9e159d81a1ec1cf645daf40b39ae5a0bd84 upstream.
Read/write requests to devices without implemented read/write_iter
using fixed buffers can cause general protection fault, which totally
hangs a machine.io_import_fixed() initialises iov_iter with bvec, but loop_rw_iter()
accesses it as iovec, dereferencing random address.kmap() page by page in this case
Cc: stable@vger.kernel.org
Signed-off-by: Pavel Begunkov
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit cdb2256f795e8e78cc43f32d091695b127dfb4df upstream.
The SDIO HW reset procedure in mwifiex_sdio_card_reset_work() is broken,
when the SDIO card is shared with another SDIO func driver. This is the
case when the Bluetooth btmrvl driver is being used in combination with
mwifiex. More precisely, when mwifiex_sdio_card_reset_work() runs to resets
the SDIO card, the btmrvl driver doesn't get notified about it. Beyond that
point, the btmrvl driver will fail to communicate with the SDIO card.This is a generic problem for SDIO func drivers sharing an SDIO card, which
are about to be addressed in subsequent changes to the mmc core and the
mmc_hw_reset() interface. In principle, these changes means the
mmc_hw_reset() interface starts to return 1 if the are multiple drivers for
the SDIO card, as to indicate to the caller that the reset needed to be
scheduled asynchronously through a hotplug mechanism of the SDIO card.Let's prepare the mwifiex driver to support the upcoming new behaviour of
mmc_hw_reset(), which means extending the mwifiex_sdio_card_reset_work() to
support the asynchronous SDIO HW reset path. This also means, we need to
allow the ->remove() callback to run, without waiting for the FW to be
loaded. Additionally, during system suspend, mwifiex_sdio_suspend() may be
called when a reset has been scheduled, but waiting to be executed. In this
scenario let's simply return -EBUSY to abort the suspend process, as to
allow the reset to be completed first.Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
Cc: stable@vger.kernel.org # v5.4+
Acked-by: Kalle Valo
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream.
The driver forgets to call pm_runtime_disable in remove.
Add the missed calls to fix it.Signed-off-by: Chuhong Yuan
Cc: stable
Link: https://lore.kernel.org/r/20191118024833.21587-1-hslester96@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 05faa64e73924556ba281911db24643e438fe7ba upstream.
Since the commit 7723f4c5ecdb ("driver core: platform: Add an error message
to platform_get_irq*()") platform_get_irq() started issuing an error message.
Thus, there is no need to have the same in the driverFixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Andy Shevchenko
Cc: stable
Link: https://lore.kernel.org/r/20191023103558.51862-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 1250ed7114a977cdc2a67a0c09d6cdda63970eb9 upstream.
The interrupt clear flag register is a "write 1 to clear" register.
So, only writing ones allows to clear flags:
- Replace buggy stm32_clr_bits() by a simple write to clear error flags
- Replace useless read/modify/write stm32_set_bits() routine by a
simple write to clear TC (transfer complete) flag.Fixes: 4f01d833fdcd ("serial: stm32: fix rx error handling")
Signed-off-by: Fabrice Gasnier
Cc: stable
Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@st.com
Signed-off-by: Greg Kroah-Hartman -
commit 7d73170e1c282576419f8b50a771f1fcd2b81a94 upstream.
Doing fuzz test on sbsa uart device, causes a kernel crash
due to NULL pointer dereference:------------[ cut here ]------------
Unable to handle kernel paging request at virtual address fffffffffffffffc
pgd = ffffffe331723000
[fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O)
Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O)
hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O)
mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O)
uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4
iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd
usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid
ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod
yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand
nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe
cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry
nfsv3 nfs nfs_acl lockd sunrpc grace autofs4
CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G O 4.4.193 #1
task: ffffffe32b23f110 task.stack: ffffffe32bda4000
PC is at uart_break_ctl+0x44/0x84
LR is at uart_break_ctl+0x34/0x84
pc : [] lr : [] pstate: 80000005
sp : ffffffe32bda7cc0
x29: ffffffe32bda7cc0 x28: ffffffe32b23f110
x27: ffffff8393402000 x26: 0000000000000000
x25: ffffffe32b233f40 x24: ffffffc07a8ec680
x23: 0000000000005425 x22: 00000000ffffffff
x21: ffffffe33ed73c98 x20: 0000000000000000
x19: ffffffe33ed94168 x18: 0000000000000004
x17: 0000007f92ae9d30 x16: ffffff8392fa6064
x15: 0000000000000010 x14: 0000000000000000
x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000020 x10: 0000007ffdac1708
x9 : 0000000000000078 x8 : 000000000000001d
x7 : 0000000052a64887 x6 : ffffffe32bda7e08
x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000
x3 : ffffff83938d5018 x2 : 0000000000000080
x1 : ffffffe32b23c040 x0 : ffffff83934428f8
virtual start addr offset is 38ac00000
module base offset is 2cd4cf1000
linear region base offset is : 0
Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000)
Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000)
7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054
7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c
7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600
7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425
7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003
7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e
7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600
7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410
7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978
7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc
7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0
7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78
7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c
7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425
7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014
7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078
7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000
7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30
7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0
7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840
7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000
7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d
7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call trace:
Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0)
7aa0: 0000000000001000 0000007fffffffff
7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025
7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c
7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20
7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000
7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110
7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600
7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018
7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887
7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020
7be0: 0000000000000000 0000000000000000
[] uart_break_ctl+0x44/0x84
[] send_break+0xa0/0x114
[] tty_ioctl+0xc50/0xe84
[] do_vfs_ioctl+0xc4/0x6e8
[] SyS_ioctl+0x68/0x9c
[] __sys_trace_return+0x0/0x4
Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280)
---[ end trace 8606094f1960c5e0 ]---
Kernel panic - not syncing: Fatal exceptionFix this problem by adding NULL checks prior to calling break_ctl ops.
Signed-off-by: Jiangfeng Xiao
Cc: stable
Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.com
Signed-off-by: Greg Kroah-Hartman -
commit f6a196477184b99a31d16366a8e826558aa11f6d upstream.
PL011's ->flush_buffer() implementation releases and reacquires the port
lock. Due to a race condition here, data can end up being added to the
circular buffer but neither being discarded nor being sent out. This
leads to, for example, tcdrain(2) waiting indefinitely.Process A Process B
uart_flush_buffer()
- acquire lock
- circ_clear
- pl011_flush_buffer()
-- release lock
-- dmaengine_terminate_all()uart_write()
- acquire lock
- add chars to circ buffer
- start_tx()
-- start DMA
- release lock-- acquire lock
-- turn off DMA
-- release lock// Data in circ buffer but DMA is off
According to the comment in the code, the releasing of the lock around
dmaengine_terminate_all() is to avoid a deadlock with the DMA engine
callback. However, since the time this code was written, the DMA engine
API documentation seems to have been clarified to say that
dmaengine_terminate_all() (in the identically implemented but
differently named dmaengine_terminate_async() variant) does not wait for
any running complete callback to be completed and can even be called
from a complete callback. So there is no possibility of deadlock if the
DMA engine driver implements this API correctly.So we should be able to just remove this release and reacquire of the
lock to prevent the aforementioned race condition.Signed-off-by: Vincent Whitchurch
Cc: stable
Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.com
Signed-off-by: Greg Kroah-Hartman -
commit b027ce258369cbfa88401a691c23dad01deb9f9b upstream.
hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and
Lenovo Miix 630 laptop. As part of initializing the wcn3990, hci_qca
disables flow, configures the uart baudrate, and then reenables flow - at
which point an event is expected to be received over the uart from the
wcn3990. It is observed that this event comes after the baudrate change
but before hci_qca re-enables flow. This is unexpected, and is a result of
msm_reset() being broken.According to the uart_dm hardware documentation, it is recommended that
automatic hardware flow control be enabled by setting RX_RDY_CTL. Auto
hw flow control will manage RFR based on the configured watermark. When
there is space to receive data, the hw will assert RFR. When the watermark
is hit, the hw will de-assert RFR.The hardware documentation indicates that RFR can me manually managed via
CR when RX_RDY_CTL is not set. SET_RFR asserts RFR, and RESET_RFR
de-asserts RFR.msm_reset() is broken because after resetting the hardware, it
unconditionally asserts RFR via SET_RFR. This enables flow regardless of
the current configuration, and would undo a previous flow disable
operation. It should instead de-assert RFR via RESET_RFR to block flow
until the hardware is reconfigured. msm_serial should rely on the client
to specify that flow should be enabled, either via mctrl() or the termios
structure, and only assert RFR in response to those triggers.Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
Signed-off-by: Jeffrey Hugo
Reviewed-by: Bjorn Andersson
Cc: stable
Reviewed-by: Andy Gross
Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 487ee861de176090b055eba5b252b56a3b9973d6 upstream.
The dmaengine_prep_slave_sg needs to use sg count returned
by dma_map_sg, not use sport->dma_tx_nents, because the return
value of dma_map_sg is not always same with "nents".When enabling iommu for lpuart + edma, iommu framework may concatenate
two sgs into one.Fixes: 6250cc30c4c4e ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx")
Cc:
Signed-off-by: Peng Fan
Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Greg Kroah-Hartman -
commit eb9c1a41ea1234907615fe47d6e47db8352d744b upstream.
As platform_get_irq() now prints an error when the interrupt does not
exist, this warnings are printed on bananapi-r2:[ 4.935780] mt6577-uart 11004000.serial: IRQ index 1 not found
[ 4.962589] 11002000.serial: ttyS1 at MMIO 0x11002000 (irq = 202, base_baud = 1625000) is a ST16650V2
[ 4.972127] mt6577-uart 11002000.serial: IRQ index 1 not found
[ 4.998927] 11003000.serial: ttyS2 at MMIO 0x11003000 (irq = 203, base_baud = 1625000) is a ST16650V2
[ 5.008474] mt6577-uart 11003000.serial: IRQ index 1 not foundFix this by calling platform_get_irq_optional() instead.
now it looks like this:
[ 4.872751] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Frank Wunderlich
Cc: stable
Link: https://lore.kernel.org/r/20191027062117.20389-1-frank-w@public-files.de
Signed-off-by: Greg Kroah-Hartman -
commit daf82bd24e308c5a83758047aff1bd81edda4f11 upstream.
gserial_alloc_line() misses locking (for a release barrier) while
resetting port entry on TTY allocation failure. Fix this.Cc: stable@vger.kernel.org
Signed-off-by: Michał Mirosław
Reviewed-by: Greg Kroah-Hartman
Tested-by: Ladislav Michl
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 17a29fea086ba18b000d28439bd5cb4f2b0a527b upstream.
When building for a non-Cavium MIPS system with COMPILE_TEST=y, the
Octeon ethernet driver hits a number of issues due to use of macros
provided only for CONFIG_CAVIUM_OCTEON_SOC=y configurations. For
example:drivers/staging/octeon/ethernet-rx.c:190:6: error:
'CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE' undeclared (first use in this function)
drivers/staging/octeon/ethernet-rx.c:472:25: error:
'OCTEON_IRQ_WORKQ0' undeclared (first use in this function)These come from various asm/ headers that a non-Octeon build will be
using a non-Octeon version of.Fix this by using the octeon-stubs.h header for non-Cavium MIPS builds,
and only using the real asm/octeon/ headers when building a Cavium
Octeon kernel configuration.This requires that octeon-stubs.h doesn't redefine XKPHYS_TO_PHYS, which
is defined for MIPS by asm/addrspace.h which is pulled in by many other
common asm/ headers.Signed-off-by: Paul Burton
Reported-by: Geert Uytterhoeven
URL: https://lore.kernel.org/linux-mips/CAMuHMdXvu+BppwzsU9imNWVKea_hoLcRt9N+a29Q-QsjW=ip2g@mail.gmail.com/
Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
Cc: Matthew Wilcox (Oracle)
Cc: David S. Miller
Link: https://lore.kernel.org/r/20191007231741.2012860-1-paul.burton@mips.com
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit c745da8d4320c49e54662c0a8f7cb6b8204f44c4 upstream.
Commit 7723f4c5ecdb ("driver core: platform: Add an error message to
platform_get_irq*()") added an error message to avoid drivers having
to print an error message when IRQ lookup fails. However, there are
some cases where IRQs are optional and so new optional versions of
the platform_get_irq*() APIs have been added for these cases.The IRQs for Tegra HSP module are optional because not all instances
of the module have the doorbell and all of the shared interrupts.
Hence, since the above commit was applied the following error messages
are now seen on Tegra194 ...ERR KERN tegra-hsp c150000.hsp: IRQ doorbell not found
ERR KERN tegra-hsp c150000.hsp: IRQ shared0 not foundThe Tegra HSP driver deliberately does not fail if these are not found
and so fix the above errors by updating the Tegra HSP driver to use
the platform_get_irq_byname_optional() API.Signed-off-by: Jon Hunter
Acked-by: Thierry Reding
Link: https://lore.kernel.org/r/20191011083459.11551-1-jonathanh@nvidia.com
Signed-off-by: Greg Kroah-Hartman -
commit 7b8474466ed97be458c825f34a85f2c2b84c3f95 upstream.
On compat interfaces, the high order bits of nanoseconds should be zeroed
out. This is because the application code or the libc do not guarantee
zeroing of these. If used without zeroing, kernel might be at risk of using
timespec values incorrectly.Originally it was handled correctly, but lost during is_compat_syscall()
cleanup. Revert the condition back to check CONFIG_64BIT.Fixes: 98f76206b335 ("compat: Cleanup in_compat_syscall() callers")
Reported-by: Ben Hutchings
Signed-off-by: Dmitry Safonov
Signed-off-by: Thomas Gleixner
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191121000303.126523-1-dima@arista.com
Signed-off-by: Greg Kroah-Hartman -
commit 45a2d64696b11913bcf1087b041740edbade3e21 upstream.
The layout of struct timeval is different on sparc64 from
anything else, and the patch I did long ago failed to take
this into account.Change it now to handle sparc64 user space correctly again.
Quite likely nobody cares about parallel ports on sparc64,
but there is no reason not to fix it.Cc: stable@vger.kernel.org
Fixes: 9a450484089d ("lp: support 64-bit time_t user space")
Signed-off-by: Arnd Bergmann
Link: https://lore.kernel.org/r/20191108203435.112759-7-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman -
commit 38e45d81d14e5f78cd67922596b1c37b4c22ec74 upstream.
On sparc64, the whole physical IO address space is accessible using
physically addressed loads and stores. *_uc does nothing like the
others.Cc: # v4.19+
Reported-by: kbuild test robot
Signed-off-by: Tuowen Zhao
Acked-by: David S. Miller
Signed-off-by: Lee Jones
Signed-off-by: Greg Kroah-Hartman -
commit af833988c088d3fed3e7188e7c3dd9ca17178dc3 upstream.
Prior to version 3.23 SQLite does not support TRUE or FALSE, so always
use 1 and 0 for SQLite.Fixes: 26c11206f433 ("perf scripts python: exported-sql-viewer.py: Use new 'has_calls' column")
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Cc: stable@vger.kernel.org # v5.3+
Link: http://lore.kernel.org/lkml/20191113120206.26957-1-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
[Adrian: backported to v5.3, v5.4]
Signed-off-by: Adrian Hunter
Signed-off-by: Greg Kroah-Hartman -
commit d440538e5f219900a9fc9d96fd10727b4d2b3c48 upstream.
Commit 4fdbfd60a3a2 ("arm64: tegra: Add PCIe slot supply information
in p2972-0000 platform") added regulators for the PCIe slot on the
Jetson Xavier platform. One of these regulators has an active-low enable
and this commit incorrectly added an active-low specifier for the GPIO
which causes the following warning to occur on boot ...WARNING KERN regulator@3 GPIO handle specifies active low - ignored
The fixed-regulator binding does not use the active-low flag from the
gpio specifier and purely relies of the presence of the
'enable-active-high' property to determine if it is active high or low
(if this property is omitted). Fix this warning by setting the GPIO
to active-high in the GPIO specifier. Finally, remove the
'enable-active-low' as this is not a valid property.Fixes: 4fdbfd60a3a2 ("arm64: tegra: Add PCIe slot supply information in p2972-0000 platform")
Signed-off-by: Jon Hunter
Signed-off-by: Thierry Reding
Signed-off-by: Greg Kroah-Hartman -
commit 1e5e929c009559bd7e898ac8e17a5d01037cb057 upstream.
Commit 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1")
added a regulator for HDMI on the Jetson TX1 platform. This regulator
has an active high enable, but the GPIO specifier for enabling the
regulator incorrectly defines it as active-low. This causes the
following warning to occur on boot ...WARNING KERN regulator@10 GPIO handle specifies active low - ignored
The fixed-regulator binding does not use the active-low flag from the
gpio specifier and purely relies of the presence of the
'enable-active-high' property to determine if it is active high or low
(if this property is omitted). Fix this warning by setting the GPIO
to active-high in the GPIO specifier which aligns with the presense of
the 'enable-active-high' property.Fixes: 34993594181d ("arm64: tegra: Enable HDMI on Jetson TX1")
Signed-off-by: Jon Hunter
Signed-off-by: Thierry Reding
Signed-off-by: Greg Kroah-Hartman -
commit d563131ef23cbc756026f839a82598c8445bc45f upstream.
In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should
be released.Signed-off-by: Navid Emamdoost
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman
05 Dec, 2019
13 commits
-
commit f3e4f3fc8ee9729c4b1b27a478c68b713df53c0c upstream.
The AML code implementing the WMI methods creates a variable length
field to hold the input data we pass like this:CreateDWordField (Arg1, 0x0C, DSZI)
Local5 = DSZI /* \HWMC.DSZI */
CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN)If we pass 0 as bios_args.datasize argument then (Local5 * 0x08)
is 0 which results in these errors:[ 71.973305] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20190816/dsopcode-133)
[ 71.973332] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529)
[ 71.973413] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529)And in our HPWMI_WIRELESS2_QUERY calls always failing. for read commands
like HPWMI_WIRELESS2_QUERY the DSZI value is not used / checked, except for
read commands where extra input is needed to specify exactly what to read.So for HPWMI_WIRELESS2_QUERY we can safely pass the size of the expected
output as insize to hp_wmi_perform_query(), as we are already doing for all
other HPWMI_READ commands we send. Doing so fixes these errors.Cc: stable@vger.kernel.org
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
Signed-off-by: Hans de Goede
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
commit 16245db1489cd9aa579506f64afeeeb13d825a93 upstream.
The HP WMI calls may take up to 128 bytes of data as input, and
the AML methods implementing the WMI calls, declare a couple of fields for
accessing input in different sizes, specifycally the HWMC method contains:CreateField (Arg1, 0x80, 0x0400, D128)
Even though we do not use any of the WMI command-types which need a buffer
of this size, the APCI interpreter still tries to create it as it is
declared in generoc code at the top of the HWMC method which runs before
the code looks at which command-type is requested.This results in many of these errors on many different HP laptop models:
[ 14.459261] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] size 160 (bits) (20170303/dsopcode-236)
[ 14.459268] ACPI Error: Method parse/execution failed [\HWMC] (Node ffff8edcc61507f8), AE_AML_BUFFER_LIMIT (20170303/psparse-543)
[ 14.459279] ACPI Error: Method parse/execution failed [\_SB.WMID.WMAA] (Node ffff8edcc61523c0), AE_AML_BUFFER_LIMIT (20170303/psparse-543)This commit increases the size of the data element of the bios_args struct
to 128 bytes fixing these errors.Cc: stable@vger.kernel.org
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703
Signed-off-by: Hans de Goede
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
commit 1cb0d2aee26335d0bccf29100c7bed00ebece851 upstream.
Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
to Main item") adds support for Usage Page item after Usage ID items
(such as keyboards manufactured by Primax).Usage Page concatenation in Main item works well for following report
descriptor patterns:USAGE_PAGE (Keyboard) 05 07
USAGE_MINIMUM (Keyboard LeftControl) 19 E0
USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8) 95 08
INPUT (Data,Var,Abs) 81 02-------------
USAGE_MINIMUM (Keyboard LeftControl) 19 E0
USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8) 95 08
USAGE_PAGE (Keyboard) 05 07
INPUT (Data,Var,Abs) 81 02But it makes the parser act wrong for the following report
descriptor pattern(such as some Gamepads):USAGE_PAGE (Button) 05 09
USAGE (Button 1) 09 01
USAGE (Button 2) 09 02
USAGE (Button 4) 09 04
USAGE (Button 5) 09 05
USAGE (Button 7) 09 07
USAGE (Button 8) 09 08
USAGE (Button 14) 09 0E
USAGE (Button 15) 09 0F
USAGE (Button 13) 09 0D
USAGE_PAGE (Consumer Devices) 05 0C
USAGE (Back) 0a 24 02
USAGE (HomePage) 0a 23 02
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (11) 95 0B
INPUT (Data,Var,Abs) 81 02With Usage Page concatenation in Main item, parser recognizes all the
11 Usages as consumer keys, it is not the HID device's real intention.This patch checks whether Usage Page is really defined after Usage ID
items by comparing usage page using status.Usage Page concatenation on currently defined Usage Page will always
do in local parsing when Usage ID items encountered.When Main item is parsing, concatenation will do again with last
defined Usage Page if this page has not been used in the previous
usages concatenation.Signed-off-by: Candle Sun
Signed-off-by: Nianfu Bai
Cc: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Cc: Siarhei Vishniakou
Signed-off-by: Greg Kroah-Hartman -
commit dbc2e87bd8b6d3cc79730b3a49c5163b4c386b49 upstream.
The talitos driver needs to select LIB_DES as it needs calls
des_expand_key.Fixes: 9d574ae8ebc1 ("crypto: talitos/des - switch to new...")
Cc:
Signed-off-by: Herbert Xu
Acked-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 6e78c01fde9023e0701f3af880c1fd9de6e4e8e3 upstream.
This reverts commit f2538f999345405f7d2e1194c0c8efa4e11f7b3a. The patch
stopped JFFS2 from being able to mount an existing filesystem with the
following errors:jffs2: error: (77) jffs2_build_inode_fragtree: Add node to tree failed -22
jffs2: error: (77) jffs2_do_read_inode_internal: Failed to build final fragtree for inode #5377: error -22Fixes: f2538f999345 ("jffs2: Fix possible null-pointer dereferences...")
Cc: stable@vger.kernel.org
Suggested-by: Hou Tao
Signed-off-by: Joel Stanley
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman -
commit 4ea99936a1630f51fc3a2d61a58ec4a1c4b7d55a upstream.
It's possible to specify a non-zero s_want_extra_isize via debugging
option, and this can cause bad things(tm) to happen when using a file
system with an inode size of 128 bytes.Add better checking when the file system is mounted, as well as when
we are actually doing the trying to do the inode expansion.Link: https://lore.kernel.org/r/20191110121510.GH23325@mit.edu
Reported-by: syzbot+f8d6f8386ceacdbfff57@syzkaller.appspotmail.com
Reported-by: syzbot+33d7ea72e47de3bdf4e1@syzkaller.appspotmail.com
Reported-by: syzbot+44b6763edfc17144296f@syzkaller.appspotmail.com
Signed-off-by: Theodore Ts'o
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 398fd408ccfb5e44b1cbe73a209d2281d3efa83c ]
It was reported [0] that network doesn't wake up on cable plug-in with
certain chip versions. Reason is that on these chip versions the PHY
doesn't detect cable plug-in when being in power-down mode. So prevent
the PHY from powering down if WoL is enabled.[0] https://bugzilla.kernel.org/show_bug.cgi?id=202103
Fixes: 95fb8bb3181b ("net: phy: force phy suspend when calling phy_stop")
Reported-by: jhdskag3
Tested-by: jhdskag3
Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 14012c9f3bb922b9e0751ba43d15cc580a6049bf ]
Alan reported [0] that network is broken since the referenced commit
when using jumbo frames. This commit isn't wrong, it just revealed
another issue that has been existing before. According to the vendor
driver the RTL8168e-specific jumbo config doesn't apply for RTL8168evl.[0] https://lkml.org/lkml/2019/11/30/119
Fixes: 4ebcb113edcc ("r8169: fix jumbo packet handling on resume from suspend")
Reported-by: Alan J. Wylie
Tested-by: Alan J. Wylie
Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 2745aea6750ff0d2c48285d25bdb00e5b636ec8b ]
Some versions of iproute2 will output more than one line per entry, which
will cause the test to fail, like:TEST: ipv6: list and flush cached exceptions [FAIL]
can't list cached exceptionsThat happens, for example, with iproute2 4.15.0. When using the -oneline
option, this will work just fine:TEST: ipv6: list and flush cached exceptions [ OK ]
This also works just fine with a more recent version of iproute2, like
5.4.0.For some reason, two lines are printed for the IPv4 test no matter what
version of iproute2 is used. Use the same -oneline parameter there instead
of counting the lines twice.Fixes: b964641e9925 ("selftests: pmtu: Make list_flush_ipv6_exception test more demanding")
Signed-off-by: Thadeu Lima de Souza Cascardo
Acked-by: Stefano Brivio
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit fd567ac20cb0377ff466d3337e6e9ac5d0cb15e4 ]
In commit 4f07b80c9733 ("tipc: check msg->req data len in
tipc_nl_compat_bearer_disable") the same patch code was copied into
routines: tipc_nl_compat_bearer_disable(),
tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats().
The two link routine occurrences should have been modified to check
the maximum link name length and not bearer name length.Fixes: 4f07b80c9733 ("tipc: check msg->reg data len in tipc_nl_compat_bearer_disable")
Signed-off-by: John Rutherford
Acked-by: Jon Maloy
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e5dc9dd3258098bf8b5ceb75fc3433b41eff618a ]
perror(str) is basically equivalent to
print("%s: %s\n", str, strerror(errno)).
New line or colon at the end of str is
a mistake/breaks formatting.Signed-off-by: Jakub Kicinski
Reviewed-by: Simon Horman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 4b67c515036313f3c3ecba3cb2babb9cbddb3f85 ]
test_sockmap creates a temporary file to use for sendpage.
this may fail for various reasons. Handle the error rather
than segfault.Signed-off-by: Jakub Kicinski
Reviewed-by: Simon Horman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
