commit 964f3712e6a7447d9d3203f2be3f6c50e78ea179
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Tue Jul 20 16:17:56 2021 +0200
Linux 4.14.240
Link: https://lore.kernel.org/r/20210719144942.861561397@linuxfoundation.org
Link: https://lore.kernel.org/r/20210719184316.271467313@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c07d1335d17ae0411101024de438dbc3734e992
Author: Eric Sandeen <sandeen@redhat.com>
Date: Tue Jul 13 17:49:23 2021 +0200
seq_file: disallow extremely large seq buffer allocations
commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream.
There is no reasonable need for a buffer larger than this, and it avoids
int overflow pitfalls.
Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation")
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Qualys Security Advisory <qsa@qualys.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2ab1c6d3294b08fd51e8bb4b942552167757cdf9
Author: Nikolay Aleksandrov <nikolay@nvidia.com>
Date: Sun Jul 11 12:56:28 2021 +0300
net: bridge: multicast: fix PIM hello router port marking race
commit 04bef83a3358946bfc98a5ecebd1b0003d83d882 upstream.
When a PIM hello packet is received on a bridge port with multicast
snooping enabled, we mark it as a router port automatically, that
includes adding that port the router port list. The multicast lock
protects that list, but it is not acquired in the PIM message case
leading to a race condition, we need to take it to fix the race.
Cc: stable@vger.kernel.org
Fixes: 91b02d3d133b ("bridge: mcast: add router port on PIM hello message")
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a69d0ba42ec05cb54f07a595d47741ede9ceb01d
Author: Martin Fäcknitz <faecknitz@hotsplots.de>
Date: Mon Jul 5 02:03:54 2021 +0200
MIPS: vdso: Invalid GIC access through VDSO
[ Upstream commit 47ce8527fbba145a7723685bc9a27d9855e06491 ]
Accessing raw timers (currently only CLOCK_MONOTONIC_RAW) through VDSO
doesn't return the correct time when using the GIC as clock source.
The address of the GIC mapped page is in this case not calculated
correctly. The GIC mapped page is calculated from the VDSO data by
subtracting PAGE_SIZE:
void *get_gic(const struct vdso_data *data) {
return (void __iomem *)data - PAGE_SIZE;
}
However, the data pointer is not page aligned for raw clock sources.
This is because the VDSO data for raw clock sources (CS_RAW = 1) is
stored after the VDSO data for coarse clock sources (CS_HRES_COARSE = 0).
Therefore, only the VDSO data for CS_HRES_COARSE is page aligned:
+--------------------+
| |
| vd[CS_RAW] | ---+
| vd[CS_HRES_COARSE] | |
+--------------------+ | -PAGE_SIZE
| | |
| GIC mapped page | <--+
| |
+--------------------+
When __arch_get_hw_counter() is called with &vd[CS_RAW], get_gic returns
the wrong address (somewhere inside the GIC mapped page). The GIC counter
values are not returned which results in an invalid time.
Fixes: a7f4df4e21dd ("MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()")
Signed-off-by: Martin Fäcknitz <faecknitz@hotsplots.de>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5d46ab0f5bfeaf5abb75433aae5a349bc8034bca
Author: Randy Dunlap <rdunlap@infradead.org>
Date: Sun Jul 4 16:02:11 2021 -0700
mips: disable branch profiling in boot/decompress.o
[ Upstream commit 97e488073cfca0eea84450169ca4cbfcc64e33e3 ]
Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o
to prevent linkage errors.
mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict':
decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update'
mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow
Fixes: e76e1fdfa8f8 ("lib: add support for LZ4-compressed kernel")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: linux-mips@vger.kernel.org
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3bb58902fa590bd350b224eb85e1422ad44637d5
Author: Arnd Bergmann <arnd@arndb.de>
Date: Fri Jul 2 16:28:37 2021 +0200
mips: always link byteswap helpers into decompressor
[ Upstream commit cddc40f5617e53f97ef019d5b29c1bd6cbb031ec ]
My series to clean up the unaligned access implementation
across architectures caused some mips randconfig builds to
fail with:
mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel':
decompress.c:(.text.decompress_kernel+0x54): undefined reference to `__bswapsi2'
It turns out that this problem has already been fixed for the XZ
decompressor but now it also shows up in (at least) LZO and LZ4. From my
analysis I concluded that the compiler could always have emitted those
calls, but the different implementation allowed it to make otherwise
better decisions about not inlining the byteswap, which results in the
link error when the out-of-line code is missing.
While it could be addressed by adding it to the two decompressor
implementations that are known to be affected, but as this only adds
112 bytes to the kernel, the safer choice is to always add them.
Fixes: c50ec6787536 ("MIPS: zboot: Fix the build with XZ compression on older GCC versions")
Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers")
Link: https://lore.kernel.org/linux-mm/202106301304.gz2wVY9w-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202106260659.TyMe8mjr-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202106172016.onWT6Tza-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202105231743.JJcALnhS-lkp@intel.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ec64cefd09e72e2e39ba8ae48c2969ec53914aa4
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sat Jun 12 09:18:34 2021 +0200
scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe()
[ Upstream commit 030e4138d11fced3b831c2761e4cecf347bae99c ]
If an error occurs after a pci_enable_pcie_error_reporting() call, it must
be undone by a corresponding pci_disable_pcie_error_reporting() call, as
already done in the remove function.
Link: https://lore.kernel.org/r/77adb02cfea7f1364e5603ecf3930d8597ae356e.1623482155.git.christophe.jaillet@wanadoo.fr
Fixes: 3567f36a09d1 ("[SCSI] be2iscsi: Fix AER handling in driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cd42cc9ae7210e953124197c19c3ead7a9ae1d82
Author: Aswath Govindraju <a-govindraju@ti.com>
Date: Tue Jun 8 10:39:51 2021 +0530
ARM: dts: am335x: align ti,pindir-d0-out-d1-in property with dt-shema
[ Upstream commit 414bfe1d26b60ef20b58e36efd5363188a694bab ]
ti,pindir-d0-out-d1-in property is expected to be of type boolean.
Therefore, fix the property accordingly.
Fixes: 444d66fafab8 ("ARM: dts: add spi wifi support to cm-t335")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7626ffbea708e5aba6912295c012d2b409a1769f
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date: Thu May 27 11:43:22 2021 -0400
memory: fsl_ifc: fix leak of private memory on probe failure
[ Upstream commit 8e0d09b1232d0538066c40ed4c13086faccbdff6 ]
On probe error the driver should free the memory allocated for private
structure. Fix this by using resource-managed allocation.
Fixes: a20cbdeffce2 ("powerpc/fsl: Add support for Integrated Flash Controller")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210527154322.81253-2-krzysztof.kozlowski@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6b3b002de90738e3c85853a682ce7e0fa078d42b
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date: Thu May 27 11:43:21 2021 -0400
memory: fsl_ifc: fix leak of IO mapping on probe failure
[ Upstream commit 3b132ab67fc7a358fff35e808fa65d4bea452521 ]
On probe error the driver should unmap the IO memory. Smatch reports:
drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.
Fixes: a20cbdeffce2 ("powerpc/fsl: Add support for Integrated Flash Controller")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210527154322.81253-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 00a6931183bae5b42fba1c018f2045e0b1f4027c
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date: Mon Jun 7 10:26:15 2021 +0200
reset: bail if try_module_get() fails
[ Upstream commit 4fb26fb83f0def3d39c14e268bcd4003aae8fade ]
Abort instead of returning a new reset control for a reset controller
device that is going to have its module unloaded.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 61fc41317666 ("reset: Add reset controller API")
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20210607082615.15160-1-p.zabel@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6f22b18922479f5d885be634e0556ddf7a9607f7
Author: Rafał Miłecki <rafal@milecki.pl>
Date: Wed May 12 15:07:09 2021 +0200
ARM: dts: BCM5301X: Fixup SPI binding
[ Upstream commit d5aede3e6dd1b8ca574600a1ecafe1e580c53f2f ]
1. Reorder interrupts
2. Fix typo: s/spi_lr_overhead/spi_lr_overread/
3. Rename node: s/spi-nor@0/flash@0/
This fixes:
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: spi@18029200: interrupt-names: 'oneOf' conditional failed, one must be fixed:
['spi_lr_fullness_reached', 'spi_lr_session_aborted', 'spi_lr_impatient', 'spi_lr_session_done', 'spi_lr_overhead', 'mspi_done', 'mspi_halted'] is too long
Additional items are not allowed ('spi_lr_session_aborted', 'spi_lr_impatient', 'spi_lr_session_done', 'spi_lr_overhead', 'mspi_done', 'mspi_halted' were unexpected)
'mspi_done' was expected
'spi_l1_intr' was expected
'mspi_halted' was expected
'spi_lr_fullness_reached' was expected
'spi_lr_session_aborted' was expected
'spi_lr_impatient' was expected
'spi_lr_session_done' was expected
'spi_lr_overread' was expected
From schema: Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: spi-nor@0: $nodename:0: 'spi-nor@0' does not match '^flash(@.*)?$'
From schema: Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 27ec98b6f7d8321ff26e6b85096ca7f4b26dbf67
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Thu Apr 29 14:41:15 2021 +0200
ARM: dts: r8a7779, marzen: Fix DU clock names
[ Upstream commit 6ab8c23096a29b69044209a5925758a6f88bd450 ]
"make dtbs_check" complains:
arch/arm/boot/dts/r8a7779-marzen.dt.yaml: display@fff80000: clock-names:0: 'du.0' was expected
Change the first clock name to match the DT bindings.
This has no effect on actual operation, as the Display Unit driver in
Linux does not use the first clock name on R-Car H1, but just grabs the
first clock.
Fixes: 665d79aa47cb3983 ("ARM: shmobile: marzen: Add DU external pixel clock to DT")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/9d5e1b371121883b3b3e10a3df43802a29c6a9da.1619699965.git.geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8f256b32b5c2d6350634f37e1f8a0692002734a4
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue May 11 10:19:26 2021 +0300
rtc: fix snprintf() checking in is_rtc_hctosys()
[ Upstream commit 54b909436ede47e0ee07f1765da27ec2efa41e84 ]
The scnprintf() function silently truncates the printf() and returns
the number bytes that it was able to copy (not counting the NUL
terminator). Thus, the highest value it can return here is
"NAME_SIZE - 1" and the overflow check is dead code. Fix this by
using the snprintf() function which returns the number of bytes that
would have been copied if there was enough space and changing the
condition from "> NAME_SIZE" to ">= NAME_SIZE".
Fixes: 92589c986b33 ("rtc-proc: permit the /proc/driver/rtc device to use other devices")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/YJov/pcGmhLi2pEl@mwanda
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8867ff3b16e8deacd50b001816b24a255044911
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date: Fri Apr 23 12:18:15 2021 +0200
memory: atmel-ebi: add missing of_node_put for loop iteration
[ Upstream commit 907c5bbb514a4676160e79764522fff56ce3448e ]
Early exits from for_each_available_child_of_node() should decrement the
node reference counter. Reported by Coccinelle:
drivers/memory/atmel-ebi.c:593:1-33: WARNING:
Function "for_each_available_child_of_node" should have of_node_put() before return around line 604.
Fixes: 6a4ec4cd0888 ("memory: add Atmel EBI (External Bus Interface) driver")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210423101815.119341-2-krzysztof.kozlowski@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ec069efdff201d3cf03f0326215372e5e21af9eb
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date: Wed May 5 09:59:41 2021 -0400
ARM: dts: exynos: fix PWM LED max brightness on Odroid XU4
[ Upstream commit fd2f1717966535b7d0b6fe45cf0d79e94330da5f ]
There is no "max_brightness" property as pointed out by dtschema:
arch/arm/boot/dts/exynos5422-odroidxu4.dt.yaml: led-controller: led-1: 'max-brightness' is a required property
Fixes: 6658356014cb ("ARM: dts: Add support Odroid XU4 board for exynos5422-odroidxu4")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210505135941.59898-5-krzysztof.kozlowski@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 276bb907e05a852021ef0d370a6d4dd356bd6e9f
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date: Wed May 5 09:59:39 2021 -0400
ARM: dts: exynos: fix PWM LED max brightness on Odroid XU/XU3
[ Upstream commit 75121e1dc9fe4def41e63d57f6a53749b88006ed ]
There is no "max_brightness" property. This brings the intentional
brightness reduce of green LED and dtschema checks as well:
arch/arm/boot/dts/exynos5410-odroidxu.dt.yaml: led-controller-1: led-1: 'max-brightness' is a required property
Fixes: 719f39fec586 ("ARM: dts: exynos5422-odroidxu3: Hook up PWM and use it for LEDs")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210505135941.59898-3-krzysztof.kozlowski@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 72a64a97733d9d58a7cb6a3ebaf7456166ddd817
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date: Fri May 7 07:28:03 2021 -0400
reset: a10sr: add missing of_match_table reference
[ Upstream commit 466ba3c8ff4fae39e455ff8d080b3d5503302765 ]
The driver defined of_device_id table but did not use it with
of_match_table. This prevents usual matching via devicetree and causes
a W=1 warning:
drivers/reset/reset-a10sr.c:111:34: warning:
‘a10sr_reset_of_match’ defined but not used [-Wunused-const-variable=]
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 627006820268 ("reset: Add Altera Arria10 SR Reset Controller")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210507112803.20012-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a33d6753516f188bc5be2c3002971cb263288892
Author: Nathan Chancellor <nathan@kernel.org>
Date: Wed Jul 7 18:07:41 2021 -0700
hexagon: use common DISCARDS macro
[ Upstream commit 681ba73c72302214686401e707e2087ed11a6556 ]
ld.lld warns that the '.modinfo' section is not currently handled:
ld.lld: warning: kernel/built-in.a(workqueue.o):(.modinfo) is being placed in '.modinfo'
ld.lld: warning: kernel/built-in.a(printk/printk.o):(.modinfo) is being placed in '.modinfo'
ld.lld: warning: kernel/built-in.a(irq/spurious.o):(.modinfo) is being placed in '.modinfo'
ld.lld: warning: kernel/built-in.a(rcu/update.o):(.modinfo) is being placed in '.modinfo'
The '.modinfo' section was added in commit 898490c010b5 ("moduleparam:
Save information about built-in modules in separate file") to the DISCARDS
macro but Hexagon has never used that macro. The unification of DISCARDS
happened in commit 023bf6f1b8bf ("linker script: unify usage of discard
definition") in 2009, prior to Hexagon being added in 2011.
Switch Hexagon over to the DISCARDS macro so that anything that is
expected to be discarded gets discarded.
Link: https://lkml.kernel.org/r/20210521011239.1332345-3-nathan@kernel.org
Fixes: e95bf452a9e2 ("Hexagon: Add configuration and makefiles for the Hexagon architecture.")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Brian Cain <bcain@codeaurora.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Oliver Glitta <glittao@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b9745dfe944707cd8aea0877b6dc84974d705c68
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date: Sat Jul 3 14:34:20 2021 -0400
NFSv4/pNFS: Don't call _nfs4_pnfs_v3_ds_connect multiple times
[ Upstream commit f46f84931a0aa344678efe412d4b071d84d8a805 ]
After we grab the lock in nfs4_pnfs_ds_connect(), there is no check for
whether or not ds->ds_clp has already been initialised, so we can end up
adding the same transports multiple times.
Fixes: fc821d59209d ("pnfs/NFSv4.1: Add multipath capabilities to pNFS flexfiles servers over NFSv3")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 32430c8d80aec70d1ddaa2249d4f4e3e4eb11ca4
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Wed Jul 7 15:40:51 2021 +0800
ALSA: isa: Fix error return code in snd_cmi8330_probe()
[ Upstream commit 31028cbed26a8afa25533a10425ffa2ab794c76c ]
When 'SB_HW_16' check fails, the error code -ENODEV instead of 0 should be
returned, which is the same as that returned when 'WSS_HW_CMI8330' check
fails.
Fixes: 43bcd973d6d0 ("[ALSA] Add snd_card_set_generic_dev() call to ISA drivers")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210707074051.2663-1-thunder.leizhen@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 05418360de0c8cf2854346d38fe37011133a686d
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Jun 23 14:01:35 2021 +0200
x86/fpu: Limit xstate copy size in xstateregs_set()
[ Upstream commit 07d6688b22e09be465652cf2da0da6bf86154df6 ]
If the count argument is larger than the xstate size, this will happily
copy beyond the end of xstate.
Fixes: 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames for XSAVES")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210623121452.120741557@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a01ae145ba0574538c75e4e56fe65b66b823daa7
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date: Fri Jun 18 16:11:03 2021 +0800
ubifs: Set/Clear I_LINKABLE under i_lock for whiteout inode
[ Upstream commit a801fcfeef96702fa3f9b22ad56c5eb1989d9221 ]
xfstests-generic/476 reports a warning message as below:
WARNING: CPU: 2 PID: 30347 at fs/inode.c:361 inc_nlink+0x52/0x70
Call Trace:
do_rename+0x502/0xd40 [ubifs]
ubifs_rename+0x8b/0x180 [ubifs]
vfs_rename+0x476/0x1080
do_renameat2+0x67c/0x7b0
__x64_sys_renameat2+0x6e/0x90
do_syscall_64+0x66/0xe0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Following race case can cause this:
rename_whiteout(Thread 1) wb_workfn(Thread 2)
ubifs_rename
do_rename
__writeback_single_inode
spin_lock(&inode->i_lock)
whiteout->i_state |= I_LINKABLE
inode->i_state &= ~dirty;
---- How race happens on i_state:
(tmp = whiteout->i_state | I_LINKABLE)
(tmp = inode->i_state & ~dirty)
(whiteout->i_state = tmp)
(inode->i_state = tmp)
----
spin_unlock(&inode->i_lock)
inc_nlink(whiteout)
WARN_ON(!(inode->i_state & I_LINKABLE)) !!!
Fix to add i_lock to avoid i_state update race condition.
Fixes: 9e0a1fff8db56ea ("ubifs: Implement RENAME_WHITEOUT")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8a2b308a54c5ec224fedc753617f99b29ffcd883
Author: Gao Xiang <hsiangkao@linux.alibaba.com>
Date: Fri Jun 18 12:20:55 2021 +0800
nfs: fix acl memory leak of posix_acl_create()
[ Upstream commit 1fcb6fcd74a222d9ead54d405842fc763bb86262 ]
When looking into another nfs xfstests report, I found acl and
default_acl in nfs3_proc_create() and nfs3_proc_mknod() error
paths are possibly leaked. Fix them in advance.
Fixes: 013cdf1088d7 ("nfs: use generic posix ACL infrastructure for v3 Posix ACLs")
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna.schumaker@netapp.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Joseph Qi <joseph.qi@linux.alibaba.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d4435845d9dcc7be78f0b87947a5eecb9577c159
Author: Tao Ren <rentao.bupt@gmail.com>
Date: Fri Apr 16 20:42:49 2021 -0700
watchdog: aspeed: fix hardware timeout calculation
[ Upstream commit e7dc481c92060f9ce872878b0b7a08c24713a7e5 ]
Fix hardware timeout calculation in aspeed_wdt_set_timeout function to
ensure the reload value does not exceed the hardware limit.
Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
Reported-by: Amithash Prasad <amithash@fb.com>
Signed-off-by: Tao Ren <rentao.bupt@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210417034249.5978-1-rentao.bupt@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8c3dbbeb674ec3512a072c3113a795572753ba9f
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Sat May 8 11:22:39 2021 +0800
um: fix error return code in winch_tramp()
[ Upstream commit ccf1236ecac476d9d2704866d9a476c86e387971 ]
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: 89df6bfc0405 ("uml: DEBUG_SHIRQ fixes")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Acked-By: anton.ivanov@cambridgegreys.com
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 09db07917614ffdef8d4a1ed9297e00b7e410d3f
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Sat May 8 11:13:54 2021 +0800
um: fix error return code in slip_open()
[ Upstream commit b77e81fbe5f5fb4ad9a61ec80f6d1e30b6da093a ]
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: a3c77c67a443 ("[PATCH] uml: slirp and slip driver cleanups and fixes")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Acked-By: anton.ivanov@cambridgegreys.com
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c729934597bf6d16951de71c111bbb78ba67a9b3
Author: Stephan Gerhold <stephan@gerhold.net>
Date: Mon May 17 12:51:12 2021 +0200
power: supply: rt5033_battery: Fix device tree enumeration
[ Upstream commit f3076cd8d1d5fa64b5e1fa5affc045c2fc123baa ]
The fuel gauge in the RT5033 PMIC has its own I2C bus and interrupt
line. Therefore, it is not actually part of the RT5033 MFD and needs
its own of_match_table to probe properly.
Also, given that it's independent of the MFD, there is actually
no need to make the Kconfig depend on MFD_RT5033. Although the driver
uses the shared <linux/mfd/rt5033.h> header, there is no compile
or runtime dependency on the RT5033 MFD driver.
Cc: Beomho Seo <beomho.seo@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Fixes: b847dd96e659 ("power: rt5033_battery: Add RT5033 Fuel gauge device driver")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit be6225e66f238a58c8563ac21c26c84a11b390a7
Author: Krzysztof Wilczyński <kw@linux.com>
Date: Thu Jun 3 00:01:12 2021 +0000
PCI/sysfs: Fix dsm_label_utf16s_to_utf8s() buffer overrun
[ Upstream commit bdcdaa13ad96f1a530711c29e6d4b8311eff767c ]
"utf16s_to_utf8s(..., buf, PAGE_SIZE)" puts up to PAGE_SIZE bytes into
"buf" and returns the number of bytes it actually put there. If it wrote
PAGE_SIZE bytes, the newline added by dsm_label_utf16s_to_utf8s() would
overrun "buf".
Reduce the size available for utf16s_to_utf8s() to use so there is always
space for the newline.
[bhelgaas: reorder patch in series, commit log]
Fixes: 6058989bad05 ("PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs")
Link: https://lore.kernel.org/r/20210603000112.703037-7-kw@linux.com
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d2dad6cb060bae2b977c53f3ca39e2185bb77a49
Author: Chao Yu <chao@kernel.org>
Date: Tue May 18 09:57:54 2021 +0800
f2fs: add MODULE_SOFTDEP to ensure crc32 is included in the initramfs
[ Upstream commit 0dd571785d61528d62cdd8aa49d76bc6085152fe ]
As marcosfrm reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=213089
Initramfs generators rely on "pre" softdeps (and "depends") to include
additional required modules.
F2FS does not declare "pre: crc32" softdep. Then every generator (dracut,
mkinitcpio...) has to maintain a hardcoded list for this purpose.
Hence let's use MODULE_SOFTDEP("pre: crc32") in f2fs code.
Fixes: 43b6573bac95 ("f2fs: use cryptoapi crc32 functions")
Reported-by: marcosfrm <marcosfrm@gmail.com>
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 56cf748562d3cbfd33d1ba2eb4a7603a5e20da88
Author: Xie Yongji <xieyongji@bytedance.com>
Date: Tue May 25 20:56:22 2021 +0800
virtio_console: Assure used length from device is limited
[ Upstream commit d00d8da5869a2608e97cfede094dfc5e11462a46 ]
The buf->len might come from an untrusted device. This
ensures the value would not exceed the size of the buffer
to avoid data corruption or loss.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Link: https://lore.kernel.org/r/20210525125622.1203-1-xieyongji@bytedance.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 733fd68b0cee23db96b1e153e0e757a4f6ed5281
Author: Xie Yongji <xieyongji@bytedance.com>
Date: Mon May 17 16:45:16 2021 +0800
virtio_net: Fix error handling in virtnet_restore()
[ Upstream commit 3f2869cace829fb4b80fc53b3ddaa7f4ba9acbf1 ]
Do some cleanups in virtnet_restore() when virtnet_cpu_notif_add() failed.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Link: https://lore.kernel.org/r/20210517084516.332-1-xieyongji@bytedance.com
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 863da837964c80c72e368a4f748c30d25daa1815
Author: Xie Yongji <xieyongji@bytedance.com>
Date: Mon May 17 16:43:32 2021 +0800
virtio-blk: Fix memory leak among suspend/resume procedure
[ Upstream commit b71ba22e7c6c6b279c66f53ee7818709774efa1f ]
The vblk->vqs should be freed before we call init_vqs()
in virtblk_restore().
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Link: https://lore.kernel.org/r/20210517084332.280-1-xieyongji@bytedance.com
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7cb9b41b5d445bf97ad13c0b78ea816e426c86aa
Author: Hans de Goede <hdegoede@redhat.com>
Date: Wed Jun 30 17:23:16 2021 +0200
ACPI: video: Add quirk for the Dell Vostro 3350
[ Upstream commit 9249c32ec9197e8d34fe5179c9e31668a205db04 ]
The Dell Vostro 3350 ACPI video-bus device reports spurious
ACPI_VIDEO_NOTIFY_CYCLE events resulting in spurious KEY_SWITCHVIDEOMODE
events being reported to userspace (and causing trouble there).
Add a quirk setting the report_key_events mask to
REPORT_BRIGHTNESS_KEY_EVENTS so that the ACPI_VIDEO_NOTIFY_CYCLE
events will be ignored, while still reporting brightness up/down
hotkey-presses to userspace normally.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1911763
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c41acf8a8a401dc5992d46ef3923877454faaa9f
Author: Liguang Zhang <zhangliguang@linux.alibaba.com>
Date: Tue Jun 29 19:27:48 2021 +0800
ACPI: AMBA: Fix resource name in /proc/iomem
[ Upstream commit 7718629432676b5ebd9a32940782fe297a0abf8d ]
In function amba_handler_attach(), dev->res.name is initialized by
amba_device_alloc. But when address_found is false, dev->res.name is
assigned to null value, which leads to wrong resource name display in
/proc/iomem, "<BAD>" is seen for those resources.
Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 30fabced7facc3fda006b12237c3c81b2fb2e45b
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu Jun 17 11:51:41 2021 +0200
pwm: tegra: Don't modify HW state in .remove callback
[ Upstream commit 86f7fa71cd830d18d7ebcaf719dffd5ddfe1acdd ]
A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.
So drop the hardware modification from the .remove() callback.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2c82d32c09a484c9c9e33341ce182a728d4fc75d
Author: Zou Wei <zou_wei@huawei.com>
Date: Sat Jun 5 09:21:41 2021 +0800
power: supply: ab8500: add missing MODULE_DEVICE_TABLE
[ Upstream commit dfe52db13ab8d24857a9840ec7ca75eef800c26c ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e9deec478409fd830b6fb4fcb1d536bcde4d6d42
Author: Zou Wei <zou_wei@huawei.com>
Date: Sat Jun 5 09:21:54 2021 +0800
power: supply: charger-manager: add missing MODULE_DEVICE_TABLE
[ Upstream commit 073b5d5b1f9cc94a3eea25279fbafee3f4f5f097 ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 34002b9fe988ee54b6556b7bdbde4e7232df9929
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date: Tue May 11 23:41:10 2021 -0400
NFS: nfs_find_open_context() may only select open files
[ Upstream commit e97bc66377bca097e1f3349ca18ca17f202ff659 ]
If a file has already been closed, then it should not be selected to
support further I/O.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
[Trond: Fix an invalid pointer deref reported by Colin Ian King]
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5962368a970b978906f25c291251e4d27e5952fd
Author: Jeff Layton <jlayton@kernel.org>
Date: Tue May 4 10:08:30 2021 -0400
ceph: remove bogus checks and WARN_ONs from ceph_set_page_dirty
[ Upstream commit 22d41cdcd3cfd467a4af074165357fcbea1c37f5 ]
The checks for page->mapping are odd, as set_page_dirty is an
address_space operation, and I don't see where it would be called on a
non-pagecache page.
The warning about the page lock also seems bogus. The comment over
set_page_dirty() says that it can be called without the page lock in
some rare cases. I don't think we want to warn if that's the case.
Reported-by: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit baa20861902db795be340d29fd2abd1268bf73fb
Author: Mike Marshall <hubcap@omnibond.com>
Date: Tue May 18 08:09:13 2021 -0400
orangefs: fix orangefs df output.
[ Upstream commit 0fdec1b3c9fbb5e856a40db5993c9eaf91c74a83 ]
Orangefs df output is whacky. Walt Ligon suggested this might fix it.
It seems way more in line with reality now...
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 538596a123515da063bb81628c4482a17b627461
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Jun 23 14:02:30 2021 +0200
x86/fpu: Return proper error codes from user access functions
[ Upstream commit aee8c67a4faa40a8df4e79316dbfc92d123989c1 ]
When *RSTOR from user memory raises an exception, there is no way to
differentiate them. That's bad because it forces the slow path even when
the failure was not a fault. If the operation raised eg. #GP then going
through the slow path is pointless.
Use _ASM_EXTABLE_FAULT() which stores the trap number and let the exception
fixup return the negated trap number as error.
This allows to separate the fast path and let it handle faults directly and
avoid the slow path for all other exceptions.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210623121457.601480369@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cb1bdbfad648aa32c43bec6ef6d03e1c9d434393
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date: Sun May 30 13:24:23 2021 +0200
watchdog: iTCO_wdt: Account for rebooting on second timeout
[ Upstream commit cb011044e34c293e139570ce5c01aed66a34345c ]
This was already attempted to fix via 1fccb73011ea: If the BIOS did not
enable TCO SMIs, the timer definitely needs to trigger twice in order to
cause a reboot. If TCO SMIs are on, as well as SMIs in general, we can
continue to assume that the BIOS will perform a reboot on the first
timeout.
QEMU with its ICH9 and related BIOS falls into the former category,
currently taking twice the configured timeout in order to reboot the
machine. For iTCO version that fall under turn_SMI_watchdog_clear_off,
this is also true and was currently only addressed for v1, irrespective
of the turn_SMI_watchdog_clear_off value.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/0b8bb307-d08b-41b5-696c-305cdac6789c@siemens.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8bec568d7518b1504a602ed5376bb322e4dbb270
Author: Zou Wei <zou_wei@huawei.com>
Date: Wed May 12 14:57:56 2021 +0800
watchdog: Fix possible use-after-free by calling del_timer_sync()
[ Upstream commit d0212f095ab56672f6f36aabc605bda205e1e0bf ]
This driver's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Link: https://lore.kernel.org/r/1620802676-19701-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2aef07017fae21c3d8acea9656b10e3b9c0f1e04
Author: Zou Wei <zou_wei@huawei.com>
Date: Tue May 11 15:04:51 2021 +0800
watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()
[ Upstream commit 90b7c141132244e8e49a34a4c1e445cce33e07f4 ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/1620716691-108460-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0ac50a76cf3cd63db000648b3b19f3f98b8aaa76
Author: Zou Wei <zou_wei@huawei.com>
Date: Tue May 11 15:01:35 2021 +0800
watchdog: Fix possible use-after-free in wdt_startup()
[ Upstream commit c08a6b31e4917034f0ed0cb457c3bb209576f542 ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/1620716495-108352-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a08f703ce75253a146e56a16af25b59d6704ce91
Author: Nick Desaulniers <ndesaulniers@google.com>
Date: Tue Jun 1 20:29:26 2021 +0100
ARM: 9087/1: kprobes: test-thumb: fix for LLVM_IAS=1
[ Upstream commit 8b95a7d90ce8160ac5cffd5bace6e2eba01a871e ]
There's a few instructions that GAS infers operands but Clang doesn't;
from what I can tell the Arm ARM doesn't say these are optional.
F5.1.257 TBB, TBH T1 Halfword variant
F5.1.238 STREXD T1 variant
F5.1.84 LDREXD T1 variant
Link: https://github.com/ClangBuiltLinux/linux/issues/1309
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Jian Cai <jiancai@google.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9f9ae22899135ca80627a7cd10eed3fbce9ff085
Author: Bixuan Cui <cuibixuan@huawei.com>
Date: Sat May 8 11:14:59 2021 +0800
power: reset: gpio-poweroff: add missing MODULE_DEVICE_TABLE
[ Upstream commit ed3443fb4df4e140a22f65144546c8a8e1e27f4e ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e11801ecf2732b615097aeda19a8a638bedf7fd0
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date: Wed May 26 13:20:35 2021 -0400
power: supply: max17042: Do not enforce (incorrect) interrupt trigger type
[ Upstream commit 7fbf6b731bca347700e460d94b130f9d734b33e9 ]
Interrupt line can be configured on different hardware in different way,
even inverted. Therefore driver should not enforce specific trigger
type - edge falling - but instead rely on Devicetree to configure it.
The Maxim 17047/77693 datasheets describe the interrupt line as active
low with a requirement of acknowledge from the CPU therefore the edge
falling is not correct.
The interrupt line is shared between PMIC and RTC driver, so using level
sensitive interrupt is here especially important to avoid races. With
an edge configuration in case if first PMIC signals interrupt followed
shortly after by the RTC, the interrupt might not be yet cleared/acked
thus the second one would not be noticed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 230208c91224e5ef214d27d722e2c4fc7aaba79b
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Sun May 23 00:50:41 2021 +0200
power: supply: ab8500: Avoid NULL pointers
[ Upstream commit 5bcb5087c9dd3dca1ff0ebd8002c5313c9332b56 ]
Sometimes the code will crash because we haven't enabled
AC or USB charging and thus not created the corresponding
psy device. Fix it by checking that it is there before
notifying.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit df87af9a83dd21266803f3f7c521bcee2331e8ed
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Wed Apr 28 11:05:24 2021 +0200
pwm: spear: Don't modify HW state in .remove callback
[ Upstream commit b601a18f12383001e7a8da238de7ca1559ebc450 ]
A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.
So drop the hardware modification from the .remove() callback.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d2e80fcae1c38536944709b7e949cdb955dcd8ac
Author: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Date: Wed Jun 30 18:56:16 2021 -0700
lib/decompress_unlz4.c: correctly handle zero-padding around initrds.
[ Upstream commit 2c484419efc09e7234c667aa72698cb79ba8d8ed ]
lz4 compatible decompressor is simple. The format is underspecified and
relies on EOF notification to determine when to stop. Initramfs buffer
format[1] explicitly states that it can have arbitrary number of zero
padding. Thus when operating without a fill function, be extra careful to
ensure that sizes less than 4, or apperantly empty chunksizes are treated
as EOF.
To test this I have created two cpio initrds, first a normal one,
main.cpio. And second one with just a single /test-file with content
"second" second.cpio. Then i compressed both of them with gzip, and with
lz4 -l. Then I created a padding of 4 bytes (dd if=/dev/zero of=pad4 bs=1
count=4). To create four testcase initrds:
1) main.cpio.gzip + extra.cpio.gzip = pad0.gzip
2) main.cpio.lz4 + extra.cpio.lz4 = pad0.lz4
3) main.cpio.gzip + pad4 + extra.cpio.gzip = pad4.gzip
4) main.cpio.lz4 + pad4 + extra.cpio.lz4 = pad4.lz4
The pad4 test-cases replicate the initrd load by grub, as it pads and
aligns every initrd it loads.
All of the above boot, however /test-file was not accessible in the initrd
for the testcase #4, as decoding in lz4 decompressor failed. Also an
error message printed which usually is harmless.
Whith a patched kernel, all of the above testcases now pass, and
/test-file is accessible.
This fixes lz4 initrd decompress warning on every boot with grub. And
more importantly this fixes inability to load multiple lz4 compressed
initrds with grub. This patch has been shipping in Ubuntu kernels since
January 2021.
[1] ./Documentation/driver-api/early-userspace/buffer-format.rst
BugLink: https://bugs.launchpad.net/bugs/1835660
Link: https://lore.kernel.org/lkml/20210114200256.196589-1-xnox@ubuntu.com/ # v0
Link: https://lkml.kernel.org/r/20210513104831.432975-1-dimitri.ledkov@canonical.com
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Bongkyu Kim <bongkyu.kim@lge.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
Cc: Rajat Asthana <thisisrast7@gmail.com>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Gao Xiang <hsiangkao@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit de5a7dab6b15203037c2fbb65e66bd5fb8ed2285
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Fri Jun 4 16:27:44 2021 -0700
i2c: core: Disable client irq on reboot/shutdown
[ Upstream commit b64210f2f7c11c757432ba3701d88241b2b98fb1 ]
If an i2c client receives an interrupt during reboot or shutdown it may
be too late to service it by making an i2c transaction on the bus
because the i2c controller has already been shutdown. This can lead to
system hangs if the i2c controller tries to make a transfer that is
doomed to fail because the access to the i2c pins is already shut down,
or an iommu translation has been torn down so i2c controller register
access doesn't work.
Let's simply disable the irq if there isn't a shutdown callback for an
i2c client when there is an irq associated with the device. This will
make sure that irqs don't come in later than the time that we can handle
it. We don't do this if the i2c client device already has a shutdown
callback because presumably they're doing the right thing and quieting
the device so irqs don't come in after the shutdown callback returns.
Reported-by: kernel test robot <lkp@intel.com>
[swboyd@chromium.org: Dropped newline, added commit text, added
interrupt.h for robot build error]
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 524449a8bdcf2ae40aae02fb7a72db1d7daae5f8
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date: Mon Jun 21 18:12:46 2021 +0300
intel_th: Wait until port is in reset before programming it
[ Upstream commit ab1afed701d2db7eb35c1a2526a29067a38e93d1 ]
Some devices don't drain their pipelines if we don't make sure that
the corresponding output port is in reset before programming it for
a new trace capture, resulting in bits of old trace appearing in the
new trace capture. Fix that by explicitly making sure the reset is
asserted before programming new trace capture.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/r/20210621151246.31891-5-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit da261750ec569b94389d1b77b632f4f5004aeca0
Author: Fabio Aiuto <fabioaiuto83@gmail.com>
Date: Tue Jun 22 15:09:58 2021 +0200
staging: rtl8723bs: fix macro value for 2.4Ghz only device
[ Upstream commit 6d490a27e23c5fb79b766530016ab8665169498e ]
fix IQK_Matrix_Settings_NUM macro value to 14 which is
the max channel number value allowed in a 2.4Ghz device.
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/0b4a876929949248aa18cb919da3583c65e4ee4e.1624367072.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7700cc40bb279f32fcaba159020c22fcf3bb1d44
Author: Jiajun Cao <jjcao20@fudan.edu.cn>
Date: Tue Jun 22 21:19:42 2021 +0800
ALSA: hda: Add IRQ check for platform_get_irq()
[ Upstream commit 8c13212443230d03ff25014514ec0d53498c0912 ]
The function hda_tegra_first_init() neglects to check the return
value after executing platform_get_irq().
hda_tegra_first_init() should check the return value (if negative
error number) for errors so as to not pass a negative value to
the devm_request_irq().
Fix it by adding a check for the return value irq_id.
Signed-off-by: Jiajun Cao <jjcao20@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20210622131947.94346-1-jjcao20@fudan.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7b8f6005f7cfbdb562e2a1d62762ba5200f9f1ed
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Mon Jun 21 14:21:47 2021 +0200
backlight: lm3630a: Fix return code of .update_status() callback
[ Upstream commit b9481a667a90ec739995e85f91f3672ca44d6ffa ]
According to <linux/backlight.h> .update_status() is supposed to
return 0 on success and a negative error code otherwise. Adapt
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status() to
actually do it.
While touching that also add the error code to the failure message.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3a8e2e83d205ac30d8844e4ea5ae6c3f15c13f20
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri Jun 18 13:49:00 2021 +1000
powerpc/boot: Fixup device-tree on little endian
[ Upstream commit c93f80849bdd9b45d834053ae1336e28f0026c84 ]
This fixes the core devtree.c functions and the ns16550 UART backend.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/YMwXrPT8nc4YUdJ9@thinks.paulus.ozlabs.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e8f59f48f113ed8ea64b3f241bd017c70e7fc3fd
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Fri Jun 18 12:38:35 2021 +0800
usb: gadget: hid: fix error return code in hid_bind()
[ Upstream commit 88693f770bb09c196b1eb5f06a484a254ecb9924 ]
Fix to return a negative error code from the error handling
case instead of 0.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210618043835.2641360-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2338690b60d54dc8832a690091dd5c51efc132bb
Author: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Date: Thu Jun 17 19:27:55 2021 +0300
usb: gadget: f_hid: fix endianness issue with descriptors
[ Upstream commit 33cb46c4676d01956811b68a29157ea969a5df70 ]
Running sparse checker it shows warning message about
incorrect endianness used for descriptor initialization:
| f_hid.c:91:43: warning: incorrect type in initializer (different base types)
| f_hid.c:91:43: expected restricted __le16 [usertype] bcdHID
| f_hid.c:91:43: got int
Fixing issue with cpu_to_le16() macro, however this is not a real issue
as the value is the same both endians.
Cc: Fabien Chouteau <fabien.chouteau@barco.com>
Cc: Segiy Stetsyuk <serg_stetsuk@ukr.net>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/20210617162755.29676-1-ruslan.bilovol@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f8c413fec835f27323d025a93097890d6f766bca
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date: Sat Jun 19 17:39:22 2021 +0900
ALSA: bebob: add support for ToneWeal FW66
[ Upstream commit 50ebe56222bfa0911a932930f9229ee5995508d9 ]
A user of FFADO project reported the issue of ToneWeal FW66. As a result,
the device is identified as one of applications of BeBoB solution.
I note that in the report the device returns contradictory result in plug
discovery process for audio subunit. Fortunately ALSA BeBoB driver doesn't
perform it thus it's likely to handle the device without issues.
I receive no reaction to test request for this patch yet, however it would
be worth to add support for it.
daniel@gibbonmoon:/sys/bus/firewire/devices/fw1$ grep -r . *
Binary file config_rom matches
dev:244:1
guid:0x0023270002000000
hardware_version:0x000002
is_local:0
model:0x020002
model_name:FW66
power/runtime_active_time:0
power/runtime_active_kids:0
power/runtime_usage:0
power/runtime_status:unsupported
power/async:disabled
power/runtime_suspended_time:0
power/runtime_enabled:disabled
power/control:auto
subsystem/drivers_autoprobe:1
uevent:MAJOR=244
uevent:MINOR=1
uevent:DEVNAME=fw1
units:0x00a02d:0x010001
vendor:0x002327
vendor_name:ToneWeal
fw1.0/uevent:MODALIAS=ieee1394:ven00002327mo00020002sp0000A02Dver00010001
fw1.0/power/runtime_active_time:0
fw1.0/power/runtime_active_kids:0
fw1.0/power/runtime_usage:0
fw1.0/power/runtime_status:unsupported
fw1.0/power/async:disabled
fw1.0/power/runtime_suspended_time:0
fw1.0/power/runtime_enabled:disabled
fw1.0/power/control:auto
fw1.0/model:0x020002
fw1.0/rom_index:15
fw1.0/specifier_id:0x00a02d
fw1.0/model_name:FW66
fw1.0/version:0x010001
fw1.0/modalias:ieee1394:ven00002327mo00020002sp0000A02Dver00010001
Cc: Daniel Jozsef <daniel.jozsef@gmail.com>
Reference: https://lore.kernel.org/alsa-devel/20200119164335.GA11974@workstation/
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210619083922.16060-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5566bd69a5c57796c39517b01d35ebd8f5e32af4
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Thu Jun 17 18:37:29 2021 +0800
ASoC: soc-core: Fix the error return code in snd_soc_of_parse_audio_routing()
[ Upstream commit 7d3865a10b9ff2669c531d5ddd60bf46b3d48f1e ]
When devm_kcalloc() fails, the error code -ENOMEM should be returned
instead of -EINVAL.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210617103729.1918-1-thunder.leizhen@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4d874bb93e0622f377f24c3e5c3d5b47cdd63d23
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date: Tue May 25 09:51:42 2021 -0400
selftests/powerpc: Fix "no_handler" EBB selftest
[ Upstream commit 45677c9aebe926192e59475b35a1ff35ff2d4217 ]
The "no_handler_test" in ebb selftests attempts to read the PMU
registers twice via helper function "dump_ebb_state". First dump is
just before closing of event and the second invocation is done after
closing of the event. The original intention of second
dump_ebb_state was to dump the state of registers at the end of
the test when the counters are frozen. But this will be achieved
with the first call itself since sample period is set to low value
and PMU will be frozen by then. Hence patch removes the
dump which was done before closing of the event.
Reported-by: Shirisha Ganta <shirisha.ganta1@ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com <mailto:rnsastry@linux.ibm.com>>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1621950703-1532-2-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 03885d1cce8462525fa01877f0b9614a68f757f0
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Wed Jun 16 10:11:21 2021 +0800
ALSA: ppc: fix error return code in snd_pmac_probe()
[ Upstream commit 80b9c1be567c3c6bbe0d4b290af578e630485b5d ]
If snd_pmac_tumbler_init() or snd_pmac_tumbler_post_init() fails,
snd_pmac_probe() need return error code.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210616021121.1991502-1-yangyingliang@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a7587d3b26cac10c9a13358ed4d2fcaa4d534aeb
Author: Srinivas Neeli <srinivas.neeli@xilinx.com>
Date: Fri Apr 9 19:38:05 2021 +0530
gpio: zynq: Check return value of pm_runtime_get_sync
[ Upstream commit a51b2fb94b04ab71e53a71b9fad03fa826941254 ]
Return value of "pm_runtime_get_sync" API was neither captured nor checked.
Fixed it by capturing the return value and then checking for any warning.
Addresses-Coverity: "check_return"
Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit dd47d2fe06390cc0f6252aa5c4a58bd93a11d596
Author: Geoff Levand <geoff@infradead.org>
Date: Thu Jun 3 19:17:02 2021 +0000
powerpc/ps3: Add dma_mask to ps3_dma_region
[ Upstream commit 9733862e50fdba55e7f1554e4286fcc5302ff28e ]
Commit f959dcd6ddfd29235030e8026471ac1b022ad2b0 (dma-direct: Fix
potential NULL pointer dereference) added a null check on the
dma_mask pointer of the kernel's device structure.
Add a dma_mask variable to the ps3_dma_region structure and set
the device structure's dma_mask pointer to point to this new variable.
Fixes runtime errors like these:
# WARNING: Fixes tag on line 10 doesn't match correct format
# WARNING: Fixes tag on line 10 doesn't match correct format
ps3_system_bus_match:349: dev=8.0(sb_01), drv=8.0(ps3flash): match
WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:151 .dma_map_page_attrs+0x34/0x1e0
ps3flash sb_01: ps3stor_setup:193: map DMA region failed
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/562d0c9ea0100a30c3b186bcc7adb34b0bbd2cd7.1622746428.git.geoff@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit fd3ec5aec809669dff981a3b1cc875b87ae0a047
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Jun 8 16:04:37 2021 +0200
ALSA: sb: Fix potential double-free of CSP mixer elements
[ Upstream commit c305366a37441c2ac90b08711cb6f032b43672f2 ]
snd_sb_qsound_destroy() contains the calls of removing the previously
created mixer controls, but it doesn't clear the pointers. As
snd_sb_qsound_destroy() itself may be repeatedly called via ioctl,
this could lead to double-free potentially.
Fix it by clearing the struct fields properly afterwards.
Link: https://lore.kernel.org/r/20210608140540.17885-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b359cb3d33ae0080937d1b6f5e5cd1e8ab27dc06
Author: Valentin Vidic <vvidic@valentin-vidic.from.hr>
Date: Tue Apr 27 21:40:10 2021 +0200
s390/sclp_vt220: fix console name to match device
[ Upstream commit b7d91d230a119fdcc334d10c9889ce9c5e15118b ]
Console name reported in /proc/consoles:
ttyS1 -W- (EC p ) 4:65
does not match the char device name:
crw--w---- 1 root root 4, 65 May 17 12:18 /dev/ttysclp0
so debian-installer inside a QEMU s390x instance gets confused and fails
to start with the following error:
steal-ctty: No such file or directory
Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr>
Link: https://lore.kernel.org/r/20210427194010.9330-1-vvidic@valentin-vidic.from.hr
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b5d7c7be789b5926d33735c255dd94ff310df6f7
Author: Zou Wei <zou_wei@huawei.com>
Date: Wed May 12 14:33:46 2021 +0800
mfd: da9052/stmpe: Add and modify MODULE_DEVICE_TABLE
[ Upstream commit 4700ef326556ed74aba188f12396740a8c1c21dd ]
This patch adds/modifies MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f83bd690f60bebd648bd9bfcea0891fbadacec86
Author: Mike Christie <michael.christie@oracle.com>
Date: Tue May 25 13:18:12 2021 -0500
scsi: qedi: Fix null ref during abort handling
[ Upstream commit 5777b7f0f03ce49372203b6521631f62f2810c8f ]
If qedi_process_cmd_cleanup_resp finds the cmd it frees the work and sets
list_tmf_work to NULL, so qedi_tmf_work should check if list_tmf_work is
non-NULL when it wants to force cleanup.
Link: https://lore.kernel.org/r/20210525181821.7617-20-michael.christie@oracle.com
Reviewed-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 57b8430c75a9382fd2e66e181ca5e11ad1ea31aa
Author: Mike Christie <michael.christie@oracle.com>
Date: Tue May 25 13:18:07 2021 -0500
scsi: iscsi: Fix shost->max_id use
[ Upstream commit bdd4aad7ff92ae39c2e93c415bb6761cb8b584da ]
The iscsi offload drivers are setting the shost->max_id to the max number
of sessions they support. The problem is that max_id is not the max number
of targets but the highest identifier the targets can have. To use it to
limit the number of targets we need to set it to max sessions - 1, or we
can end up with a session we might not have preallocated resources for.
Link: https://lore.kernel.org/r/20210525181821.7617-15-michael.christie@oracle.com
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7b5ddec4b8c270f5c0493055ef0d0b6b6194b303
Author: Mike Christie <michael.christie@oracle.com>
Date: Tue May 25 13:18:03 2021 -0500
scsi: iscsi: Add iscsi_cls_conn refcount helpers
[ Upstream commit b1d19e8c92cfb0ded180ef3376c20e130414e067 ]
There are a couple places where we could free the iscsi_cls_conn while it's
still in use. This adds some helpers to get/put a refcount on the struct
and converts an exiting user. Subsequent commits will then use the helpers
to fix 2 bugs in the eh code.
Link: https://lore.kernel.org/r/20210525181821.7617-11-michael.christie@oracle.com
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2376e2ad335657c6e13e41fc0e2392b9e409745d
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date: Tue Jun 1 19:07:10 2021 +0800
fs/jfs: Fix missing error code in lmLogInit()
[ Upstream commit 492109333c29e1bb16d8732e1d597b02e8e0bf2e ]
The error code is missing in this code scenario, add the error code
'-EINVAL' to the return value 'rc.
Eliminate the follow smatch warning:
fs/jfs/jfs_logmgr.c:1327 lmLogInit() warn: missing error code 'rc'.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 34f4590f5ec9859ea9136249f528173d150bd584
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Tue May 25 21:44:04 2021 +0200
tty: serial: 8250: serial_cs: Fix a memory leak in error handling path
[ Upstream commit fad92b11047a748c996ebd6cfb164a63814eeb2e ]
In the probe function, if the final 'serial_config()' fails, 'info' is
leaking.
Add a resource handling path to free this memory.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/dc25f96b7faebf42e60fe8d02963c941cf4d8124.1621971720.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d3e071efa32f953c543f612252bc1cb0a1b5c715
Author: John Garry <john.garry@huawei.com>
Date: Wed May 19 22:31:02 2021 +0800
scsi: core: Cap scsi_host cmd_per_lun at can_queue
[ Upstream commit ea2f0f77538c50739b9fb4de4700cee5535e1f77 ]
The sysfs handling function sdev_store_queue_depth() enforces that the sdev
queue depth cannot exceed shost can_queue. The initial sdev queue depth
comes from shost cmd_per_lun. However, the LLDD may manually set
cmd_per_lun to be larger than can_queue, which leads to an initial sdev
queue depth greater than can_queue.
Such an issue was reported in [0], which caused a hang. That has since been
fixed in commit fc09acb7de31 ("scsi: scsi_debug: Fix cmd_per_lun, set to
max_queue").
Stop this possibly happening for other drivers by capping shost cmd_per_lun
at shost can_queue.
[0] https://lore.kernel.org/linux-scsi/YHaez6iN2HHYxYOh@T590/
Link: https://lore.kernel.org/r/1621434662-173079-1-git-send-email-john.garry@huawei.com
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit fa169003381eece466df4ced7e18c1adf1dfa40c
Author: James Smart <jsmart2021@gmail.com>
Date: Fri May 14 12:55:56 2021 -0700
scsi: lpfc: Fix crash when lpfc_sli4_hba_setup() fails to initialize the SGLs
[ Upstream commit 5aa615d195f1e142c662cb2253f057c9baec7531 ]
The driver is encountering a crash in lpfc_free_iocb_list() while
performing initial attachment.
Code review found this to be an errant failure path that was taken, jumping
to a tag that then referenced structures that were uninitialized.
Fix the failure path.
Link: https://lore.kernel.org/r/20210514195559.119853-9-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 21be6864028f28672b560f0d784dadc9c0b00301
Author: James Smart <jsmart2021@gmail.com>
Date: Fri May 14 12:55:51 2021 -0700
scsi: lpfc: Fix "Unexpected timeout" error in direct attach topology
[ Upstream commit e30d55137edef47434c40d7570276a0846fe922c ]
An 'unexpected timeout' message may be seen in a point-2-point topology.
The message occurs when a PLOGI is received before the driver is notified
of FLOGI completion. The FLOGI completion failure causes discovery to be
triggered for a second time. The discovery timer is restarted but no new
discovery activity is initiated, thus the timeout message eventually
appears.
In point-2-point, when discovery has progressed before the FLOGI completion
is processed, it is not a failure. Add code to FLOGI completion to detect
that discovery has progressed and exit the FLOGI handling (noop'ing it).
Link: https://lore.kernel.org/r/20210514195559.119853-4-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ba286c498e87c74f229900fba566ebdaad0367d3
Author: Luiz Sampaio <sampaio.ime@gmail.com>
Date: Wed May 19 19:30:44 2021 -0300
w1: ds2438: fixing bug that would always get page0
[ Upstream commit 1f5e7518f063728aee0679c5086b92d8ea429e11 ]
The purpose of the w1_ds2438_get_page function is to get the register
values at the page passed as the pageno parameter. However, the page0 was
hardcoded, such that the function always returned the page0 contents. Fixed
so that the function can retrieve any page.
Signed-off-by: Luiz Sampaio <sampaio.ime@gmail.com>
Link: https://lore.kernel.org/r/20210519223046.13798-5-sampaio.ime@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f819e9ec91e3ad49b6ce6882f9837cbdc07f0a48
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date: Tue May 18 17:45:47 2021 +0900
Revert "ALSA: bebob/oxfw: fix Kconfig entry for Mackie d.2 Pro"
[ Upstream commit 5d6fb80a142b5994355ce675c517baba6089d199 ]
This reverts commit 0edabdfe89581669609eaac5f6a8d0ae6fe95e7f.
I've explained that optional FireWire card for d.2 is also built-in to
d.2 Pro, however it's wrong. The optional card uses DM1000 ASIC and has
'Mackie DJ Mixer' in its model name of configuration ROM. On the other
hand, built-in FireWire card for d.2 Pro and d.4 Pro uses OXFW971 ASIC
and has 'd.Pro' in its model name according to manuals and user
experiences. The former card is not the card for d.2 Pro. They are similar
in appearance but different internally.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5b06ca113bf197aab2ab61288f42506e0049fbab
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date: Mon Apr 26 10:06:20 2021 -0700
misc/libmasm/module: Fix two use after free in ibmasm_init_one
[ Upstream commit 7272b591c4cb9327c43443f67b8fbae7657dd9ae ]
In ibmasm_init_one, it calls ibmasm_init_remote_input_dev().
Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are
allocated by input_allocate_device(), and assigned to
sp->remote.mouse_dev and sp->remote.keybd_dev respectively.
In the err_free_devices error branch of ibmasm_init_one,
mouse_dev and keybd_dev are freed by input_free_device(), and return
error. Then the execution runs into error_send_message error branch
of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called
to unregister the freed sp->remote.mouse_dev and sp->remote.keybd_dev.
My patch add a "error_init_remote" label to handle the error of
ibmasm_init_remote_input_dev(), to avoid the uaf bugs.
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Link: https://lore.kernel.org/r/20210426170620.10546-1-lyl2019@mail.ustc.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ab822cefeb868f8a0b8dd9a4f5017a6f8e68b7c9
Author: Sherry Sun <sherry.sun@nxp.com>
Date: Tue Apr 27 10:12:26 2021 +0800
tty: serial: fsl_lpuart: fix the potential risk of division or modulo by zero
[ Upstream commit fcb10ee27fb91b25b68d7745db9817ecea9f1038 ]
We should be very careful about the register values that will be used
for division or modulo operations, althrough the possibility that the
UARTBAUD register value is zero is very low, but we had better to deal
with the "bad data" of hardware in advance to avoid division or modulo
by zero leading to undefined kernel behavior.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Link: https://lore.kernel.org/r/20210427021226.27468-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 400e6b1860c8be61388d0b77814c53260f96e17a
Author: Pali Rohár <pali@kernel.org>
Date: Tue Jun 8 22:36:55 2021 +0200
PCI: aardvark: Fix kernel panic during PIO transfer
commit f18139966d072dab8e4398c95ce955a9742e04f7 upstream.
Trying to start a new PIO transfer by writing value 0 in PIO_START register
when previous transfer has not yet completed (which is indicated by value 1
in PIO_START) causes an External Abort on CPU, which results in kernel
panic:
SError Interrupt on CPU0, code 0xbf000002 -- SError
Kernel panic - not syncing: Asynchronous SError Interrupt
To prevent kernel panic, it is required to reject a new PIO transfer when
previous one has not finished yet.
If previous PIO transfer is not finished yet, the kernel may issue a new
PIO request only if the previous PIO transfer timed out.
In the past the root cause of this issue was incorrectly identified (as it
often happens during link retraining or after link down event) and special
hack was implemented in Trusted Firmware to catch all SError events in EL3,
to ignore errors with code 0xbf000002 and not forwarding any other errors
to kernel and instead throw panic from EL3 Trusted Firmware handler.
Links to discussion and patches about this issue:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541
But the real cause was the fact that during link retraining or after link
down event the PIO transfer may take longer time, up to the 1.44s until it
times out. This increased probability that a new PIO transfer would be
issued by kernel while previous one has not finished yet.
After applying this change into the kernel, it is possible to revert the
mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.
Link: https://lore.kernel.org/r/20210608203655.31228-1-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Marek Behún <kabel@kernel.org>
Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1460cb56923d3b20405c92e3b995b086dc8f404b
Author: Remi Pommarel <repk@triplefau.lt>
Date: Fri Sep 27 10:55:02 2019 +0200
PCI: aardvark: Don't rely on jiffies while holding spinlock
commit 7fbcb5da811be7d47468417c7795405058abb3da upstream.
advk_pcie_wait_pio() can be called while holding a spinlock (from
pci_bus_read_config_dword()), then depends on jiffies in order to
timeout while polling on PIO state registers. In the case the PIO
transaction failed, the timeout will never happen and will also cause
the cpu to stall.
This decrements a variable and wait instead of using jiffies.
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7e35f39f21bdc9347638997d6406c8ab115e4afb
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date: Thu Jul 15 00:02:06 2021 -0400
tracing: Do not reference char * as a string in histograms
commit 704adfb5a9978462cd861f170201ae2b5e3d3a80 upstream.
The histogram logic was allowing events with char * pointers to be used as
normal strings. But it was easy to crash the kernel with:
# echo 'hist:keys=filename' > events/syscalls/sys_enter_openat/trigger
And open some files, and boom!
BUG: unable to handle page fault for address: 00007f2ced0c3280
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 1173fa067 P4D 1173fa067 PUD 1171b6067 PMD 1171dd067 PTE 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 6 PID: 1810 Comm: cat Not tainted 5.13.0-rc5-test+ #61
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
v03.03 07/14/2016
RIP: 0010:strlen+0x0/0x20
Code: f6 82 80 2a 0b a9 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2a 0b
a9 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74
10 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3
RSP: 0018:ffffbdbf81567b50 EFLAGS: 00010246
RAX: 0000000000000003 RBX: ffff93815cdb3800 RCX: ffff9382401a22d0
RDX: 0000000000000100 RSI: 0000000000000000 RDI: 00007f2ced0c3280
RBP: 0000000000000100 R08: ffff9382409ff074 R09: ffffbdbf81567c98
R10: ffff9382409ff074 R11: 0000000000000000 R12: ffff9382409ff074
R13: 0000000000000001 R14: ffff93815a744f00 R15: 00007f2ced0c3280
FS: 00007f2ced0f8580(0000) GS:ffff93825a800000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2ced0c3280 CR3: 0000000107069005 CR4: 00000000001706e0
Call Trace:
event_hist_trigger+0x463/0x5f0
? find_held_lock+0x32/0x90
? sched_clock_cpu+0xe/0xd0
? lock_release+0x155/0x440
? kernel_init_free_pages+0x6d/0x90
? preempt_count_sub+0x9b/0xd0
? kernel_init_free_pages+0x6d/0x90
? get_page_from_freelist+0x12c4/0x1680
? __rb_reserve_next+0xe5/0x460
? ring_buffer_lock_reserve+0x12a/0x3f0
event_triggers_call+0x52/0xe0
ftrace_syscall_enter+0x264/0x2c0
syscall_trace_enter.constprop.0+0x1ee/0x210
do_syscall_64+0x1c/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Where it triggered a fault on strlen(key) where key was the filename.
The reason is that filename is a char * to user space, and the histogram
code just blindly dereferenced it, with obvious bad results.
I originally tried to use strncpy_from_user/kernel_nofault() but found
that there's other places that its dereferenced and not worth the effort.
Just do not allow "char *" to act like strings.
Link: https://lkml.kernel.org/r/20210715000206.025df9d2@rorschach.local.home
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Cc: stable@vger.kernel.org
Acked-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Tom Zanussi <zanussi@kernel.org>
Fixes: 79e577cbce4c4 ("tracing: Support string type key properly")
Fixes: 5967bd5c4239 ("tracing: Let filter_assign_type() detect FILTER_PTR_STRING")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f3d0a109240c9bed5c60d819014786be3a2fe515
Author: Tyrel Datwyler <tyreld@linux.ibm.com>
Date: Thu Jul 1 13:56:59 2021 -0600
scsi: core: Fix bad pointer dereference when ehandler kthread is invalid
commit 93aa71ad7379900e61c8adff6a710a4c18c7c99b upstream.
Commit 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")
changed the allocation logic to call put_device() to perform host cleanup
with the assumption that IDA removal and stopping the kthread would
properly be performed in scsi_host_dev_release(). However, in the unlikely
case that the error handler thread fails to spawn, shost->ehandler is set
to ERR_PTR(-ENOMEM).
The error handler cleanup code in scsi_host_dev_release() will call
kthread_stop() if shost->ehandler != NULL which will always be the case
whether the kthread was successfully spawned or not. In the case that it
failed to spawn this has the nasty side effect of trying to dereference an
invalid pointer when kthread_stop() is called. The following splat provides
an example of this behavior in the wild:
scsi host11: error handler thread failed to spawn, error = -4
Kernel attempted to read user page (10c) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x0000010c
Faulting instruction address: 0xc00000000818e9a8
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region
hash dm_log dm_mod fuse overlay squashfs loop
CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1
NIP: c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8
REGS: c000000037d12ea0 TRAP: 0300 Not tainted (5.13.0-rc7)
MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28228228
XER: 20040001
CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0
GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc
GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000
GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff
GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0
GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288
GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898
GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000
GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc
NIP [c00000000818e9a8] kthread_stop+0x38/0x230
LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160
Call Trace:
[c000000033bb2c48] 0xc000000033bb2c48 (unreliable)
[c0000000089846e8] scsi_host_dev_release+0x98/0x160
[c00000000891e960] device_release+0x60/0x100
[c0000000087e55c4] kobject_release+0x84/0x210
[c00000000891ec78] put_device+0x28/0x40
[c000000008984ea4] scsi_host_alloc+0x314/0x430
[c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi]
[c000000008110104] vio_bus_probe+0xa4/0x4b0
[c00000000892a860] really_probe+0x140/0x680
[c00000000892aefc] driver_probe_device+0x15c/0x200
[c00000000892b63c] device_driver_attach+0xcc/0xe0
[c00000000892b740] __driver_attach+0xf0/0x200
[c000000008926f28] bus_for_each_dev+0xa8/0x130
[c000000008929ce4] driver_attach+0x34/0x50
[c000000008928fc0] bus_add_driver+0x1b0/0x300
[c00000000892c798] driver_register+0x98/0x1a0
[c00000000810eb60] __vio_register_driver+0x80/0xe0
[c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi]
[c0000000080121d0] do_one_initcall+0x60/0x2d0
[c000000008261abc] do_init_module+0x7c/0x320
[c000000008265700] load_module+0x2350/0x25b0
[c000000008265cb4] __do_sys_finit_module+0xd4/0x160
[c000000008031110] system_call_exception+0x150/0x2d0
[c00000000800d35c] system_call_common+0xec/0x278
Fix this be nulling shost->ehandler when the kthread fails to spawn.
Link: https://lore.kernel.org/r/20210701195659.3185475-1-tyreld@linux.ibm.com
Fixes: 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")
Cc: stable@vger.kernel.org
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1abfd98c6d0e1c1cf81f586d51f85ca80b22ff1
Author: Lai Jiangshan <laijs@linux.alibaba.com>
Date: Tue Jun 29 01:26:32 2021 +0800
KVM: X86: Disable hardware breakpoints unconditionally before kvm_x86->run()
commit f85d40160691881a17a397c448d799dfc90987ba upstream.
When the host is using debug registers but the guest is not using them
nor is the guest in guest-debug state, the kvm code does not reset
the host debug registers before kvm_x86->run(). Rather, it relies on
the hardware vmentry instruction to automatically reset the dr7 registers
which ensures that the host breakpoints do not affect the guest.
This however violates the non-instrumentable nature around VM entry
and exit; for example, when a host breakpoint is set on vcpu->arch.cr2,
Another issue is consistency. When the guest debug registers are active,
the host breakpoints are reset before kvm_x86->run(). But when the
guest debug registers are inactive, the host breakpoints are delayed to
be disabled. The host tracing tools may see different results depending
on what the guest is doing.
To fix the problems, we clear %db7 unconditionally before kvm_x86->run()
if the host has set any breakpoints, no matter if the guest is using
them or not.
Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
Message-Id: <20210628172632.81029-1-jiangshanlai@gmail.com>
Cc: stable@vger.kernel.org
[Only clear %db7 instead of reloading all debug registers. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5312c036240a4cc223a393a4b851f7f8deef05eb
Author: Sean Christopherson <seanjc@google.com>
Date: Wed Jun 23 16:05:46 2021 -0700
KVM: x86: Use guest MAXPHYADDR from CPUID.0x8000_0008 iff TDP is enabled
commit 4bf48e3c0aafd32b960d341c4925b48f416f14a5 upstream.
Ignore the guest MAXPHYADDR reported by CPUID.0x8000_0008 if TDP, i.e.
NPT, is disabled, and instead use the host's MAXPHYADDR. Per AMD'S APM:
Maximum guest physical address size in bits. This number applies only
to guests using nested paging. When this field is zero, refer to the
PhysAddrSize field for the maximum guest physical address size.
Fixes: 24c82e576b78 ("KVM: Sanitize cpuid")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210623230552.4027702-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5c2dca9a7a7ff6a2df34158903515e2e4fd3d2b2
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: Mon Apr 12 22:45:50 2021 +0900
smackfs: restrict bytes count in smk_set_cipso()
commit 49ec114a6e62d8d320037ce71c1aaf9650b3cafd upstream.
Oops, I failed to update subject line.
From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon, 12 Apr 2021 22:25:06 +0900
Subject: smackfs: restrict bytes count in smk_set_cipso()
Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write
functions") missed that count > SMK_CIPSOMAX check applies to only
format == SMK_FIXED24_FMT case.
Reported-by: syzbot <syzbot+77c53db50c9fff774e8e@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 49def1b0644892e3b113673c13d650c3060b43bc
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Sun Jun 6 17:24:05 2021 +0300
jfs: fix GPF in diFree
commit 9d574f985fe33efd6911f4d752de6f485a1ea732 upstream.
Avoid passing inode with
JFS_SBI(inode->i_sb)->ipimap == NULL to
diFree()[1]. GFP will appear:
struct inode *ipimap = JFS_SBI(ip->i_sb)->ipimap;
struct inomap *imap = JFS_IP(ipimap)->i_imap;
JFS_IP() will return invalid pointer when ipimap == NULL
Call Trace:
diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1]
jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154
evict+0x2ed/0x750 fs/inode.c:578
iput_final fs/inode.c:1654 [inline]
iput.part.0+0x3fe/0x820 fs/inode.c:1680
iput+0x58/0x70 fs/inode.c:1670
Reported-and-tested-by: syzbot+0a89a7b56db04c21a656@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 939d80e1895f7bfabb818331aeb676a9cfc0c476
Author: Benjamin Drung <bdrung@posteo.de>
Date: Sat Jun 5 22:15:36 2021 +0200
media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K
commit 4c6e0976295add7f0ed94d276c04a3d6f1ea8f83 upstream.
The Elgato Cam Link 4K HDMI video capture card reports to support three
different pixel formats, where the first format depends on the connected
HDMI device.
```
$ v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture
[0]: 'NV12' (Y/CbCr 4:2:0)
Size: Discrete 3840x2160
Interval: Discrete 0.033s (29.970 fps)
[1]: 'NV12' (Y/CbCr 4:2:0)
Size: Discrete 3840x2160
Interval: Discrete 0.033s (29.970 fps)
[2]: 'YU12' (Planar YUV 4:2:0)
Size: Discrete 3840x2160
Interval: Discrete 0.033s (29.970 fps)
```
Changing the pixel format to anything besides the first pixel format
does not work:
```
$ v4l2-ctl -d /dev/video0 --try-fmt-video pixelformat=YU12
Format Video Capture:
Width/Height : 3840/2160
Pixel Format : 'NV12' (Y/CbCr 4:2:0)
Field : None
Bytes per Line : 3840
Size Image : 12441600
Colorspace : sRGB
Transfer Function : Rec. 709
YCbCr/HSV Encoding: Rec. 709
Quantization : Default (maps to Limited Range)
Flags :
```
User space applications like VLC might show an error message on the
terminal in that case:
```
libv4l2: error set_fmt gave us a different result than try_fmt!
```
Depending on the error handling of the user space applications, they
might display a distorted video, because they use the wrong pixel format
for decoding the stream.
The Elgato Cam Link 4K responds to the USB video probe
VS_PROBE_CONTROL/VS_COMMIT_CONTROL with a malformed data structure: The
second byte contains bFormatIndex (instead of being the second byte of
bmHint). The first byte is always zero. The third byte is always 1.
The firmware bug was reported to Elgato on 2020-12-01 and it was
forwarded by the support team to the developers as feature request.
There is no firmware update available since then. The latest firmware
for Elgato Cam Link 4K as of 2021-03-23 has MCU 20.02.19 and FPGA 67.
Therefore correct the malformed data structure for this device. The
change was successfully tested with VLC, OBS, and Chromium using
different pixel formats (YUYV, NV12, YU12), resolutions (3840x2160,
1920x1080), and frame rates (29.970 and 59.940 fps).
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Drung <bdrung@posteo.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5ad1178207e6dfb111052ab67817d080d1708bbb
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 24 13:09:19 2021 +0200
media: gspca/sunplus: fix zero-length control requests
commit b4bb4d425b7b02424afea2dfdcd77b3b4794175e upstream.
The direction of the pipe argument must match the request-type direction
bit or control requests may fail depending on the host-controller-driver
implementation.
Control transfers without a data stage are treated as OUT requests by
the USB stack and should be using usb_sndctrlpipe(). Failing to do so
will now trigger a warning.
Fix the single zero-length control request which was using the
read-register helper, and update the helper so that zero-length reads
fail with an error message instead.
Fixes: 6a7eba24e4f0 ("V4L/DVB (8157): gspca: all subdrivers")
Cc: stable@vger.kernel.org # 2.6.27
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8e2a7cd99b54d770a2f5cb212823cf0a47ffedea
Author: Johan Hovold <johan@kernel.org>
Date: Fri May 21 15:28:39 2021 +0200
media: gspca/sq905: fix control-request direction
commit 53ae298fde7adcc4b1432bce2dbdf8dac54dfa72 upstream.
The direction of the pipe argument must match the request-type direction
bit or control requests may fail depending on the host-controller-driver
implementation.
Fix the USB_REQ_SYNCH_FRAME request which erroneously used
usb_sndctrlpipe().
Fixes: 27d35fc3fb06 ("V4L/DVB (10639): gspca - sq905: New subdriver.")
Cc: stable@vger.kernel.org # 2.6.30
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b0633051a6cb24186ff04ce1af99c7de18c1987e
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Mon May 17 21:18:14 2021 +0200
media: zr364xx: fix memory leak in zr364xx_start_readpipe
commit 0a045eac8d0427b64577a24d74bb8347c905ac65 upstream.
syzbot reported memory leak in zr364xx driver.
The problem was in non-freed urb in case of
usb_submit_urb() fail.
backtrace:
[<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline]
[<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74
[<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022
[<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]
[<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516
[<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
[<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576
Fixes: ccbf035ae5de ("V4L/DVB (12278): zr364xx: implement V4L2_CAP_STREAMING")
Cc: stable@vger.kernel.org
Reported-by: syzbot+af4fa391ef18efdd5f69@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0e61a83aee05603a7de951e72eaf9d77949532fc
Author: Johan Hovold <johan@kernel.org>
Date: Fri May 21 15:28:38 2021 +0200
media: dtv5100: fix control-request directions
commit 8c8b9a9be2afa8bd6a72ad1130532baab9fab89d upstream.
The direction of the pipe argument must match the request-type direction
bit or control requests may fail depending on the host-controller-driver
implementation.
Fix the control requests which erroneously used usb_rcvctrlpipe().
Fixes: 8466028be792 ("V4L/DVB (8734): Initial support for AME DTV-5100 USB2.0 DVB-T")
Cc: stable@vger.kernel.org # 2.6.28
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 73f27adaa73e3057a9ec464e33c4f54d34ea5de3
Author: Hou Tao <houtao1@huawei.com>
Date: Thu Jun 17 15:45:47 2021 +0800
dm btree remove: assign new_root only when removal succeeds
commit b6e58b5466b2959f83034bead2e2e1395cca8aeb upstream.
remove_raw() in dm_btree_remove() may fail due to IO read error
(e.g. read the content of origin block fails during shadowing),
and the value of shadow_spine::root is uninitialized, but
the uninitialized value is still assign to new_root in the
end of dm_btree_remove().
For dm-thin, the value of pmd->details_root or pmd->root will become
an uninitialized value, so if trying to read details_info tree again
out-of-bound memory may occur as showed below:
general protection fault, probably for non-canonical address 0x3fdcb14c8d7520
CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6
Hardware name: QEMU Standard PC
RIP: 0010:metadata_ll_load_ie+0x14/0x30
Call Trace:
sm_metadata_count_is_more_than_one+0xb9/0xe0
dm_tm_shadow_block+0x52/0x1c0
shadow_step+0x59/0xf0
remove_raw+0xb2/0x170
dm_btree_remove+0xf4/0x1c0
dm_pool_delete_thin_device+0xc3/0x140
pool_message+0x218/0x2b0
target_message+0x251/0x290
ctl_ioctl+0x1c4/0x4d0
dm_ctl_ioctl+0xe/0x20
__x64_sys_ioctl+0x7b/0xb0
do_syscall_64+0x40/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixing it by only assign new_root when removal succeeds
Signed-off-by: Hou Tao <houtao1@huawei.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 51b8e23cd92003410f3b4e7ed5deeb3105ef983c
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date: Mon May 24 02:32:05 2021 -0700
ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe
commit 9272e5d0028d45a3b45b58c9255e6e0df53f7ad9 upstream.
In the out_err_bus_register error branch of tpci200_pci_probe,
tpci200->info->cfg_regs is freed by tpci200_uninstall()->
tpci200_unregister()->pci_iounmap(..,tpci200->info->cfg_regs)
in the first time.
But later, iounmap() is called to free tpci200->info->cfg_regs
again.
My patch sets tpci200->info->cfg_regs to NULL after tpci200_uninstall()
to avoid the double free.
Fixes: cea2f7cdff2af ("Staging: ipack/bridges/tpci200: Use the TPCI200 in big endian mode")
Cc: stable <stable@vger.kernel.org>
Acked-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Link: https://lore.kernel.org/r/20210524093205.8333-1-lyl2019@mail.ustc.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5ec5e2952c6d2dd3dca2329e9ff6f4c90a15ad12
Author: Paul Burton <paulburton@google.com>
Date: Tue Jun 29 17:34:05 2021 -0700
tracing: Simplify & fix saved_tgids logic
commit b81b3e959adb107cd5b36c7dc5ba1364bbd31eb2 upstream.
The tgid_map array records a mapping from pid to tgid, where the index
of an entry within the array is the pid & the value stored at that index
is the tgid.
The saved_tgids_next() function iterates over pointers into the tgid_map
array & dereferences the pointers which results in the tgid, but then it
passes that dereferenced value to trace_find_tgid() which treats it as a
pid & does a further lookup within the tgid_map array. It seems likely
that the intent here was to skip over entries in tgid_map for which the
recorded tgid is zero, but instead we end up skipping over entries for
which the thread group leader hasn't yet had its own tgid recorded in
tgid_map.
A minimal fix would be to remove the call to trace_find_tgid, turning:
if (trace_find_tgid(*ptr))
into:
if (*ptr)
..but it seems like this logic can be much simpler if we simply let
seq_read() iterate over the whole tgid_map array & filter out empty
entries by returning SEQ_SKIP from saved_tgids_show(). Here we take that
approach, removing the incorrect logic here entirely.
Link: https://lkml.kernel.org/r/20210630003406.4013668-1-paulburton@google.com
Fixes: d914ba37d714 ("tracing: Add support for recording tgid of tasks")
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Paul Burton <paulburton@google.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50b51460f59acbd403475510ad423bb5ea7a4c97
Author: Yun Zhou <yun.zhou@windriver.com>
Date: Sat Jun 26 11:21:55 2021 +0800
seq_buf: Fix overflow in seq_buf_putmem_hex()
commit d3b16034a24a112bb83aeb669ac5b9b01f744bb7 upstream.
There's two variables being increased in that loop (i and j), and i
follows the raw data, and j follows what is being written into the buffer.
We should compare 'i' to MAX_MEMHEX_BYTES or compare 'j' to HEX_CHARS.
Otherwise, if 'j' goes bigger than HEX_CHARS, it will overflow the
destination buffer.
Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/
Link: https://lkml.kernel.org/r/20210626032156.47889-1-yun.zhou@windriver.com
Cc: stable@vger.kernel.org
Fixes: 5e3ca0ec76fce ("ftrace: introduce the "hex" output method")
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 58023396feba43f536d6d1ede5e90bf5b3c3ff66
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Sun Jun 27 01:47:49 2021 +0200
power: supply: ab8500: Fix an old bug
commit f1c74a6c07e76fcb31a4bcc1f437c4361a2674ce upstream.
Trying to get the AB8500 charging driver working I ran into a bit
of bitrot: we haven't used the driver for a while so errors in
refactorings won't be noticed.
This one is pretty self evident: use argument to the macro or we
end up with a random pointer to something else.
Cc: stable@vger.kernel.org
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Marcus Cooper <codekipper@gmail.com>
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 580920d1e89c8e330d5b6d18ef8cd42def0106cc
Author: Petr Pavlu <petr.pavlu@suse.com>
Date: Thu May 13 14:26:36 2021 +0200
ipmi/watchdog: Stop watchdog timer when the current action is 'none'
commit 2253042d86f57d90a621ac2513a7a7a13afcf809 upstream.
When an IPMI watchdog timer is being stopped in ipmi_close() or
ipmi_ioctl(WDIOS_DISABLECARD), the current watchdog action is updated to
WDOG_TIMEOUT_NONE and _ipmi_set_timeout(IPMI_SET_TIMEOUT_NO_HB) is called
to install this action. The latter function ends up invoking
__ipmi_set_timeout() which makes the actual 'Set Watchdog Timer' IPMI
request.
For IPMI 1.0, this operation results in fully stopping the watchdog timer.
For IPMI >= 1.5, function __ipmi_set_timeout() always specifies the "don't
stop" flag in the prepared 'Set Watchdog Timer' IPMI request. This causes
that the watchdog timer has its action correctly updated to 'none' but the
timer continues to run. A problem is that IPMI firmware can then still log
an expiration event when the configured timeout is reached, which is
unexpected because the watchdog timer was requested to be stopped.
The patch fixes this problem by not setting the "don't stop" flag in
__ipmi_set_timeout() when the current action is WDOG_TIMEOUT_NONE which
results in stopping the watchdog timer. This makes the behaviour for
IPMI >= 1.5 consistent with IPMI 1.0. It also matches the logic in
__ipmi_heartbeat() which does not allow to reset the watchdog if the
current action is WDOG_TIMEOUT_NONE as that would start the timer.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Message-Id: <10a41bdc-9c99-089c-8d89-fa98ce5ea080@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0fb0ab7340c85c918ce784f6c4c76ea1419a4f7e
Author: Nathan Chancellor <nathan@kernel.org>
Date: Thu Feb 11 12:42:58 2021 -0700
qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute
commit fca41af18e10318e4de090db47d9fa7169e1bf2f upstream.
fw_cfg_showrev() is called by an indirect call in kobj_attr_show(),
which violates clang's CFI checking because fw_cfg_showrev()'s second
parameter is 'struct attribute', whereas the ->show() member of 'struct
kobj_structure' expects the second parameter to be of type 'struct
kobj_attribute'.
$ cat /sys/firmware/qemu_fw_cfg/rev
3
$ dmesg | grep "CFI failure"
[ 26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8):
Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where
this would have been caught automatically by the incompatible pointer
types compiler warning. Update fw_cfg_showrev() accordingly.
Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
Link: https://github.com/ClangBuiltLinux/linux/issues/1299
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210211194258.4137998-1-nathan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9a79027bf0a8385b27a48380b5de087bfb5b89c6
Author: Dmitry Osipenko <digetx@gmail.com>
Date: Sat May 29 18:46:46 2021 +0300
ASoC: tegra: Set driver_name=tegra for all machine drivers
commit f6eb84fa596abf28959fc7e0b626f925eb1196c7 upstream.
The driver_name="tegra" is now required by the newer ALSA UCMs, otherwise
Tegra UCMs don't match by the path/name.
All Tegra machine drivers are specifying the card's name, but it has no
effect if model name is specified in the device-tree since it overrides
the card's name. We need to set the driver_name to "tegra" in order to
get a usable lookup path for the updated ALSA UCMs. The new UCM lookup
path has a form of driver_name/card_name.
The old lookup paths that are based on driver module name continue to
work as before. Note that UCM matching never worked for Tegra ASoC drivers
if they were compiled as built-in, this is fixed by supporting the new
naming scheme.
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210529154649.25936-2-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9f6e4f48e9e00784a6af5b94ffdb8feecd8f609e
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sat Mar 27 22:01:36 2021 +0100
cpu/hotplug: Cure the cpusets trainwreck
commit b22afcdf04c96ca58327784e280e10288cfd3303 upstream.
Alexey and Joshua tried to solve a cpusets related hotplug problem which is
user space visible and results in unexpected behaviour for some time after
a CPU has been plugged in and the corresponding uevent was delivered.
cpusets delegate the hotplug work (rebuilding cpumasks etc.) to a
workqueue. This is done because the cpusets code has already a lock
nesting of cgroups_mutex -> cpu_hotplug_lock. A synchronous callback or
waiting for the work to finish with cpu_hotplug_lock held can and will
deadlock because that results in the reverse lock order.
As a consequence the uevent can be delivered before cpusets have consistent
state which means that a user space invocation of sched_setaffinity() to
move a task to the plugged CPU fails up to the point where the scheduled
work has been processed.
The same is true for CPU unplug, but that does not create user observable
failure (yet).
It's still inconsistent to claim that an operation is finished before it
actually is and that's the real issue at hand. uevents just make it
reliably observable.
Obviously the problem should be fixed in cpusets/cgroups, but untangling
that is pretty much impossible because according to the changelog of the
commit which introduced this 8 years ago:
3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()")
the lock order cgroups_mutex -> cpu_hotplug_lock is a design decision and
the whole code is built around that.
So bite the bullet and invoke the relevant cpuset function, which waits for
the work to finish, in _cpu_up/down() after dropping cpu_hotplug_lock and
only when tasks are not frozen by suspend/hibernate because that would
obviously wait forever.
Waiting there with cpu_add_remove_lock, which is protecting the present
and possible CPU maps, held is not a problem at all because neither work
queues nor cpusets/cgroups have any lockchains related to that lock.
Waiting in the hotplug machinery is not problematic either because there
are already state callbacks which wait for hardware queues to drain. It
makes the operations slightly slower, but hotplug is slow anyway.
This ensures that state is consistent before returning from a hotplug
up/down operation. It's still inconsistent during the operation, but that's
a different story.
Add a large comment which explains why this is done and why this is not a
dump ground for the hack of the day to work around half thought out locking
schemes. Document also the implications vs. hotplug operations and
serialization or the lack of it.
Thanks to Alexy and Joshua for analyzing why this temporary
sched_setaffinity() failure happened.
Fixes: 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()")
Reported-by: Alexey Klimov <aklimov@redhat.com>
Reported-by: Joshua Baker <jobaker@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexey Klimov <aklimov@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87tuowcnv3.ffs@nanos.tec.linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 474da7a8076a462a07d01046d55de8665a3e7c93
Author: Timo Sigurdsson <public_timo.s@silentcreek.de>
Date: Mon Jun 14 09:25:39 2021 +0200
ata: ahci_sunxi: Disable DIPM
commit f6bca4d91b2ea052e917cca3f9d866b5cc1d500a upstream.
DIPM is unsupported or broken on sunxi. Trying to enable the power
management policy med_power_with_dipm on an Allwinner A20 SoC based board
leads to immediate I/O errors and the attached SATA disk disappears from
the /dev filesystem. A reset (power cycle) is required to make the SATA
controller or disk work again. The A10 and A20 SoC data sheets and manuals
don't mention DIPM at all [1], so it's fair to assume that it's simply not
supported. But even if it was, it should be considered broken and best be
disabled in the ahci_sunxi driver.
[1] https://github.com/allwinner-zh/documents/tree/master/
Fixes: c5754b5220f0 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform")
Cc: stable@vger.kernel.org
Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
Tested-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
Link: https://lore.kernel.org/r/20210614072539.3307-1-public_timo.s@silentcreek.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1d5955b13e6e89cc30d155bc2e1e1a76f79c11bd
Author: Christian Löhle <CLoehle@hyperstone.com>
Date: Wed May 12 16:03:24 2021 +0000
mmc: core: Allow UHS-I voltage switch for SDSC cards if supported
commit 09247e110b2efce3a104e57e887c373e0a57a412 upstream.
While initializing an UHS-I SD card, the mmc core first tries to switch to
1.8V I/O voltage, before it continues to change the settings for the bus
speed mode.
However, the current behaviour in the mmc core is inconsistent and doesn't
conform to the SD spec. More precisely, an SD card that supports UHS-I must
set both the SD_OCR_CCS bit and the SD_OCR_S18R bit in the OCR register
response. When switching to 1.8V I/O the mmc core correctly checks both of
the bits, but only the SD_OCR_S18R bit when changing the settings for bus
speed mode.
Rather than actually fixing the code to confirm to the SD spec, let's
deliberately deviate from it by requiring only the SD_OCR_S18R bit for both
parts. This enables us to support UHS-I for SDSC cards (outside spec),
which is actually being supported by some existing SDSC cards. Moreover,
this fixes the inconsistent behaviour.
Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
Link: https://lore.kernel.org/r/CWXP265MB26803AE79E0AD5ED083BF2A6C4529@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM
Cc: stable@vger.kernel.org
[Ulf: Rewrote commit message and comments to clarify the changes]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 31eac126fe443250677f94b6347141be094b8500
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date: Thu Jun 24 17:16:14 2021 +0200
mmc: core: clear flags before allowing to retune
commit 77347eda64ed5c9383961d1de9165f9d0b7d8df6 upstream.
It might be that something goes wrong during tuning so the MMC core will
immediately trigger a retune. In our case it was:
- we sent a tuning block
- there was an error so we need to send an abort cmd to the eMMC
- the abort cmd had a CRC error
- retune was set by the MMC core
This lead to a vicious circle causing a performance regression of 75%.
So, clear retuning flags before we enable retuning to start with a known
cleared state.
Reported-by Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210624151616.38770-2-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5e8114bffac57f3cc655095517281abc11a5fa2c
Author: Al Cooper <alcooperx@gmail.com>
Date: Thu Jun 24 12:30:45 2021 -0400
mmc: sdhci: Fix warning message when accessing RPMB in HS400 mode
commit d0244847f9fc5e20df8b7483c8a4717fe0432d38 upstream.
When an eMMC device is being run in HS400 mode, any access to the
RPMB device will cause the error message "mmc1: Invalid UHS-I mode
selected". This happens as a result of tuning being disabled before
RPMB access and then re-enabled after the RPMB access is complete.
When tuning is re-enabled, the system has to switch from HS400
to HS200 to do the tuning and then back to HS400. As part of
sequence to switch from HS400 to HS200 the system is temporarily
put into HS mode. When switching to HS mode, sdhci_get_preset_value()
is called and does not have support for HS mode and prints the warning
message and returns the preset for SDR12. The fix is to add support
for MMC and SD HS modes to sdhci_get_preset_value().
This can be reproduced on any system running eMMC in HS400 mode
(not HS400ES) by using the "mmc" utility to run the following
command: "mmc rpmb read-counter /dev/mmcblk0rpmb".
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 52983382c74f ("mmc: sdhci: enhance preset value function")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210624163045.33651-1-alcooperx@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f4dd77c7c3162c7d1f89bda4c9df103cc35188a
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date: Wed May 12 23:03:16 2021 +0200
pinctrl/amd: Add device HID for new AMD GPIO controller
commit 1ca46d3e43569186bd1decfb02a6b4c4ddb4304b upstream.
Add device HID AMDI0031 to the AMD GPIO controller driver match table.
This controller can be found on Microsoft Surface Laptop 4 devices and
seems similar enough that we can just copy the existing AMDI0030 entry.
Cc: <stable@vger.kernel.org> # 5.10+
Tested-by: Sachi King <nakato@nakato.io>
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210512210316.1982416-1-luzmaximilian@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 20792916733730cd3ea556ff319c084af9ec67cb
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date: Tue Jun 29 19:44:55 2021 +0800
drm/radeon: Add the missed drm_gem_object_put() in radeon_user_framebuffer_create()
commit 9ba85914c36c8fed9bf3e8b69c0782908c1247b7 upstream.
radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
an error path. Add the missed function call to fix it.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 646cdf842cc52169ffe4178d26e47d4ae5253ab6
Author: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Date: Thu Jun 3 12:15:07 2021 -0500
usb: gadget: f_fs: Fix setting of device and driver data cross-references
commit ecfbd7b9054bddb12cea07fda41bb3a79a7b0149 upstream.
FunctionFS device structure 'struct ffs_dev' and driver data structure
'struct ffs_data' are bound to each other with cross-reference pointers
'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one
is supposed to be valid through the whole life of 'struct ffs_data'
(and while 'struct ffs_dev' exists non-freed), the second one is cleared
in 'ffs_closed()' (called from 'ffs_data_reset()' or the last
'ffs_data_put()'). This can be called several times, alternating in
different order with 'ffs_free_inst()', that, if possible, clears
the other cross-reference.
As a result, different cases of these calls order may leave stale
cross-reference pointers, used when the pointed structure is already
freed. Even if it occasionally doesn't cause kernel crash, this error
is reported by KASAN-enabled kernel configuration.
For example, the case [last 'ffs_data_put()' - 'ffs_free_inst()'] was
fixed by commit cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in
ffs_free_inst").
The other case ['ffs_data_reset()' - 'ffs_free_inst()' - 'ffs_data_put()']
now causes KASAN reported error [1], when 'ffs_data_reset()' clears
'ffs_dev->ffs_data', then 'ffs_free_inst()' frees the 'struct ffs_dev',
but can't clear 'ffs_data->private_data', which is then accessed
in 'ffs_closed()' called from 'ffs_data_put()'. This happens since
'ffs_dev->ffs_data' reference is cleared too early.
Moreover, one more use case, when 'ffs_free_inst()' is called immediately
after mounting FunctionFS device (that is before the descriptors are
written and 'ffs_ready()' is called), and then 'ffs_data_reset()'
or 'ffs_data_put()' is called from accessing "ep0" file or unmounting
the device. This causes KASAN error report like [2], since
'ffs_dev->ffs_data' is not yet set when 'ffs_free_inst()' can't properly
clear 'ffs_data->private_data', that is later accessed to freed structure.
Fix these (and may be other) cases of stale pointers access by moving
setting and clearing of the mentioned cross-references to the single
places, setting both of them when 'struct ffs_data' is created and
bound to 'struct ffs_dev', and clearing both of them when one of the
structures is destroyed. It seems convenient to make this pointer
initialization and structures binding in 'ffs_acquire_dev()' and
make pointers clearing in 'ffs_release_dev()'. This required some
changes in these functions parameters and return types.
Also, 'ffs_release_dev()' calling requires some cleanup, fixing minor
issues, like (1) 'ffs_release_dev()' is not called if 'ffs_free_inst()'
is called without unmounting the device, and "release_dev" callback
is not called at all, or (2) "release_dev" callback is called before
"ffs_closed" callback on unmounting, which seems to be not correctly
nested with "acquire_dev" and "ffs_ready" callbacks.
Make this cleanup togther with other mentioned 'ffs_release_dev()' changes.
[1]
==================================================================
root@rcar-gen3:~# mkdir /dev/cfs
root@rcar-gen3:~# mkdir /dev/ffs
root@rcar-gen3:~# modprobe libcomposite
root@rcar-gen3:~# mount -t configfs none /dev/cfs
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 64.340664] file system registered
root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
root@rcar-gen3:~# cd /dev/ffs
root@rcar-gen3:/dev/ffs# /home/root/ffs-test
ffs-test: info: ep0: writing descriptors (in v2 format)
[ 83.181442] read descriptors
[ 83.186085] read strings
ffs-test: info: ep0: writing strings
ffs-test: dbg: ep1: starting
ffs-test: dbg: ep2: starting
ffs-test: info: ep1: starts
ffs-test: info: ep2: starts
ffs-test: info: ep0: starts
^C
root@rcar-gen3:/dev/ffs# cd /home/root/
root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 98.935061] unloading
root@rcar-gen3:~# umount /dev/ffs
[ 102.734301] ==================================================================
[ 102.742059] BUG: KASAN: use-after-free in ffs_release_dev+0x64/0xa8 [usb_f_fs]
[ 102.749683] Write of size 1 at addr ffff0004d46ff549 by task umount/2997
[ 102.756709]
[ 102.758311] CPU: 0 PID: 2997 Comm: umount Not tainted 5.13.0-rc4+ #8
[ 102.764971] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 102.772179] Call trace:
[ 102.774779] dump_backtrace+0x0/0x330
[ 102.778653] show_stack+0x20/0x2c
[ 102.782152] dump_stack+0x11c/0x1ac
[ 102.785833] print_address_description.constprop.0+0x30/0x274
[ 102.791862] kasan_report+0x14c/0x1c8
[ 102.795719] __asan_report_store1_noabort+0x34/0x58
[ 102.800840] ffs_release_dev+0x64/0xa8 [usb_f_fs]
[ 102.805801] ffs_fs_kill_sb+0x50/0x84 [usb_f_fs]
[ 102.810663] deactivate_locked_super+0xa0/0xf0
[ 102.815339] deactivate_super+0x98/0xac
[ 102.819378] cleanup_mnt+0xd0/0x1b0
[ 102.823057] __cleanup_mnt+0x1c/0x28
[ 102.826823] task_work_run+0x104/0x180
[ 102.830774] do_notify_resume+0x458/0x14e0
[ 102.835083] work_pending+0xc/0x5f8
[ 102.838762]
[ 102.840357] Allocated by task 2988:
[ 102.844032] kasan_save_stack+0x28/0x58
[ 102.848071] kasan_set_track+0x28/0x3c
[ 102.852016] ____kasan_kmalloc+0x84/0x9c
[ 102.856142] __kasan_kmalloc+0x10/0x1c
[ 102.860088] __kmalloc+0x214/0x2f8
[ 102.863678] kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
[ 102.868990] ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
[ 102.873942] try_get_usb_function_instance+0xf0/0x164 [libcomposite]
[ 102.880629] usb_get_function_instance+0x64/0x68 [libcomposite]
[ 102.886858] function_make+0x128/0x1ec [libcomposite]
[ 102.892185] configfs_mkdir+0x330/0x590 [configfs]
[ 102.897245] vfs_mkdir+0x12c/0x1bc
[ 102.900835] do_mkdirat+0x180/0x1d0
[ 102.904513] __arm64_sys_mkdirat+0x80/0x94
[ 102.908822] invoke_syscall+0xf8/0x25c
[ 102.912772] el0_svc_common.constprop.0+0x150/0x1a0
[ 102.917891] do_el0_svc+0xa0/0xd4
[ 102.921386] el0_svc+0x24/0x34
[ 102.924613] el0_sync_handler+0xcc/0x154
[ 102.928743] el0_sync+0x198/0x1c0
[ 102.932238]
[ 102.933832] Freed by task 2996:
[ 102.937144] kasan_save_stack+0x28/0x58
[ 102.941181] kasan_set_track+0x28/0x3c
[ 102.945128] kasan_set_free_info+0x28/0x4c
[ 102.949435] ____kasan_slab_free+0x104/0x118
[ 102.953921] __kasan_slab_free+0x18/0x24
[ 102.958047] slab_free_freelist_hook+0x148/0x1f0
[ 102.962897] kfree+0x318/0x440
[ 102.966123] ffs_free_inst+0x164/0x2d8 [usb_f_fs]
[ 102.971075] usb_put_function_instance+0x84/0xa4 [libcomposite]
[ 102.977302] ffs_attr_release+0x18/0x24 [usb_f_fs]
[ 102.982344] config_item_put+0x140/0x1a4 [configfs]
[ 102.987486] configfs_rmdir+0x3fc/0x518 [configfs]
[ 102.992535] vfs_rmdir+0x114/0x234
[ 102.996122] do_rmdir+0x274/0x2b0
[ 102.999617] __arm64_sys_unlinkat+0x94/0xc8
[ 103.004015] invoke_syscall+0xf8/0x25c
[ 103.007961] el0_svc_common.constprop.0+0x150/0x1a0
[ 103.013080] do_el0_svc+0xa0/0xd4
[ 103.016575] el0_svc+0x24/0x34
[ 103.019801] el0_sync_handler+0xcc/0x154
[ 103.023930] el0_sync+0x198/0x1c0
[ 103.027426]
[ 103.029020] The buggy address belongs to the object at ffff0004d46ff500
[ 103.029020] which belongs to the cache kmalloc-128 of size 128
[ 103.042079] The buggy address is located 73 bytes inside of
[ 103.042079] 128-byte region [ffff0004d46ff500, ffff0004d46ff580)
[ 103.054236] The buggy address belongs to the page:
[ 103.059262] page:0000000021aa849b refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0004d46fee00 pfn:0x5146fe
[ 103.070437] head:0000000021aa849b order:1 compound_mapcount:0
[ 103.076456] flags: 0x8000000000010200(slab|head|zone=2)
[ 103.081948] raw: 8000000000010200 fffffc0013521a80 0000000d0000000d ffff0004c0002300
[ 103.090052] raw: ffff0004d46fee00 000000008020001e 00000001ffffffff 0000000000000000
[ 103.098150] page dumped because: kasan: bad access detected
[ 103.103985]
[ 103.105578] Memory state around the buggy address:
[ 103.110602] ffff0004d46ff400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 103.118161] ffff0004d46ff480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 103.125726] >ffff0004d46ff500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 103.133284] ^
[ 103.139120] ffff0004d46ff580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 103.146679] ffff0004d46ff600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 103.154238] ==================================================================
[ 103.161792] Disabling lock debugging due to kernel taint
[ 103.167319] Unable to handle kernel paging request at virtual address 0037801d6000018e
[ 103.175406] Mem abort info:
[ 103.178457] ESR = 0x96000004
[ 103.181609] EC = 0x25: DABT (current EL), IL = 32 bits
[ 103.187020] SET = 0, FnV = 0
[ 103.190185] EA = 0, S1PTW = 0
[ 103.193417] Data abort info:
[ 103.196385] ISV = 0, ISS = 0x00000004
[ 103.200315] CM = 0, WnR = 0
[ 103.203366] [0037801d6000018e] address between user and kernel address ranges
[ 103.210611] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 103.216231] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk sata_rc4
[ 103.259233] CPU: 0 PID: 2997 Comm: umount Tainted: G B 5.13.0-rc4+ #8
[ 103.267031] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 103.273951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 103.280001] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 103.285197] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
[ 103.290385] sp : ffff800014777a80
[ 103.293725] x29: ffff800014777a80 x28: ffff0004d7649c80 x27: 0000000000000000
[ 103.300931] x26: ffff800014777fb0 x25: ffff60009aec9394 x24: ffff0004d7649ca4
[ 103.308136] x23: 1fffe0009a3d063a x22: dfff800000000000 x21: ffff0004d1e831d0
[ 103.315340] x20: e1c000eb00000bb4 x19: ffff0004d1e83000 x18: 0000000000000000
[ 103.322545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 103.329748] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000012ef658
[ 103.336952] x11: ffff7000012ef658 x10: 0720072007200720 x9 : ffff800011322648
[ 103.344157] x8 : ffff800014777818 x7 : ffff80000977b2c7 x6 : 0000000000000000
[ 103.351359] x5 : 0000000000000001 x4 : ffff7000012ef659 x3 : 0000000000000001
[ 103.358562] x2 : 0000000000000000 x1 : 1c38001d6000018e x0 : e1c000eb00000c70
[ 103.365766] Call trace:
[ 103.368235] ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 103.373076] ffs_data_reset+0x20/0x304 [usb_f_fs]
[ 103.377829] ffs_data_closed+0x1ec/0x244 [usb_f_fs]
[ 103.382755] ffs_fs_kill_sb+0x70/0x84 [usb_f_fs]
[ 103.387420] deactivate_locked_super+0xa0/0xf0
[ 103.391905] deactivate_super+0x98/0xac
[ 103.395776] cleanup_mnt+0xd0/0x1b0
[ 103.399299] __cleanup_mnt+0x1c/0x28
[ 103.402906] task_work_run+0x104/0x180
[ 103.406691] do_notify_resume+0x458/0x14e0
[ 103.410823] work_pending+0xc/0x5f8
[ 103.414351] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
[ 103.420490] ---[ end trace 57b43a50e8244f57 ]---
Segmentation fault
root@rcar-gen3:~#
==================================================================
[2]
==================================================================
root@rcar-gen3:~# mkdir /dev/ffs
root@rcar-gen3:~# modprobe libcomposite
root@rcar-gen3:~#
root@rcar-gen3:~# mount -t configfs none /dev/cfs
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 54.766480] file system registered
root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
[ 63.197597] unloading
root@rcar-gen3:~# cat /dev/ffs/ep0
cat: read error:[ 67.213506] ==================================================================
[ 67.222095] BUG: KASAN: use-after-free in ffs_data_clear+0x70/0x370 [usb_f_fs]
[ 67.229699] Write of size 1 at addr ffff0004c26e974a by task cat/2994
[ 67.236446]
[ 67.238045] CPU: 0 PID: 2994 Comm: cat Not tainted 5.13.0-rc4+ #8
[ 67.244431] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 67.251624] Call trace:
[ 67.254212] dump_backtrace+0x0/0x330
[ 67.258081] show_stack+0x20/0x2c
[ 67.261579] dump_stack+0x11c/0x1ac
[ 67.265260] print_address_description.constprop.0+0x30/0x274
[ 67.271286] kasan_report+0x14c/0x1c8
[ 67.275143] __asan_report_store1_noabort+0x34/0x58
[ 67.280265] ffs_data_clear+0x70/0x370 [usb_f_fs]
[ 67.285220] ffs_data_reset+0x20/0x304 [usb_f_fs]
[ 67.290172] ffs_data_closed+0x240/0x244 [usb_f_fs]
[ 67.295305] ffs_ep0_release+0x40/0x54 [usb_f_fs]
[ 67.300256] __fput+0x304/0x580
[ 67.303576] ____fput+0x18/0x24
[ 67.306893] task_work_run+0x104/0x180
[ 67.310846] do_notify_resume+0x458/0x14e0
[ 67.315154] work_pending+0xc/0x5f8
[ 67.318834]
[ 67.320429] Allocated by task 2988:
[ 67.324105] kasan_save_stack+0x28/0x58
[ 67.328144] kasan_set_track+0x28/0x3c
[ 67.332090] ____kasan_kmalloc+0x84/0x9c
[ 67.336217] __kasan_kmalloc+0x10/0x1c
[ 67.340163] __kmalloc+0x214/0x2f8
[ 67.343754] kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
[ 67.349066] ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
[ 67.354017] try_get_usb_function_instance+0xf0/0x164 [libcomposite]
[ 67.360705] usb_get_function_instance+0x64/0x68 [libcomposite]
[ 67.366934] function_make+0x128/0x1ec [libcomposite]
[ 67.372260] configfs_mkdir+0x330/0x590 [configfs]
[ 67.377320] vfs_mkdir+0x12c/0x1bc
[ 67.380911] do_mkdirat+0x180/0x1d0
[ 67.384589] __arm64_sys_mkdirat+0x80/0x94
[ 67.388899] invoke_syscall+0xf8/0x25c
[ 67.392850] el0_svc_common.constprop.0+0x150/0x1a0
[ 67.397969] do_el0_svc+0xa0/0xd4
[ 67.401464] el0_svc+0x24/0x34
[ 67.404691] el0_sync_handler+0xcc/0x154
[ 67.408819] el0_sync+0x198/0x1c0
[ 67.412315]
[ 67.413909] Freed by task 2993:
[ 67.417220] kasan_save_stack+0x28/0x58
[ 67.421257] kasan_set_track+0x28/0x3c
[ 67.425204] kasan_set_free_info+0x28/0x4c
[ 67.429513] ____kasan_slab_free+0x104/0x118
[ 67.434001] __kasan_slab_free+0x18/0x24
[ 67.438128] slab_free_freelist_hook+0x148/0x1f0
[ 67.442978] kfree+0x318/0x440
[ 67.446205] ffs_free_inst+0x164/0x2d8 [usb_f_fs]
[ 67.451156] usb_put_function_instance+0x84/0xa4 [libcomposite]
[ 67.457385] ffs_attr_release+0x18/0x24 [usb_f_fs]
[ 67.462428] config_item_put+0x140/0x1a4 [configfs]
[ 67.467570] configfs_rmdir+0x3fc/0x518 [configfs]
[ 67.472626] vfs_rmdir+0x114/0x234
[ 67.476215] do_rmdir+0x274/0x2b0
[ 67.479710] __arm64_sys_unlinkat+0x94/0xc8
[ 67.484108] invoke_syscall+0xf8/0x25c
[ 67.488055] el0_svc_common.constprop.0+0x150/0x1a0
[ 67.493175] do_el0_svc+0xa0/0xd4
[ 67.496671] el0_svc+0x24/0x34
[ 67.499896] el0_sync_handler+0xcc/0x154
[ 67.504024] el0_sync+0x198/0x1c0
[ 67.507520]
[ 67.509114] The buggy address belongs to the object at ffff0004c26e9700
[ 67.509114] which belongs to the cache kmalloc-128 of size 128
[ 67.522171] The buggy address is located 74 bytes inside of
[ 67.522171] 128-byte region [ffff0004c26e9700, ffff0004c26e9780)
[ 67.534328] The buggy address belongs to the page:
[ 67.539355] page:000000003177a217 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5026e8
[ 67.549175] head:000000003177a217 order:1 compound_mapcount:0
[ 67.555195] flags: 0x8000000000010200(slab|head|zone=2)
[ 67.560687] raw: 8000000000010200 fffffc0013037100 0000000c00000002 ffff0004c0002300
[ 67.568791] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
[ 67.576890] page dumped because: kasan: bad access detected
[ 67.582725]
[ 67.584318] Memory state around the buggy address:
[ 67.589343] ffff0004c26e9600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 67.596903] ffff0004c26e9680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 67.604463] >ffff0004c26e9700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 67.612022] ^
[ 67.617860] ffff0004c26e9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 67.625421] ffff0004c26e9800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 67.632981] ==================================================================
[ 67.640535] Disabling lock debugging due to kernel taint
File descriptor[ 67.646100] Unable to handle kernel paging request at virtual address fabb801d4000018d
in bad state
[ 67.655456] Mem abort info:
[ 67.659619] ESR = 0x96000004
[ 67.662801] EC = 0x25: DABT (current EL), IL = 32 bits
[ 67.668225] SET = 0, FnV = 0
[ 67.671375] EA = 0, S1PTW = 0
[ 67.674613] Data abort info:
[ 67.677587] ISV = 0, ISS = 0x00000004
[ 67.681522] CM = 0, WnR = 0
[ 67.684588] [fabb801d4000018d] address between user and kernel address ranges
[ 67.691849] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 67.697470] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha1_ce evdev sata_rcar libata xhci_plat_hcd scsi_mod xhci_hcd rene4
[ 67.740467] CPU: 0 PID: 2994 Comm: cat Tainted: G B 5.13.0-rc4+ #8
[ 67.748005] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
[ 67.754924] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 67.760974] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 67.766178] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
[ 67.771365] sp : ffff800014767ad0
[ 67.774706] x29: ffff800014767ad0 x28: ffff800009cf91c0 x27: ffff0004c54861a0
[ 67.781913] x26: ffff0004dc90b288 x25: 1fffe00099ec10f5 x24: 00000000000a801d
[ 67.789118] x23: 1fffe00099f6953a x22: dfff800000000000 x21: ffff0004cfb4a9d0
[ 67.796322] x20: d5e000ea00000bb1 x19: ffff0004cfb4a800 x18: 0000000000000000
[ 67.803526] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 67.810730] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000028ecefa
[ 67.817934] x11: ffff7000028ecefa x10: 0720072007200720 x9 : ffff80001132c014
[ 67.825137] x8 : ffff8000147677d8 x7 : ffff8000147677d7 x6 : 0000000000000000
[ 67.832341] x5 : 0000000000000001 x4 : ffff7000028ecefb x3 : 0000000000000001
[ 67.839544] x2 : 0000000000000005 x1 : 1abc001d4000018d x0 : d5e000ea00000c6d
[ 67.846748] Call trace:
[ 67.849218] ffs_data_clear+0x138/0x370 [usb_f_fs]
[ 67.854058] ffs_data_reset+0x20/0x304 [usb_f_fs]
[ 67.858810] ffs_data_closed+0x240/0x244 [usb_f_fs]
[ 67.863736] ffs_ep0_release+0x40/0x54 [usb_f_fs]
[ 67.868488] __fput+0x304/0x580
[ 67.871665] ____fput+0x18/0x24
[ 67.874837] task_work_run+0x104/0x180
[ 67.878622] do_notify_resume+0x458/0x14e0
[ 67.882754] work_pending+0xc/0x5f8
[ 67.886282] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
[ 67.892422] ---[ end trace 6d7cedf53d7abbea ]---
Segmentation fault
root@rcar-gen3:~#
==================================================================
Fixes: 4b187fceec3c ("usb: gadget: FunctionFS: add devices management code")
Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Fixes: cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst")
Reported-by: Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com>
Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Link: https://lore.kernel.org/r/20210603171507.22514-1-andrew_gabbasov@mentor.com
[agabbasov: Backported to earlier mount API, resolved context conflicts]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7423ca0c189d9ac53ed1c4d02d5454bebc9da8ad
Author: Nathan Chancellor <nathan@kernel.org>
Date: Fri May 28 11:27:52 2021 -0700
powerpc/barrier: Avoid collision with clang's __lwsync macro
commit 015d98149b326e0f1f02e44413112ca8b4330543 upstream.
A change in clang 13 results in the __lwsync macro being defined as
__builtin_ppc_lwsync, which emits 'lwsync' or 'msync' depending on what
the target supports. This breaks the build because of -Werror in
arch/powerpc, along with thousands of warnings:
In file included from arch/powerpc/kernel/pmc.c:12:
In file included from include/linux/bug.h:5:
In file included from arch/powerpc/include/asm/bug.h:109:
In file included from include/asm-generic/bug.h:20:
In file included from include/linux/kernel.h:12:
In file included from include/linux/bitops.h:32:
In file included from arch/powerpc/include/asm/bitops.h:62:
arch/powerpc/include/asm/barrier.h:49:9: error: '__lwsync' macro redefined [-Werror,-Wmacro-redefined]
#define __lwsync() __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :"memory")
^
<built-in>:308:9: note: previous definition is here
#define __lwsync __builtin_ppc_lwsync
^
1 error generated.
Undefine this macro so that the runtime patching introduced by
commit 2d1b2027626d ("powerpc: Fixup lwsync at runtime") continues to
work properly with clang and the build no longer breaks.
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://github.com/ClangBuiltLinux/linux/issues/1386
Link: https://github.com/llvm/llvm-project/commit/62b5df7fe2b3fda1772befeda15598fbef96a614
Link: https://lore.kernel.org/r/20210528182752.1852002-1-nathan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b6d3d1884fa31f701603772732c404020b0598d
Author: Davis Mosenkovs <davis@mosenkovs.lv>
Date: Sat Jul 10 21:37:10 2021 +0300
mac80211: fix memory corruption in EAPOL handling
Commit e3d4030498c3 ("mac80211: do not accept/forward invalid EAPOL
frames") uses skb_mac_header() before eth_type_trans() is called
leading to incorrect pointer, the pointer gets written to. This issue
has appeared during backporting to 4.4, 4.9 and 4.14.
Fixes: e3d4030498c3 ("mac80211: do not accept/forward invalid EAPOL frames")
Link: https://lore.kernel.org/r/CAHQn7pKcyC_jYmGyTcPCdk9xxATwW5QPNph=bsZV8d-HPwNsyA@mail.gmail.com
Cc: <stable@vger.kernel.org> # 4.4.x
Signed-off-by: Davis Mosenkovs <davis@mosenkovs.lv>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d172a77a790c1b755eed952ae0745c00c6fe3408
Author: Miklos Szeredi <mszeredi@redhat.com>
Date: Tue Jun 22 09:15:35 2021 +0200
fuse: reject internal errno
commit 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 upstream.
Don't allow userspace to report errors that could be kernel-internal.
Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
Fixes: 334f485df85a ("[PATCH] FUSE - device functions")
Cc: <stable@vger.kernel.org> # v2.6.14
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c801b7e6784c67bb2d7d5f4ba0c81d53cbbf1465
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Fri Oct 4 13:00:24 2019 +0300
bdi: Do not use freezable workqueue
commit a2b90f11217790ec0964ba9c93a4abb369758c26 upstream.
A removable block device, such as NVMe or SSD connected over Thunderbolt
can be hot-removed any time including when the system is suspended. When
device is hot-removed during suspend and the system gets resumed, kernel
first resumes devices and then thaws the userspace including freezable
workqueues. What happens in that case is that the NVMe driver notices
that the device is unplugged and removes it from the system. This ends
up calling bdi_unregister() for the gendisk which then schedules
wb_workfn() to be run one more time.
However, since the bdi_wq is still frozen flush_delayed_work() call in
wb_shutdown() blocks forever halting system resume process. User sees
this as hang as nothing is happening anymore.
Triggering sysrq-w reveals this:
Workqueue: nvme-wq nvme_remove_dead_ctrl_work [nvme]
Call Trace:
? __schedule+0x2c5/0x630
? wait_for_completion+0xa4/0x120
schedule+0x3e/0xc0
schedule_timeout+0x1c9/0x320
? resched_curr+0x1f/0xd0
? wait_for_completion+0xa4/0x120
wait_for_completion+0xc3/0x120
? wake_up_q+0x60/0x60
__flush_work+0x131/0x1e0
? flush_workqueue_prep_pwqs+0x130/0x130
bdi_unregister+0xb9/0x130
del_gendisk+0x2d2/0x2e0
nvme_ns_remove+0xed/0x110 [nvme_core]
nvme_remove_namespaces+0x96/0xd0 [nvme_core]
nvme_remove+0x5b/0x160 [nvme]
pci_device_remove+0x36/0x90
device_release_driver_internal+0xdf/0x1c0
nvme_remove_dead_ctrl_work+0x14/0x30 [nvme]
process_one_work+0x1c2/0x3f0
worker_thread+0x48/0x3e0
kthread+0x100/0x140
? current_work+0x30/0x30
? kthread_park+0x80/0x80
ret_from_fork+0x35/0x40
This is not limited to NVMes so exactly same issue can be reproduced by
hot-removing SSD (over Thunderbolt) while the system is suspended.
Prevent this from happening by removing WQ_FREEZABLE from bdi_wq.
Reported-by: AceLan Kao <acelan.kao@canonical.com>
Link: https://marc.info/?l=linux-kernel&m=138695698516487
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204385
Link: https://lore.kernel.org/lkml/20191002122136.GD2819@lahna.fi.intel.com/#t
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Macpaul Lin <macpaul.lin@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b921f9f4bfcbd084a4621a8d3b68907a457e9fa
Author: Eric Biggers <ebiggers@google.com>
Date: Thu May 27 16:52:36 2021 -0700
fscrypt: don't ignore minor_hash when hash is 0
commit 77f30bfcfcf484da7208affd6a9e63406420bf91 upstream.
When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the
minor_hash to 0 if the (major) hash is 0.
This doesn't make sense because 0 is a valid hash code, so we shouldn't
ignore the filesystem-provided minor_hash in that case. Fix this by
removing the special case for 'hash == 0'.
This is an old bug that appears to have originated when the encryption
code in ext4 and f2fs was moved into fs/crypto/. The original ext4 and
f2fs code passed the hash by pointer instead of by value. So
'if (hash)' actually made sense then, as it was checking whether a
pointer was NULL. But now the hashes are passed by value, and
filesystems just pass 0 for any hashes they don't have. There is no
need to handle this any differently from the hashes actually being 0.
It is difficult to reproduce this bug, as it only made a difference in
the case where a filename's 32-bit major hash happened to be 0.
However, it probably had the largest chance of causing problems on
ubifs, since ubifs uses minor_hash to do lookups of no-key names, in
addition to using it as a readdir cookie. ext4 only uses minor_hash as
a readdir cookie, and f2fs doesn't use minor_hash at all.
Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto")
Cc: <stable@vger.kernel.org> # v4.6+
Link: https://lore.kernel.org/r/20210527235236.2376556-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d890768c1ed6688ca5cd54ee37a69d90ea8c422f
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Mon Jun 28 16:13:42 2021 -0300
sctp: add size validation when walking chunks
[ Upstream commit 50619dbf8db77e98d821d615af4f634d08e22698 ]
The first chunk in a packet is ensured to be present at the beginning of
sctp_rcv(), as a packet needs to have at least 1 chunk. But the second
one, may not be completely available and ch->length can be over
uninitialized memory.
Fix here is by only trying to walk on the next chunk if there is enough to
hold at least the header, and then proceed with the ch->length validation
that is already there.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f01bfaea62d14938ff2fbeaf67f0afec2ec64ab9
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Mon Jun 28 16:13:41 2021 -0300
sctp: validate from_addr_param return
[ Upstream commit 0c5dc070ff3d6246d22ddd931f23a6266249e3db ]
Ilja reported that, simply putting it, nothing was validating that
from_addr_param functions were operating on initialized memory. That is,
the parameter itself was being validated by sctp_walk_params, but it
doesn't check for types and their specific sizes and it could be a 0-length
one, causing from_addr_param to potentially work over the next parameter or
even uninitialized memory.
The fix here is to, in all calls to from_addr_param, check if enough space
is there for the wanted IP address type.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bb8bdaeee0d85f0246a26620f4aea587c80391c3
Author: Tim Jiang <tjiang@codeaurora.org>
Date: Tue Jun 1 17:57:10 2021 +0800
Bluetooth: btusb: fix bt fiwmare downloading failure issue for qca btsoc.
[ Upstream commit 4f00bfb372674d586c4a261bfc595cbce101fbb6 ]
This is btsoc timing issue, after host start to downloading bt firmware,
ep2 need time to switch from function acl to function dfu, so host add
20ms delay as workaround.
Signed-off-by: Tim Jiang <tjiang@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 854e6d767a33bd53b00902d65dced7d1e7abfe1a
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Fri May 14 15:14:52 2021 +0800
Bluetooth: Shutdown controller after workqueues are flushed or cancelled
[ Upstream commit 0ea9fd001a14ebc294f112b0361a4e601551d508 ]
Rfkill block and unblock Intel USB Bluetooth [8087:0026] may make it
stops working:
[ 509.691509] Bluetooth: hci0: HCI reset during shutdown failed
[ 514.897584] Bluetooth: hci0: MSFT filter_enable is already on
[ 530.044751] usb 3-10: reset full-speed USB device number 5 using xhci_hcd
[ 545.660350] usb 3-10: device descriptor read/64, error -110
[ 561.283530] usb 3-10: device descriptor read/64, error -110
[ 561.519682] usb 3-10: reset full-speed USB device number 5 using xhci_hcd
[ 566.686650] Bluetooth: hci0: unexpected event for opcode 0x0500
[ 568.752452] Bluetooth: hci0: urb 0000000096cd309b failed to resubmit (113)
[ 578.797955] Bluetooth: hci0: Failed to read MSFT supported features (-110)
[ 586.286565] Bluetooth: hci0: urb 00000000c522f633 failed to resubmit (113)
[ 596.215302] Bluetooth: hci0: Failed to read MSFT supported features (-110)
Or kernel panics because other workqueues already freed skb:
[ 2048.663763] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 2048.663775] #PF: supervisor read access in kernel mode
[ 2048.663779] #PF: error_code(0x0000) - not-present page
[ 2048.663782] PGD 0 P4D 0
[ 2048.663787] Oops: 0000 [#1] SMP NOPTI
[ 2048.663793] CPU: 3 PID: 4491 Comm: rfkill Tainted: G W 5.13.0-rc1-next-20210510+ #20
[ 2048.663799] Hardware name: HP HP EliteBook 850 G8 Notebook PC/8846, BIOS T76 Ver. 01.01.04 12/02/2020
[ 2048.663801] RIP: 0010:__skb_ext_put+0x6/0x50
[ 2048.663814] Code: 8b 1b 48 85 db 75 db 5b 41 5c 5d c3 be 01 00 00 00 e8 de 13 c0 ff eb e7 be 02 00 00 00 e8 d2 13 c0 ff eb db 0f 1f 44 00 00 55 <8b> 07 48 89 e5 83 f8 01 74 14 b8 ff ff ff ff f0 0f c1
07 83 f8 01
[ 2048.663819] RSP: 0018:ffffc1d105b6fd80 EFLAGS: 00010286
[ 2048.663824] RAX: 0000000000000000 RBX: ffff9d9ac5649000 RCX: 0000000000000000
[ 2048.663827] RDX: ffffffffc0d1daf6 RSI: 0000000000000206 RDI: 0000000000000000
[ 2048.663830] RBP: ffffc1d105b6fd98 R08: 0000000000000001 R09: ffff9d9ace8ceac0
[ 2048.663834] R10: ffff9d9ace8ceac0 R11: 0000000000000001 R12: ffff9d9ac5649000
[ 2048.663838] R13: 0000000000000000 R14: 00007ffe0354d650 R15: 0000000000000000
[ 2048.663843] FS: 00007fe02ab19740(0000) GS:ffff9d9e5f8c0000(0000) knlGS:0000000000000000
[ 2048.663849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2048.663853] CR2: 0000000000000000 CR3: 0000000111a52004 CR4: 0000000000770ee0
[ 2048.663856] PKRU: 55555554
[ 2048.663859] Call Trace:
[ 2048.663865] ? skb_release_head_state+0x5e/0x80
[ 2048.663873] kfree_skb+0x2f/0xb0
[ 2048.663881] btusb_shutdown_intel_new+0x36/0x60 [btusb]
[ 2048.663905] hci_dev_do_close+0x48c/0x5e0 [bluetooth]
[ 2048.663954] ? __cond_resched+0x1a/0x50
[ 2048.663962] hci_rfkill_set_block+0x56/0xa0 [bluetooth]
[ 2048.664007] rfkill_set_block+0x98/0x170
[ 2048.664016] rfkill_fop_write+0x136/0x1e0
[ 2048.664022] vfs_write+0xc7/0x260
[ 2048.664030] ksys_write+0xb1/0xe0
[ 2048.664035] ? exit_to_user_mode_prepare+0x37/0x1c0
[ 2048.664042] __x64_sys_write+0x1a/0x20
[ 2048.664048] do_syscall_64+0x40/0xb0
[ 2048.664055] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 2048.664060] RIP: 0033:0x7fe02ac23c27
[ 2048.664066] Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[ 2048.664070] RSP: 002b:00007ffe0354d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2048.664075] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fe02ac23c27
[ 2048.664078] RDX: 0000000000000008 RSI: 00007ffe0354d650 RDI: 0000000000000003
[ 2048.664081] RBP: 0000000000000000 R08: 0000559b05998440 R09: 0000559b05998440
[ 2048.664084] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
[ 2048.664086] R13: 0000000000000000 R14: ffffffff00000000 R15: 00000000ffffffff
So move the shutdown callback to a place where workqueues are either
flushed or cancelled to resolve the issue.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d1bca43282eea61d10126ad4188475d116c90acd
Author: Yu Liu <yudiliu@google.com>
Date: Mon Apr 19 16:53:30 2021 -0700
Bluetooth: Fix the HCI to MGMT status conversion table
[ Upstream commit 4ef36a52b0e47c80bbfd69c0cce61c7ae9f541ed ]
0x2B, 0x31 and 0x33 are reserved for future use but were not present in
the HCI to MGMT conversion table, this caused the conversion to be
incorrect for the HCI status code greater than 0x2A.
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
Signed-off-by: Yu Liu <yudiliu@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e4e062da082a199357ba4911145f331d40139ad8
Author: Gerd Rausch <gerd.rausch@oracle.com>
Date: Thu Jun 24 11:55:31 2021 -0700
RDMA/cma: Fix rdma_resolve_route() memory leak
[ Upstream commit 74f160ead74bfe5f2b38afb4fcf86189f9ff40c9 ]
Fix a memory leak when "mda_resolve_route() is called more than once on
the same "rdma_cm_id".
This is possible if cma_query_handler() triggers the
RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and
allows rdma_resolve_route() to be called again.
Link: https://lore.kernel.org/r/f6662b7b-bdb7-2706-1e12-47c61d3474b6@oracle.com
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a95b0f5c444ebf755537ed5799135f0faf2f0920
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date: Thu Apr 22 15:00:32 2021 -0500
wireless: wext-spy: Fix out-of-bounds warning
[ Upstream commit e93bdd78406da9ed01554c51e38b2a02c8ef8025 ]
Fix the following out-of-bounds warning:
net/wireless/wext-spy.c:178:2: warning: 'memcpy' offset [25, 28] from the object at 'threshold' is out of the bounds of referenced subobject 'low' with type 'struct iw_quality' at offset 20 [-Warray-bounds]
The problem is that the original code is trying to copy data into a
couple of struct members adjacent to each other in a single call to
memcpy(). This causes a legitimate compiler warning because memcpy()
overruns the length of &threshold.low and &spydata->spy_thr_low. As
these are just a couple of struct members, fix this by using direct
assignments, instead of memcpy().
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210422200032.GA168995@embeddedor
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e8e3c44e20279d10ec84d2b86ecb32a7a1d63691
Author: Íñigo Huguet <ihuguet@redhat.com>
Date: Mon Jun 21 17:32:36 2021 +0200
sfc: error code if SRIOV cannot be disabled
[ Upstream commit 1ebe4feb8b442884f5a28d2437040096723dd1ea ]
If SRIOV cannot be disabled during device removal or module unloading,
return error code so it can be logged properly in the calling function.
Note that this can only happen if any VF is currently attached to a
guest using Xen, but not with vfio/KVM. Despite that in that case the
VFs won't work properly with PF removed and/or the module unloaded, I
have let it as is because I don't know what side effects may have
changing it, and also it seems to be the same that other drivers are
doing in this situation.
In the case of being called during SRIOV reconfiguration, the behavior
hasn't changed because the function is called with force=false.
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 708f19f1cb98f722b1a7ba235d8c97511e585346
Author: Íñigo Huguet <ihuguet@redhat.com>
Date: Mon Jun 21 17:32:35 2021 +0200
sfc: avoid double pci_remove of VFs
[ Upstream commit 45423cff1db66cf0993e8a9bd0ac93e740149e49 ]
If pci_remove was called for a PF with VFs, the removal of the VFs was
called twice from efx_ef10_sriov_fini: one directly with pci_driver->remove
and another implicit by calling pci_disable_sriov, which also perform
the VFs remove. This was leading to crashing the kernel on the second
attempt.
Given that pci_disable_sriov already calls to pci remove function, get
rid of the direct call to pci_driver->remove from the driver.
2 different ways to trigger the bug:
- Create one or more VFs, then attach the PF to a virtual machine (at
least with qemu/KVM)
- Create one or more VFs, then remove the PF with:
echo 1 > /sys/bus/pci/devices/PF_PCI_ID/remove
Removing sfc module does not trigger the error, at least for me, because
it removes the VF first, and then the PF.
Example of a log with the error:
list_del corruption, ffff967fd20a8ad0->next is LIST_POISON1 (dead000000000100)
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:47!
[...trimmed...]
RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c
[...trimmed...]
Call Trace:
efx_dissociate+0x1f/0x140 [sfc]
efx_pci_remove+0x27/0x150 [sfc]
pci_device_remove+0x3b/0xc0
device_release_driver_internal+0x103/0x1f0
pci_stop_bus_device+0x69/0x90
pci_stop_and_remove_bus_device+0xe/0x20
pci_iov_remove_virtfn+0xba/0x120
sriov_disable+0x2f/0xe0
efx_ef10_pci_sriov_disable+0x52/0x80 [sfc]
? pcie_aer_is_native+0x12/0x40
efx_ef10_sriov_fini+0x72/0x110 [sfc]
efx_pci_remove+0x62/0x150 [sfc]
pci_device_remove+0x3b/0xc0
device_release_driver_internal+0x103/0x1f0
unbind_store+0xf6/0x130
kernfs_fop_write+0x116/0x190
vfs_write+0xa5/0x1a0
ksys_write+0x4f/0xb0
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2b475438e691f14cba0886679135f610a1856caa
Author: Johannes Berg <johannes.berg@intel.com>
Date: Sat Jun 12 14:32:38 2021 +0300
iwlwifi: mvm: don't change band on bound PHY contexts
[ Upstream commit 8835a64f74c46baebfc946cd5a2c861b866ebcee ]
When we have a P2P Device active, we attempt to only change the
PHY context it uses when we get a new remain-on-channel, if the
P2P Device is the only user of the PHY context.
This is fine if we're switching within a band, but if we're
switching bands then the switch implies a removal and re-add
of the PHY context, which isn't permitted by the firmware while
it's bound to an interface.
Fix the code to skip the unbind/release/... cycle only if the
band doesn't change (or we have old devices that can switch the
band on the fly as well.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210612142637.e9ac313f70f3.I713b9d109957df7e7d9ed0861d5377ce3f8fccd3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 48c78097a146f04a056f63e893e20a547db6232f
Author: Xiao Yang <yangx.jy@fujitsu.com>
Date: Mon Jun 21 15:14:56 2021 +0800
RDMA/rxe: Don't overwrite errno from ib_umem_get()
[ Upstream commit 20ec0a6d6016aa28b9b3299be18baef1a0f91cd2 ]
rxe_mr_init_user() always returns the fixed -EINVAL when ib_umem_get()
fails so it's hard for user to know which actual error happens in
ib_umem_get(). For example, ib_umem_get() will return -EOPNOTSUPP when
trying to pin pages on a DAX file.
Return actual error as mlx4/mlx5 does.
Link: https://lore.kernel.org/r/20210621071456.4259-1-ice_yangxiao@163.com
Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 17069bfdc89adda7ba09fdc952eff20141956575
Author: Longpeng(Mike) <longpeng2@huawei.com>
Date: Mon Jun 21 14:26:01 2021 +0800
vsock: notify server to shutdown when client has pending signal
[ Upstream commit c7ff9cff70601ea19245d997bb977344663434c7 ]
The client's sk_state will be set to TCP_ESTABLISHED if the server
replay the client's connect request.
However, if the client has pending signal, its sk_state will be set
to TCP_CLOSE without notify the server, so the server will hold the
corrupt connection.
client server
1. sk_state=TCP_SYN_SENT |
2. call ->connect() |
3. wait reply |
| 4. sk_state=TCP_ESTABLISHED
| 5. insert to connected list
| 6. reply to the client
7. sk_state=TCP_ESTABLISHED |
8. insert to connected list |
9. *signal pending* <--------------------- the user kill client
10. sk_state=TCP_CLOSE |
client is exiting... |
11. call ->release() |
virtio_transport_close
if (!(sk->sk_state == TCP_ESTABLISHED ||
sk->sk_state == TCP_CLOSING))
return true; *return at here, the server cannot notice the connection is corrupt*
So the client should notify the peer in this case.
Cc: David S. Miller <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Jorgen Hansen <jhansen@vmware.com>
Cc: Norbert Slusarek <nslusarek@gmx.net>
Cc: Andra Paraschiv <andraprs@amazon.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: David Brazdil <dbrazdil@google.com>
Cc: Alexander Popov <alex.popov@linux.com>
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://lkml.org/lkml/2021/5/17/418
Signed-off-by: lixianming <lixianming5@huawei.com>
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d4fb1bd10f6ab2a7304317bee8e519603506a5f8
Author: Zheyu Ma <zheyuma97@gmail.com>
Date: Sun Jun 20 15:24:15 2021 +0000
atm: nicstar: register the interrupt handler in the right place
[ Upstream commit 70b639dc41ad499384e41e106fce72e36805c9f2 ]
Because the error handling is sequential, the application of resources
should be carried out in the order of error handling, so the operation
of registering the interrupt handler should be put in front, so as not
to free the unregistered interrupt handler during error handling.
This log reveals it:
[ 3.438724] Trying to free already-free IRQ 23
[ 3.439060] WARNING: CPU: 5 PID: 1 at kernel/irq/manage.c:1825 free_irq+0xfb/0x480
[ 3.440039] Modules linked in:
[ 3.440257] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.12.4-g70e7f0549188-dirty #142
[ 3.440793] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 3.441561] RIP: 0010:free_irq+0xfb/0x480
[ 3.441845] Code: 6e 08 74 6f 4d 89 f4 e8 c3 78 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 b4 78 09 00 8b 75 c8 48 c7 c7 a0 ac d5 85 e8 95 d7 f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 87 c5 90 03 48 8b 43 40 4c 8b a0 80
[ 3.443121] RSP: 0000:ffffc90000017b50 EFLAGS: 00010086
[ 3.443483] RAX: 0000000000000000 RBX: ffff888107c6f000 RCX: 0000000000000000
[ 3.443972] RDX: 0000000000000000 RSI: ffffffff8123f301 RDI: 00000000ffffffff
[ 3.444462] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000003
[ 3.444950] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 3.444994] R13: ffff888107dc0000 R14: ffff888104f6bf00 R15: ffff888107c6f0a8
[ 3.444994] FS: 0000000000000000(0000) GS:ffff88817bd40000(0000) knlGS:0000000000000000
[ 3.444994] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.444994] CR2: 0000000000000000 CR3: 000000000642e000 CR4: 00000000000006e0
[ 3.444994] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3.444994] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 3.444994] Call Trace:
[ 3.444994] ns_init_card_error+0x18e/0x250
[ 3.444994] nicstar_init_one+0x10d2/0x1130
[ 3.444994] local_pci_probe+0x4a/0xb0
[ 3.444994] pci_device_probe+0x126/0x1d0
[ 3.444994] ? pci_device_remove+0x100/0x100
[ 3.444994] really_probe+0x27e/0x650
[ 3.444994] driver_probe_device+0x84/0x1d0
[ 3.444994] ? mutex_lock_nested+0x16/0x20
[ 3.444994] device_driver_attach+0x63/0x70
[ 3.444994] __driver_attach+0x117/0x1a0
[ 3.444994] ? device_driver_attach+0x70/0x70
[ 3.444994] bus_for_each_dev+0xb6/0x110
[ 3.444994] ? rdinit_setup+0x40/0x40
[ 3.444994] driver_attach+0x22/0x30
[ 3.444994] bus_add_driver+0x1e6/0x2a0
[ 3.444994] driver_register+0xa4/0x180
[ 3.444994] __pci_register_driver+0x77/0x80
[ 3.444994] ? uPD98402_module_init+0xd/0xd
[ 3.444994] nicstar_init+0x1f/0x75
[ 3.444994] do_one_initcall+0x7a/0x3d0
[ 3.444994] ? rdinit_setup+0x40/0x40
[ 3.444994] ? rcu_read_lock_sched_held+0x4a/0x70
[ 3.444994] kernel_init_freeable+0x2a7/0x2f9
[ 3.444994] ? rest_init+0x2c0/0x2c0
[ 3.444994] kernel_init+0x13/0x180
[ 3.444994] ? rest_init+0x2c0/0x2c0
[ 3.444994] ? rest_init+0x2c0/0x2c0
[ 3.444994] ret_from_fork+0x1f/0x30
[ 3.444994] Kernel panic - not syncing: panic_on_warn set ...
[ 3.444994] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.12.4-g70e7f0549188-dirty #142
[ 3.444994] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 3.444994] Call Trace:
[ 3.444994] dump_stack+0xba/0xf5
[ 3.444994] ? free_irq+0xfb/0x480
[ 3.444994] panic+0x155/0x3ed
[ 3.444994] ? __warn+0xed/0x150
[ 3.444994] ? free_irq+0xfb/0x480
[ 3.444994] __warn+0x103/0x150
[ 3.444994] ? free_irq+0xfb/0x480
[ 3.444994] report_bug+0x119/0x1c0
[ 3.444994] handle_bug+0x3b/0x80
[ 3.444994] exc_invalid_op+0x18/0x70
[ 3.444994] asm_exc_invalid_op+0x12/0x20
[ 3.444994] RIP: 0010:free_irq+0xfb/0x480
[ 3.444994] Code: 6e 08 74 6f 4d 89 f4 e8 c3 78 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 b4 78 09 00 8b 75 c8 48 c7 c7 a0 ac d5 85 e8 95 d7 f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 87 c5 90 03 48 8b 43 40 4c 8b a0 80
[ 3.444994] RSP: 0000:ffffc90000017b50 EFLAGS: 00010086
[ 3.444994] RAX: 0000000000000000 RBX: ffff888107c6f000 RCX: 0000000000000000
[ 3.444994] RDX: 0000000000000000 RSI: ffffffff8123f301 RDI: 00000000ffffffff
[ 3.444994] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000003
[ 3.444994] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 3.444994] R13: ffff888107dc0000 R14: ffff888104f6bf00 R15: ffff888107c6f0a8
[ 3.444994] ? vprintk_func+0x71/0x110
[ 3.444994] ns_init_card_error+0x18e/0x250
[ 3.444994] nicstar_init_one+0x10d2/0x1130
[ 3.444994] local_pci_probe+0x4a/0xb0
[ 3.444994] pci_device_probe+0x126/0x1d0
[ 3.444994] ? pci_device_remove+0x100/0x100
[ 3.444994] really_probe+0x27e/0x650
[ 3.444994] driver_probe_device+0x84/0x1d0
[ 3.444994] ? mutex_lock_nested+0x16/0x20
[ 3.444994] device_driver_attach+0x63/0x70
[ 3.444994] __driver_attach+0x117/0x1a0
[ 3.444994] ? device_driver_attach+0x70/0x70
[ 3.444994] bus_for_each_dev+0xb6/0x110
[ 3.444994] ? rdinit_setup+0x40/0x40
[ 3.444994] driver_attach+0x22/0x30
[ 3.444994] bus_add_driver+0x1e6/0x2a0
[ 3.444994] driver_register+0xa4/0x180
[ 3.444994] __pci_register_driver+0x77/0x80
[ 3.444994] ? uPD98402_module_init+0xd/0xd
[ 3.444994] nicstar_init+0x1f/0x75
[ 3.444994] do_one_initcall+0x7a/0x3d0
[ 3.444994] ? rdinit_setup+0x40/0x40
[ 3.444994] ? rcu_read_lock_sched_held+0x4a/0x70
[ 3.444994] kernel_init_freeable+0x2a7/0x2f9
[ 3.444994] ? rest_init+0x2c0/0x2c0
[ 3.444994] kernel_init+0x13/0x180
[ 3.444994] ? rest_init+0x2c0/0x2c0
[ 3.444994] ? rest_init+0x2c0/0x2c0
[ 3.444994] ret_from_fork+0x1f/0x30
[ 3.444994] Dumping ftrace buffer:
[ 3.444994] (ftrace buffer empty)
[ 3.444994] Kernel Offset: disabled
[ 3.444994] Rebooting in 1 seconds..
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 482a27298390a437811dfd6a0baa8041650c1071
Author: Zheyu Ma <zheyuma97@gmail.com>
Date: Sun Jun 20 15:24:14 2021 +0000
atm: nicstar: use 'dma_free_coherent' instead of 'kfree'
[ Upstream commit 6a1e5a4af17e440dd82a58a2c5f40ff17a82b722 ]
When 'nicstar_init_one' fails, 'ns_init_card_error' will be executed for
error handling, but the correct memory free function should be used,
otherwise it will cause an error. Since 'card->rsq.org' and
'card->tsq.org' are allocated using 'dma_alloc_coherent' function, they
should be freed using 'dma_free_coherent'.
Fix this by using 'dma_free_coherent' instead of 'kfree'
This log reveals it:
[ 3.440294] kernel BUG at mm/slub.c:4206!
[ 3.441059] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 3.441430] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.12.4-g70e7f0549188-dirty #141
[ 3.441986] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 3.442780] RIP: 0010:kfree+0x26a/0x300
[ 3.443065] Code: e8 3a c3 b9 ff e9 d6 fd ff ff 49 8b 45 00 31 db a9 00 00 01 00 75 4d 49 8b 45 00 a9 00 00 01 00 75 0a 49 8b 45 08 a8 01 75 02 <0f> 0b 89 d9 b8 00 10 00 00 be 06 00 00 00 48 d3 e0 f7 d8 48 63 d0
[ 3.443396] RSP: 0000:ffffc90000017b70 EFLAGS: 00010246
[ 3.443396] RAX: dead000000000100 RBX: 0000000000000000 RCX: 0000000000000000
[ 3.443396] RDX: 0000000000000000 RSI: ffffffff85d3df94 RDI: ffffffff85df38e6
[ 3.443396] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000001
[ 3.443396] R10: 0000000000000000 R11: 0000000000000001 R12: ffff888107dc0000
[ 3.443396] R13: ffffea00001f0100 R14: ffff888101a8bf00 R15: ffff888107dc0160
[ 3.443396] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000
[ 3.443396] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.443396] CR2: 0000000000000000 CR3: 000000000642e000 CR4: 00000000000006e0
[ 3.443396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3.443396] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 3.443396] Call Trace:
[ 3.443396] ns_init_card_error+0x12c/0x220
[ 3.443396] nicstar_init_one+0x10d2/0x1130
[ 3.443396] local_pci_probe+0x4a/0xb0
[ 3.443396] pci_device_probe+0x126/0x1d0
[ 3.443396] ? pci_device_remove+0x100/0x100
[ 3.443396] really_probe+0x27e/0x650
[ 3.443396] driver_probe_device+0x84/0x1d0
[ 3.443396] ? mutex_lock_nested+0x16/0x20
[ 3.443396] device_driver_attach+0x63/0x70
[ 3.443396] __driver_attach+0x117/0x1a0
[ 3.443396] ? device_driver_attach+0x70/0x70
[ 3.443396] bus_for_each_dev+0xb6/0x110
[ 3.443396] ? rdinit_setup+0x40/0x40
[ 3.443396] driver_attach+0x22/0x30
[ 3.443396] bus_add_driver+0x1e6/0x2a0
[ 3.443396] driver_register+0xa4/0x180
[ 3.443396] __pci_register_driver+0x77/0x80
[ 3.443396] ? uPD98402_module_init+0xd/0xd
[ 3.443396] nicstar_init+0x1f/0x75
[ 3.443396] do_one_initcall+0x7a/0x3d0
[ 3.443396] ? rdinit_setup+0x40/0x40
[ 3.443396] ? rcu_read_lock_sched_held+0x4a/0x70
[ 3.443396] kernel_init_freeable+0x2a7/0x2f9
[ 3.443396] ? rest_init+0x2c0/0x2c0
[ 3.443396] kernel_init+0x13/0x180
[ 3.443396] ? rest_init+0x2c0/0x2c0
[ 3.443396] ? rest_init+0x2c0/0x2c0
[ 3.443396] ret_from_fork+0x1f/0x30
[ 3.443396] Modules linked in:
[ 3.443396] Dumping ftrace buffer:
[ 3.443396] (ftrace buffer empty)
[ 3.458593] ---[ end trace 3c6f8f0d8ef59bcd ]---
[ 3.458922] RIP: 0010:kfree+0x26a/0x300
[ 3.459198] Code: e8 3a c3 b9 ff e9 d6 fd ff ff 49 8b 45 00 31 db a9 00 00 01 00 75 4d 49 8b 45 00 a9 00 00 01 00 75 0a 49 8b 45 08 a8 01 75 02 <0f> 0b 89 d9 b8 00 10 00 00 be 06 00 00 00 48 d3 e0 f7 d8 48 63 d0
[ 3.460499] RSP: 0000:ffffc90000017b70 EFLAGS: 00010246
[ 3.460870] RAX: dead000000000100 RBX: 0000000000000000 RCX: 0000000000000000
[ 3.461371] RDX: 0000000000000000 RSI: ffffffff85d3df94 RDI: ffffffff85df38e6
[ 3.461873] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000001
[ 3.462372] R10: 0000000000000000 R11: 0000000000000001 R12: ffff888107dc0000
[ 3.462871] R13: ffffea00001f0100 R14: ffff888101a8bf00 R15: ffff888107dc0160
[ 3.463368] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000
[ 3.463949] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.464356] CR2: 0000000000000000 CR3: 000000000642e000 CR4: 00000000000006e0
[ 3.464856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3.465356] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 3.465860] Kernel panic - not syncing: Fatal exception
[ 3.466370] Dumping ftrace buffer:
[ 3.466616] (ftrace buffer empty)
[ 3.466871] Kernel Offset: disabled
[ 3.467122] Rebooting in 1 seconds..
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 920a42d8b854b1f112aef97a21f0549918889442
Author: Huang Pei <huangpei@loongson.cn>
Date: Fri Jun 11 15:09:46 2021 +0800
MIPS: add PMD table accounting into MIPS'pmd_alloc_one
[ Upstream commit ed914d48b6a1040d1039d371b56273d422c0081e ]
This fixes Page Table accounting bug.
MIPS is the ONLY arch just defining __HAVE_ARCH_PMD_ALLOC_ONE alone.
Since commit b2b29d6d011944 (mm: account PMD tables like PTE tables),
"pmd_free" in asm-generic with PMD table accounting and "pmd_alloc_one"
in MIPS without PMD table accounting causes PageTable accounting number
negative, which read by global_zone_page_state(), always returns 0.
Signed-off-by: Huang Pei <huangpei@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a1451ae057a7eb688d8e25d0c6224880e48e6bf4
Author: Zou Wei <zou_wei@huawei.com>
Date: Wed May 12 11:05:14 2021 +0800
cw1200: add missing MODULE_DEVICE_TABLE
[ Upstream commit dd778f89225cd258e8f0fed2b7256124982c8bb5 ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1620788714-14300-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0f6c0488368c9ac1aa685821916fadba32f5d1ef
Author: Lee Gibson <leegib@gmail.com>
Date: Wed Apr 28 12:55:08 2021 +0100
wl1251: Fix possible buffer overflow in wl1251_cmd_scan
[ Upstream commit d10a87a3535cce2b890897914f5d0d83df669c63 ]
Function wl1251_cmd_scan calls memcpy without checking the length.
Harden by checking the length is within the maximum allowed size.
Signed-off-by: Lee Gibson <leegib@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210428115508.25624-1-leegib@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6bb8e970546da4527963f3e49b362fa03d86ee81
Author: Tony Lindgren <tony@atomide.com>
Date: Thu Jun 3 09:28:14 2021 +0300
wlcore/wl12xx: Fix wl12xx get_mac error if device is in ELP
[ Upstream commit 11ef6bc846dcdce838f0b00c5f6a562c57e5d43b ]
At least on wl12xx, reading the MAC after boot can fail with a warning
at drivers/net/wireless/ti/wlcore/sdio.c:78 wl12xx_sdio_raw_read.
The failed call comes from wl12xx_get_mac() that wlcore_nvs_cb() calls
after request_firmware_work_func().
After the error, no wireless interface is created. Reloading the wl12xx
module makes the interface work.
Turns out the wlan controller can be in a low-power ELP state after the
boot from the bootloader or kexec, and needs to be woken up first.
Let's wake the hardware and add a sleep after that similar to
wl12xx_pre_boot() is already doing.
Note that a similar issue could exist for wl18xx, but I have not seen it
so far. And a search for wl18xx_get_mac and wl12xx_sdio_raw_read did not
produce similar errors.
Cc: Carl Philipp Klemm <philipp@uvos.xyz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210603062814.19464-1-tony@atomide.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5f33f7fde277b6b424bb386e221407e8ac1dc9c1
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon Jun 7 15:21:49 2021 +0200
xfrm: Fix error reporting in xfrm_state_construct.
[ Upstream commit 6fd06963fa74197103cdbb4b494763127b3f2f34 ]
When memory allocation for XFRMA_ENCAP or XFRMA_COADDR fails,
the error will not be reported because the -ENOMEM assignment
to the err variable is overwritten before. Fix this by moving
these two in front of the function so that memory allocation
failures will be reported.
Reported-by: Tobias Brunner <tobias@strongswan.org>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3531c1c2ae7d82d1dd59476db6efa4ab992fc183
Author: Minchan Kim <minchan@kernel.org>
Date: Wed Jun 9 09:37:17 2021 -0700
selinux: use __GFP_NOWARN with GFP_NOWAIT in the AVC
[ Upstream commit 648f2c6100cfa18e7dfe43bc0b9c3b73560d623c ]
In the field, we have seen lots of allocation failure from the call
path below.
06-03 13:29:12.999 1010315 31557 31557 W Binder : 31542_2: page allocation failure: order:0, mode:0x800(GFP_NOWAIT), nodemask=(null),cpuset=background,mems_allowed=0
...
...
06-03 13:29:12.999 1010315 31557 31557 W Call trace:
06-03 13:29:12.999 1010315 31557 31557 W : dump_backtrace.cfi_jt+0x0/0x8
06-03 13:29:12.999 1010315 31557 31557 W : dump_stack+0xc8/0x14c
06-03 13:29:12.999 1010315 31557 31557 W : warn_alloc+0x158/0x1c8
06-03 13:29:12.999 1010315 31557 31557 W : __alloc_pages_slowpath+0x9d8/0xb80
06-03 13:29:12.999 1010315 31557 31557 W : __alloc_pages_nodemask+0x1c4/0x430
06-03 13:29:12.999 1010315 31557 31557 W : allocate_slab+0xb4/0x390
06-03 13:29:12.999 1010315 31557 31557 W : ___slab_alloc+0x12c/0x3a4
06-03 13:29:12.999 1010315 31557 31557 W : kmem_cache_alloc+0x358/0x5e4
06-03 13:29:12.999 1010315 31557 31557 W : avc_alloc_node+0x30/0x184
06-03 13:29:12.999 1010315 31557 31557 W : avc_update_node+0x54/0x4f0
06-03 13:29:12.999 1010315 31557 31557 W : avc_has_extended_perms+0x1a4/0x460
06-03 13:29:12.999 1010315 31557 31557 W : selinux_file_ioctl+0x320/0x3d0
06-03 13:29:12.999 1010315 31557 31557 W : __arm64_sys_ioctl+0xec/0x1fc
06-03 13:29:12.999 1010315 31557 31557 W : el0_svc_common+0xc0/0x24c
06-03 13:29:12.999 1010315 31557 31557 W : el0_svc+0x28/0x88
06-03 13:29:12.999 1010315 31557 31557 W : el0_sync_handler+0x8c/0xf0
06-03 13:29:12.999 1010315 31557 31557 W : el0_sync+0x1a4/0x1c0
..
..
06-03 13:29:12.999 1010315 31557 31557 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:12.999 1010315 31557 31557 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:12.999 1010315 31557 31557 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:12.999 1010161 10686 10686 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:12.999 1010161 10686 10686 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:12.999 1010161 10686 10686 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:12.999 1010161 10686 10686 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:12.999 1010161 10686 10686 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:12.999 1010161 10686 10686 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:12.999 1010161 10686 10686 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:12.999 1010161 10686 10686 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:12.999 1010161 10686 10686 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:13.000 1010161 10686 10686 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:13.000 1010161 10686 10686 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:13.000 1010161 10686 10686 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:13.000 1010161 10686 10686 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:13.000 1010161 10686 10686 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:13.000 1010161 10686 10686 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:13.000 1010161 10686 10686 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:13.000 1010161 10686 10686 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:13.000 1010161 10686 10686 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:13.000 10230 30892 30892 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:13.000 10230 30892 30892 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
06-03 13:29:13.000 10230 30892 30892 W node 0 : slabs: 57, objs: 2907, free: 0
06-03 13:29:13.000 10230 30892 30892 W SLUB : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
06-03 13:29:13.000 10230 30892 30892 W cache : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
Based on [1], selinux is tolerate for failure of memory allocation.
Then, use __GFP_NOWARN together.
[1] 476accbe2f6e ("selinux: use GFP_NOWAIT in the AVC kmem_caches")
Signed-off-by: Minchan Kim <minchan@kernel.org>
[PM: subj fix, line wraps, normalized commit refs]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit aedf9cf2c15317b3621781a2b3f44e6e0ede5058
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Thu Jun 10 16:02:43 2021 +0800
fjes: check return value after calling platform_get_resource()
[ Upstream commit f18c11812c949553d2b2481ecaa274dd51bed1e7 ]
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 08851c9bb008734a1eddb2efa17f8f119e668c52
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Mon Jun 7 22:55:21 2021 +0800
net: micrel: check return value after calling platform_get_resource()
[ Upstream commit 20f1932e2282c58cb5ac59517585206cf5b385ae ]
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8a2f2eb04a21d1f99f2d1d3319fcf4ec1169c5b
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Mon Jun 7 21:38:37 2021 +0800
net: bcmgenet: check return value after calling platform_get_resource()
[ Upstream commit 74325bf0104573c6dfce42837139aeef3f34be76 ]
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8438287fb6dc93ef076fcf801bcbef66e827b65d
Author: Xianting Tian <xianting.tian@linux.alibaba.com>
Date: Sat Jun 5 11:31:00 2021 -0400
virtio_net: Remove BUG() to avoid machine dead
[ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ]
We should not directly BUG() when there is hdr error, it is
better to output a print when such error happens. Currently,
the caller of xmit_skb() already did it.
Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a70b5f2c5db89063c22adf7ea69a241c17eab4b2
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Apr 13 09:03:49 2021 +0100
dm space maps: don't reset space map allocation cursor when committing
[ Upstream commit 5faafc77f7de69147d1e818026b9a0cbf036a7b2 ]
Current commit code resets the place where the search for free blocks
will begin back to the start of the metadata device. There are a couple
of repercussions to this:
- The first allocation after the commit is likely to take longer than
normal as it searches for a free block in an area that is likely to
have very few free blocks (if any).
- Any free blocks it finds will have been recently freed. Reusing them
means we have fewer old copies of the metadata to aid recovery from
hardware error.
Fix these issues by leaving the cursor alone, only resetting when the
search hits the end of the metadata device.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8fc8bbfcc2eeed7b01548896b197436a85df996
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date: Tue Jun 1 19:07:49 2021 +0800
RDMA/cxgb4: Fix missing error code in create_qp()
[ Upstream commit aeb27bb76ad8197eb47890b1ff470d5faf8ec9a5 ]
The error code is missing in this code scenario so 0 will be returned. Add
the error code '-EINVAL' to the return value 'ret'.
Eliminates the follow smatch warning:
drivers/infiniband/hw/cxgb4/qp.c:298 create_qp() warn: missing error code 'ret'.
Link: https://lore.kernel.org/r/1622545669-20625-1-git-send-email-jiapeng.chong@linux.alibaba.com
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4b55d7b3106a410cdab4ea60f5e55ca0668c6a09
Author: Willy Tarreau <w@1wt.eu>
Date: Sat May 29 13:07:46 2021 +0200
ipv6: use prandom_u32() for ID generation
[ Upstream commit 62f20e068ccc50d6ab66fdb72ba90da2b9418c99 ]
This is a complement to commit aa6dd211e4b1 ("inet: use bigger hash
table for IP ID generation"), but focusing on some specific aspects
of IPv6.
Contary to IPv4, IPv6 only uses packet IDs with fragments, and with a
minimum MTU of 1280, it's much less easy to force a remote peer to
produce many fragments to explore its ID sequence. In addition packet
IDs are 32-bit in IPv6, which further complicates their analysis. On
the other hand, it is often easier to choose among plenty of possible
source addresses and partially work around the bigger hash table the
commit above permits, which leaves IPv6 partially exposed to some
possibilities of remote analysis at the risk of weakening some
protocols like DNS if some IDs can be predicted with a good enough
probability.
Given the wide range of permitted IDs, the risk of collision is extremely
low so there's no need to rely on the positive increment algorithm that
is shared with the IPv4 code via ip_idents_reserve(). We have a fast
PRNG, so let's simply call prandom_u32() and be done with it.
Performance measurements at 10 Gbps couldn't show any difference with
the previous code, even when using a single core, because due to the
large fragments, we're limited to only ~930 kpps at 10 Gbps and the cost
of the random generation is completely offset by other operations and by
the network transfer time. In addition, this change removes the need to
update a shared entry in the idents table so it may even end up being
slightly faster on large scale systems where this matters.
The risk of at least one collision here is about 1/80 million among
10 IDs, 1/850k among 100 IDs, and still only 1/8.5k among 1000 IDs,
which remains very low compared to IPv4 where all IDs are reused
every 4 to 80ms on a 10 Gbps flow depending on packet sizes.
Reported-by: Amit Klein <aksecurity@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20210529110746.6796-1-w@1wt.eu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit af23af93e89c5d79d9d6e5992fc388d7c385d774
Author: Dmitry Osipenko <digetx@gmail.com>
Date: Sun May 16 19:30:35 2021 +0300
clk: tegra: Ensure that PLLU configuration is applied properly
[ Upstream commit a7196048cd5168096c2c4f44a3939d7a6dcd06b9 ]
The PLLU (USB) consists of the PLL configuration itself and configuration
of the PLLU outputs. The PLLU programming is inconsistent on T30 vs T114,
where T114 immediately bails out if PLLU is enabled and T30 re-enables
a potentially already enabled PLL (left after bootloader) and then fully
reprograms it, which could be unsafe to do. The correct way should be to
skip enabling of the PLL if it's already enabled and then apply
configuration to the outputs. This patch doesn't fix any known problems,
it's a minor improvement.
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d1401c2c8482962a41d41eb164efe6e5a7f95ffb
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Thu May 27 13:36:38 2021 +0900
clk: renesas: r8a77995: Add ZA2 clock
[ Upstream commit 790c06cc5df263cdaff748670cc65958c81b0951 ]
R-Car D3 ZA2 clock is from PLL0D3 or S0,
and it can be controlled by ZA2CKCR.
It is needed for R-Car Sound, but is not used so far.
Using default settings is very enough at this point.
This patch adds it by DEF_FIXED().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pmxclrmy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 55950841137b796434cf60fc251431e5d3227192
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Thu Mar 25 17:38:24 2021 -0700
e100: handle eeprom as little endian
[ Upstream commit d4ef55288aa2e1b76033717242728ac98ddc4721 ]
Sparse tool was warning on some implicit conversions from
little endian data read from the EEPROM on the e100 cards.
Fix these by being explicit about the conversions using
le16_to_cpu().
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit baea588a42d675e35daeaddd10fbc9700550bc4d
Author: Arturo Giusti <koredump@protonmail.com>
Date: Tue May 18 12:34:57 2021 +0200
udf: Fix NULL pointer dereference in udf_symlink function
[ Upstream commit fa236c2b2d4436d9f19ee4e5d5924e90ffd7bb43 ]
In function udf_symlink, epos.bh is assigned with the value returned
by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c
and returns the value of sb_getblk function that could be NULL.
Then, epos.bh is used without any check, causing a possible
NULL pointer dereference when sb_getblk fails.
This fix adds a check to validate the value of epos.bh.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=213083
Signed-off-by: Arturo Giusti <koredump@protonmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4f058828dfc45cf26d34afe3e8869850f30ebc64
Author: Xie Yongji <xieyongji@bytedance.com>
Date: Mon May 17 16:49:12 2021 +0800
drm/virtio: Fix double free on probe failure
[ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ]
The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure.
But such failure will be caught by virtio_gpu_probe() and then
virtio_gpu_release() will be called to do some cleanup which
will free vgdev and vgdev->vbufs again. So let's set dev->dev_private
to NULL to avoid double free.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyongji@bytedance.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f565c1e7c80b6ba4fa641280a3260843230ae7b0
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Mon May 17 15:15:45 2021 +0300
reiserfs: add check for invalid 1st journal block
[ Upstream commit a149127be52fa7eaf5b3681a0317a2bbb772d5a9 ]
syzbot reported divide error in reiserfs.
The problem was in incorrect journal 1st block.
Syzbot's reproducer manualy generated wrong superblock
with incorrect 1st block. In journal_init() wasn't
any checks about this particular case.
For example, if 1st journal block is before superblock
1st block, it can cause zeroing important superblock members
in do_journal_end().
Link: https://lore.kernel.org/r/20210517121545.29645-1-paskripkin@gmail.com
Reported-by: syzbot+0ba9909df31c6a36974d@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a5f688a13a9c7e6cc05fbd5786d8f6817b13f48c
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed May 12 23:43:24 2021 +0200
net: Treat __napi_schedule_irqoff() as __napi_schedule() on PREEMPT_RT
[ Upstream commit 8380c81d5c4fced6f4397795a5ae65758272bbfd ]
__napi_schedule_irqoff() is an optimized version of __napi_schedule()
which can be used where it is known that interrupts are disabled,
e.g. in interrupt-handlers, spin_lock_irq() sections or hrtimer
callbacks.
On PREEMPT_RT enabled kernels this assumptions is not true. Force-
threaded interrupt handlers and spinlocks are not disabling interrupts
and the NAPI hrtimer callback is forced into softirq context which runs
with interrupts enabled as well.
Chasing all usage sites of __napi_schedule_irqoff() is a whack-a-mole
game so make __napi_schedule_irqoff() invoke __napi_schedule() for
PREEMPT_RT kernels.
The callers of ____napi_schedule() in the networking core have been
audited and are correct on PREEMPT_RT kernels as well.
Reported-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c471569632654e57c83512e0fc1ba0dbb4544ad6
Author: Zou Wei <zou_wei@huawei.com>
Date: Wed May 12 15:00:24 2021 +0800
atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
[ Upstream commit 34e7434ba4e97f4b85c1423a59b2922ba7dff2ea ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7867ddc5f3de7f289aee63233afc0df4b62834c5
Author: Zou Wei <zou_wei@huawei.com>
Date: Tue May 11 14:58:53 2021 +0800
mISDN: fix possible use-after-free in HFC_cleanup()
[ Upstream commit 009fc857c5f6fda81f2f7dd851b2d54193a8e733 ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bcdd2be48edd8c6867fb44112cb8d18086beae29
Author: Zou Wei <zou_wei@huawei.com>
Date: Tue May 11 14:53:36 2021 +0800
atm: iphase: fix possible use-after-free in ia_module_exit()
[ Upstream commit 1c72e6ab66b9598cac741ed397438a52065a8f1f ]
This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 899cb83e647f6d2dd213a228d2d09fce20ec7dc2
Author: Bibo Mao <maobibo@loongson.cn>
Date: Mon Jun 29 21:15:32 2020 +0800
hugetlb: clear huge pte during flush function on mips platform
[ Upstream commit 33ae8f801ad8bec48e886d368739feb2816478f2 ]
If multiple threads are accessing the same huge page at the same
time, hugetlb_cow will be called if one thread write the COW huge
page. And function huge_ptep_clear_flush is called to notify other
threads to clear the huge pte tlb entry. The other threads clear
the huge pte tlb entry and reload it from page table, the reload
huge pte entry may be old.
This patch fixes this issue on mips platform, and it clears huge
pte entry before notifying other threads to flush current huge
page entry, it is similar with other architectures.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9a513bc9ec91fb0d2e0489eff03d8da44d54ac0b
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon May 10 19:39:30 2021 +0300
net: pch_gbe: Use proper accessors to BE data in pch_ptp_match()
[ Upstream commit 443ef39b499cc9c6635f83238101f1bb923e9326 ]
Sparse is not happy about handling of strict types in pch_ptp_match():
.../pch_gbe_main.c:158:33: warning: incorrect type in argument 2 (different base types)
.../pch_gbe_main.c:158:33: expected unsigned short [usertype] uid_hi
.../pch_gbe_main.c:158:33: got restricted __be16 [usertype]
.../pch_gbe_main.c:158:45: warning: incorrect type in argument 3 (different base types)
.../pch_gbe_main.c:158:45: expected unsigned int [usertype] uid_lo
.../pch_gbe_main.c:158:45: got restricted __be32 [usertype]
.../pch_gbe_main.c:158:56: warning: incorrect type in argument 4 (different base types)
.../pch_gbe_main.c:158:56: expected unsigned short [usertype] seqid
.../pch_gbe_main.c:158:56: got restricted __be16 [usertype]
Fix that by switching to use proper accessors to BE data.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Flavio Suligoi <f.suligoi@asem.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 46203c865e82e93d40ac2989c43dedb8418ed71d
Author: Jack Zhang <Jack.Zhang1@amd.com>
Date: Tue Apr 27 17:08:47 2021 +0800
drm/amd/amdgpu/sriov disable all ip hw status by default
[ Upstream commit 95ea3dbc4e9548d35ab6fbf67675cef8c293e2f5 ]
Disable all ip's hw status to false before any hw_init.
Only set it to true until its hw_init is executed.
The old 5.9 branch has this change but somehow the 5.11 kernrel does
not have this fix.
Without this change, sriov tdr have gfx IB test fail.
Signed-off-by: Jack Zhang <Jack.Zhang1@amd.com>
Review-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 40824c0966d5024d485bfa7aaa68041498e5920a
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Thu Apr 15 13:00:39 2021 +0200
drm/zte: Don't select DRM_KMS_FB_HELPER
[ Upstream commit a50e74bec1d17e95275909660c6b43ffe11ebcf0 ]
Selecting DRM_FBDEV_EMULATION will include the correct settings for
fbdev emulation. Drivers should not override this.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210415110040.23525-4-tzimmermann@suse.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit fb3518b8113456af53384e48b8c2e4934d5ccd7f
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Thu Apr 15 13:00:38 2021 +0200
drm/mxsfb: Don't select DRM_KMS_FB_HELPER
[ Upstream commit 13b29cc3a722c2c0bc9ab9f72f9047d55d08a2f9 ]
Selecting DRM_FBDEV_EMULATION will include the correct settings for
fbdev emulation. Drivers should not override this.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Stefan Agner <stefan@agner.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210415110040.23525-3-tzimmermann@suse.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 548f2f39bd9d4f0a83bc1b29ab3e637b2cf83f1a
Author: Quat Le <quat.le@oracle.com>
Date: Tue Jun 29 08:58:26 2021 -0700
scsi: core: Retry I/O for Notify (Enable Spinup) Required error
commit 104739aca4488909175e9e31d5cd7d75b82a2046 upstream.
If the device is power-cycled, it takes time for the initiator to transmit
the periodic NOTIFY (ENABLE SPINUP) SAS primitive, and for the device to
respond to the primitive to become ACTIVE. Retry the I/O request to allow
the device time to become ACTIVE.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210629155826.48441-1-quat.le@oracle.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Quat Le <quat.le@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8e96ff655b2f52e7c36dd0bb985e70b180000fab
Author: Johan Hovold <johan@kernel.org>
Date: Fri May 21 15:30:26 2021 +0200
mmc: vub3000: fix control-request direction
commit 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 upstream.
The direction of the pipe argument must match the request-type direction
bit or control requests may fail depending on the host-controller-driver
implementation.
Fix the SET_ROM_WAIT_STATES request which erroneously used
usb_rcvctrlpipe().
Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
Cc: stable@vger.kernel.org # 3.0
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210521133026.17296-1-johan@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c59680b9281e1f7f7717cd071a4df3b1c553214a
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date: Wed Jun 30 18:56:53 2021 -0700
selftests/vm/pkeys: fix alloc_random_pkey() to make it really, really random
[ Upstream commit f36ef407628835a7d7fb3d235b1f1aac7022d9a3 ]
Patch series "selftests/vm/pkeys: Bug fixes and a new test".
There has been a lot of activity on the x86 front around the XSAVE
architecture which is used to context-switch processor state (among other
things). In addition, AMD has recently joined the protection keys club by
adding processor support for PKU.
The AMD implementation helped uncover a kernel bug around the PKRU "init
state", which actually applied to Intel's implementation but was just
harder to hit. This series adds a test which is expected to help find
this class of bug both on AMD and Intel. All the work around pkeys on x86
also uncovered a few bugs in the selftest.
This patch (of 4):
The "random" pkey allocation code currently does the good old:
srand((unsigned int)time(NULL));
*But*, it unfortunately does this on every random pkey allocation.
There may be thousands of these a second. time() has a one second
resolution. So, each time alloc_random_pkey() is called, the PRNG is
*RESET* to time(). This is nasty. Normally, if you do:
srand(<ANYTHING>);
foo = rand();
bar = rand();
You'll be quite guaranteed that 'foo' and 'bar' are different. But, if
you do:
srand(1);
foo = rand();
srand(1);
bar = rand();
You are quite guaranteed that 'foo' and 'bar' are the *SAME*. The recent
"fix" effectively forced the test case to use the same "random" pkey for
the whole test, unless the test run crossed a second boundary.
Only run srand() once at program startup.
This explains some very odd and persistent test failures I've been seeing.
Link: https://lkml.kernel.org/r/20210611164153.91B76FB8@viggo.jf.intel.com
Link: https://lkml.kernel.org/r/20210611164155.192D00FF@viggo.jf.intel.com
Fixes: 6e373263ce07 ("selftests/vm/pkeys: fix alloc_random_pkey() to make it really random")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: "Desnes A. Nunes do Rosario" <desnesn@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Michal Suchanek <msuchanek@suse.de>
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6f10741b1366bafc510297fe18bd08344d768ecb
Author: Miaohe Lin <linmiaohe@huawei.com>
Date: Wed Jun 30 18:47:57 2021 -0700
mm/huge_memory.c: don't discard hugepage if other processes are mapping it
[ Upstream commit babbbdd08af98a59089334eb3effbed5a7a0cf7f ]
If other processes are mapping any other subpages of the hugepage, i.e.
in pte-mapped thp case, page_mapcount() will return 1 incorrectly. Then
we would discard the page while other processes are still mapping it. Fix
it by using total_mapcount() which can tell whether other processes are
still mapping it.
Link: https://lkml.kernel.org/r/20210511134857.1581273-6-linmiaohe@huawei.com
Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called")
Reviewed-by: Yang Shi <shy828301@gmail.com>
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2d9cb13c8ca644cedd377cab23404d05ce0335a1
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Fri May 21 13:21:01 2021 +0200
leds: ktd2692: Fix an error handling path
[ Upstream commit ee78b9360e14c276f5ceaa4a0d06f790f04ccdad ]
In 'ktd2692_parse_dt()', if an error occurs after a successful
'regulator_enable()' call, we should call 'regulator_enable()'.
This is the same in 'ktd2692_probe()', if an error occurs after a
successful 'ktd2692_parse_dt()' call.
Instead of adding 'regulator_enable()' in several places, implement a
resource managed solution and simplify the remove function accordingly.
Fixes: b7da8c5c725c ("leds: Add ktd2692 flash LED driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit fef8843d6f42e599660abb1bfb7e2d1c4d0ec39c
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Sat May 15 11:06:46 2021 +0800
leds: as3645a: Fix error return code in as3645a_parse_node()
[ Upstream commit 96a30960a2c5246c8ffebe8a3c9031f9df094d97 ]
Return error code -ENODEV rather than '0' when the indicator node can not
be found.
Fixes: a56ba8fbcb55 ("media: leds: as3645a: Add LED flash class driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bb16947765c0e7c43033b28463b66f4f6f86491c
Author: Chung-Chiang Cheng <shepjeng@gmail.com>
Date: Fri Jun 18 15:59:25 2021 +0800
configfs: fix memleak in configfs_release_bin_file
[ Upstream commit 3c252b087de08d3cb32468b54a158bd7ad0ae2f7 ]
When reading binary attributes in progress, buffer->bin_buffer is setup in
configfs_read_bin_file() but never freed.
Fixes: 03607ace807b4 ("configfs: implement binary attributes")
Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
[hch: move the vfree rather than duplicating it]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d879f75daf659bac6f1e8962e754dada4fab7150
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Fri Apr 23 22:46:24 2021 +0200
extcon: max8997: Add missing modalias string
[ Upstream commit dc11fc2991e9efbceef93912b83e333d2835fb19 ]
The platform device driver name is "max8997-muic", so advertise it
properly in the modalias string. This fixes automated module loading when
this driver is compiled as a module.
Fixes: b76668ba8a77 ("Extcon: add MAX8997 extcon driver")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 01c171a53e5872a62cb6a198387c5de344fededf
Author: Stephan Gerhold <stephan@gerhold.net>
Date: Mon May 31 15:34:35 2021 +0200
extcon: sm5502: Drop invalid register write in sm5502_reg_data
[ Upstream commit d25b224f8e5507879b36a769a6d1324cf163466c ]
When sm5502_init_dev_type() iterates over sm5502_reg_data to
initialize the registers it is limited by ARRAY_SIZE(sm5502_reg_data).
There is no need to add another empty element to sm5502_reg_data.
Having the additional empty element in sm5502_reg_data will just
result in writing 0xff to register 0x00, which does not really
make sense.
Fixes: 914b881f9452 ("extcon: sm5502: Add support new SM5502 extcon device driver")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5ea99a3596474d565cc86334c0184993a6524a3b
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sat Jun 5 15:17:43 2021 +0200
phy: ti: dm816x: Fix the error handling path in 'dm816x_usb_phy_probe()
[ Upstream commit f7eedcb8539ddcbb6fe7791f1b4ccf43f905c72f ]
Add an error handling path in the probe to release some resources, as
already done in the remove function.
Fixes: 609adde838f4 ("phy: Add a driver for dm816x USB PHY")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/ac5136881f6bdec50be19b3bf73b3bc1b15ef1f1.1622898974.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 815dd4a66a5f9d09b78604ee2381e70c26155f9b
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Fri May 14 16:13:00 2021 +0800
scsi: mpt3sas: Fix error return value in _scsih_expander_add()
[ Upstream commit d6c2ce435ffe23ef7f395ae76ec747414589db46 ]
When an expander does not contain any 'phys', an appropriate error code -1
should be returned, as done elsewhere in this function. However, we
currently do not explicitly assign this error code to 'rc'. As a result, 0
was incorrectly returned.
Link: https://lore.kernel.org/r/20210514081300.6650-1-thunder.leizhen@huawei.com
Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8e0b5577822656e736d6a72e61f1e1251f7ebd38
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed Jun 16 11:27:44 2021 +0200
of: Fix truncation of memory sizes on 32-bit platforms
[ Upstream commit 2892d8a00d23d511a0591ac4b2ff3f050ae1f004 ]
Variable "size" has type "phys_addr_t", which can be either 32-bit or
64-bit on 32-bit systems, while "unsigned long" is always 32-bit on
32-bit systems. Hence the cast in
(unsigned long)size / SZ_1M
may truncate a 64-bit size to 32-bit, as casts have a higher operator
precedence than divisions.
Fix this by inverting the order of the cast and division, which should
be safe for memory blocks smaller than 4 PiB. Note that the division is
actually a shift, as SZ_1M is a power-of-two constant, hence there is no
need to use div_u64().
While at it, use "%lu" to format "unsigned long".
Fixes: e8d9d1f5485b52ec ("drivers: of: add initialization code for static reserved memory")
Fixes: 3f0c8206644836e4 ("drivers: of: add initialization code for dynamic reserved memory")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 737848185b0879605d359f24a19e152eb350c975
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Wed Jun 16 14:56:04 2021 +0100
ASoC: cs42l42: Correct definition of CS42L42_ADC_PDN_MASK
[ Upstream commit fac165f22ac947b55407cd3a60a2a9824f905235 ]
The definition of CS42L42_ADC_PDN_MASK was incorrectly defined
as the HP_PDN bit.
Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210616135604.19363-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f285d626756b300269ff13b260c599b977f88a86
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Jun 14 12:58:36 2021 +0300
staging: gdm724x: check for overflow in gdm_lte_netif_rx()
[ Upstream commit 7002b526f4ff1f6da34356e67085caafa6be383a ]
This code assumes that "len" is at least 62 bytes, but we need a check
to prevent a read overflow.
Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YMcoTPsCYlhh2TQo@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f5da82bdfca230a13126b2241e18dfd2200c46b1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Jun 14 12:55:35 2021 +0300
staging: gdm724x: check for buffer overflow in gdm_lte_multi_sdu_pkt()
[ Upstream commit 4a36e160856db8a8ddd6a3d2e5db5a850ab87f82 ]
There needs to be a check to verify that we don't read beyond the end
of "buf". This function is called from do_rx(). The "buf" is the USB
transfer_buffer and "len" is "urb->actual_length".
Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YMcnl4zCwGWGDVMG@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 93bafb30949fe65ed6722b27c5bcbc249287e936
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sun Jun 13 16:22:56 2021 +0100
iio: adc: mxs-lradc: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 6a6be221b8bd561b053f0701ec752a5ed9007f69 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Add a comment on why the buffer is the size it is as not immediately
obvious.
Found during an audit of all calls of this function.
Fixes: 6dd112b9f85e ("iio: adc: mxs-lradc: Add support for ADC driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210613152301.571002-4-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7e557474ea40a6aca506b368ae2834e2aa02c5f8
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Tue Jun 8 01:17:55 2021 +0300
eeprom: idt_89hpesx: Put fwnode in matching case during ->probe()
[ Upstream commit 3f6ee1c095156a74ab2df605af13020f1ce3e600 ]
device_get_next_child_node() bumps a reference counting of a returned variable.
We have to balance it whenever we return to the caller.
Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing")
Cc: Huy Duong <qhuyduong@hotmail.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210607221757.81465-1-andy.shevchenko@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit eb04cb6b3dc75f0306f47465d11216c7c5ba07a5
Author: Randy Dunlap <rdunlap@infradead.org>
Date: Thu May 27 17:24:20 2021 -0700
s390: appldata depends on PROC_SYSCTL
[ Upstream commit 5d3516b3647621d5a1180672ea9e0817fb718ada ]
APPLDATA_BASE should depend on PROC_SYSCTL instead of PROC_FS.
Building with PROC_FS but not PROC_SYSCTL causes a build error,
since appldata_base.c uses data and APIs from fs/proc/proc_sysctl.c.
arch/s390/appldata/appldata_base.o: in function `appldata_generic_handler':
appldata_base.c:(.text+0x192): undefined reference to `sysctl_vals'
Fixes: c185b783b099 ("[S390] Remove config options.")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Link: https://lore.kernel.org/r/20210528002420.17634-1-rdunlap@infradead.org
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ab4f0b8019184e440e015d48d109fdc973af59f6
Author: Randy Dunlap <rdunlap@infradead.org>
Date: Sat May 29 16:48:57 2021 -0700
scsi: FlashPoint: Rename si_flags field
[ Upstream commit 4d431153e751caa93f3b7e6f6313446974e92253 ]
The BusLogic driver has build errors on ia64 due to a name collision (in
the #included FlashPoint.c file). Rename the struct field in struct
sccb_mgr_info from si_flags to si_mflags (manager flags) to mend the build.
This is the first problem. There are 50+ others after this one:
In file included from ../include/uapi/linux/signal.h:6,
from ../include/linux/signal_types.h:10,
from ../include/linux/sched.h:29,
from ../include/linux/hardirq.h:9,
from ../include/linux/interrupt.h:11,
from ../drivers/scsi/BusLogic.c:27:
../arch/ia64/include/uapi/asm/siginfo.h:15:27: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token
15 | #define si_flags _sifields._sigfault._flags
| ^
../drivers/scsi/FlashPoint.c:43:6: note: in expansion of macro 'si_flags'
43 | u16 si_flags;
| ^~~~~~~~
In file included from ../drivers/scsi/BusLogic.c:51:
../drivers/scsi/FlashPoint.c: In function 'FlashPoint_ProbeHostAdapter':
../drivers/scsi/FlashPoint.c:1076:11: error: 'struct sccb_mgr_info' has no member named '_sifields'
1076 | pCardInfo->si_flags = 0x0000;
| ^~
../drivers/scsi/FlashPoint.c:1079:12: error: 'struct sccb_mgr_info' has no member named '_sifields'
Link: https://lore.kernel.org/r/20210529234857.6870-1-rdunlap@infradead.org
Fixes: 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit.")
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Khalid Aziz <khalid.aziz@oracle.com>
Cc: Khalid Aziz <khalid@gonehiking.org>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e71799b1ed1b4955cf0c7ffe753f75d739886c56
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Tue May 25 20:51:57 2021 +0200
tty: nozomi: Fix the error handling path of 'nozomi_card_init()'
[ Upstream commit 6ae7d0f5a92b9619f6e3c307ce56b2cefff3f0e9 ]
The error handling path is broken and we may un-register things that have
never been registered.
Update the loops index accordingly.
Fixes: 9842c38e9176 ("kfifo: fix warn_unused_result")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/e28c2e92c7475da25b03d022ea2d6dcf1ba807a2.1621968629.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 91415679fa1c1885fa09d1522164c9d0c2bad256
Author: Yu Kuai <yukuai3@huawei.com>
Date: Fri May 21 20:06:17 2021 +0800
char: pcmcia: error out if 'num_bytes_read' is greater than 4 in set_protocol()
[ Upstream commit 37188559c610f1b7eec83c8e448936c361c578de ]
Theoretically, it will cause index out of bounds error if
'num_bytes_read' is greater than 4. As we expect it(and was tested)
never to be greater than 4, error out if it happens.
Fixes: c1986ee9bea3 ("[PATCH] New Omnikey Cardman 4000 driver")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20210521120617.138396-1-yukuai3@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 702ac1c1dc0ed1e709f3719ef6cf4a1663323601
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Mon May 24 11:52:42 2021 -0700
Input: hil_kbd - fix error return code in hil_dev_connect()
[ Upstream commit d9b576917a1d0efa293801a264150a1b37691617 ]
Return error code -EINVAL rather than '0' when the combo devices are not
supported.
Fixes: fa71c605c2bb ("Input: combine hil_kbd and hil_ptr drivers")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210515030053.6824-1-thunder.leizhen@huawei.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7f79b35a843f2e7c86a07d9d0b9878018ad22f04
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Tue May 18 12:45:14 2021 +0800
ASoC: hisilicon: fix missing clk_disable_unprepare() on error in hi6210_i2s_startup()
[ Upstream commit 375904e3931955fcf0a847f029b2492a117efc43 ]
After calling clk_prepare_enable(), clk_disable_unprepare() need
be called when calling clk_set_rate() failed.
Fixes: 0bf750f4cbe1 ("ASoC: hisilicon: Add hi6210 i2s audio driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210518044514.607010-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4ad4a3629d9c4a201aa091d219a6c11c3e6ac028
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:13:48 2021 +0100
iio: potentiostat: lmp91000: Fix alignment of buffer in iio_push_to_buffers_with_timestamp()
[ Upstream commit 8979b67ec61abc232636400ee8c758a16a73c95f ]
Add __aligned(8) to ensure the buffer passed to
iio_push_to_buffers_with_timestamp() is suitable for the naturally
aligned timestamp that will be inserted.
Here structure is not used, because this buffer is also used
elsewhere in the driver.
Fixes: 67e17300dc1d ("iio: potentiostat: add LMP91000 support")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Link: https://lore.kernel.org/r/20210501171352.512953-8-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c443f2240d103b8ac6ad95e6310786453301033d
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:20 2021 +0100
iio: light: tcs3414: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit ff08fbc22ab32ccc6690c21b0e5e1d402dcc076f ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: a244e7b57f0f ("iio: Add driver for AMS/TAOS tcs3414 digital color sensor")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-19-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2234430403d760cdb4ba8784be68eca0f9553a00
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:19 2021 +0100
iio: light: isl29125: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 3d4725194de6935dba2ad7c9cc075c885008f747 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: 6c25539cbc46 ("iio: Add Intersil isl29125 digital color light sensor driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-18-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cb711041690a071ef510437e6654014a1ba16717
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:16 2021 +0100
iio: prox: as3935: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 37eb8d8c64f2ecb3a5521ba1cc1fad973adfae41 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: 37b1ba2c68cf ("iio: proximity: as3935: fix buffer stack trashing")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-15-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ec27cb64bb034a4b64f22ae8c5567fcbc2dbd04a
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:15 2021 +0100
iio: prox: pulsed-light: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 679cc377a03ff1944491eafc7355c1eb1fad4109 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: cb119d535083 ("iio: proximity: add support for PulsedLight LIDAR")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-14-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7514ea6cc0de7a6df75969b01b31018fa7ab50b0
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:14 2021 +0100
iio: prox: srf08: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 19f1a254fe4949fff1e67db386409f48cf438bd7 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: 78f839029e1d ("iio: distance: srf08: add IIO driver for us ranger")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-13-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2984d01b35ef8a5b41b3668c08df5ee2dbeebaca
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:13 2021 +0100
iio: humidity: am2315: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit f4ca2e2595d9fee65d5ce0d218b22ce00e5b2915 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: 0d96d5ead3f7 ("iio: humidity: Add triggered buffer support for AM2315")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-12-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 262e1581a330c321854efb6e6ade833978915d47
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:12 2021 +0100
iio: gyro: bmg160: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 06778d881f3798ce93ffbbbf801234292250b598 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: 13426454b649 ("iio: bmg160: Separate i2c and core driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-11-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 84bec6601c2058486340b508fa9176dc1dfa8cdd
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:11 2021 +0100
iio: adc: vf610: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 7765dfaa22ea08abf0c175e7553826ba2a939632 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of uses of
iio_push_to_buffers_with_timestamp()
Fixes: 0010d6b44406 ("iio: adc: vf610: Add IIO buffer support for Vybrid ADC")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
Cc: Sanchayan Maity <maitysanchayan@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-10-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ce2f42f6b6a9bb4eae240334e7dc021a4ebb66b6
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:10 2021 +0100
iio: adc: ti-ads1015: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit d85d71dd1ab67eaa7351f69fec512d8f09d164e1 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Daniel Baluta <daniel.baluta@nxp.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-9-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 354558d25a803aef57d100fe9dd45512c78c6880
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:09 2021 +0100
iio: accel: stk8ba50: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 334883894bc1e145a1e0f5de1b0d1b6a1133f0e6 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: db6a19b8251f ("iio: accel: Add trigger support for STK8BA50")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-8-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 800dc3dc35063a591782b7aa220a5e61c0dc6580
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:08 2021 +0100
iio: accel: stk8312: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit f40a71ffec808e7e51848f63f0c0d3c32d65081b ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: 95c12bba51c3 ("iio: accel: Add buffer mode for Sensortek STK8312")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-7-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 89f252cbe6f0db128903ac7d0096fcf06f18a1c4
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:06 2021 +0100
iio: accel: kxcjk-1013: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 3ab3aa2e7bd57497f9a7c6275c00dce237d2c9ba ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: 1a4fbf6a9286 ("iio: accel: kxcjk1013 3-axis accelerometer driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-5-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6a890c76e37b387332aa1f9db4d31f8a591f84d9
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:05 2021 +0100
iio: accel: hid: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit c6559bf796ccdb3a0c79db846af96c8f7046880b ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Note this matches what was done in all the other hid sensor drivers.
This one was missed previously due to an extra level of indirection.
Found during an audit of all calls of this function.
Fixes: a96cd0f901ee ("iio: accel: hid-sensor-accel-3d: Add timestamp")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-4-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b7a037dca9c8e3dad1d9f5951c17da031f56efde
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:04 2021 +0100
iio: accel: bma220: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit 151dbf0078da98206817ee0b87d499035479ef11 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: 194dc4c71413 ("iio: accel: Add triggered buffer support for BMA220")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-3-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0eaa556d3081e7e91b373e9eb82a6774186dfb25
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Sat May 1 18:01:03 2021 +0100
iio: accel: bma180: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
[ Upstream commit fc36da3131a747a9367a05caf06de19be1bcc972 ]
To make code more readable, use a structure to express the channel
layout and ensure the timestamp is 8 byte aligned.
Found during an audit of all calls of this function.
Fixes: b9a6a237ffc9 ("iio:bma180: Drop _update_scan_mode()")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210501170121.512209-2-jic23@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 37b8074fdf3454194ee9be82a4e8a504fde31333
Author: Nuno Sa <nuno.sa@analog.com>
Date: Thu Apr 22 12:19:03 2021 +0200
iio: adis_buffer: do not return ints in irq handlers
[ Upstream commit d877539ad8e8fdde9af69887055fec6402be1a13 ]
On an IRQ handler we should not return normal error codes as 'irqreturn_t'
is expected.
Not necessarily stable material as the old check cannot fail, so it's a bug
we can not hit.
Fixes: ccd2b52f4ac69 ("staging:iio: Add common ADIS library")
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210422101911.135630-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2c416d40d2f1bcf737bf1ad67a06e7f9538ac965
Author: Arnd Bergmann <arnd@arndb.de>
Date: Sat May 8 00:07:55 2021 +0200
mwifiex: re-fix for unaligned accesses
[ Upstream commit 8f4e3d48bb50765ab27ae5bebed2595b20de80a1 ]
A patch from 2017 changed some accesses to DMA memory to use
get_unaligned_le32() and similar interfaces, to avoid problems
with doing unaligned accesson uncached memory.
However, the change in the mwifiex_pcie_alloc_sleep_cookie_buf()
function ended up changing the size of the access instead,
as it operates on a pointer to u8.
Change this function back to actually access the entire 32 bits.
Note that the pointer is aligned by definition because it came
from dma_alloc_coherent().
Fixes: 92c70a958b0b ("mwifiex: fix for unaligned reads")
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f811408a54d52753b6da9825a6be94a95d78e626
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sun May 9 19:22:33 2021 +0200
tty: nozomi: Fix a resource leak in an error handling function
[ Upstream commit 31a9a318255960d32ae183e95d0999daf2418608 ]
A 'request_irq()' call is not balanced by a corresponding 'free_irq()' in
the error handling path, as already done in the remove function.
Add it.
Fixes: 9842c38e9176 ("kfifo: fix warn_unused_result")
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/4f0d2b3038e82f081d370ccb0cade3ad88463fe7.1620580838.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 63594fd2f764c2d13bf1f71b1e73b4751ccae3b7
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Fri Jun 25 23:23:48 2021 +0300
net: sched: fix warning in tcindex_alloc_perfect_hash
[ Upstream commit 3f2db250099f46988088800052cdf2332c7aba61 ]
Syzbot reported warning in tcindex_alloc_perfect_hash. The problem
was in too big cp->hash, which triggers warning in kmalloc. Since
cp->hash comes from userspace, there is no need to warn if value
is not correct
Fixes: b9a24bb76bf6 ("net_sched: properly handle failure case of tcf_exts_init()")
Reported-and-tested-by: syzbot+1071ad60cd7df39fdadb@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Acked-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a6edc1d9085c802ab325ef577c5811c450900df3
Author: Muchun Song <songmuchun@bytedance.com>
Date: Fri Apr 2 17:11:45 2021 +0800
writeback: fix obtain a reference to a freeing memcg css
[ Upstream commit 8b0ed8443ae6458786580d36b7d5f8125535c5d4 ]
The caller of wb_get_create() should pin the memcg, because
wb_get_create() relies on this guarantee. The rcu read lock
only can guarantee that the memcg css returned by css_from_id()
cannot be released, but the reference of the memcg can be zero.
rcu_read_lock()
memcg_css = css_from_id()
wb_get_create(memcg_css)
cgwb_create(memcg_css)
// css_get can change the ref counter from 0 back to 1
css_get(memcg_css)
rcu_read_unlock()
Fix it by holding a reference to the css before calling
wb_get_create(). This is not a problem I encountered in the
real world. Just the result of a code review.
Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates")
Link: https://lore.kernel.org/r/20210402091145.80635-1-songmuchun@bytedance.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 18678837cc28d8ed0480ffece4f1084b03de8286
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Fri May 28 11:45:02 2021 -0700
Bluetooth: mgmt: Fix slab-out-of-bounds in tlv_data_is_valid
[ Upstream commit 799acb9347915bfe4eac0ff2345b468f0a1ca207 ]
This fixes parsing of LTV entries when the length is 0.
Found with:
tools/mgmt-tester -s "Add Advertising - Success (ScRsp only)"
Add Advertising - Success (ScRsp only) - run
Sending Add Advertising (0x003e)
Test condition added, total 1
[ 11.004577] ==================================================================
[ 11.005292] BUG: KASAN: slab-out-of-bounds in tlv_data_is_valid+0x87/0xe0
[ 11.005984] Read of size 1 at addr ffff888002c695b0 by task mgmt-tester/87
[ 11.006711]
[ 11.007176]
[ 11.007429] Allocated by task 87:
[ 11.008151]
[ 11.008438] The buggy address belongs to the object at ffff888002c69580
[ 11.008438] which belongs to the cache kmalloc-64 of size 64
[ 11.010526] The buggy address is located 48 bytes inside of
[ 11.010526] 64-byte region [ffff888002c69580, ffff888002c695c0)
[ 11.012423] The buggy address belongs to the page:
[ 11.013291]
[ 11.013544] Memory state around the buggy address:
[ 11.014359] ffff888002c69480: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 11.015453] ffff888002c69500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 11.016232] >ffff888002c69580: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
[ 11.017010] ^
[ 11.017547] ffff888002c69600: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
[ 11.018296] ffff888002c69680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 11.019116] ==================================================================
Fixes: 2bb36870e8cb2 ("Bluetooth: Unify advertising instance flags check")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c90f2ae27bda63967a4f591ebf9747018b07fcd6
Author: Dany Madden <drt@linux.ibm.com>
Date: Wed Jun 23 21:13:11 2021 -0700
Revert "ibmvnic: remove duplicate napi_schedule call in open function"
[ Upstream commit 2ca220f92878470c6ba03f9946e412323093cc94 ]
This reverts commit 7c451f3ef676c805a4b77a743a01a5c21a250a73.
When a vnic interface is taken down and then up, connectivity is not
restored. We bisected it to this commit. Reverting this commit until
we can fully investigate the issue/benefit of the change.
Fixes: 7c451f3ef676 ("ibmvnic: remove duplicate napi_schedule call in open function")
Reported-by: Cristobal Forno <cforno12@linux.ibm.com>
Reported-by: Abdul Haleem <abdhalee@in.ibm.com>
Signed-off-by: Dany Madden <drt@linux.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1e8fce99d9508c5a151358a210f0bdb237e9b52f
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date: Sun Feb 28 19:50:58 2021 +0800
i40e: Fix error handling in i40e_vsi_open
[ Upstream commit 9c04cfcd4aad232e36306cdc5c74cd9fc9148a7e ]
When vsi->type == I40E_VSI_FDIR, we have caught the return value of
i40e_vsi_request_irq() but without further handling. Check and execute
memory clean on failure just like the other i40e_vsi_request_irq().
Fixes: 8a9eb7d3cbcab ("i40e: rework fdir setup and teardown")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit db765a58e42121520a1bd0354fecdcaf7a6d2f01
Author: Jian-Hong Pan <jhp@endlessos.org>
Date: Wed Jun 23 11:28:03 2021 +0800
net: bcmgenet: Fix attaching to PYH failed on RPi 4B
[ Upstream commit b2ac9800cfe0f8da16abc4e74e003440361c112e ]
The Broadcom UniMAC MDIO bus from mdio-bcm-unimac module comes too late.
So, GENET cannot find the ethernet PHY on UniMAC MDIO bus. This leads
GENET fail to attach the PHY as following log:
bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
...
could not attach to PHY
bcmgenet fd580000.ethernet eth0: failed to connect to PHY
uart-pl011 fe201000.serial: no DMA platform data
libphy: bcmgenet MII bus: probed
...
unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
This patch adds the soft dependency to load mdio-bcm-unimac module
before genet module to avoid the issue.
Fixes: 9a4e79697009 ("net: bcmgenet: utilize generic Broadcom UniMAC MDIO controller driver")
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=213485
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2b81e22f42f71bda861e1655a6afed840439c356
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Jun 21 07:44:17 2021 -0700
vxlan: add missing rcu_read_lock() in neigh_reduce()
[ Upstream commit 85e8b032d6ebb0f698a34dd22c2f13443d905888 ]
syzbot complained in neigh_reduce(), because rcu_read_lock_bh()
is treated differently than rcu_read_lock()
WARNING: suspicious RCU usage
5.13.0-rc6-syzkaller #0 Not tainted
-----------------------------
include/net/addrconf.h:313 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by kworker/0:0/5:
#0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic64_set include/asm-generic/atomic-instrumented.h:856 [inline]
#0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
#0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:617 [inline]
#0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x871/0x1600 kernel/workqueue.c:2247
#1: ffffc90000ca7da8 ((work_completion)(&port->wq)){+.+.}-{0:0}, at: process_one_work+0x8a5/0x1600 kernel/workqueue.c:2251
#2: ffffffff8bf795c0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x1da/0x3130 net/core/dev.c:4180
stack backtrace:
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.13.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events ipvlan_process_multicast
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
__in6_dev_get include/net/addrconf.h:313 [inline]
__in6_dev_get include/net/addrconf.h:311 [inline]
neigh_reduce drivers/net/vxlan.c:2167 [inline]
vxlan_xmit+0x34d5/0x4c30 drivers/net/vxlan.c:2919
__netdev_start_xmit include/linux/netdevice.h:4944 [inline]
netdev_start_xmit include/linux/netdevice.h:4958 [inline]
xmit_one net/core/dev.c:3654 [inline]
dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3670
__dev_queue_xmit+0x2133/0x3130 net/core/dev.c:4246
ipvlan_process_multicast+0xa99/0xd70 drivers/net/ipvlan/ipvlan_core.c:287
process_one_work+0x98d/0x1600 kernel/workqueue.c:2276
worker_thread+0x64c/0x1120 kernel/workqueue.c:2422
kthread+0x3b1/0x4a0 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Fixes: f564f45c4518 ("vxlan: add ipv6 proxy support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 559f994ff23f9ed92349523e8dc38fa394c71226
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Jun 21 10:54:49 2021 -0700
pkt_sched: sch_qfq: fix qfq_change_class() error path
[ Upstream commit 0cd58e5c53babb9237b741dbef711f0a9eb6d3fd ]
If qfq_change_class() is unable to allocate memory for qfq_aggregate,
it frees the class that has been inserted in the class hash table,
but does not unhash it.
Defer the insertion after the problematic allocation.
BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:884 [inline]
BUG: KASAN: use-after-free in qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731
Write of size 8 at addr ffff88814a534f10 by task syz-executor.4/31478
CPU: 0 PID: 31478 Comm: syz-executor.4 Not tainted 5.13.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
__kasan_report mm/kasan/report.c:419 [inline]
kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
hlist_add_head include/linux/list.h:884 [inline]
qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731
qfq_change_class+0x96c/0x1990 net/sched/sch_qfq.c:489
tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665d9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdc7b5f0188 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 00000000004665d9
RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003
RBP: 00007fdc7b5f01d0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 00007ffcf7310b3f R14: 00007fdc7b5f0300 R15: 0000000000022000
Allocated by task 31445:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:428 [inline]
____kasan_kmalloc mm/kasan/common.c:507 [inline]
____kasan_kmalloc mm/kasan/common.c:466 [inline]
__kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:516
kmalloc include/linux/slab.h:556 [inline]
kzalloc include/linux/slab.h:686 [inline]
qfq_change_class+0x705/0x1990 net/sched/sch_qfq.c:464
tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 31445:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
____kasan_slab_free mm/kasan/common.c:360 [inline]
____kasan_slab_free mm/kasan/common.c:325 [inline]
__kasan_slab_free+0xfb/0x130 mm/kasan/common.c:368
kasan_slab_free include/linux/kasan.h:212 [inline]
slab_free_hook mm/slub.c:1583 [inline]
slab_free_freelist_hook+0xdf/0x240 mm/slub.c:1608
slab_free mm/slub.c:3168 [inline]
kfree+0xe5/0x7f0 mm/slub.c:4212
qfq_change_class+0x10fb/0x1990 net/sched/sch_qfq.c:518
tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:654 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:674
____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
___sys_sendmsg+0xf3/0x170 net/socket.c:2404
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88814a534f00
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 16 bytes inside of
128-byte region [ffff88814a534f00, ffff88814a534f80)
The buggy address belongs to the page:
page:ffffea0005294d00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a534
flags: 0x57ff00000000200(slab|node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff00000000200 ffffea00004fee00 0000000600000006 ffff8880110418c0
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 29797, ts 604817765317, free_ts 604810151744
prep_new_page mm/page_alloc.c:2358 [inline]
get_page_from_freelist+0x1033/0x2b60 mm/page_alloc.c:3994
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5200
alloc_pages+0x18c/0x2a0 mm/mempolicy.c:2272
alloc_slab_page mm/slub.c:1646 [inline]
allocate_slab+0x2c5/0x4c0 mm/slub.c:1786
new_slab mm/slub.c:1849 [inline]
new_slab_objects mm/slub.c:2595 [inline]
___slab_alloc+0x4a1/0x810 mm/slub.c:2758
__slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2798
slab_alloc_node mm/slub.c:2880 [inline]
slab_alloc mm/slub.c:2922 [inline]
__kmalloc+0x315/0x330 mm/slub.c:4050
kmalloc include/linux/slab.h:561 [inline]
kzalloc include/linux/slab.h:686 [inline]
__register_sysctl_table+0x112/0x1090 fs/proc/proc_sysctl.c:1318
mpls_dev_sysctl_register+0x1b7/0x2d0 net/mpls/af_mpls.c:1421
mpls_add_dev net/mpls/af_mpls.c:1472 [inline]
mpls_dev_notify+0x214/0x8b0 net/mpls/af_mpls.c:1588
notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2121
call_netdevice_notifiers_extack net/core/dev.c:2133 [inline]
call_netdevice_notifiers net/core/dev.c:2147 [inline]
register_netdevice+0x106b/0x1500 net/core/dev.c:10312
veth_newlink+0x585/0xac0 drivers/net/veth.c:1547
__rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3452
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1298 [inline]
free_pcp_prepare+0x223/0x300 mm/page_alloc.c:1342
free_unref_page_prepare mm/page_alloc.c:3250 [inline]
free_unref_page+0x12/0x1d0 mm/page_alloc.c:3298
__vunmap+0x783/0xb60 mm/vmalloc.c:2566
free_work+0x58/0x70 mm/vmalloc.c:80
process_one_work+0x98d/0x1600 kernel/workqueue.c:2276
worker_thread+0x64c/0x1120 kernel/workqueue.c:2422
kthread+0x3b1/0x4a0 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Memory state around the buggy address:
ffff88814a534e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88814a534e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88814a534f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88814a534f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88814a535000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fixes: 462dbc9101acd ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 515e2010f6dbdf755ae37e49964a6a9ae3a612be
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Fri Jun 18 19:14:47 2021 +0300
net: ethernet: ezchip: fix error handling
[ Upstream commit 0de449d599594f5472e00267d651615c7f2c6c1d ]
As documented at drivers/base/platform.c for platform_get_irq:
* Gets an IRQ for a platform device and prints an error message if finding the
* IRQ fails. Device drivers should check the return value for errors so as to
* not pass a negative integer value to the request_irq() APIs.
So, the driver should check that platform_get_irq() return value
is _negative_, not that it's equal to zero, because -ENXIO (return
value from request_irq() if irq was not found) will
pass this check and it leads to passing negative irq to request_irq()
Fixes: 0dd077093636 ("NET: Add ezchip ethernet driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a00994e372f4a996e9c36b1eb8c3d7a6ac67e3f7
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Fri Jun 18 19:14:31 2021 +0300
net: ethernet: ezchip: fix UAF in nps_enet_remove
[ Upstream commit e4b8700e07a86e8eab6916aa5c5ba99042c34089 ]
priv is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing priv
pointer. So, fix it by moving free_netdev() after netif_napi_del()
call.
Fixes: 0dd077093636 ("NET: Add ezchip ethernet driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9cddf9f7f18da6e35cb7a80ce0e7ebc42048af8b
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Fri Jun 18 17:57:31 2021 +0300
net: ethernet: aeroflex: fix UAF in greth_of_remove
[ Upstream commit e3a5de6d81d8b2199935c7eb3f7d17a50a7075b7 ]
static int greth_of_remove(struct platform_device *of_dev)
{
...
struct greth_private *greth = netdev_priv(ndev);
...
unregister_netdev(ndev);
free_netdev(ndev);
of_iounmap(&of_dev->resource[0], greth->regs, resource_size(&of_dev->resource[0]));
...
}
greth is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing greth
pointer. So, fix it by moving free_netdev() after of_iounmap()
call.
Fixes: d4c41139df6e ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 93a861ff5b1f4055d2f051c46d596a9407c97fb7
Author: Wang Hai <wanghai38@huawei.com>
Date: Wed Jun 16 12:25:34 2021 +0800
samples/bpf: Fix the error return code of xdp_redirect's main()
[ Upstream commit 7c6090ee2a7b3315410cfc83a94c3eb057407b25 ]
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
If bpf_map_update_elem() failed, main() should return a negative error.
Fixes: 832622e6bd18 ("xdp: sample program for new bpf_redirect helper")
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210616042534.315097-1-wanghai38@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 59c39d153b4999b100841e881dc824dcbd66df48
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu Jun 10 20:20:30 2021 +0200
netfilter: nft_exthdr: check for IPv6 packet before further processing
[ Upstream commit cdd73cc545c0fb9b1a1f7b209f4f536e7990cff4 ]
ipv6_find_hdr() does not validate that this is an IPv6 packet. Add a
sanity check for calling ipv6_find_hdr() to make sure an IPv6 packet
is passed for parsing.
Fixes: 96518518cc41 ("netfilter: add nftables")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7678947287692ddfd57d3f3378af6847cefc8e3f
Author: Liu Shixin <liushixin2@huawei.com>
Date: Tue Jun 15 10:14:44 2021 +0800
netlabel: Fix memory leak in netlbl_mgmt_add_common
[ Upstream commit b8f6b0522c298ae9267bd6584e19b942a0636910 ]
Hulk Robot reported memory leak in netlbl_mgmt_add_common.
The problem is non-freed map in case of netlbl_domhsh_add() failed.
BUG: memory leak
unreferenced object 0xffff888100ab7080 (size 96):
comm "syz-executor537", pid 360, jiffies 4294862456 (age 22.678s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................
backtrace:
[<0000000008b40026>] netlbl_mgmt_add_common.isra.0+0xb2a/0x1b40
[<000000003be10950>] netlbl_mgmt_add+0x271/0x3c0
[<00000000c70487ed>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320
[<000000001f2ff614>] genl_rcv_msg+0x2bf/0x4f0
[<0000000089045792>] netlink_rcv_skb+0x134/0x3d0
[<0000000020e96fdd>] genl_rcv+0x24/0x40
[<0000000042810c66>] netlink_unicast+0x4a0/0x6a0
[<000000002e1659f0>] netlink_sendmsg+0x789/0xc70
[<000000006e43415f>] sock_sendmsg+0x139/0x170
[<00000000680a73d7>] ____sys_sendmsg+0x658/0x7d0
[<0000000065cbb8af>] ___sys_sendmsg+0xf8/0x170
[<0000000019932b6c>] __sys_sendmsg+0xd3/0x190
[<00000000643ac172>] do_syscall_64+0x37/0x90
[<000000009b79d6dc>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes: 63c416887437 ("netlabel: Add network address selectors to the NetLabel/LSM domain mapping")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ec53571e06cf6d7c1902bc6002f888af8c687d83
Author: Yang Li <yang.lee@linux.alibaba.com>
Date: Tue May 25 18:46:17 2021 +0800
ath10k: Fix an error code in ath10k_add_interface()
[ Upstream commit e9ca70c735ce66fc6a0e02c8b6958434f74ef8de ]
When the code execute this if statement, the value of ret is 0.
However, we can see from the ath10k_warn() log that the value of
ret should be -EINVAL.
Clean up smatch warning:
drivers/net/wireless/ath/ath10k/mac.c:5596 ath10k_add_interface() warn:
missing error code 'ret'
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes: ccec9038c721 ("ath10k: enable raw encap mode and software crypto engine")
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1621939577-62218-1-git-send-email-yang.lee@linux.alibaba.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 46e635d94cb26560c9f20aed207eda46619f6c0e
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed May 12 22:58:30 2021 +0200
brcmsmac: mac80211_if: Fix a resource leak in an error handling path
[ Upstream commit 9a25344d5177c2b9285532236dc3d10a091f39a8 ]
If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()'
as already done in the remove function.
Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8d1d12e769d12e8d0e35c8e52eaf3113d006f3f6
Author: Randy Dunlap <rdunlap@infradead.org>
Date: Mon May 31 17:41:28 2021 +0300
wireless: carl9170: fix LEDS build errors & warnings
[ Upstream commit 272fdc0c4542fad173b44965be02a16d6db95499 ]
kernel test robot reports over 200 build errors and warnings
that are due to this Kconfig problem when CARL9170=m,
MAC80211=y, and LEDS_CLASS=m.
WARNING: unmet direct dependencies detected for MAC80211_LEDS
Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
Selected by [m]:
- CARL9170_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && CARL9170 [=m]
CARL9170_LEDS selects MAC80211_LEDS even though its kconfig
dependencies are not met. This happens because 'select' does not follow
any Kconfig dependency chains.
Fix this by making CARL9170_LEDS depend on MAC80211_LEDS, where
the latter supplies any needed dependencies on LEDS_CLASS.
Fixes: 1d7e1e6b1b8ed ("carl9170: Makefile, Kconfig files and MAINTAINERS")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: linux-wireless@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210530031134.23274-1-rdunlap@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 20f63246550f5acb4237aaffa2c5bee8692ee344
Author: Colin Ian King <colin.king@canonical.com>
Date: Tue Jun 8 17:13:13 2021 +0100
drm: qxl: ensure surf.data is ininitialized
[ Upstream commit fbbf23ddb2a1cc0c12c9f78237d1561c24006f50 ]
The object surf is not fully initialized and the uninitialized
field surf.data is being copied by the call to qxl_bo_create
via the call to qxl_gem_object_create. Set surf.data to zero
to ensure garbage data from the stack is not being copied.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210608161313.161922-1-colin.king@canonical.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8d034c20b4334b4f0d6e171424603bd657ac2e2e
Author: Kamal Heib <kamalheib1@gmail.com>
Date: Thu Jun 3 12:01:12 2021 +0300
RDMA/rxe: Fix failure during driver load
[ Upstream commit 32a25f2ea690dfaace19f7a3a916f5d7e1ddafe8 ]
To avoid the following failure when trying to load the rdma_rxe module
while IPv6 is disabled, add a check for EAFNOSUPPORT and ignore the
failure, also delete the needless debug print from rxe_setup_udp_tunnel().
$ modprobe rdma_rxe
modprobe: ERROR: could not insert 'rdma_rxe': Operation not permitted
Fixes: dfdd6158ca2c ("IB/rxe: Fix kernel panic in udp_setup_tunnel")
Link: https://lore.kernel.org/r/20210603090112.36341-1-kamalheib1@gmail.com
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bffe21fb1ccffd47ab8fa51e27b2292f7f065938
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Fri May 28 16:55:55 2021 +0800
ehea: fix error return code in ehea_restart_qps()
[ Upstream commit 015dbf5662fd689d581c0bc980711b073ca09a1a ]
Fix to return -EFAULT from the error handling case instead of 0, as done
elsewhere in this function.
By the way, when get_zeroed_page() fails, directly return -ENOMEM to
simplify code.
Fixes: 2c69448bbced ("ehea: DLPAR memory add fix")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210528085555.9390-1-thunder.leizhen@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e35d40e546451424112152313ad8ac3986061485
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Wed May 19 21:49:28 2021 +0800
drm/rockchip: cdn-dp-core: add missing clk_disable_unprepare() on error in cdn_dp_grf_write()
[ Upstream commit ae41d925c75b53798f289c69ee8d9f7d36432f6d ]
After calling clk_prepare_enable(), clk_disable_unprepare() need
be called when calling regmap_write() failed.
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210519134928.2696617-1-yangyingliang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d6fb0a110c34c16a43ba2a71da0d4c9a19ed548a
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon May 10 19:39:27 2021 +0300
net: pch_gbe: Propagate error from devm_gpio_request_one()
[ Upstream commit 9e3617a7b84512bf96c04f9cf82d1a7257d33794 ]
If GPIO controller is not available yet we need to defer
the probe of GBE until provider will become available.
While here, drop GPIOF_EXPORT because it's deprecated and
may not be available.
Fixes: f1a26fdf5944 ("pch_gbe: Add MinnowBoard support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Flavio Suligoi <f.suligoi@asem.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 790b3ac6207142a27822bff332cc7d9d2459dc28
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Jun 28 19:34:01 2021 -0700
ocfs2: fix snprintf() checking
[ Upstream commit 54e948c60cc843b6e84dc44496edc91f51d2a28e ]
The snprintf() function returns the number of bytes which would have been
printed if the buffer was large enough. In other words it can return ">=
remain" but this code assumes it returns "== remain".
The run time impact of this bug is not very severe. The next iteration
through the loop would trigger a WARN() when we pass a negative limit to
snprintf(). We would then return success instead of -E2BIG.
The kernel implementation of snprintf() will never return negatives so
there is no need to check and I have deleted that dead code.
Link: https://lkml.kernel.org/r/20210511135350.GV1955@kadam
Fixes: a860f6eb4c6a ("ocfs2: sysfile interfaces for online file check")
Fixes: 74ae4e104dfc ("ocfs2: Create stack glue sysfs files.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 28649ddf06789d90aefc479d59006865eeeab650
Author: Krzysztof Wilczyński <kw@linux.com>
Date: Thu Jun 3 17:12:01 2021 +0000
ACPI: sysfs: Fix a buffer overrun problem with description_show()
[ Upstream commit 888be6067b97132c3992866bbcf647572253ab3f ]
Currently, a device description can be obtained using ACPI, if the _STR
method exists for a particular device, and then exposed to the userspace
via a sysfs object as a string value.
If the _STR method is available for a given device then the data
(usually a Unicode string) is read and stored in a buffer (of the
ACPI_TYPE_BUFFER type) with a pointer to said buffer cached in the
struct acpi_device_pnp for later access.
The description_show() function is responsible for exposing the device
description to the userspace via a corresponding sysfs object and
internally calls the utf16s_to_utf8s() function with a pointer to the
buffer that contains the Unicode string so that it can be converted from
UTF16 encoding to UTF8 and thus allowing for the value to be safely
stored and later displayed.
When invoking the utf16s_to_utf8s() function, the description_show()
function also sets a limit of the data that can be saved into a provided
buffer as a result of the character conversion to be a total of
PAGE_SIZE, and upon completion, the utf16s_to_utf8s() function returns
an integer value denoting the number of bytes that have been written
into the provided buffer.
Following the execution of the utf16s_to_utf8s() a newline character
will be added at the end of the resulting buffer so that when the value
is read in the userspace through the sysfs object then it would include
newline making it more accessible when working with the sysfs file
system in the shell, etc. Normally, this wouldn't be a problem, but if
the function utf16s_to_utf8s() happens to return the number of bytes
written to be precisely PAGE_SIZE, then we would overrun the buffer and
write the newline character outside the allotted space which can have
undefined consequences or result in a failure.
To fix this buffer overrun, ensure that there always is enough space
left for the newline character to be safely appended.
Fixes: d1efe3c324ea ("ACPI: Add new sysfs interface to export device description")
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c4b65c4e921474b76ee3877465cf51722666279b
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jun 17 15:57:12 2021 +0800
crypto: nx - Fix RCU warning in nx842_OF_upd_status
[ Upstream commit 2a96726bd0ccde4f12b9b9a9f61f7b1ac5af7e10 ]
The function nx842_OF_upd_status triggers a sparse RCU warning when
it directly dereferences the RCU-protected devdata. This appears
to be an accident as there was another variable of the same name
that was passed in from the caller.
After it was removed (because the main purpose of using it, to
update the status member was itself removed) the global variable
unintenionally stood in as its replacement.
This patch restores the devdata parameter.
Fixes: 90fd73f912f0 ("crypto: nx - remove pSeries NX 'status' field")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d52dfff366fd95784635d6bb67399cbfa8abf72b
Author: Mirko Vogt <mirko-dev|linux@nanl.de>
Date: Mon Jun 14 16:45:07 2021 +0200
spi: spi-sun6i: Fix chipselect/clock bug
[ Upstream commit 0d7993b234c9fad8cb6bec6adfaa74694ba85ecb ]
The current sun6i SPI implementation initializes the transfer too early,
resulting in SCK going high before the transfer. When using an additional
(gpio) chipselect with sun6i, the chipselect is asserted at a time when
clock is high, making the SPI transfer fail.
This is due to SUN6I_GBL_CTL_BUS_ENABLE being written into
SUN6I_GBL_CTL_REG at an early stage. Moving that to the transfer
function, hence, right before the transfer starts, mitigates that
problem.
Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Mirko Vogt <mirko-dev|linux@nanl.de>
Signed-off-by: Ralf Schlatterbeck <rsc@runtux.com>
Link: https://lore.kernel.org/r/20210614144507.y3udezjfbko7eavv@runtux.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 57d4aa5fc3b0411bcf75e0694ad6053429cd409b
Author: David Sterba <dsterba@suse.com>
Date: Tue Jul 7 18:38:05 2020 +0200
btrfs: clear log tree recovering status if starting transaction fails
[ Upstream commit 1aeb6b563aea18cd55c73cf666d1d3245a00f08c ]
When a log recovery is in progress, lots of operations have to take that
into account, so we keep this status per tree during the operation. Long
time ago error handling revamp patch 79787eaab461 ("btrfs: replace many
BUG_ONs with proper error handling") removed clearing of the status in
an error branch. Add it back as was intended in e02119d5a7b4 ("Btrfs:
Add a write ahead tree log to optimize synchronous operations").
There are probably no visible effects, log replay is done only during
mount and if it fails all structures are cleared so the stale status
won't be kept.
Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling")
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d734346d51cd54a8fcadb827bd33de1719a9b404
Author: Guenter Roeck <linux@roeck-us.net>
Date: Wed May 26 08:40:16 2021 -0700
hwmon: (max31790) Fix fan speed reporting for fan7..12
[ Upstream commit cbbf244f0515af3472084f22b6213121b4a63835 ]
Fans 7..12 do not have their own set of configuration registers.
So far the code ignored that and read beyond the end of the configuration
register range to get the tachometer period. This resulted in more or less
random fan speed values for those fans.
The datasheet is quite vague when it comes to defining the tachometer
period for fans 7..12. Experiments confirm that the period is the same
for both fans associated with a given set of configuration registers.
Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API")
Fixes: 195a4b4298a7 ("hwmon: Driver for Maxim MAX31790")
Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: Václav Kubernát <kubernat@cesnet.cz>
Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210526154022.3223012-2-linux@roeck-us.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit df81c1e935bf5c58049d6447c4becc739fe55904
Author: Guenter Roeck <linux@roeck-us.net>
Date: Sat May 8 09:50:25 2021 -0700
hwmon: (max31722) Remove non-standard ACPI device IDs
[ Upstream commit 97387c2f06bcfd79d04a848d35517b32ee6dca7c ]
Valid Maxim Integrated ACPI device IDs would start with MXIM,
not with MAX1. On top of that, ACPI device IDs reflecting chip names
are almost always invalid.
Remove the invalid ACPI IDs.
Fixes: 04e1e70afec6 ("hwmon: (max31722) Add support for MAX31722/MAX31723 temperature sensors")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a9e5ee4c329b0d9f37494b624d3594e926310ea0
Author: Dillon Min <dillon.minfei@gmail.com>
Date: Wed May 26 17:18:32 2021 +0200
media: s5p-g2d: Fix a memory leak on ctx->fh.m2m_ctx
[ Upstream commit 5d11e6aad1811ea293ee2996cec9124f7fccb661 ]
The m2m_ctx resources was allocated by v4l2_m2m_ctx_init() in g2d_open()
should be freed from g2d_release() when it's not used.
Fix it
Fixes: 918847341af0 ("[media] v4l: add G2D driver for s5p device family")
Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 42acca42405afe049c05e15143e4b976b0409c1a
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Sat May 8 10:03:21 2021 +0800
mmc: usdhi6rol0: fix error return code in usdhi6_probe()
[ Upstream commit 2f9ae69e5267f53e89e296fccee291975a85f0eb ]
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210508020321.1677-1-thunder.leizhen@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 69e6cf44c7833f92a41492107959435b71bbb762
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date: Wed Mar 10 19:40:43 2021 -0600
media: siano: Fix out-of-bounds warnings in smscore_load_firmware_family2()
[ Upstream commit 13dfead49db07225335d4f587a560a2210391a1a ]
Rename struct sms_msg_data4 to sms_msg_data5 and increase the size of
its msg_data array from 4 to 5 elements. Notice that at some point
the 5th element of msg_data is being accessed in function
smscore_load_firmware_family2():
1006 trigger_msg->msg_data[4] = 4; /* Task ID */
Also, there is no need for the object _trigger_msg_ of type struct
sms_msg_data *, when _msg_ can be used, directly. Notice that msg_data
in struct sms_msg_data is a one-element array, which causes multiple
out-of-bounds warnings when accessing beyond its first element
in function smscore_load_firmware_family2():
992 struct sms_msg_data *trigger_msg =
993 (struct sms_msg_data *) msg;
994
995 pr_debug("sending MSG_SMS_SWDOWNLOAD_TRIGGER_REQ\n");
996 SMS_INIT_MSG(&msg->x_msg_header,
997 MSG_SMS_SWDOWNLOAD_TRIGGER_REQ,
998 sizeof(struct sms_msg_hdr) +
999 sizeof(u32) * 5);
1000
1001 trigger_msg->msg_data[0] = firmware->start_address;
1002 /* Entry point */
1003 trigger_msg->msg_data[1] = 6; /* Priority */
1004 trigger_msg->msg_data[2] = 0x200; /* Stack size */
1005 trigger_msg->msg_data[3] = 0; /* Parameter */
1006 trigger_msg->msg_data[4] = 4; /* Task ID */
even when enough dynamic memory is allocated for _msg_:
929 /* PAGE_SIZE buffer shall be enough and dma aligned */
930 msg = kmalloc(PAGE_SIZE, GFP_KERNEL | coredev->gfp_buf_flags);
but as _msg_ is casted to (struct sms_msg_data *):
992 struct sms_msg_data *trigger_msg =
993 (struct sms_msg_data *) msg;
the out-of-bounds warnings are actually valid and should be addressed.
Fix this by declaring object _msg_ of type struct sms_msg_data5 *,
which contains a 5-elements array, instead of just 4. And use
_msg_ directly, instead of creating object trigger_msg.
This helps with the ongoing efforts to enable -Warray-bounds by fixing
the following warnings:
CC [M] drivers/media/common/siano/smscoreapi.o
drivers/media/common/siano/smscoreapi.c: In function ‘smscore_load_firmware_family2’:
drivers/media/common/siano/smscoreapi.c:1003:24: warning: array subscript 1 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
1003 | trigger_msg->msg_data[1] = 6; /* Priority */
| ~~~~~~~~~~~~~~~~~~~~~^~~
In file included from drivers/media/common/siano/smscoreapi.c:12:
drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
619 | u32 msg_data[1];
| ^~~~~~~~
drivers/media/common/siano/smscoreapi.c:1004:24: warning: array subscript 2 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
1004 | trigger_msg->msg_data[2] = 0x200; /* Stack size */
| ~~~~~~~~~~~~~~~~~~~~~^~~
In file included from drivers/media/common/siano/smscoreapi.c:12:
drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
619 | u32 msg_data[1];
| ^~~~~~~~
drivers/media/common/siano/smscoreapi.c:1005:24: warning: array subscript 3 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
1005 | trigger_msg->msg_data[3] = 0; /* Parameter */
| ~~~~~~~~~~~~~~~~~~~~~^~~
In file included from drivers/media/common/siano/smscoreapi.c:12:
drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
619 | u32 msg_data[1];
| ^~~~~~~~
drivers/media/common/siano/smscoreapi.c:1006:24: warning: array subscript 4 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
1006 | trigger_msg->msg_data[4] = 4; /* Task ID */
| ~~~~~~~~~~~~~~~~~~~~~^~~
In file included from drivers/media/common/siano/smscoreapi.c:12:
drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
619 | u32 msg_data[1];
| ^~~~~~~~
Fixes: 018b0c6f8acb ("[media] siano: make load firmware logic to work with newer firmwares")
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 06b6b83ba103b36ce91f66218f9ecc6b9b32bbb4
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Sat May 15 08:58:30 2021 +0200
media: tc358743: Fix error return code in tc358743_probe_of()
[ Upstream commit a6b1e7093f0a099571fc8836ab4a589633f956a8 ]
When the CSI bps per lane is not in the valid range, an appropriate error
code -EINVAL should be returned. However, we currently do not explicitly
assign this error code to 'ret'. As a result, 0 was incorrectly returned.
Fixes: 256148246852 ("[media] tc358743: support probe from device tree")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 427d78c34435f014a997b9e4e7c5304c9817d6b6
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date: Sun May 9 10:12:31 2021 +0200
media: exynos4-is: Fix a use after free in isp_video_release
[ Upstream commit 01fe904c9afd26e79c1f73aa0ca2e3d785e5e319 ]
In isp_video_release, file->private_data is freed via
_vb2_fop_release()->v4l2_fh_release(). But the freed
file->private_data is still used in v4l2_fh_is_singular_file()
->v4l2_fh_is_singular(file->private_data), which is a use
after free bug.
My patch uses a variable 'is_singular_file' to avoid the uaf.
v3: https://lore.kernel.org/patchwork/patch/1419058/
Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6f05426403866d8567ff563bdccf811e2b23a1ae
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date: Sat Mar 20 23:32:38 2021 +0300
pata_ep93xx: fix deferred probing
[ Upstream commit 5c8121262484d99bffb598f39a0df445cecd8efb ]
The driver overrides the error codes returned by platform_get_irq() to
-ENXIO, so if it returns -EPROBE_DEFER, the driver would fail the probe
permanently instead of the deferred probing. Propagate the error code
upstream, as it should have been done from the start...
Fixes: 2fff27512600 ("PATA host controller driver for ep93xx")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Link: https://lore.kernel.org/r/509fda88-2e0d-2cc7-f411-695d7e94b136@omprussia.ru
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4c6735325c9c365c9354e970b8dd10ceb0b5b576
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sun May 16 08:58:04 2021 +0200
crypto: ccp - Fix a resource leak in an error handling path
[ Upstream commit a6f8e68e238a15bb15f1726b35c695136c64eaba ]
If an error occurs after calling 'sp_get_irqs()', 'sp_free_irqs()' must be
called as already done in the error handling path.
Fixes: f4d18d656f88 ("crypto: ccp - Abstract interrupt registeration")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4bfecac4b0eaa572df5cd505c65fd6bdc3aa6316
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Tue May 18 23:38:54 2021 +0300
pata_octeon_cf: avoid WARN_ON() in ata_host_activate()
[ Upstream commit bfc1f378c8953e68ccdbfe0a8c20748427488b80 ]
Iff platform_get_irq() fails (or returns IRQ0) and thus the polling mode
has to be used, ata_host_activate() hits the WARN_ON() due to 'irq_handler'
parameter being non-NULL if the polling mode is selected. Let's only set
the pointer to the driver's IRQ handler if platform_get_irq() returns a
valid IRQ # -- this should avoid the unnecessary WARN_ON()...
Fixes: 43f01da0f279 ("MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/3a241167-f84d-1d25-5b9b-be910afbe666@omp.ru
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6a02f41baad6c1b214d432128ea7345df595a41d
Author: Randy Dunlap <rdunlap@infradead.org>
Date: Fri Apr 30 22:19:55 2021 +0200
media: I2C: change 'RST' to "RSET" to fix multiple build errors
[ Upstream commit 8edcb5049ac29aa3c8acc5ef15dd4036543d747e ]
The use of an enum named 'RST' conflicts with a #define macro
named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h.
The MIPS use of RST was there first (AFAICT), so change the
media/i2c/ uses of RST to be named 'RSET'.
'git grep -w RSET' does not report any naming conflicts with the
new name.
This fixes multiple build errors:
arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
15 | #define RST (1 << 15)
| ^
drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST'
356 | RST,
| ^~~
../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
15 | #define RST (1 << 15)
| ^
../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST'
180 | RST,
| ^~~
../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
15 | #define RST (1 << 15)
| ^
../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST'
238 | RST,
| ^~~
and some others that I have trimmed.
Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver")
Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor")
Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Sangwook Lee <sangwook.lee@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 225e684af383781b75418c8d6e5f6c1d792860b3
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date: Mon Mar 15 14:46:53 2021 +0300
pata_rb532_cf: fix deferred probing
[ Upstream commit 2d3a62fbae8e5badc2342388f65ab2191c209cc0 ]
The driver overrides the error codes returned by platform_get_irq() to
-ENOENT, so if it returns -EPROBE_DEFER, the driver would fail the probe
permanently instead of the deferred probing. Switch to propagating the
error code upstream, still checking/overriding IRQ0 as libata regards it
as "no IRQ" (thus polling) anyway...
Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Link: https://lore.kernel.org/r/771ced55-3efb-21f5-f21c-b99920aae611@omprussia.ru
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5996d4e85328aecf4abd3a4053efe07ae1804cdd
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date: Sun Mar 14 23:34:27 2021 +0300
sata_highbank: fix deferred probing
[ Upstream commit 4a24efa16e7db02306fb5db84518bb0a7ada5a46 ]
The driver overrides the error codes returned by platform_get_irq() to
-EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe
permanently instead of the deferred probing. Switch to propagating the
error code upstream, still checking/overriding IRQ0 as libata regards it
as "no IRQ" (thus polling) anyway...
Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Link: https://lore.kernel.org/r/105b456d-1199-f6e9-ceb7-ffc5ba551d1a@omprussia.ru
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7b6374522735cb53071831bb5f0ea45ba7bfa648
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Sat May 8 15:00:49 2021 +0800
crypto: ux500 - Fix error return code in hash_hw_final()
[ Upstream commit b01360384009ab066940b45f34880991ea7ccbfb ]
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 8a63b1994c50 ("crypto: ux500 - Add driver for HASH hardware")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 51c8e166b13e83a11ec80d6306a171ed01b80035
Author: Corentin Labbe <clabbe@baylibre.com>
Date: Wed May 5 20:26:08 2021 +0000
crypto: ixp4xx - dma_unmap the correct address
[ Upstream commit 9395c58fdddd79cdd3882132cdd04e8ac7ad525f ]
Testing ixp4xx_crypto with CONFIG_DMA_API_DEBUG lead to the following error:
DMA-API: platform ixp4xx_crypto.0: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=24 bytes]
This is due to dma_unmap using the wrong address.
Fixes: 0d44dc59b2b4 ("crypto: ixp4xx - Fix handling of chained sg buffers")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 29054c037742a850e21b835317e527e04074dfba
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date: Wed Apr 28 09:38:56 2021 +0200
media: s5p_cec: decrement usage count if disabled
[ Upstream commit 747bad54a677d8633ec14b39dfbeb859c821d7f2 ]
There's a bug at s5p_cec_adap_enable(): if called to
disable the device, it should call pm_runtime_put()
instead of pm_runtime_disable(), as the goal here is to
decrement the usage_count and not to disable PM runtime.
Reported-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes: 1bcbf6f4b6b0 ("[media] cec: s5p-cec: Add s5p-cec driver")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4349743c27e588acfa98150f6cdb552cc8ce828d
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon Jun 28 19:33:41 2021 -0700
ia64: mca_drv: fix incorrect array size calculation
[ Upstream commit c5f320ff8a79501bb59338278336ec43acb9d7e2 ]
gcc points out a mistake in the mca driver that goes back to before the
git history:
arch/ia64/kernel/mca_drv.c: In function 'init_record_index_pools':
arch/ia64/kernel/mca_drv.c:346:54: error: expression does not compute the number of elements in this array; element typ
e is 'int', not 'size_t' {aka 'long unsigned int'} [-Werror=sizeof-array-div]
346 | for (i = 1; i < sizeof sal_log_sect_min_sizes/sizeof(size_t); i++)
| ^
This is the same as sizeof(size_t), which is two shorter than the actual
array. Use the ARRAY_SIZE() macro to get the correct calculation instead.
Link: https://lkml.kernel.org/r/20210514214123.875971-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 28f8e9931bb16ba0da1a52101793689c2372d005
Author: Jason Gerecke <killertofu@gmail.com>
Date: Wed Jun 23 09:58:09 2021 -0700
HID: wacom: Correct base usage for capacitive ExpressKey status bits
[ Upstream commit 424d8237945c6c448c8b3f23885d464fb5685c97 ]
The capacitive status of ExpressKeys is reported with usages beginning
at 0x940, not 0x950. Bring our driver into alignment with reality.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ca3c0011157641ff3c604a2f9b1715371c6fe892
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Mon Jun 21 16:24:33 2021 +0100
ACPI: tables: Add custom DSDT file as makefile prerequisite
[ Upstream commit d1059c1b1146870c52f3dac12cb7b6cbf39ed27f ]
A custom DSDT file is mostly used during development or debugging,
and in that case it is quite likely to want to rebuild the kernel
after changing ONLY the content of the DSDT.
This patch adds the custom DSDT as a prerequisite to tables.o
to ensure a rebuild if the DSDT file is updated. Make will merge
the prerequisites from multiple rules for the same target.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b20c1634cd041559cb778f04c13e046fb15fb250
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date: Wed Jun 2 18:05:48 2021 +0800
platform/x86: toshiba_acpi: Fix missing error code in toshiba_acpi_setup_keyboard()
[ Upstream commit 28e367127718a9cb85d615a71e152f7acee41bfc ]
The error code is missing in this code scenario, add the error code
'-EINVAL' to the return value 'error'.
Eliminate the follow smatch warning:
drivers/platform/x86/toshiba_acpi.c:2834 toshiba_acpi_setup_keyboard()
warn: missing error code 'error'.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/1622628348-87035-1-git-send-email-jiapeng.chong@linux.alibaba.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8b8b93704be138ea705e304580bc7d4241516a6c
Author: Hanjun Guo <guohanjun@huawei.com>
Date: Wed Jun 2 17:36:50 2021 +0800
ACPI: bus: Call kobject_put() in acpi_init() error path
[ Upstream commit 4ac7a817f1992103d4e68e9837304f860b5e7300 ]
Although the system will not be in a good condition or it will not
boot if acpi_bus_init() fails, it is still necessary to put the
kobject in the error path before returning to avoid leaking memory.
Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a5a48c35655f37a4a2ea15b57d1f4f62cb7de3e6
Author: Erik Kaneda <erik.kaneda@intel.com>
Date: Fri Jun 4 14:25:57 2021 -0700
ACPICA: Fix memory leak caused by _CID repair function
[ Upstream commit c27bac0314131b11bccd735f7e8415ac6444b667 ]
ACPICA commit 180cb53963aa876c782a6f52cc155d951b26051a
According to the ACPI spec, _CID returns a package containing
hardware ID's. Each element of an ASL package contains a reference
count from the parent package as well as the element itself.
Name (TEST, Package() {
"String object" // this package element has a reference count of 2
})
A memory leak was caused in the _CID repair function because it did
not decrement the reference count created by the package. Fix the
memory leak by calling acpi_ut_remove_reference on _CID package elements
that represent a hardware ID (_HID).
Link: https://github.com/acpica/acpica/commit/180cb539
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ffb576cbdeb0020afb7ac3c9f4508b75c927410c
Author: Alexander Aring <aahringo@redhat.com>
Date: Wed Jun 2 09:45:16 2021 -0400
fs: dlm: fix memory leak when fenced
[ Upstream commit 700ab1c363c7b54c9ea3222379b33fc00ab02f7b ]
I got some kmemleak report when a node was fenced. The user space tool
dlm_controld will therefore run some rmdir() in dlm configfs which was
triggering some memleaks. This patch stores the sps and cms attributes
which stores some handling for subdirectories of the configfs cluster
entry and free them if they get released as the parent directory gets
freed.
unreferenced object 0xffff88810d9e3e00 (size 192):
comm "dlm_controld", pid 342, jiffies 4294698126 (age 55438.801s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 73 70 61 63 65 73 00 00 ........spaces..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000db8b640b>] make_cluster+0x5d/0x360
[<000000006a571db4>] configfs_mkdir+0x274/0x730
[<00000000b094501c>] vfs_mkdir+0x27e/0x340
[<0000000058b0adaf>] do_mkdirat+0xff/0x1b0
[<00000000d1ffd156>] do_syscall_64+0x40/0x80
[<00000000ab1408c8>] entry_SYSCALL_64_after_hwframe+0x44/0xae
unreferenced object 0xffff88810d9e3a00 (size 192):
comm "dlm_controld", pid 342, jiffies 4294698126 (age 55438.801s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 63 6f 6d 6d 73 00 00 00 ........comms...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000a7ef6ad2>] make_cluster+0x82/0x360
[<000000006a571db4>] configfs_mkdir+0x274/0x730
[<00000000b094501c>] vfs_mkdir+0x27e/0x340
[<0000000058b0adaf>] do_mkdirat+0xff/0x1b0
[<00000000d1ffd156>] do_syscall_64+0x40/0x80
[<00000000ab1408c8>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d6028644ae2d5bf100d7f88347bc7484b8493988
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Tue May 25 13:20:12 2021 +0100
random32: Fix implicit truncation warning in prandom_seed_state()
[ Upstream commit d327ea15a305024ef0085252fa3657bbb1ce25f5 ]
sparse generates the following warning:
include/linux/prandom.h:114:45: sparse: sparse: cast truncates bits from
constant value
This is because the 64-bit seed value is manipulated and then placed in a
u32, causing an implicit cast and truncation. A forced cast to u32 doesn't
prevent this warning, which is reasonable because a typecast doesn't prove
that truncation was expected.
Logical-AND the value with 0xffffffff to make explicit that truncation to
32-bit is intended.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20210525122012.6336-3-rf@opensource.cirrus.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8d98a177c6ba0bd659f9c14a1813ad7316984fb
Author: Alexander Aring <aahringo@redhat.com>
Date: Fri May 21 15:08:38 2021 -0400
fs: dlm: cancel work sync othercon
[ Upstream commit c6aa00e3d20c2767ba3f57b64eb862572b9744b3 ]
These rx tx flags arguments are for signaling close_connection() from
which worker they are called. Obviously the receive worker cannot cancel
itself and vice versa for swork. For the othercon the receive worker
should only be used, however to avoid deadlocks we should pass the same
flags as the original close_connection() was called.
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ee692b6db03036c32b7c33f3e063f77a88593f9c
Author: zhangyi (F) <yi.zhang@huawei.com>
Date: Sat Mar 13 11:01:44 2021 +0800
block_dump: remove block_dump feature in mark_inode_dirty()
[ Upstream commit 12e0613715e1cf305fffafaf0e89d810d9a85cc0 ]
block_dump is an old debugging interface, one of it's functions is used
to print the information about who write which file on disk. If we
enable block_dump through /proc/sys/vm/block_dump and turn on debug log
level, we can gather information about write process name, target file
name and disk from kernel message. This feature is realized in
block_dump___mark_inode_dirty(), it print above information into kernel
message directly when marking inode dirty, so it is noisy and can easily
trigger log storm. At the same time, get the dentry refcount is also not
safe, we found it will lead to deadlock on ext4 file system with
data=journal mode.
After tracepoints has been introduced into the kernel, we got a
tracepoint in __mark_inode_dirty(), which is a better replacement of
block_dump___mark_inode_dirty(). The only downside is that it only trace
the inode number and not a file name, but it probably doesn't matter
because the original printed file name in block_dump is not accurate in
some cases, and we can still find it through the inode number and device
id. So this patch delete the dirting inode part of block_dump feature.
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210313030146.2882027-2-yi.zhang@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3a8aff135045d3631f5afba6a26dbcaadfad4c90
Author: Chris Chiu <chris.chiu@canonical.com>
Date: Thu May 20 11:09:50 2021 +0800
ACPI: EC: Make more Asus laptops use ECDT _GPE
[ Upstream commit 6306f0431914beaf220634ad36c08234006571d5 ]
More ASUS laptops have the _GPE define in the DSDT table with a
different value than the _GPE number in the ECDT.
This is causing media keys not working on ASUS X505BA/BP, X542BA/BP
Add model info to the quirks list.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit aea6a00ad6027871f661da99666af6fa6509c83d
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Fri May 14 17:12:04 2021 +0100
lib: vsprintf: Fix handling of number field widths in vsscanf
[ Upstream commit 900fdc4573766dd43b847b4f54bd4a1ee2bc7360 ]
The existing code attempted to handle numbers by doing a strto[u]l(),
ignoring the field width, and then repeatedly dividing to extract the
field out of the full converted value. If the string contains a run of
valid digits longer than will fit in a long or long long, this would
overflow and no amount of dividing can recover the correct value.
This patch fixes vsscanf() to obey number field widths when parsing
the number.
A new _parse_integer_limit() is added that takes a limit for the number
of characters to parse. The number field conversion in vsscanf is changed
to use this new function.
If a number starts with a radix prefix, the field width must be long
enough for at last one digit after the prefix. If not, it will be handled
like this:
sscanf("0x4", "%1i", &i): i=0, scanning continues with the 'x'
sscanf("0x4", "%2i", &i): i=0, scanning continues with the '4'
This is consistent with the observed behaviour of userland sscanf.
Note that this patch does NOT fix the problem of a single field value
overflowing the target type. So for example:
sscanf("123456789abcdef", "%x", &i);
Will not produce the correct result because the value obviously overflows
INT_MAX. But sscanf will report a successful conversion.
Note that where a very large number is used to mean "unlimited", the value
INT_MAX is used for consistency with the behaviour of vsnprintf().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20210514161206.30821-2-rf@opensource.cirrus.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0cdf35809bb709014595ea13e31966dcd61cf066
Author: YueHaibing <yuehaibing@huawei.com>
Date: Fri May 14 15:01:16 2021 +0800
hv_utils: Fix passing zero to 'PTR_ERR' warning
[ Upstream commit c6a8625fa4c6b0a97860d053271660ccedc3d1b3 ]
Sparse warn this:
drivers/hv/hv_util.c:753 hv_timesync_init() warn:
passing zero to 'PTR_ERR'
Use PTR_ERR_OR_ZERO instead of PTR_ERR to fix this.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20210514070116.16800-1-yuehaibing@huawei.com
[ wei: change %ld to %d ]
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit eebf184071dce20813133ea9623d6e77e10362a4
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Wed May 12 17:15:14 2021 -0500
ACPI: processor idle: Fix up C-state latency if not ordered
[ Upstream commit 65ea8f2c6e230bdf71fed0137cf9e9d1b307db32 ]
Generally, the C-state latency is provided by the _CST method or
FADT, but some OEM platforms using AMD Picasso, Renoir, Van Gogh,
and Cezanne set the C2 latency greater than C3's which causes the
C2 state to be skipped.
That will block the core entering PC6, which prevents S0ix working
properly on Linux systems.
In other operating systems, the latency values are not validated and
this does not cause problems by skipping states.
To avoid this issue on Linux, detect when latencies are not an
arithmetic progression and sort them.
Link: https://gitlab.freedesktop.org/agd5f/linux/-/commit/026d186e4592c1ee9c1cb44295912d0294508725
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1230#note_712174
Suggested-by: Prike Liang <Prike.Liang@amd.com>
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 37aabd5daf945ccb03d3e4733dc12eb3beaa1e8b
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Fri Mar 19 17:27:16 2021 -0700
HID: do not use down_interruptible() when unbinding devices
[ Upstream commit f2145f8dc566c4f3b5a8deb58dcd12bed4e20194 ]
Action of unbinding driver from a device is not cancellable and should not
fail, and driver core does not pay attention to the result of "remove"
method, therefore using down_interruptible() in hid_device_remove() does
not make sense.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 171d0e86fc223b9c44625f134e0105c82105feaf
Author: Axel Lin <axel.lin@ingics.com>
Date: Fri Jun 18 22:14:11 2021 +0800
regulator: da9052: Ensure enough delay time for .set_voltage_time_sel
[ Upstream commit a336dc8f683e5be794186b5643cd34cb28dd2c53 ]
Use DIV_ROUND_UP to prevent truncation by integer division issue.
This ensures we return enough delay time.
Also fix returning negative value when new_sel < old_sel.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210618141412.4014912-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b127c17f76b312a9fcfdab3ed0c0dffa59bcf178
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date: Thu Jun 10 05:23:02 2021 +0000
btrfs: disable build on platforms having page size 256K
[ Upstream commit b05fbcc36be1f8597a1febef4892053a0b2f3f60 ]
With a config having PAGE_SIZE set to 256K, BTRFS build fails
with the following message
include/linux/compiler_types.h:326:38: error: call to
'__compiletime_assert_791' declared with attribute error:
BUILD_BUG_ON failed: (BTRFS_MAX_COMPRESSED % PAGE_SIZE) != 0
BTRFS_MAX_COMPRESSED being 128K, BTRFS cannot support platforms with
256K pages at the time being.
There are two platforms that can select 256K pages:
- hexagon
- powerpc
Disable BTRFS when 256K page size is selected. Supporting this would
require changes to the subpage mode that's currently being developed.
Given that 256K is many times larger than page sizes commonly used and
for what the algorithms and structures have been tuned, it's out of
scope and disabling build is a reasonable option.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e4e95f3532221b31c8528ee53e08a5ea5e20e071
Author: Josef Bacik <josef@toxicpanda.com>
Date: Fri May 21 16:44:09 2021 -0400
btrfs: abort transaction if we fail to update the delayed inode
[ Upstream commit 04587ad9bef6ce9d510325b4ba9852b6129eebdb ]
If we fail to update the delayed inode we need to abort the transaction,
because we could leave an inode with the improper counts or some other
such corruption behind.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2fccac17d85058c001309daeaae9fa0f1c55cbf1
Author: Josef Bacik <josef@toxicpanda.com>
Date: Fri May 21 16:44:08 2021 -0400
btrfs: fix error handling in __btrfs_update_delayed_inode
[ Upstream commit bb385bedded3ccbd794559600de4a09448810f4a ]
If we get an error while looking up the inode item we'll simply bail
without cleaning up the delayed node. This results in this style of
warning happening on commit:
WARNING: CPU: 0 PID: 76403 at fs/btrfs/delayed-inode.c:1365 btrfs_assert_delayed_root_empty+0x5b/0x90
CPU: 0 PID: 76403 Comm: fsstress Tainted: G W 5.13.0-rc1+ #373
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
RIP: 0010:btrfs_assert_delayed_root_empty+0x5b/0x90
RSP: 0018:ffffb8bb815a7e50 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff95d6d07e1888 RCX: ffff95d6c0fa3000
RDX: 0000000000000002 RSI: 000000000029e91c RDI: ffff95d6c0fc8060
RBP: ffff95d6c0fc8060 R08: 00008d6d701a2c1d R09: 0000000000000000
R10: ffff95d6d1760ea0 R11: 0000000000000001 R12: ffff95d6c15a4d00
R13: ffff95d6c0fa3000 R14: 0000000000000000 R15: ffffb8bb815a7e90
FS: 00007f490e8dbb80(0000) GS:ffff95d73bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6e75555cb0 CR3: 00000001101ce001 CR4: 0000000000370ef0
Call Trace:
btrfs_commit_transaction+0x43c/0xb00
? finish_wait+0x80/0x80
? vfs_fsync_range+0x90/0x90
iterate_supers+0x8c/0x100
ksys_sync+0x50/0x90
__do_sys_sync+0xa/0x10
do_syscall_64+0x3d/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Because the iref isn't dropped and this leaves an elevated node->count,
so any release just re-queues it onto the delayed inodes list. Fix this
by going to the out label to handle the proper cleanup of the delayed
node.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2744d3fdcc3c49f819774ca6bee629344ae013bb
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date: Thu Jun 10 08:57:02 2021 +0200
media: siano: fix device register error path
[ Upstream commit 5368b1ee2939961a16e74972b69088433fc52195 ]
As reported by smatch:
drivers/media/common/siano/smsdvb-main.c:1231 smsdvb_hotplug() warn: '&client->entry' not removed from list
If an error occur at the end of the registration logic, it won't
drop the device from the list.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 00d1d5c6c6536b755f9bfc9905f2f4b3baf2e9d7
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date: Wed Jun 16 13:13:54 2021 +0200
media: dvb_net: avoid speculation from net slot
[ Upstream commit abc0226df64dc137b48b911c1fe4319aec5891bb ]
The risk of especulation is actually almost-non-existing here,
as there are very few users of TCP/IP using the DVB stack,
as, this is mainly used with DVB-S/S2 cards, and only by people
that receives TCP/IP from satellite connections, which limits
a lot the number of users of such feature(*).
(*) In thesis, DVB-C cards could also benefit from it, but I'm
yet to see a hardware that supports it.
Yet, fixing it is trivial.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 391b50b5b844a73a1fa9a619202d0185b02f1699
Author: Ard Biesheuvel <ardb@kernel.org>
Date: Thu Jun 10 08:21:50 2021 +0200
crypto: shash - avoid comparing pointers to exported functions under CFI
[ Upstream commit 22ca9f4aaf431a9413dcc115dd590123307f274f ]
crypto_shash_alg_has_setkey() is implemented by testing whether the
.setkey() member of a struct shash_alg points to the default version,
called shash_no_setkey(). As crypto_shash_alg_has_setkey() is a static
inline, this requires shash_no_setkey() to be exported to modules.
Unfortunately, when building with CFI, function pointers are routed
via CFI stubs which are private to each module (or to the kernel proper)
and so this function pointer comparison may fail spuriously.
Let's fix this by turning crypto_shash_alg_has_setkey() into an out of
line function.
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9223182df155b241f2dd6cb557731f224fc4a78a
Author: Zheyu Ma <zheyuma97@gmail.com>
Date: Thu Jun 3 13:33:20 2021 +0000
mmc: via-sdmmc: add a check against NULL pointer dereference
[ Upstream commit 45c8ddd06c4b729c56a6083ab311bfbd9643f4a6 ]
Before referencing 'host->data', the driver needs to check whether it is
null pointer, otherwise it will cause a null pointer reference.
This log reveals it:
[ 29.355199] BUG: kernel NULL pointer dereference, address:
0000000000000014
[ 29.357323] #PF: supervisor write access in kernel mode
[ 29.357706] #PF: error_code(0x0002) - not-present page
[ 29.358088] PGD 0 P4D 0
[ 29.358280] Oops: 0002 [#1] PREEMPT SMP PTI
[ 29.358595] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.12.4-
g70e7f0549188-dirty #102
[ 29.359164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 29.359978] RIP: 0010:via_sdc_isr+0x21f/0x410
[ 29.360314] Code: ff ff e8 84 aa d0 fd 66 45 89 7e 28 66 41 f7 c4 00
10 75 56 e8 72 aa d0 fd 66 41 f7 c4 00 c0 74 10 e8 65 aa d0 fd 48 8b 43
18 <c7> 40 14 ac ff ff ff e8 55 aa d0 fd 48 89 df e8 ad fb ff ff e9 77
[ 29.361661] RSP: 0018:ffffc90000118e98 EFLAGS: 00010046
[ 29.362042] RAX: 0000000000000000 RBX: ffff888107d77880
RCX: 0000000000000000
[ 29.362564] RDX: 0000000000000000 RSI: ffffffff835d20bb
RDI: 00000000ffffffff
[ 29.363085] RBP: ffffc90000118ed8 R08: 0000000000000001
R09: 0000000000000001
[ 29.363604] R10: 0000000000000000 R11: 0000000000000001
R12: 0000000000008600
[ 29.364128] R13: ffff888107d779c8 R14: ffffc90009c00200
R15: 0000000000008000
[ 29.364651] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000)
knlGS:0000000000000000
[ 29.365235] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 29.365655] CR2: 0000000000000014 CR3: 0000000005a2e000
CR4: 00000000000006e0
[ 29.366170] DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
[ 29.366683] DR3: 0000000000000000 DR6: 00000000fffe0ff0
DR7: 0000000000000400
[ 29.367197] Call Trace:
[ 29.367381] <IRQ>
[ 29.367537] __handle_irq_event_percpu+0x53/0x3e0
[ 29.367916] handle_irq_event_percpu+0x35/0x90
[ 29.368247] handle_irq_event+0x39/0x60
[ 29.368632] handle_fasteoi_irq+0xc2/0x1d0
[ 29.368950] __common_interrupt+0x7f/0x150
[ 29.369254] common_interrupt+0xb4/0xd0
[ 29.369547] </IRQ>
[ 29.369708] asm_common_interrupt+0x1e/0x40
[ 29.370016] RIP: 0010:native_safe_halt+0x17/0x20
[ 29.370360] Code: 07 0f 00 2d db 80 43 00 f4 5d c3 0f 1f 84 00 00 00
00 00 8b 05 c2 37 e5 01 55 48 89 e5 85 c0 7e 07 0f 00 2d bb 80 43 00 fb
f4 <5d> c3 cc cc cc cc cc cc cc 55 48 89 e5 e8 67 53 ff ff 8b 0d f9 91
[ 29.371696] RSP: 0018:ffffc9000008fe90 EFLAGS: 00000246
[ 29.372079] RAX: 0000000000000000 RBX: 0000000000000002
RCX: 0000000000000000
[ 29.372595] RDX: 0000000000000000 RSI: ffffffff854f67a4
RDI: ffffffff85403406
[ 29.373122] RBP: ffffc9000008fe90 R08: 0000000000000001
R09: 0000000000000001
[ 29.373646] R10: 0000000000000000 R11: 0000000000000001
R12: ffffffff86009188
[ 29.374160] R13: 0000000000000000 R14: 0000000000000000
R15: ffff888100258000
[ 29.374690] default_idle+0x9/0x10
[ 29.374944] arch_cpu_idle+0xa/0x10
[ 29.375198] default_idle_call+0x6e/0x250
[ 29.375491] do_idle+0x1f0/0x2d0
[ 29.375740] cpu_startup_entry+0x18/0x20
[ 29.376034] start_secondary+0x11f/0x160
[ 29.376328] secondary_startup_64_no_verify+0xb0/0xbb
[ 29.376705] Modules linked in:
[ 29.376939] Dumping ftrace buffer:
[ 29.377187] (ftrace buffer empty)
[ 29.377460] CR2: 0000000000000014
[ 29.377712] ---[ end trace 51a473dffb618c47 ]---
[ 29.378056] RIP: 0010:via_sdc_isr+0x21f/0x410
[ 29.378380] Code: ff ff e8 84 aa d0 fd 66 45 89 7e 28 66 41 f7 c4 00
10 75 56 e8 72 aa d0 fd 66 41 f7 c4 00 c0 74 10 e8 65 aa d0 fd 48 8b 43
18 <c7> 40 14 ac ff ff ff e8 55 aa d0 fd 48 89 df e8 ad fb ff ff e9 77
[ 29.379714] RSP: 0018:ffffc90000118e98 EFLAGS: 00010046
[ 29.380098] RAX: 0000000000000000 RBX: ffff888107d77880
RCX: 0000000000000000
[ 29.380614] RDX: 0000000000000000 RSI: ffffffff835d20bb
RDI: 00000000ffffffff
[ 29.381134] RBP: ffffc90000118ed8 R08: 0000000000000001
R09: 0000000000000001
[ 29.381653] R10: 0000000000000000 R11: 0000000000000001
R12: 0000000000008600
[ 29.382176] R13: ffff888107d779c8 R14: ffffc90009c00200
R15: 0000000000008000
[ 29.382697] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000)
knlGS:0000000000000000
[ 29.383277] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 29.383697] CR2: 0000000000000014 CR3: 0000000005a2e000
CR4: 00000000000006e0
[ 29.384223] DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
[ 29.384736] DR3: 0000000000000000 DR6: 00000000fffe0ff0
DR7: 0000000000000400
[ 29.385260] Kernel panic - not syncing: Fatal exception in interrupt
[ 29.385882] Dumping ftrace buffer:
[ 29.386135] (ftrace buffer empty)
[ 29.386401] Kernel Offset: disabled
[ 29.386656] Rebooting in 1 seconds..
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Link: https://lore.kernel.org/r/1622727200-15808-1-git-send-email-zheyuma97@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 180f1b0195de37043ae7442a269fe1aebf3ed61b
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date: Tue May 25 15:06:52 2021 +0200
media: dvd_usb: memory leak in cinergyt2_fe_attach
[ Upstream commit 9ad1efee086e0e913914fa2b2173efb830bad68c ]
When the driver fails to talk with the hardware with dvb_usb_generic_rw,
it will return an error to dvb_usb_adapter_frontend_init. However, the
driver forgets to free the resource (e.g., struct cinergyt2_fe_state),
which leads to a memory leak.
Fix this by freeing struct cinergyt2_fe_state when dvb_usb_generic_rw
fails in cinergyt2_frontend_attach.
backtrace:
[<0000000056e17b1a>] kmalloc include/linux/slab.h:552 [inline]
[<0000000056e17b1a>] kzalloc include/linux/slab.h:682 [inline]
[<0000000056e17b1a>] cinergyt2_fe_attach+0x21/0x80 drivers/media/usb/dvb-usb/cinergyT2-fe.c:271
[<00000000ae0b1711>] cinergyt2_frontend_attach+0x21/0x70 drivers/media/usb/dvb-usb/cinergyT2-core.c:74
[<00000000d0254861>] dvb_usb_adapter_frontend_init+0x11b/0x1b0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290
[<0000000002e08ac6>] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:84 [inline]
[<0000000002e08ac6>] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:173 [inline]
[<0000000002e08ac6>] dvb_usb_device_init.cold+0x4d0/0x6ae drivers/media/usb/dvb-usb/dvb-usb-init.c:287
Reported-by: syzbot+e1de8986786b3722050e@syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0b4d122394e9ede5ca44d2600eacb5ddaef50a3d
Author: Evgeny Novikov <novikov@ispras.ru>
Date: Wed May 19 14:04:49 2021 +0200
media: st-hva: Fix potential NULL pointer dereferences
[ Upstream commit b7fdd208687ba59ebfb09b2199596471c63b69e3 ]
When ctx_id >= HVA_MAX_INSTANCES in hva_hw_its_irq_thread() it tries to
access fields of ctx that is NULL at that point. The patch gets rid of
these accesses.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7069eeff5f11d6e80b781a8368cc9605d0de99b6
Author: Zheyu Ma <zheyuma97@gmail.com>
Date: Wed May 12 17:18:36 2021 +0200
media: bt8xx: Fix a missing check bug in bt878_probe
[ Upstream commit 1a4520090681853e6b850cbe54b27247a013e0e5 ]
In 'bt878_irq', the driver calls 'tasklet_schedule', but this tasklet is
set in 'dvb_bt8xx_load_card' of another driver 'dvb-bt8xx'.
However, this two drivers are separate. The user may not load the
'dvb-bt8xx' driver when loading the 'bt8xx' driver, that is, the tasklet
has not been initialized when 'tasklet_schedule' is called, so it is
necessary to check whether the tasklet is initialized in 'bt878_probe'.
Fix this by adding a check at the end of bt878_probe.
The KASAN's report reveals it:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 800000006aab2067 P4D 800000006aab2067 PUD 6b2ea067 PMD 0
Oops: 0010 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 8724 Comm: syz-executor.0 Not tainted 4.19.177-
gdba4159c14ef-dirty #40
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-
gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:ffff88806c287ea0 EFLAGS: 00010246
RAX: fffffbfff1b01774 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffffffff1b01775 RDI: 0000000000000000
RBP: ffff88806c287f00 R08: fffffbfff1b01774 R09: fffffbfff1b01774
R10: 0000000000000001 R11: fffffbfff1b01773 R12: 0000000000000000
R13: ffff88806c29f530 R14: ffffffff8d80bb88 R15: ffffffff8d80bb90
FS: 00007f6b550e6700(0000) GS:ffff88806c280000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 000000005ec98000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
tasklet_action_common.isra.17+0x141/0x420 kernel/softirq.c:522
tasklet_action+0x50/0x70 kernel/softirq.c:540
__do_softirq+0x224/0x92c kernel/softirq.c:292
invoke_softirq kernel/softirq.c:372 [inline]
irq_exit+0x15a/0x180 kernel/softirq.c:412
exiting_irq arch/x86/include/asm/apic.h:535 [inline]
do_IRQ+0x123/0x1e0 arch/x86/kernel/irq.c:260
common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
</IRQ>
RIP: 0010:__do_sys_interrupt kernel/sys.c:2593 [inline]
RIP: 0010:__se_sys_interrupt kernel/sys.c:2584 [inline]
RIP: 0010:__x64_sys_interrupt+0x5b/0x80 kernel/sys.c:2584
Code: ba 00 04 00 00 48 c7 c7 c0 99 31 8c e8 ae 76 5e 01 48 85 c0 75 21 e8
14 ae 24 00 48 c7 c3 c0 99 31 8c b8 0c 00 00 00 0f 01 c1 <31> db e8 fe ad
24 00 48 89 d8 5b 5d c3 48 c7 c3 ea ff ff ff eb ec
RSP: 0018:ffff888054167f10 EFLAGS: 00000212 ORIG_RAX: ffffffffffffffde
RAX: 000000000000000c RBX: ffffffff8c3199c0 RCX: ffffc90001ca6000
RDX: 000000000000001a RSI: ffffffff813478fc RDI: ffffffff8c319dc0
RBP: ffff888054167f18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000080 R11: fffffbfff18633b7 R12: ffff888054167f58
R13: ffff88805f638000 R14: 0000000000000000 R15: 0000000000000000
do_syscall_64+0xb0/0x4e0 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4692a9
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f6b550e5c48 EFLAGS: 00000246 ORIG_RAX: 000000000000014f
RAX: ffffffffffffffda RBX: 000000000077bf60 RCX: 00000000004692a9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140
RBP: 00000000004cf7eb R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf60
R13: 0000000000000000 R14: 000000000077bf60 R15: 00007fff55a1dca0
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
CR2: 0000000000000000
---[ end trace 68e5849c3f77cbb6 ]---
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:ffff88806c287ea0 EFLAGS: 00010246
RAX: fffffbfff1b01774 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffffffff1b01775 RDI: 0000000000000000
RBP: ffff88806c287f00 R08: fffffbfff1b01774 R09: fffffbfff1b01774
R10: 0000000000000001 R11: fffffbfff1b01773 R12: 0000000000000000
R13: ffff88806c29f530 R14: ffffffff8d80bb88 R15: ffffffff8d80bb90
FS: 00007f6b550e6700(0000) GS:ffff88806c280000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 000000005ec98000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Reported-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 01da7812c03bbce49efd1037e7eb4c20984e6fa0
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date: Sun May 9 10:24:02 2021 +0200
media: v4l2-core: Avoid the dangling pointer in v4l2_fh_release
[ Upstream commit 7dd0c9e547b6924e18712b6b51aa3cba1896ee2c ]
A use after free bug caused by the dangling pointer
filp->privitate_data in v4l2_fh_release.
See https://lore.kernel.org/patchwork/patch/1419058/.
My patch sets the dangling pointer to NULL to provide
robust.
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d4f48bb8b973a5cbef39f58c8213b032d66bb354
Author: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Date: Tue May 4 20:32:49 2021 +0200
media: em28xx: Fix possible memory leak of em28xx struct
[ Upstream commit ac5688637144644f06ed1f3c6d4dd8bb7db96020 ]
The em28xx struct kref isn't being decreased after an error in the
em28xx_ir_init, leading to a possible memory leak.
A kref_put and em28xx_shutdown_buttons is added to the error handler code.
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2d7d84cf7b74b35a2e5e27c34d8a83835425524f
Author: Jack Xu <jack.xu@intel.com>
Date: Mon May 17 05:13:16 2021 -0400
crypto: qat - remove unused macro in FW loader
[ Upstream commit 9afe77cf25d9670e61b489fd52cc6f75fd7f6803 ]
Remove the unused macro ICP_DH895XCC_PESRAM_BAR_SIZE in the firmware
loader.
This is to fix the following warning when compiling the driver using the
clang compiler with CC=clang W=2:
drivers/crypto/qat/qat_common/qat_uclo.c:345:9: warning: macro is not used [-Wunused-macros]
Signed-off-by: Jack Xu <jack.xu@intel.com>
Co-developed-by: Zhehui Xiang <zhehui.xiang@intel.com>
Signed-off-by: Zhehui Xiang <zhehui.xiang@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 93a1633f406084726de878cf20ac85346c485030
Author: Jack Xu <jack.xu@intel.com>
Date: Mon May 17 05:13:15 2021 -0400
crypto: qat - check return code of qat_hal_rd_rel_reg()
[ Upstream commit 96b57229209490c8bca4335b01a426a96173dc56 ]
Check the return code of the function qat_hal_rd_rel_reg() and return it
to the caller.
This is to fix the following warning when compiling the driver with
clang scan-build:
drivers/crypto/qat/qat_common/qat_hal.c:1436:2: warning: 6th function call argument is an uninitialized value
Signed-off-by: Jack Xu <jack.xu@intel.com>
Co-developed-by: Zhehui Xiang <zhehui.xiang@intel.com>
Signed-off-by: Zhehui Xiang <zhehui.xiang@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit df74607b41111de08ceac7fbb1a75668d73dc698
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date: Tue May 4 19:08:58 2021 +0200
media: pvrusb2: fix warning in pvr2_i2c_core_done
[ Upstream commit f8194e5e63fdcb349e8da9eef9e574d5b1d687cb ]
syzbot has reported the following warning in pvr2_i2c_done:
sysfs group 'power' not found for kobject '1-0043'
When the device is disconnected (pvr_hdw_disconnect), the i2c adapter is
not unregistered along with the USB and v4l2 teardown. As part of the USB
device disconnect, the sysfs files of the subdevices are also deleted.
So, by the time pvr_i2c_core_done is called by pvr_context_destroy, the
sysfs files have been deleted.
To fix this, unregister the i2c adapter too in pvr_hdw_disconnect. Make
the device deregistration code shared by calling pvr_hdw_disconnect from
pvr2_hdw_destroy.
Reported-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com
Tested-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit dd8e8acb32c62acd0dce202ba943d378df8eaeb4
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date: Fri Apr 23 10:00:49 2021 +0200
media: cobalt: fix race condition in setting HPD
[ Upstream commit 3d37ef41bed0854805ab9af22c422267510e1344 ]
The cobalt_s_bit_sysctrl reads the old register value over PCI,
then changes a bit and sets writes the new value to the register.
This is used among other things for setting the HPD output pin.
But if the HPD is changed for multiple inputs at the same time,
then this causes a race condition where a stale value is read.
Serialize this function with a mutex.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 23abeea9dd40a1dcaa0a60acf14daec01b55a66e
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Wed Apr 21 21:43:45 2021 +0200
media: cpia2: fix memory leak in cpia2_usb_probe
[ Upstream commit be8656e62e9e791837b606a027802b504a945c97 ]
syzbot reported leak in cpia2 usb driver. The problem was
in invalid error handling.
v4l2_device_register() is called in cpia2_init_camera_struct(), but
all error cases after cpia2_init_camera_struct() did not call the
v4l2_device_unregister()
Reported-by: syzbot+d1e69c888f0d3866ead4@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8fe0436c40b6c8e464f4e7f6fa07e55e56e1d98b
Author: Bixuan Cui <cuibixuan@huawei.com>
Date: Sat May 8 11:14:55 2021 +0800
crypto: nx - add missing MODULE_DEVICE_TABLE
[ Upstream commit 06676aa1f455c74e3ad1624cea3acb9ed2ef71ae ]
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 09ee6e28304f488f38a584e7073fa28b8e7100e2
Author: Tian Tao <tiantao6@hisilicon.com>
Date: Thu Apr 29 19:20:48 2021 +0800
spi: omap-100k: Fix the length judgment problem
[ Upstream commit e7a1a3abea373e41ba7dfe0fbc93cb79b6a3a529 ]
word_len should be checked in the omap1_spi100k_setup_transfer
function to see if it exceeds 32.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Link: https://lore.kernel.org/r/1619695248-39045-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e812d75e752d0e5e0c461cd6373d786140bc53f2
Author: Jay Fang <f.fangjian@huawei.com>
Date: Thu May 6 15:08:08 2021 +0800
spi: spi-topcliff-pch: Fix potential double free in pch_spi_process_messages()
[ Upstream commit 026a1dc1af52742c5897e64a3431445371a71871 ]
pch_spi_set_tx() frees data->pkt_tx_buff on failure of kzalloc() for
data->pkt_rx_buff, but its caller, pch_spi_process_messages(), will
free data->pkt_tx_buff again. Set data->pkt_tx_buff to NULL after
kfree() to avoid double free.
Signed-off-by: Jay Fang <f.fangjian@huawei.com>
Link: https://lore.kernel.org/r/1620284888-65215-1-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit de8b2276d404d9b5c194c5c6f363eaea07dc55c7
Author: Jay Fang <f.fangjian@huawei.com>
Date: Mon May 10 14:58:23 2021 +0800
spi: spi-loopback-test: Fix 'tx_buf' might be 'rx_buf'
[ Upstream commit 9e37a3ab0627011fb63875e9a93094b6fc8ddf48 ]
In function 'spi_test_run_iter': Value 'tx_buf' might be 'rx_buf'.
Signed-off-by: Jay Fang <f.fangjian@huawei.com>
Link: https://lore.kernel.org/r/1620629903-15493-5-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 73ae6e1fc91e7fe8ab56014f6730d24d739f534d
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date: Wed Apr 21 11:14:02 2021 +0100
spi: Make of_register_spi_device also set the fwnode
[ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ]
Currently, the SPI core doesn't set the struct device fwnode pointer
when it creates a new SPI device. This means when the device is
registered the fwnode is NULL and the check in device_add which sets
the fwnode->dev pointer is skipped. This wasn't previously an issue,
however these two patches:
commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
fw_devlink=on by default")
commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the
primary device")
Added some code to the GPIO core which relies on using that
fwnode->dev pointer to determine if a driver is bound to the fwnode
and if not bind a stub GPIO driver. This means the GPIO providers
behind SPI will get both the expected driver and this stub driver
causing the stub driver to fail if it attempts to request any pin
configuration. For example on my system:
madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3
madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22
madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1 on device madera-pinctrl
gpio_stub_drv gpiochip3: Error applying setting, reverse things back
gpio_stub_drv: probe of gpiochip3 failed with error -22
The firmware node on the device created by the GPIO framework is set
through the of_node pointer hence things generally actually work,
however that fwnode->dev is never set, as the check was skipped at
device_add time. This fix appears to match how the I2C subsystem
handles the same situation.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b9a7ef4e8eeccc251d0b23df4ec20879372cb76d
Author: Miklos Szeredi <mszeredi@redhat.com>
Date: Tue Jun 22 09:15:35 2021 +0200
fuse: check connected before queueing on fpq->io
commit 80ef08670d4c28a06a3de954bd350368780bcfef upstream.
A request could end up on the fpq->io list after fuse_abort_conn() has
reset fpq->connected and aborted requests on that list:
Thread-1 Thread-2
======== ========
->fuse_simple_request() ->shutdown
->__fuse_request_send()
->queue_request() ->fuse_abort_conn()
->fuse_dev_do_read() ->acquire(fpq->lock)
->wait_for(fpq->lock) ->set err to all req's in fpq->io
->release(fpq->lock)
->acquire(fpq->lock)
->add req to fpq->io
After the userspace copy is done the request will be ended, but
req->out.h.error will remain uninitialized. Also the copy might block
despite being already aborted.
Fix both issues by not allowing the request to be queued on the fpq->io
list after fuse_abort_conn() has processed this list.
Reported-by: Pradeep P V K <pragalla@codeaurora.org>
Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
Cc: <stable@vger.kernel.org> # v4.2
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 675b56e1390bf0d282931da701a908b951ee4061
Author: Yun Zhou <yun.zhou@windriver.com>
Date: Sat Jun 26 11:21:56 2021 +0800
seq_buf: Make trace_seq_putmem_hex() support data longer than 8
commit 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 upstream.
Since the raw memory 'data' does not go forward, it will dump repeated
data if the data length is more than 8. If we want to dump longer data
blocks, we need to repeatedly call macro SEQ_PUT_HEX_FIELD. I think it
is a bit redundant, and multiple function calls also affect the performance.
Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/
Link: https://lkml.kernel.org/r/20210626032156.47889-2-yun.zhou@windriver.com
Cc: stable@vger.kernel.org
Fixes: 6d2289f3faa7 ("tracing: Make trace_seq_putmem_hex() more robust")
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c5fac2a1bc75f133e5d1b28be5ab1f0103ce637b
Author: Marek Vasut <marex@denx.de>
Date: Fri May 7 23:31:05 2021 +0200
rsi: Assign beacon rate settings to the correct rate_info descriptor field
commit b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 upstream.
The RSI_RATE_x bits must be assigned to struct rsi_data_desc rate_info
field. The rest of the driver does it correctly, except this one place,
so fix it. This is also aligned with the RSI downstream vendor driver.
Without this patch, an AP operating at 5 GHz does not transmit any
beacons at all, this patch fixes that.
Fixes: d26a9559403c ("rsi: add beacon changes for AP mode")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com>
Cc: Angus Ainslie <angus@akkea.ca>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Karun Eagalapati <karun256@gmail.com>
Cc: Martin Kepplinger <martink@posteo.de>
Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Cc: Siva Rebbagondla <siva8118@gmail.com>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210507213105.140138-1-marex@denx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ccaf101e780a04a273bddefdd23aa52ace2ad89f
Author: Michael Buesch <m@bues.ch>
Date: Sat May 15 21:02:52 2021 +0200
ssb: sdio: Don't overwrite const buffer if block_write fails
commit 47ec636f7a25aa2549e198c48ecb6b1c25d05456 upstream.
It doesn't make sense to clobber the const driver-side buffer, if a
write-to-device attempt failed. All other SSB variants (PCI, PCMCIA and SoC)
also don't corrupt the buffer on any failure in block_write.
Therefore, remove this memset from the SDIO variant.
Signed-off-by: Michael Büsch <m@bues.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c68d07718b5e23ecdc95298dfe2528af54861626
Author: Pali Rohár <pali@kernel.org>
Date: Mon May 31 17:41:27 2021 +0300
ath9k: Fix kernel NULL pointer dereference during ath_reset_internal()
commit fb312ac5ccb007e843f982b38d4d6886ba4b32f2 upstream.
I got this crash more times during debugging of PCIe controller and crash
happens somehow at the time when PCIe kernel code started link retraining (as
part of ASPM code) when at the same time PCIe link went down and ath9k probably
executed hw reset procedure.
Currently I'm not able to reproduce this issue as it looks like to be
some race condition between link training, ASPM, link down and reset
path. And as always, race conditions which depends on more input
parameters are hard to reproduce as it depends on precise timings.
But it is clear that pointers are zero in this case and should be
properly filled as same code pattern is used in ath9k_stop() function.
Anyway I was able to reproduce this crash by manually triggering ath
reset worker prior putting card up. I created simple patch to export
reset functionality via debugfs and use it to "simulate" of triggering
reset. s proved that NULL-pointer dereference issue is there.
Function ath9k_hw_reset() is dereferencing chan structure pointer, so it
needs to be non-NULL pointer.
Function ath9k_stop() already contains code which sets ah->curchan to valid
non-NULL pointer prior calling ath9k_hw_reset() function.
Add same code pattern also into ath_reset_internal() function to prevent
kernel NULL pointer dereference in ath9k_hw_reset() function.
This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which
is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL
chan structure.
[ 45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
[ 45.344417] Mem abort info:
[ 45.347301] ESR = 0x96000005
[ 45.350448] EC = 0x25: DABT (current EL), IL = 32 bits
[ 45.356166] SET = 0, FnV = 0
[ 45.359350] EA = 0, S1PTW = 0
[ 45.362596] Data abort info:
[ 45.365756] ISV = 0, ISS = 0x00000005
[ 45.369735] CM = 0, WnR = 0
[ 45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000
[ 45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 45.388856] Internal error: Oops: 96000005 [#1] SMP
[ 45.393897] Modules linked in: ath9k ath9k_common ath9k_hw
[ 45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785
[ 45.414746] Workqueue: phy0 ath_reset_work [ath9k]
[ 45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[ 45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw]
[ 45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw]
[ 45.436548] sp : ffffffc0118dbca0
[ 45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000
[ 45.445442] x27: ffffff800dee4080 x26: 0000000000000000
[ 45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000
[ 45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408
[ 45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8
[ 45.467366] x19: 0000000000000000 x18: 0000000000000000
[ 45.472846] x17: 0000000000000000 x16: 0000000000000000
[ 45.478326] x15: 0000000000000010 x14: ffffffffffffffff
[ 45.483807] x13: ffffffc0918db94f x12: ffffffc011498720
[ 45.489289] x11: 0000000000000003 x10: ffffffc0114806e0
[ 45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8
[ 45.500251] x7 : c0000000ffffefff x6 : 0000000000000001
[ 45.505733] x5 : 0000000000000000 x4 : 0000000000000000
[ 45.511213] x3 : 0000000000000000 x2 : ffffff801fece870
[ 45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f
[ 45.522174] Call trace:
[ 45.524695] ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw]
[ 45.529653] ath_reset_internal+0x1a8/0x2b8 [ath9k]
[ 45.534696] ath_reset_work+0x2c/0x40 [ath9k]
[ 45.539198] process_one_work+0x210/0x480
[ 45.543339] worker_thread+0x5c/0x510
[ 45.547115] kthread+0x12c/0x130
[ 45.550445] ret_from_fork+0x10/0x1c
[ 45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61)
[ 45.560430] ---[ end trace 566410ba90b50e8b ]---
[ 45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 45.572282] SMP: stopping secondary CPUs
[ 45.576331] Kernel Offset: disabled
[ 45.579924] CPU features: 0x00040002,0000200c
[ 45.584416] Memory Limit: none
[ 45.587564] Rebooting in 3 seconds..
Signed-off-by: Pali Rohár <pali@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4e6c942926320605ca0886a0c7ca382a46e8e9e
Author: Ondrej Zary <linux@zary.sk>
Date: Fri Jun 11 22:19:39 2021 +0200
serial_cs: remove wrong GLOBETROTTER.cis entry
commit 11b1d881a90fc184cc7d06e9804eb288c24a2a0d upstream.
The GLOBETROTTER.cis entry in serial_cs matches more devices than
intended and breaks them. Remove it.
Example: # pccardctl info
PRODID_1="Option International
"
PRODID_2="GSM-Ready 56K/ISDN
"
PRODID_3="021
"
PRODID_4="A
"
MANFID=0013,0000
FUNCID=0
result:
pcmcia 0.0: Direct firmware load for cis/GLOBETROTTER.cis failed with error -2
The GLOBETROTTER.cis is nowhere to be found. There's GLOBETROTTER.cis.ihex at
https://netdev.vger.kernel.narkive.com/h4inqdxM/patch-axnet-cs-fix-phy-id-detection-for-bogus-asix-chip#post41
It's from completely diffetent card:
vers_1 4.1, "Option International", "GSM/GPRS GlobeTrotter", "001", "A"
Signed-off-by: Ondrej Zary <linux@zary.sk>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5e310acb32099c290fa07fae6db7de735b3283f9
Author: Ondrej Zary <linux@zary.sk>
Date: Fri Jun 11 22:19:40 2021 +0200
serial_cs: Add Option International GSM-Ready 56K/ISDN modem
commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream.
Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem
card.
Signed-off-by: Ondrej Zary <linux@zary.sk>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 13b5a80be5443d81b3ccd0e5bb3c5110f326a004
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Thu Jun 10 20:08:06 2021 +0900
serial: sh-sci: Stop dmaengine transfer in sci_stop_tx()
commit 08a84410a04f05c7c1b8e833f552416d8eb9f6fe upstream.
Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following
message is possible output when system enters suspend and while
transferring data, because clearing TIE bit in SCSCR is not able to
stop any dmaengine transfer.
sh-sci e6550000.serial: ttySC1: Unable to drain transmitter
Note that this driver has already used some #ifdef in the .c file
so that this patch also uses #ifdef to fix the issue. Otherwise,
build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled.
Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dc5e47b9227f15f3d973e4e822d6156aef294001
Author: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
Date: Thu Jun 10 15:46:18 2021 +0200
iio: ltr501: ltr501_read_ps(): add missing endianness conversion
commit 71b33f6f93ef9462c84560e2236ed22209d26a58 upstream.
The PS ADC Channel data is spread over 2 registers in little-endian
form. This patch adds the missing endianness conversion.
Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
Signed-off-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 51c1ab060fd08f8109a0ed7602e6328d2470aadb
Author: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
Date: Thu Jun 10 15:46:17 2021 +0200
iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR
commit 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 upstream.
The ltr559 chip uses only the lowest bit of the ALS_CONTR register to
configure between active and stand-by mode. In the original driver
BIT(1) is used, which does a software reset instead.
This patch fixes the problem by using BIT(0) as als_mode_active for
the ltr559 chip.
Fixes: 8592a7eefa54 ("iio: ltr501: Add support for ltr559 chip")
Signed-off-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9bcecc967a355f6b985929f51df61d3d2588bd1
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu Jun 10 15:46:16 2021 +0200
iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and PS_DATA as volatile, too
commit 2ac0b029a04b673ce83b5089368f467c5dca720c upstream.
The regmap is configured for 8 bit registers, uses a RB-Tree cache and
marks several registers as volatile (i.e. do not cache).
The ALS and PS data registers in the chip are 16 bit wide and spans
two regmap registers. In the current driver only the base register is
marked as volatile, resulting in the upper register only read once.
Further the data sheet notes:
| When the I2C read operation starts, all four ALS data registers are
| locked until the I2C read operation of register 0x8B is completed.
Which results in the registers never update after the 2nd read.
This patch fixes the problem by marking the upper 8 bits of the ALS
and PS registers as volatile, too.
Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.")
Reported-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e73dcdf669fb0951c9e2c160f9e9da8c522b0a09
Author: Martin Fuzzey <martin.fuzzey@flowbird.group>
Date: Mon Jun 7 19:36:40 2021 +0200
rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path
commit 950ac33dbe6ff656a623d862022f0762ec061ba7 upstream.
The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck.
If clk_prepare_enable() fails for the second clock (rtc_ck) we must only
call clk_disable_unprepare() for the first clock (pclk) but currently we
call it on both leading to a WARN:
[ 15.629568] WARNING: CPU: 0 PID: 146 at drivers/clk/clk.c:958 clk_core_disable+0xb0/0xc8
[ 15.637620] ck_rtc already disabled
[ 15.663322] CPU: 0 PID: 146 Comm: systemd-udevd Not tainted 5.4.77-pknbsp-svn5759-atag-v5.4.77-204-gea4235203137-dirty #2413
[ 15.674510] Hardware name: STM32 (Device Tree Support)
[ 15.679658] [<c0111148>] (unwind_backtrace) from [<c010c0b8>] (show_stack+0x10/0x14)
[ 15.687371] [<c010c0b8>] (show_stack) from [<c0ab3d28>] (dump_stack+0xc0/0xe0)
[ 15.694574] [<c0ab3d28>] (dump_stack) from [<c012360c>] (__warn+0xc8/0xf0)
[ 15.701428] [<c012360c>] (__warn) from [<c0123694>] (warn_slowpath_fmt+0x60/0x94)
[ 15.708894] [<c0123694>] (warn_slowpath_fmt) from [<c053b518>] (clk_core_disable+0xb0/0xc8)
[ 15.717230] [<c053b518>] (clk_core_disable) from [<c053c190>] (clk_core_disable_lock+0x18/0x24)
[ 15.725924] [<c053c190>] (clk_core_disable_lock) from [<bf0adc44>] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32])
[ 15.735739] [<bf0adc44>] (stm32_rtc_probe [rtc_stm32]) from [<c05f7d4c>] (platform_drv_probe+0x48/0x98)
[ 15.745095] [<c05f7d4c>] (platform_drv_probe) from [<c05f5cec>] (really_probe+0x1f0/0x458)
[ 15.753338] [<c05f5cec>] (really_probe) from [<c05f61c4>] (driver_probe_device+0x70/0x1c4)
[ 15.761584] [<c05f61c4>] (driver_probe_device) from [<c05f6580>] (device_driver_attach+0x58/0x60)
[ 15.770439] [<c05f6580>] (device_driver_attach) from [<c05f6654>] (__driver_attach+0xcc/0x170)
[ 15.779032] [<c05f6654>] (__driver_attach) from [<c05f40d8>] (bus_for_each_dev+0x58/0x7c)
[ 15.787191] [<c05f40d8>] (bus_for_each_dev) from [<c05f4ffc>] (bus_add_driver+0xdc/0x1f8)
[ 15.795352] [<c05f4ffc>] (bus_add_driver) from [<c05f6ed8>] (driver_register+0x7c/0x110)
[ 15.803425] [<c05f6ed8>] (driver_register) from [<c01027bc>] (do_one_initcall+0x70/0x1b8)
[ 15.811588] [<c01027bc>] (do_one_initcall) from [<c01a1094>] (do_init_module+0x58/0x1f8)
[ 15.819660] [<c01a1094>] (do_init_module) from [<c01a0074>] (load_module+0x1e58/0x23c8)
[ 15.827646] [<c01a0074>] (load_module) from [<c01a0860>] (sys_finit_module+0xa0/0xd4)
[ 15.835459] [<c01a0860>] (sys_finit_module) from [<c01011e0>] (__sys_trace_return+0x0/0x20)
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
Cc: stable@vger.kernel.org
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1f85e7a002d1f91761d917b74848dd405f4cdacc
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date: Wed Jun 9 09:21:08 2021 +0200
s390/cio: dont call css_wait_for_slow_path() inside a lock
commit c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 upstream.
Currently css_wait_for_slow_path() gets called inside the chp->lock.
The path-verification-loop of slowpath inside this lock could lead to
deadlock as reported by the lockdep validator.
The ccw_device_get_chp_desc() during the instance of a device-set-online
would try to acquire the same 'chp->lock' to read the chp->desc.
The instance of this function can get called from multiple scenario,
like probing or setting-device online manually. This could, in some
corner-cases lead to the deadlock.
lockdep validator reported this as,
CPU0 CPU1
---- ----
lock(&chp->lock);
lock(kn->active#43);
lock(&chp->lock);
lock((wq_completion)cio);
The chp->lock was introduced to serialize the access of struct
channel_path. This lock is not needed for the css_wait_for_slow_path()
function, so invoke the slow-path function outside this lock.
Fixes: b730f3a93395 ("[S390] cio: add lock to struct channel_path")
Cc: <stable@vger.kernel.org>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 96ee5b4c5591868dd4f83dc77ebef4499fd23d5a
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date: Sat Jun 26 15:50:42 2021 +0800
SUNRPC: Should wake up the privileged task firstly.
commit 5483b904bf336948826594610af4c9bbb0d9e3aa upstream.
When find a task from wait queue to wake up, a non-privileged task may
be found out, rather than the privileged. This maybe lead a deadlock
same as commit dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode()
and nfs4_opendata_get_inode()"):
Privileged delegreturn task is queued to privileged list because all
the slots are assigned. If there has no enough slot to wake up the
non-privileged batch tasks(session less than 8 slot), then the privileged
delegreturn task maybe lost waked up because the found out task can't
get slot since the session is on draining.
So we should treate the privileged task as the emergency task, and
execute it as for as we can.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode")
Cc: stable@vger.kernel.org
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98c887fafa40fa6d65ce04110b8020d12907d64f
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date: Sat Jun 26 15:50:41 2021 +0800
SUNRPC: Fix the batch tasks count wraparound.
commit fcb170a9d825d7db4a3fb870b0300f5a40a8d096 upstream.
The 'queue->nr' will wraparound from 0 to 255 when only current
priority queue has tasks. This maybe lead a deadlock same as commit
dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode()
and nfs4_opendata_get_inode()"):
Privileged delegreturn task is queued to privileged list because all
the slots are assigned. When non-privileged task complete and release
the slot, a non-privileged maybe picked out. It maybe allocate slot
failed when the session on draining.
If the 'queue->nr' has wraparound to 255, and no enough slot to
service it, then the privileged delegreturn will lost to wake up.
So we should avoid the wraparound on 'queue->nr'.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dada02ccd86e0d68e4c2ab495a457f62a697cbf3
Author: Stephane Grosjean <s.grosjean@peak-system.com>
Date: Wed Jun 23 16:26:00 2021 +0200
can: peak_pciefd: pucan_handle_status(): fix a potential starvation issue in TX path
commit b17233d385d0b6b43ecf81d43008cb1bbb008166 upstream.
Rather than just indicating that transmission can start, this patch
requires the explicit flushing of the network TX queue when the driver
is informed by the device that it can transmit, next to its
configuration.
In this way, if frames have already been written by the application,
they will actually be transmitted.
Fixes: ffd137f7043c ("can: peak/pcie_fd: remove useless code when interface starts")
Link: https://lore.kernel.org/r/20210623142600.149904-1-s.grosjean@peak-system.com
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2c9e095989b4779767bca0a532f168e80ed09ec7
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Fri Jun 18 19:36:45 2021 +0200
can: gw: synchronize rcu operations before removing gw job entry
commit fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 upstream.
can_can_gw_rcv() is called under RCU protection, so after calling
can_rx_unregister(), we have to call synchronize_rcu in order to wait
for any RCU read-side critical sections to finish before removing the
kmem_cache entry with the referenced gw job entry.
Link: https://lore.kernel.org/r/20210618173645.2238-1-socketcan@hartkopp.net
Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing")
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 630f13442f1472abe5013ef98f76a3bbca64dd80
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date: Sat Jun 19 13:18:13 2021 -0300
can: bcm: delay release of struct bcm_op after synchronize_rcu()
commit d5f9023fa61ee8b94f37a93f08e94b136cf1e463 upstream.
can_rx_register() callbacks may be called concurrently to the call to
can_rx_unregister(). The callbacks and callback data, though, are
protected by RCU and the struct sock reference count.
So the callback data is really attached to the life of sk, meaning
that it should be released on sk_destruct. However, bcm_remove_op()
calls tasklet_kill(), and RCU callbacks may be called under RCU
softirq, so that cannot be used on kernels before the introduction of
HRTIMER_MODE_SOFT.
However, bcm_rx_handler() is called under RCU protection, so after
calling can_rx_unregister(), we may call synchronize_rcu() in order to
wait for any RCU read-side critical sections to finish. That is,
bcm_rx_handler() won't be called anymore for those ops. So, we only
free them, after we do that synchronize_rcu().
Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol")
Link: https://lore.kernel.org/r/20210619161813.2098382-1-cascardo@canonical.com
Cc: linux-stable <stable@vger.kernel.org>
Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com
Reported-by: Norbert Slusarek <nslusarek@gmx.net>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a3620b28b3d2ef90e1cac43c447d97c1bfdf63de
Author: Stephen Brennan <stephen.s.brennan@oracle.com>
Date: Wed Jun 23 16:21:14 2021 -0700
ext4: use ext4_grp_locked_error in mb_find_extent
commit cd84bbbac12a173a381a64c6ec8b76a5277b87b5 upstream.
Commit 5d1b1b3f492f ("ext4: fix BUG when calling ext4_error with locked
block group") introduces ext4_grp_locked_error to handle unlocking a
group in error cases. Otherwise, there is a possibility of a sleep while
atomic. However, since 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON
in mb_find_extent()"), mb_find_extent() has contained a ext4_error()
call while a group spinlock is held. Replace this with
ext4_grp_locked_error.
Fixes: 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON in mb_find_extent()")
Cc: <stable@vger.kernel.org> # 4.14+
Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Link: https://lore.kernel.org/r/20210623232114.34457-1-stephen.s.brennan@oracle.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6145acdd2a33f64cc897832696c568c9fdf9cf3d
Author: Pan Dong <pandong.peter@bytedance.com>
Date: Tue May 25 15:36:56 2021 +0800
ext4: fix avefreec in find_group_orlov
commit c89849cc0259f3d33624cc3bd127685c3c0fa25d upstream.
The avefreec should be average free clusters instead
of average free blocks, otherwize Orlov's allocator
will not work properly when bigalloc enabled.
Cc: stable@kernel.org
Signed-off-by: Pan Dong <pandong.peter@bytedance.com>
Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 14402da8160f5dae67996b6213d78dbe5cf85185
Author: Zhang Yi <yi.zhang@huawei.com>
Date: Sat May 22 18:30:44 2021 +0800
ext4: remove check for zero nr_to_scan in ext4_es_scan()
commit e5e7010e5444d923e4091cafff61d05f2d19cada upstream.
After converting fs shrinkers to new scan/count API, we are no longer
pass zero nr_to_scan parameter to detect the number of objects to free,
just remove this check.
Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API")
Cc: stable@vger.kernel.org # 3.12+
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20210522103045.690103-2-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 72a1c16e982081462123d34430b17e45f61c38ff
Author: Zhang Yi <yi.zhang@huawei.com>
Date: Sat May 22 18:30:45 2021 +0800
ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit
commit 4fb7c70a889ead2e91e184895ac6e5354b759135 upstream.
The cache_cnt parameter of tracepoint ext4_es_shrink_exit means the
remaining cache count after shrink, but now it is the cache count before
shrink, fix it by read sbi->s_extent_cache_cnt again.
Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API")
Cc: stable@vger.kernel.org # 3.12+
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20210522103045.690103-3-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 29d882f9a6a6219a1c59729e1f43fa40663903e4
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date: Fri May 7 00:26:54 2021 +0530
ext4: fix kernel infoleak via ext4_extent_header
commit ce3aba43599f0b50adbebff133df8d08a3d5fffe upstream.
Initialize eh_generation of struct ext4_extent_header to prevent leaking
info to userspace. Fixes KMSAN kernel-infoleak bug reported by syzbot at:
http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8
Cc: stable@kernel.org
Reported-by: syzbot+2dcfeaf8cb49b05e8f1a@syzkaller.appspotmail.com
Fixes: a86c61812637 ("[PATCH] ext3: add extent map support")
Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
Link: https://lore.kernel.org/r/20210506185655.7118-1-mail@anirudhrb.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6bb5e1c5d387b318b1188e4f100add301ee30d73
Author: Zhang Yi <yi.zhang@huawei.com>
Date: Fri May 7 15:19:04 2021 +0800
ext4: cleanup in-core orphan list if ext4_truncate() failed to get a transaction handle
commit b9a037b7f3c401d3c63e0423e56aef606b1ffaaf upstream.
In ext4_orphan_cleanup(), if ext4_truncate() failed to get a transaction
handle, it didn't remove the inode from the in-core orphan list, which
may probably trigger below error dump in ext4_destroy_inode() during the
final iput() and could lead to memory corruption on the later orphan
list changes.
EXT4-fs (sda): Inode 6291467 (00000000b8247c67): orphan list check failed!
00000000b8247c67: 0001f30a 00000004 00000000 00000023 ............#...
00000000e24cde71: 00000006 014082a3 00000000 00000000 ......@.........
0000000072c6a5ee: 00000000 00000000 00000000 00000000 ................
...
This patch fix this by cleanup in-core orphan list manually if
ext4_truncate() return error.
Cc: stable@kernel.org
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20210507071904.160808-1-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c4984eed9087d410d33f5f75d2e74bf93eb46b94
Author: David Sterba <dsterba@suse.com>
Date: Tue Jul 7 18:30:06 2020 +0200
btrfs: clear defrag status of a root if starting transaction fails
commit 6819703f5a365c95488b07066a8744841bf14231 upstream.
The defrag loop processes leaves in batches and starting transaction for
each. The whole defragmentation on a given root is protected by a bit
but in case the transaction fails, the bit is not cleared
In case the transaction fails the bit would prevent starting
defragmentation again, so make sure it's cleared.
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc824fbe9fd4ba7e15d135b9ddab9ca7cd425749
Author: Filipe Manana <fdmanana@suse.com>
Date: Wed Jun 9 11:25:03 2021 +0100
btrfs: send: fix invalid path for unlink operations after parent orphanization
commit d8ac76cdd1755b21e8c008c28d0b7251c0b14986 upstream.
During an incremental send operation, when processing the new references
for the current inode, we might send an unlink operation for another inode
that has a conflicting path and has more than one hard link. However this
path was computed and cached before we processed previous new references
for the current inode. We may have orphanized a directory of that path
while processing a previous new reference, in which case the path will
be invalid and cause the receiver process to fail.
The following reproducer triggers the problem and explains how/why it
happens in its comments:
$ cat test-send-unlink.sh
#!/bin/bash
DEV=/dev/sdi
MNT=/mnt/sdi
mkfs.btrfs -f $DEV >/dev/null
mount $DEV $MNT
# Create our test files and directory. Inode 259 (file3) has two hard
# links.
touch $MNT/file1
touch $MNT/file2
touch $MNT/file3
mkdir $MNT/A
ln $MNT/file3 $MNT/A/hard_link
# Filesystem looks like:
#
# . (ino 256)
# |----- file1 (ino 257)
# |----- file2 (ino 258)
# |----- file3 (ino 259)
# |----- A/ (ino 260)
# |---- hard_link (ino 259)
#
# Now create the base snapshot, which is going to be the parent snapshot
# for a later incremental send.
btrfs subvolume snapshot -r $MNT $MNT/snap1
btrfs send -f /tmp/snap1.send $MNT/snap1
# Move inode 257 into directory inode 260. This results in computing the
# path for inode 260 as "/A" and caching it.
mv $MNT/file1 $MNT/A/file1
# Move inode 258 (file2) into directory inode 260, with a name of
# "hard_link", moving first inode 259 away since it currently has that
# location and name.
mv $MNT/A/hard_link $MNT/tmp
mv $MNT/file2 $MNT/A/hard_link
# Now rename inode 260 to something else (B for example) and then create
# a hard link for inode 258 that has the old name and location of inode
# 260 ("/A").
mv $MNT/A $MNT/B
ln $MNT/B/hard_link $MNT/A
# Filesystem now looks like:
#
# . (ino 256)
# |----- tmp (ino 259)
# |----- file3 (ino 259)
# |----- B/ (ino 260)
# | |---- file1 (ino 257)
# | |---- hard_link (ino 258)
# |
# |----- A (ino 258)
# Create another snapshot of our subvolume and use it for an incremental
# send.
btrfs subvolume snapshot -r $MNT $MNT/snap2
btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2
# Now unmount the filesystem, create a new one, mount it and try to
# apply both send streams to recreate both snapshots.
umount $DEV
mkfs.btrfs -f $DEV >/dev/null
mount $DEV $MNT
# First add the first snapshot to the new filesystem by applying the
# first send stream.
btrfs receive -f /tmp/snap1.send $MNT
# The incremental receive operation below used to fail with the
# following error:
#
# ERROR: unlink A/hard_link failed: No such file or directory
#
# This is because when send is processing inode 257, it generates the
# path for inode 260 as "/A", since that inode is its parent in the send
# snapshot, and caches that path.
#
# Later when processing inode 258, it first processes its new reference
# that has the path of "/A", which results in orphanizing inode 260
# because there is a a path collision. This results in issuing a rename
# operation from "/A" to "/o260-6-0".
#
# Finally when processing the new reference "B/hard_link" for inode 258,
# it notices that it collides with inode 259 (not yet processed, because
# it has a higher inode number), since that inode has the name
# "hard_link" under the directory inode 260. It also checks that inode
# 259 has two hardlinks, so it decides to issue a unlink operation for
# the name "hard_link" for inode 259. However the path passed to the
# unlink operation is "/A/hard_link", which is incorrect since currently
# "/A" does not exists, due to the orphanization of inode 260 mentioned
# before. The path is incorrect because it was computed and cached
# before the orphanization. This results in the receiver to fail with
# the above error.
btrfs receive -f /tmp/snap2.send $MNT
umount $MNT
When running the test, it fails like this:
$ ./test-send-unlink.sh
Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1'
At subvol /mnt/sdi/snap1
Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2'
At subvol /mnt/sdi/snap2
At subvol snap1
At snapshot snap2
ERROR: unlink A/hard_link failed: No such file or directory
Fix this by recomputing a path before issuing an unlink operation when
processing the new references for the current inode if we previously
have orphanized a directory.
A test case for fstests will follow soon.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 196ccf0730b040dbb0b33e95021f50684370eec5
Author: Ludovic Desroches <ludovic.desroches@microchip.com>
Date: Fri Oct 25 10:42:10 2019 +0200
ARM: dts: at91: sama5d4: fix pinctrl muxing
commit 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c upstream.
Fix pinctrl muxing, PD28, PD29 and PD31 can be muxed to peripheral A. It
allows to use SCK0, SCK1 and SPI0_NPCS2 signals.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Fixes: 679f8d92bb01 ("ARM: at91/dt: sama5d4: add pioD pin mux mask and enable pioD")
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20191025084210.14726-1-ludovic.desroches@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0f3e884a746ad9a1038f9c85ef983a4dfbee0d8e
Author: Alexander Larkin <avlarkin82@gmail.com>
Date: Sun Jul 4 22:39:36 2021 -0700
Input: joydev - prevent use of not validated data in JSIOCSBTNMAP ioctl
commit f8f84af5da9ee04ef1d271528656dac42a090d00 upstream.
Even though we validate user-provided inputs we then traverse past
validated data when applying the new map. The issue was originally
discovered by Murray McAllister with this simple POC (if the following
is executed by an unprivileged user it will instantly panic the system):
int main(void) {
int fd, ret;
unsigned int buffer[10000];
fd = open("/dev/input/js0", O_RDONLY);
if (fd == -1)
printf("Error opening file\n");
ret = ioctl(fd, JSIOCSBTNMAP & ~IOCSIZE_MASK, &buffer);
printf("%d\n", ret);
}
The solution is to traverse internal buffer which is guaranteed to only
contain valid date when constructing the map.
Fixes: 182d679b2298 ("Input: joydev - prevent potential read overflow in ioctl")
Fixes: 999b874f4aa3 ("Input: joydev - validate axis/button maps before clobbering current ones")
Reported-by: Murray McAllister <murray.mcallister@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Alexander Larkin <avlarkin82@gmail.com>
Link: https://lore.kernel.org/r/20210620120030.1513655-1-avlarkin82@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ff545051fb76c29efd82f0bece107cc5ba6a9bb
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Wed Jun 2 14:48:21 2021 -0400
iov_iter_fault_in_readable() should do nothing in xarray case
commit 0e8f0d67401589a141950856902c7d0ec8d9c985 upstream.
... and actually should just check it's given an iovec-backed iterator
in the first place.
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1c8520e4661e1fa39b2d768bfdf11d0730a0e711
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date: Mon Jun 28 19:33:52 2021 -0700
ntfs: fix validity check for file name attribute
commit d98e4d95411bbde2220a7afa38dcc9c14d71acbe upstream.
When checking the file name attribute, we want to ensure that it fits
within the bounds of ATTR_RECORD. To do this, we should check that (attr
record + file name offset + file name length) < (attr record + attr record
length).
However, the original check did not include the file name offset in the
calculation. This means that corrupted on-disk metadata might not caught
by the incorrect file name check, and lead to an invalid memory access.
An example can be seen in the crash report of a memory corruption error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=a1a1e379b225812688566745c3e2f7242bffc246
Adding the file name offset to the validity check fixes this error and
passes the Syzbot reproducer test.
Link: https://lkml.kernel.org/r/20210614050540.289494-1-desmondcheongzx@gmail.com
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Reported-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
Tested-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
Acked-by: Anton Altaparmakov <anton@tuxera.com>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a97ae69bfc606ee3b3bbf7b0b9b38c2d32e390a0
Author: Hannu Hartikainen <hannu@hrtk.in>
Date: Tue Jun 22 17:14:54 2021 +0300
USB: cdc-acm: blacklist Heimann USB Appset device
commit 4897807753e078655a78de39ed76044d784f3e63 upstream.
The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be
a CDC-ACM device in its descriptors but in fact is not. If it is run
with echo disabled it returns garbled data, probably due to something
that happens in the TTY layer. And when run with echo enabled (the
default), it will mess up the calibration data of the sensor the first
time any data is sent to the device.
In short, I had a bad time after connecting the sensor and trying to get
it to work. I hope blacklisting it in the cdc-acm driver will save
someone else a bit of trouble.
Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210622141454.337948-1-hannu@hrtk.in
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3680a6ff9a9ccd3c664663da04bef2534397d591
Author: Linyu Yuan <linyyuan@codeaurora.com>
Date: Wed Jun 16 19:51:42 2021 +0800
usb: gadget: eem: fix echo command packet response issue
commit 4249d6fbc10fd997abdf8a1ea49c0389a0edf706 upstream.
when receive eem echo command, it will send a response,
but queue this response to the usb request which allocate
from gadget device endpoint zero,
and transmit the request to IN endpoint of eem interface.
on dwc3 gadget, it will trigger following warning in function
__dwc3_gadget_ep_queue(),
if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
&req->request, req->dep->name))
return -EINVAL;
fix it by allocating a usb request from IN endpoint of eem interface,
and transmit the usb request to same IN endpoint of eem interface.
Signed-off-by: Linyu Yuan <linyyuan@codeaurora.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210616115142.34075-1-linyyuan@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4648a7827925cb6331876fa10d6338a60ea78c12
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Thu Jun 17 21:51:30 2021 +0300
net: can: ems_usb: fix use-after-free in ems_usb_disconnect()
commit ab4a0b8fcb9a95c02909b62049811bd2e586aaa4 upstream.
In ems_usb_disconnect() dev pointer, which is netdev private data, is
used after free_candev() call:
| if (dev) {
| unregister_netdev(dev->netdev);
| free_candev(dev->netdev);
|
| unlink_all_urbs(dev);
|
| usb_free_urb(dev->intr_urb);
|
| kfree(dev->intr_in_buffer);
| kfree(dev->tx_msg_buffer);
| }
Fix it by simply moving free_candev() at the end of the block.
Fail log:
| BUG: KASAN: use-after-free in ems_usb_disconnect
| Read of size 8 at addr ffff88804e041008 by task kworker/1:2/2895
|
| CPU: 1 PID: 2895 Comm: kworker/1:2 Not tainted 5.13.0-rc5+ #164
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.4
| Workqueue: usb_hub_wq hub_event
| Call Trace:
| dump_stack (lib/dump_stack.c:122)
| print_address_description.constprop.0.cold (mm/kasan/report.c:234)
| kasan_report.cold (mm/kasan/report.c:420 mm/kasan/report.c:436)
| ems_usb_disconnect (drivers/net/can/usb/ems_usb.c:683 drivers/net/can/usb/ems_usb.c:1058)
Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface")
Link: https://lore.kernel.org/r/20210617185130.5834-1-paskripkin@gmail.com
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 889e72203f04552db243d019460865d15ed704f0
Author: Johan Hovold <johan@kernel.org>
Date: Mon May 24 10:02:59 2021 -0700
Input: usbtouchscreen - fix control-request directions
commit 41e81022a04a0294c55cfa7e366bc14b9634c66e upstream.
The direction of the pipe argument must match the request-type direction
bit or control requests may fail depending on the host-controller-driver
implementation.
Fix the four control requests which erroneously used usb_rcvctrlpipe().
Fixes: 1d3e20236d7a ("[PATCH] USB: usbtouchscreen: unified USB touchscreen driver")
Fixes: 24ced062a296 ("usbtouchscreen: add support for DMC TSC-10/25 devices")
Fixes: 9e3b25837a20 ("Input: usbtouchscreen - add support for e2i touchscreen controller")
Signed-off-by: Johan Hovold <johan@kernel.org>
Cc: stable@vger.kernel.org # 2.6.17
Link: https://lore.kernel.org/r/20210524092048.4443-1-johan@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d6c7565704d8b607452d173f9397a7e62dcfdb4
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Fri May 7 14:50:43 2021 +0200
media: dvb-usb: fix wrong definition
commit c680ed46e418e9c785d76cf44eb33bfd1e8cf3f6 upstream.
syzbot reported WARNING in vmalloc. The problem
was in zero size passed to vmalloc.
The root case was in wrong cxusb_bluebird_lgz201_properties
definition. adapter array has only 1 entry, but num_adapters was
2.
Call Trace:
__vmalloc_node mm/vmalloc.c:2963 [inline]
vmalloc+0x67/0x80 mm/vmalloc.c:2996
dvb_dmx_init+0xe4/0xb90 drivers/media/dvb-core/dvb_demux.c:1251
dvb_usb_adapter_dvb_init+0x564/0x860 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:184
dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86 [inline]
dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:184 [inline]
dvb_usb_device_init.cold+0xc94/0x146e drivers/media/usb/dvb-usb/dvb-usb-init.c:308
cxusb_probe+0x159/0x5e0 drivers/media/usb/dvb-usb/cxusb.c:1634
Fixes: 4d43e13f723e ("V4L/DVB (4643): Multi-input patch for DVB-USB device")
Cc: stable@vger.kernel.org
Reported-by: syzbot+7336195c02c1bd2f64e1@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fa1fc9fe20a18f6356e7441ca174e76557aad22e
Author: Daehwan Jung <dh10.jung@samsung.com>
Date: Wed Jun 16 18:34:55 2021 +0900
ALSA: usb-audio: fix rate on Ozone Z90 USB headset
commit aecc19ec404bdc745c781058ac97a373731c3089 upstream.
It mislabels its 96 kHz altsetting and that's why it causes some noise
Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1623836097-61918-1-git-send-email-dh10.jung@samsung.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>