Selvin Xavier [Wed, 15 Sep 2021 12:32:38 +0000 (05:32 -0700)]
RDMA/bnxt_re: Fix query SRQ failure
[ Upstream commit
598d16fa1bf93431ad35bbab3ed1affe4fb7b562 ]
Fill the missing parameters for the FW command while querying SRQ.
Fixes:
37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")
Link: https://lore.kernel.org/r/1631709163-2287-8-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Mon, 30 Aug 2021 17:57:39 +0000 (19:57 +0200)]
ARM: dts: qcom: msm8974: Add xo_board reference clock to DSI0 PHY
[ Upstream commit
8ccecf6c710b8c048eecc65709640642e5357d6e ]
According to YAML validation, and for a future patchset putting this
xo_board reference clock to use as VCO reference parent, add the missing
clock to dsi_phy0.
Fixes:
5a9fc531f6ec ("ARM: dts: msm8974: add display support")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210830175739.143401-1-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alex Bee [Wed, 23 Jun 2021 11:59:26 +0000 (13:59 +0200)]
arm64: dts: rockchip: Fix GPU register width for RK3328
[ Upstream commit
932b4610f55b49f3a158b0db451137bab7ed0e1f ]
As can be seen in RK3328's TRM the register range for the GPU is
0xff300000 to 0xff330000.
It would (and does in vendor kernel) overlap with the registers of
the HEVC encoder (node/driver do not exist yet in upstream kernel).
See already existing h265e_mmu node.
Fixes:
752fbc0c8da7 ("arm64: dts: rockchip: add rk3328 mali gpu node")
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20210623115926.164861-1-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jackie Liu [Wed, 1 Sep 2021 12:35:57 +0000 (20:35 +0800)]
ARM: s3c: irq-s3c24xx: Fix return value check for s3c24xx_init_intc()
[ Upstream commit
2aa717473ce96c93ae43a5dc8c23cedc8ce7dd9f ]
The s3c24xx_init_intc() returns an error pointer upon failure, not NULL.
let's add an error pointer check in s3c24xx_handle_irq.
s3c_intc[0] is not NULL or ERR, we can simplify the code.
Fixes:
1f629b7a3ced ("ARM: S3C24XX: transform irq handling into a declarative form")
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Link: https://lore.kernel.org/r/20210901123557.1043953-1-liu.yun@linux.dev
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Smart [Fri, 10 Sep 2021 23:31:52 +0000 (16:31 -0700)]
scsi: lpfc: Fix NVMe I/O failover to non-optimized path
[ Upstream commit
b507357f79171fb4fb4e732ca43a1f30bc5aab1d ]
Currently, we hold off unregistering with NVMe transport layer until GID_FT
or ADISC completes upon receipt of RSCN. In the ADISC discovery routine,
for nodes not found in the GID_FT response, the nodes are unregistered from
the SCSI transport but not UNREG_RPI'd. Meaning outstanding WQEs continue
to be outstanding and were not failed back to the OS. If an NVMe device,
this mean there wasn't initial termination of the I/Os so they could be
issued on a different NVMe path.
Fix by unregistering the RPI so that I/O is cancelled.
Link: https://lore.kernel.org/r/20210910233159.115896-8-jsmart2021@gmail.com
Fixes:
0614568361b0 ("scsi: lpfc: Delay unregistering from transport until GIDFT or ADISC completes")
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>
Quinn Tran [Wed, 8 Sep 2021 16:46:17 +0000 (09:46 -0700)]
scsi: qla2xxx: edif: Use link event to wake up app
[ Upstream commit
527d46e0b0147f2b32b78ba49c6a231835b24a41 ]
Authentication application may be running and in the past tried to probe
driver (app_start) but was unsuccessful. This could be due to the bsg layer
not being ready to service the request. On a successful link up, driver
will use the netlink Link Up event to notify the app to retry the app_start
call.
In another case, app does not poll for new NPIV host. This link up event
would notify app of the presence of a new SCSI host.
Link: https://lore.kernel.org/r/20210908164622.19240-6-njavali@marvell.com
Fixes:
4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF")
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Quinn Tran <qutran@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ajish Koshy [Mon, 6 Sep 2021 17:04:02 +0000 (22:34 +0530)]
scsi: pm80xx: Fix lockup in outbound queue management
[ Upstream commit
b27a40534ef76a22628a5c12f98ea489823a8ba5 ]
Commit
1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue
processing") introduced a lock per outbound queue. Prior to that change the
driver was using a global lock for all outbound queues.
While processing the I/O responses and events the driver takes the outbound
queue spinlock and is supposed to release it in pm8001_ccb_task_free_done()
before calling command done(). Since the older code was using a global
lock, pm8001_ccb_task_free_done() was releasing the global spin lock. The
change that split the lock per outbound queue did not consider this and
pm8001_ccb_task_free_done() was still releasing the global lock.
Link: https://lore.kernel.org/r/20210906170404.5682-3-Ajish.Koshy@microchip.com
Fixes:
1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue processing")
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Ajish Koshy <Ajish.Koshy@microchip.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Fri, 23 Apr 2021 07:02:26 +0000 (09:02 +0200)]
clk: mvebu: ap-cpu-clk: Fix a memory leak in error handling paths
[ Upstream commit
af9617b419f77cf0b99702a7b2b0519da0d27715 ]
If we exit the for_each_of_cpu_node loop early, the reference on the
current node must be decremented, otherwise there is a leak.
Fixes:
f756e362d938 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/545df946044fc1fc05a4217cdf0054be7a79e49e.1619161112.git.christophe.jaillet@wanadoo.fr
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafał Miłecki [Thu, 19 Aug 2021 15:37:02 +0000 (17:37 +0200)]
arm64: dts: broadcom: bcm4908: Fix UART clock name
[ Upstream commit
6c38c39ab2141f53786d73e706675e8819a3f2cb ]
According to the binding the correct clock name is "refclk".
Fixes:
2961f69f151c ("arm64: dts: broadcom: add BCM4908 and Asus GT-AC5300 early DTS files")
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>
Rafał Miłecki [Thu, 19 Aug 2021 06:57:02 +0000 (08:57 +0200)]
ARM: dts: BCM5301X: Fix memory nodes names
[ Upstream commit
c5e1df3276d7a500678da9453be31a66ad115150 ]
Thix fixes:
arch/arm/boot/dts/bcm4708-netgear-r6250.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728], [
2281701376,
134217728]]}
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728], [
2281701376,
134217728]]}
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728], [
2281701376,
402653184]]}
arch/arm/boot/dts/bcm4709-linksys-ea9200.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728], [
2281701376,
134217728]]}
arch/arm/boot/dts/bcm4709-netgear-r7000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728], [
2281701376,
134217728]]}
arch/arm/boot/dts/bcm4709-netgear-r8000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728], [
2281701376,
134217728]]}
arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728]]}
arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728], [
2281701376,
402653184]]}
arch/arm/boot/dts/bcm53016-meraki-mr32.dt.yaml: /: memory: False schema does not allow {'reg': [[0,
134217728]], 'device_type': ['memory']}
arch/arm/boot/dts/bcm94708.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728]]}
arch/arm/boot/dts/bcm94709.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0,
134217728]]}
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>
Junji Wei [Tue, 31 Aug 2021 08:32:23 +0000 (16:32 +0800)]
RDMA/rxe: Fix wrong port_cap_flags
[ Upstream commit
dcd3f985b20ffcc375f82ca0ca9f241c7025eb5e ]
The port->attr.port_cap_flags should be set to enum
ib_port_capability_mask_bits in ib_mad.h, not
RDMA_CORE_CAP_PROT_ROCE_UDP_ENCAP.
Fixes:
8700e3e7c485 ("Soft RoCE driver")
Link: https://lore.kernel.org/r/20210831083223.65797-1-weijunji@bytedance.com
Signed-off-by: Junji Wei <weijunji@bytedance.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexandru Ardelean [Mon, 23 Aug 2021 11:22:00 +0000 (14:22 +0300)]
iio: st_sensors: disable regulators after device unregistration
[ Upstream commit
9f0b3e0cc0c88618aa9e5cecef747b1337ae0a5d ]
Up until commit
ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal
to core") only the ST pressure driver seems to have had any regulator
disable. After that commit, the regulator handling was moved into the
common st_sensors logic.
In all instances of this regulator handling, the regulators were disabled
before unregistering the IIO device.
This can cause issues where the device would be powered down and still be
available to userspace, allowing it to send invalid/garbage data.
This change moves the st_sensors_power_disable() after the common probe
functions. These common probe functions also handle unregistering the IIO
device.
Fixes:
774487611c949 ("iio: pressure-core: st: Provide support for the Vdd power supply")
Fixes:
ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core")
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Denis CIOCCA <denis.ciocca@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210823112204.243255-2-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dongjin Kim [Thu, 26 Aug 2021 03:28:32 +0000 (12:28 +0900)]
arm64: dts: meson: sm1: add Ethernet PHY reset line for ODROID-C4/HC4
[ Upstream commit
9d02214f8332d5dbbcce3d6c5c915e54d43a0c46 ]
This patch is to fix an issue that the ethernet link doesn't come up
when using ip link set down/up:
[ 11.428114] meson8b-dwmac
ff3f0000.ethernet eth0: Link is Down
[ 14.428595] meson8b-dwmac
ff3f0000.ethernet eth0: PHY [0.0:00] driver [RTL8211F Gigabit Ethernet] (irq=31)
[ 14.428610] meson8b-dwmac
ff3f0000.ethernet: Failed to reset the dma
[ 14.428974] meson8b-dwmac
ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
[ 14.711185] meson8b-dwmac
ff3f0000.ethernet eth0: stmmac_open: Hw setup failed
This fix refers to two commits applied for ODROID-N2 (G12B).
commit
658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY reset line")
commit
1c7412530d5d0 ("arm64: dts: meson: g12b: odroid-n2: fix PHY deassert timing requirements")
Fixes:
88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi")
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[narmstrong: added fixes tag and typo in commit log]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/YScKYFWlYymgGw3l@anyang-linuxfactory-or-kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavel Skripkin [Fri, 3 Sep 2021 18:17:52 +0000 (21:17 +0300)]
staging: r8188eu: fix memory leak in rtw_set_key
[ Upstream commit
393db0f6827f96054a769ba3a38aa382d137d3c7 ]
Before returning with an error we should free allocated buffers, since
they are not assigned to anywhere.
Fixes:
15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/ee783fbb71abb549505b84542223be7a7c905eea.1630692375.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hector.Yuan [Mon, 4 Oct 2021 14:42:33 +0000 (22:42 +0800)]
cpufreq: Fix parameter in parse_perf_domain()
[ Upstream commit
4a08e3271c55f8b5d56906a8aa5bd041911cf897 ]
Pass cpu to parse_perf_domain() instead of pcpu.
Fixes:
8486a32dd484 ("cpufreq: Add of_perf_domain_get_sharing_cpumask")
Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com>
[ Viresh: Massaged changelog ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Frank Rowand [Fri, 29 Oct 2021 01:32:25 +0000 (20:32 -0500)]
of: unittest: fix EXPECT text for gpio hog errors
[ Upstream commit
e85860e5bc077865a04f0a88d0b0335d3200484a ]
The console message text for gpio hog errors does not match
what unittest expects.
Fixes:
f4056e705b2ef ("of: unittest: add overlay gpio test to catch gpio hog problem")
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Link: https://lore.kernel.org/r/20211029013225.2048695-1-frowand.list@gmail.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexei Starovoitov [Mon, 1 Nov 2021 22:21:52 +0000 (15:21 -0700)]
bpf: Fix propagation of signed bounds from 64-bit min/max into 32-bit.
[ Upstream commit
388e2c0b978339dee9b0a81a2e546f8979e021e2 ]
Similar to unsigned bounds propagation fix signed bounds.
The 'Fixes' tag is a hint. There is no security bug here.
The verifier was too conservative.
Fixes:
3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20211101222153.78759-2-alexei.starovoitov@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexei Starovoitov [Mon, 1 Nov 2021 22:21:51 +0000 (15:21 -0700)]
bpf: Fix propagation of bounds from 64-bit min/max into 32-bit and var_off.
[ Upstream commit
b9979db8340154526d9ab38a1883d6f6ba9b6d47 ]
Before this fix:
166: (b5) if r2 <= 0x1 goto pc+22
from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0xffffffff))
After this fix:
166: (b5) if r2 <= 0x1 goto pc+22
from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0x1))
While processing BPF_JLE the reg_set_min_max() would set true_reg->umax_value = 1
and call __reg_combine_64_into_32(true_reg).
Without the fix it would not pass the condition:
if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_value))
since umin_value == 0 at this point.
Before commit
10bf4e83167c the umin was incorrectly ingored.
The commit
10bf4e83167c fixed the correctness issue, but pessimized
propagation of 64-bit min max into 32-bit min max and corresponding var_off.
Fixes:
10bf4e83167c ("bpf: Fix propagation of 32 bit unsigned bounds from 64 bit bounds")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20211101222153.78759-1-alexei.starovoitov@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Schatzberg [Thu, 28 Oct 2021 22:15:27 +0000 (15:15 -0700)]
cgroup: Fix rootcg cpu.stat guest double counting
[ Upstream commit
81c49d39aea8a10e6d05d3aa1cb65ceb721e19b0 ]
In account_guest_time in kernel/sched/cputime.c guest time is
attributed to both CPUTIME_NICE and CPUTIME_USER in addition to
CPUTIME_GUEST_NICE and CPUTIME_GUEST respectively. Therefore, adding
both to calculate usage results in double counting any guest time at
the rootcg.
Fixes:
936f2a70f207 ("cgroup: add cpu.stat file to root cgroup")
Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liu Jian [Fri, 29 Oct 2021 14:12:14 +0000 (22:12 +0800)]
skmsg: Lose offset info in sk_psock_skb_ingress
[ Upstream commit
7303524e04af49a47991e19f895c3b8cdc3796c7 ]
If sockmap enable strparser, there are lose offset info in
sk_psock_skb_ingress(). If the length determined by parse_msg function is not
skb->len, the skb will be converted to sk_msg multiple times, and userspace
app will get the data multiple times.
Fix this by get the offset and length from strp_msg. And as Cong suggested,
add one bit in skb->_sk_redir to distinguish enable or disable strparser.
Fixes:
604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Liu Jian <liujian56@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Cong Wang <cong.wang@bytedance.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20211029141216.211899-1-liujian56@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geliang Tang [Fri, 29 Oct 2021 23:55:58 +0000 (16:55 -0700)]
selftests: mptcp: fix proto type in link_failure tests
[ Upstream commit
7c909a98042ce403c8497c5d6ff94dd53bdd2131 ]
In listener_ns, we should pass srv_proto argument to mptcp_connect command,
not cl_proto.
Fixes:
7d1e6f1639044 ("selftests: mptcp: add testcase for active-back")
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sukadev Bhattiprolu [Fri, 29 Oct 2021 22:03:16 +0000 (15:03 -0700)]
ibmvnic: delay complete()
[ Upstream commit
6b278c0cb378079f3c0c61ae4a369c09ff1a4188 ]
If we get CRQ_INIT, we set errno to -EIO and first call complete() to
notify the waiter. Then we try to schedule a FAILOVER reset. If this
occurs while adapter is in PROBING state, ibmvnic_reset() changes the
error code to EAGAIN and returns without scheduling the FAILOVER. The
purpose of setting error code to EAGAIN is to ask the waiter to retry.
But due to the earlier complete() call, the waiter may already have seen
the -EIO response and decided not to retry. This can cause intermittent
failures when bringing up ibmvnic adapters during boot, specially in
in kexec/kdump kernels.
Defer the complete() call until after scheduling the reset.
Also streamline the error code to EAGAIN. Don't see why we need EIO
sometimes. All 3 callers of ibmvnic_reset_init() can handle EAGAIN.
Fixes:
17c8705838a5 ("ibmvnic: Return error code if init interrupted by transport event")
Reported-by: Vaishnavi Bhat <vaish123@in.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Reviewed-by: Dany Madden <drt@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sukadev Bhattiprolu [Fri, 29 Oct 2021 22:03:15 +0000 (15:03 -0700)]
ibmvnic: Process crqs after enabling interrupts
[ Upstream commit
6e20d00158f31f7631d68b86996b7e951c4451c8 ]
Soon after registering a CRQ it is possible that we get a fail over or
maybe a CRQ_INIT from the VIOS while interrupts were disabled.
Look for any such CRQs after enabling interrupts.
Otherwise we can intermittently fail to bring up ibmvnic adapters during
boot, specially in kexec/kdump kernels.
Fixes:
032c5e82847a ("Driver for IBM System i/p VNIC protocol")
Reported-by: Vaishnavi Bhat <vaish123@in.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Reviewed-by: Dany Madden <drt@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sukadev Bhattiprolu [Fri, 29 Oct 2021 22:03:14 +0000 (15:03 -0700)]
ibmvnic: don't stop queue in xmit
[ Upstream commit
8878e46fcfd46b19964bd90e13b25dd94cbfc9be ]
If adapter's resetting bit is on, discard the packet but don't stop the
transmit queue - instead leave that to the reset code. With this change,
it is possible that we may get several calls to ibmvnic_xmit() that simply
discard packets and return.
But if we stop the queue here, we might end up doing so just after
__ibmvnic_open() started the queues (during a hard/soft reset) and before
the ->resetting bit was cleared. If that happens, there will be no one to
restart queue and transmissions will be blocked indefinitely.
This can cause a TIMEOUT reset and with auto priority failover enabled,
an unnecessary FAILOVER reset to less favored backing device and then a
FAILOVER back to the most favored backing device. If we hit the window
repeatedly, we can get stuck in a loop of TIMEOUT, FAILOVER, FAILOVER
resets leaving the adapter unusable for extended periods of time.
Fixes:
7f5b030830fe ("ibmvnic: Free skb's in cases of failure in transmit")
Reported-by: Abdul Haleem <abdhalee@in.ibm.com>
Reported-by: Vaishnavi Bhat <vaish123@in.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Reviewed-by: Dany Madden <drt@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Fri, 29 Oct 2021 15:51:34 +0000 (08:51 -0700)]
udp6: allow SO_MARK ctrl msg to affect routing
[ Upstream commit
42dcfd850e514b229d616a53dec06d0f2533217c ]
Commit
c6af0c227a22 ("ip: support SO_MARK cmsg")
added propagation of SO_MARK from cmsg to skb->mark.
For IPv4 and raw sockets the mark also affects route
lookup, but in case of IPv6 the flow info is
initialized before cmsg is parsed.
Fixes:
c6af0c227a22 ("ip: support SO_MARK cmsg")
Reported-and-tested-by: Xintong Hu <huxintong@fb.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrea Righi [Tue, 26 Oct 2021 14:34:09 +0000 (16:34 +0200)]
selftests/bpf: Fix fclose/pclose mismatch in test_progs
[ Upstream commit
f48ad69097fe79d1de13c4d8fef556d4c11c5e68 ]
Make sure to use pclose() to properly close the pipe opened by popen().
Fixes:
81f77fd0deeb ("bpf: add selftest for stackmap with BPF_F_STACK_BUILD_ID")
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20211026143409.42666-1-andrea.righi@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Jordan [Thu, 21 Oct 2021 18:30:28 +0000 (14:30 -0400)]
crypto: pcrypt - Delay write to padata->info
[ Upstream commit
68b6dea802cea0dbdd8bd7ccc60716b5a32a5d8a ]
These three events can race when pcrypt is used multiple times in a
template ("pcrypt(pcrypt(...))"):
1. [taskA] The caller makes the crypto request via crypto_aead_encrypt()
2. [kworkerB] padata serializes the inner pcrypt request
3. [kworkerC] padata serializes the outer pcrypt request
3 might finish before the call to crypto_aead_encrypt() returns in 1,
resulting in two possible issues.
First, a use-after-free of the crypto request's memory when, for
example, taskA writes to the outer pcrypt request's padata->info in
pcrypt_aead_enc() after kworkerC completes the request.
Second, the outer pcrypt request overwrites the inner pcrypt request's
return code with -EINPROGRESS, making a successful request appear to
fail. For instance, kworkerB writes the outer pcrypt request's
padata->info in pcrypt_aead_done() and then taskA overwrites it
in pcrypt_aead_enc().
Avoid both situations by delaying the write of padata->info until after
the inner crypto request's return code is checked. This prevents the
use-after-free by not touching the crypto request's memory after the
next-inner crypto request is made, and stops padata->info from being
overwritten.
Fixes:
5068c7a883d16 ("crypto: pcrypt - Add pcrypt crypto parallelization wrapper")
Reported-by: syzbot+b187b77c8474f9648fae@syzkaller.appspotmail.com
Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nikolay Aleksandrov [Fri, 29 Oct 2021 12:05:27 +0000 (15:05 +0300)]
selftests: net: bridge: update IGMP/MLD membership interval value
[ Upstream commit
34d7ecb3d4f772eb00ce1f7195ae30886ddf4d2e ]
When I fixed IGMPv3/MLDv2 to use the bridge's multicast_membership_interval
value which is chosen by user-space instead of calculating it based on
multicast_query_interval and multicast_query_response_interval I forgot
to update the selftests relying on that behaviour. Now we have to
manually set the expected GMI value to perform the tests correctly and get
proper results (similar to IGMPv2 behaviour).
Fixes:
fac3cb82a54a ("net: bridge: mcast: use multicast_membership_interval for IGMPv3")
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ivan Vecera [Thu, 28 Oct 2021 15:58:35 +0000 (17:58 +0200)]
net: bridge: fix uninitialized variables when BRIDGE_CFM is disabled
[ Upstream commit
829e050eea69c7442441b714b6f5b339b5b8c367 ]
Function br_get_link_af_size_filtered() calls br_cfm_{,peer}_mep_count()
that return a count. When BRIDGE_CFM is not enabled these functions
simply return -EOPNOTSUPP but do not modify count parameter and
calling function then works with uninitialized variables.
Modify these inline functions to return zero in count parameter.
Fixes:
b6d0425b816e ("bridge: cfm: Netlink Notifications.")
Cc: Henrik Bjoernlund <henrik.bjoernlund@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Russell King (Oracle) [Thu, 28 Oct 2021 14:55:34 +0000 (15:55 +0100)]
net: phylink: avoid mvneta warning when setting pause parameters
[ Upstream commit
fd8d9731bcdfb22d28e45bce789bcb211c868c78 ]
mvneta does not support asymetric pause modes, and it flags this by the
lack of AsymPause in the supported field. When setting pause modes, we
check that pause->rx_pause == pause->tx_pause, but only when pause
autoneg is enabled. When pause autoneg is disabled, we still allow
pause->rx_pause != pause->tx_pause, which is incorrect when the MAC
does not support asymetric pause, and causes mvneta to issue a warning.
Fix this by removing the test for pause->autoneg, so we always check
that pause->rx_pause == pause->tx_pause for network devices that do not
support AsymPause.
Fixes:
9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yinjun Zhang [Fri, 29 Oct 2021 11:29:03 +0000 (13:29 +0200)]
nfp: fix potential deadlock when canceling dim work
[ Upstream commit
17e712c6a1bade9dac02a7bf2b464746faa7e9a0 ]
When port is linked down, the process which has acquired rtnl_lock
will wait for the in-progress dim work to finish, and the work also
acquires rtnl_lock, which may cause deadlock.
Currently IRQ_MOD registers can be configured by `ethtool -C` and
dim work, and which will take effect depends on the execution order,
rtnl_lock is useless here, so remove them.
Fixes:
9d32e4e7e9e1 ("nfp: add support for coalesce adaptive feature")
Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
Signed-off-by: Louis Peens <louis.peens@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yinjun Zhang [Fri, 29 Oct 2021 11:29:02 +0000 (13:29 +0200)]
nfp: fix NULL pointer access when scheduling dim work
[ Upstream commit
f8d384a640dd32aaf0a05fec137ccbf0e986b09f ]
Each rx/tx ring has a related dim work, when rx/tx ring number is
decreased by `ethtool -L`, the corresponding rx_ring or tx_ring is
assigned NULL, while its related work is not destroyed. When scheduled,
the work will access NULL pointer.
Fixes:
9d32e4e7e9e1 ("nfp: add support for coalesce adaptive feature")
Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
Signed-off-by: Louis Peens <louis.peens@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Tue, 7 Sep 2021 21:06:32 +0000 (23:06 +0200)]
ipmi: kcs_bmc: Fix a memory leak in the error handling path of 'kcs_bmc_serio_add_device()'
[ Upstream commit
f281d010b87454e72475b668ad66e34961f744e0 ]
In the unlikely event where 'devm_kzalloc()' fails and 'kzalloc()'
succeeds, 'port' would be leaking.
Test each allocation separately to avoid the leak.
Fixes:
3a3d2f6a4c64 ("ipmi: kcs_bmc: Add serio adaptor")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-Id: <
ecbfa15e94e64f4b878ecab1541ea46c74807670.
1631048724.git.christophe.jaillet@wanadoo.fr>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shyam Sundar S K [Wed, 27 Oct 2021 09:57:27 +0000 (15:27 +0530)]
net: amd-xgbe: Toggle PLL settings during rate change
[ Upstream commit
daf182d360e509a494db18666799f4e85d83dda0 ]
For each rate change command submission, the FW has to do a phy
power off sequence internally. For this to happen correctly, the
PLL re-initialization control setting has to be turned off before
sending mailbox commands and re-enabled once the command submission
is complete.
Without the PLL control setting, the link up takes longer time in a
fixed phy configuration.
Fixes:
47f164deab22 ("amd-xgbe: Add PCI device support")
Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xin Long [Thu, 28 Oct 2021 09:36:04 +0000 (05:36 -0400)]
sctp: return true only for pathmtu update in sctp_transport_pl_toobig
[ Upstream commit
75cf662c64dd8543f56c329c69eba18141c8fd9f ]
sctp_transport_pl_toobig() supposes to return true only if there's
pathmtu update, so that in sctp_icmp_frag_needed() it would call
sctp_assoc_sync_pmtu() and sctp_retransmit(). This patch is to fix
these return places in sctp_transport_pl_toobig().
Fixes:
836964083177 ("sctp: do state transition when receiving an icmp TOOBIG packet")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xin Long [Thu, 28 Oct 2021 09:36:03 +0000 (05:36 -0400)]
sctp: subtract sctphdr len in sctp_transport_pl_hlen
[ Upstream commit
cc4665ca646c96181a7c00198aa72c59e0c576e8 ]
sctp_transport_pl_hlen() is called to calculate the outer header length
for PL. However, as the Figure in rfc8899#section-4.4:
Any additional
headers .--- MPS -----.
| | |
v v v
+------------------------------+
| IP | ** | PL | protocol data |
+------------------------------+
<----- PLPMTU ----->
<---------- PMTU -------------->
Outer header are IP + Any additional headers, which doesn't include
Packetization Layer itself header, namely sctphdr, whereas sctphdr
is counted by __sctp_mtu_payload().
The incorrect calculation caused the link pathmtu to be set larger
than expected by t->pl.pmtu + sctp_transport_pl_hlen(). This patch
is to fix it by subtracting sctphdr len in sctp_transport_pl_hlen().
Fixes:
d9e2e410ae30 ("sctp: add the constants/variables and states and some APIs for transport")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xin Long [Thu, 28 Oct 2021 09:36:02 +0000 (05:36 -0400)]
sctp: reset probe_timer in sctp_transport_pl_update
[ Upstream commit
c6ea04ea692fa0d8e7faeb133fcd28e3acf470a0 ]
sctp_transport_pl_update() is called when transport update its dst and
pathmtu, instead of stopping the PLPMTUD probe timer, PLPMTUD should
start over and reset the probe timer. Otherwise, the PLPMTUD service
would stop.
Fixes:
92548ec2f1f9 ("sctp: add the probe timer in transport for PLPMTUD")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xin Long [Thu, 28 Oct 2021 09:36:01 +0000 (05:36 -0400)]
sctp: allow IP fragmentation when PLPMTUD enters Error state
[ Upstream commit
40171248bb8934537fec8fbaf718e57c8add187c ]
Currently when PLPMTUD enters Error state, transport pathmtu will be set
to MIN_PLPMTU(512) while probe is continuing with BASE_PLPMTU(1200). It
will cause pathmtu to stay in a very small value, even if the real pmtu
is some value like 1000.
RFC8899 doesn't clearly say how to set the value in Error state. But one
possibility could be keep using BASE_PLPMTU for the real pmtu, but allow
to do IP fragmentation when it's in Error state.
As it says in rfc8899#section-5.4:
Some paths could be unable to sustain packets of the BASE_PLPMTU
size. The Error State could be implemented to provide robustness to
such paths. This allows fallback to a smaller than desired PLPMTU
rather than suffer connectivity failure. This could utilize methods
such as endpoint IP fragmentation to enable the PL sender to
communicate using packets smaller than the BASE_PLPMTU.
This patch is to set pmtu to BASE_PLPMTU instead of MIN_PLPMTU for Error
state in sctp_transport_pl_send/toobig(), and set packet ipfragok for
non-probe packets when it's in Error state.
Fixes:
1dc68c194571 ("sctp: do state transition when PROBE_COUNT == MAX_PROBES on HB send path")
Reported-by: Ying Xu <yinxu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kumar Kartikeya Dwivedi [Thu, 28 Oct 2021 06:35:01 +0000 (12:05 +0530)]
selftests/bpf: Fix memory leak in test_ima
[ Upstream commit
efadf2ad17a2d5dc90bda4e6e8b2f96af4c62dae ]
The allocated ring buffer is never freed, do so in the cleanup path.
Fixes:
f446b570ac7e ("bpf/selftests: Update the IMA test to use BPF ring buffer")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20211028063501.2239335-9-memxor@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kumar Kartikeya Dwivedi [Thu, 28 Oct 2021 06:35:00 +0000 (12:05 +0530)]
selftests/bpf: Fix fd cleanup in sk_lookup test
[ Upstream commit
c3fc706e94f5653def2783ffcd809a38676b7551 ]
Similar to the fix in commit:
e31eec77e4ab ("bpf: selftests: Fix fd cleanup in get_branch_snapshot")
We use designated initializer to set fds to -1 without breaking on
future changes to MAX_SERVER constant denoting the array size.
The particular close(0) occurs on non-reuseport tests, so it can be seen
with -n 115/{2,3} but not 115/4. This can cause problems with future
tests if they depend on BTF fd never being acquired as fd 0, breaking
internal libbpf assumptions.
Fixes:
0ab5539f8584 ("selftests/bpf: Tests for BPF_SK_LOOKUP attach point")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20211028063501.2239335-8-memxor@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alex Deucher [Wed, 27 Oct 2021 17:26:19 +0000 (13:26 -0400)]
drm/amdgpu/gmc6: fix DMA mask from 44 to 40 bits
[ Upstream commit
403475be6d8b122c3e6b8a47e075926d7299e5ef ]
The DMA mask on SI parts is 40 bits not 44. Copy
paste typo.
Fixes:
244511f386ccb9 ("drm/amdgpu: simplify and cleanup setting the dma mask")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1762
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lang Yu [Thu, 21 Oct 2021 06:36:36 +0000 (14:36 +0800)]
drm/amdgpu: fix a potential memory leak in amdgpu_device_fini_sw()
[ Upstream commit
a5c5d8d50ecf5874be90a76e1557279ff8a30c9e ]
amdgpu_fence_driver_sw_fini() should be executed before
amdgpu_device_ip_fini(), otherwise fence driver resource
won't be properly freed as adev->rings have been tore down.
Fixes:
72c8c97b1522 ("drm/amdgpu: Split amdgpu_device_fini into early and late")
Signed-off-by: Lang Yu <lang.yu@amd.com>
Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Loic Poulain [Mon, 25 Oct 2021 15:22:08 +0000 (17:22 +0200)]
wcn36xx: Channel list update before hardware scan
[ Upstream commit
d707f812bb0513ea0030d0c9fe2a456bae5a4583 ]
The channel scan list must be updated before triggering a hardware scan
so that firmware takes into account the regulatory info for each single
channel such as active/passive config, power, DFS, etc... Without this
the firmware uses its own internal default channel configuration, which
is not aligned with mac80211 regulatory rules, and misses several
channels (e.g. 144).
Fixes:
2f3bef4b247e ("wcn36xx: Add hardware scan offload support")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1635175328-25642-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Tue, 26 Oct 2021 21:41:32 +0000 (14:41 -0700)]
bpf: Fixes possible race in update_prog_stats() for 32bit arches
[ Upstream commit
d979617aa84d96acca44c2f5778892b4565e322f ]
It seems update_prog_stats() suffers from same issue fixed
in the prior patch:
As it can run while interrupts are enabled, it could
be re-entered and the u64_stats syncp could be mangled.
Fixes:
fec56f5890d9 ("bpf: Introduce BPF trampoline")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211026214133.3114279-3-eric.dumazet@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Tue, 26 Oct 2021 21:41:31 +0000 (14:41 -0700)]
bpf: Avoid races in __bpf_prog_run() for 32bit arches
[ Upstream commit
f941eadd8d6d4ee2f8c9aeab8e1da5e647533a7d ]
__bpf_prog_run() can run from non IRQ contexts, meaning
it could be re entered if interrupted.
This calls for the irq safe variant of u64_stats_update_{begin|end},
or risk a deadlock.
This patch is a nop on 64bit arches, fortunately.
syzbot report:
WARNING: inconsistent lock state
5.12.0-rc3-syzkaller #0 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
udevd/4013 [HC0[0]:SC0[0]:HE1:SE1] takes:
ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: sk_filter include/linux/filter.h:867 [inline]
ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: do_one_broadcast net/netlink/af_netlink.c:1468 [inline]
ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: netlink_broadcast_filtered+0x27c/0x4fc net/netlink/af_netlink.c:1520
{IN-SOFTIRQ-W} state was registered at:
lock_acquire.part.0+0xf0/0x41c kernel/locking/lockdep.c:5510
lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5483
do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline]
do_write_seqcount_begin include/linux/seqlock.h:545 [inline]
u64_stats_update_begin include/linux/u64_stats_sync.h:129 [inline]
bpf_prog_run_pin_on_cpu include/linux/filter.h:624 [inline]
bpf_prog_run_clear_cb+0x1bc/0x270 include/linux/filter.h:755
run_filter+0xa0/0x17c net/packet/af_packet.c:2031
packet_rcv+0xc0/0x3e0 net/packet/af_packet.c:2104
dev_queue_xmit_nit+0x2bc/0x39c net/core/dev.c:2387
xmit_one net/core/dev.c:3588 [inline]
dev_hard_start_xmit+0x94/0x518 net/core/dev.c:3609
sch_direct_xmit+0x11c/0x1f0 net/sched/sch_generic.c:313
qdisc_restart net/sched/sch_generic.c:376 [inline]
__qdisc_run+0x194/0x7f8 net/sched/sch_generic.c:384
qdisc_run include/net/pkt_sched.h:136 [inline]
qdisc_run include/net/pkt_sched.h:128 [inline]
__dev_xmit_skb net/core/dev.c:3795 [inline]
__dev_queue_xmit+0x65c/0xf84 net/core/dev.c:4150
dev_queue_xmit+0x14/0x18 net/core/dev.c:4215
neigh_resolve_output net/core/neighbour.c:1491 [inline]
neigh_resolve_output+0x170/0x228 net/core/neighbour.c:1471
neigh_output include/net/neighbour.h:510 [inline]
ip6_finish_output2+0x2e4/0x9fc net/ipv6/ip6_output.c:117
__ip6_finish_output net/ipv6/ip6_output.c:182 [inline]
__ip6_finish_output+0x164/0x3f8 net/ipv6/ip6_output.c:161
ip6_finish_output+0x2c/0xb0 net/ipv6/ip6_output.c:192
NF_HOOK_COND include/linux/netfilter.h:290 [inline]
ip6_output+0x74/0x294 net/ipv6/ip6_output.c:215
dst_output include/net/dst.h:448 [inline]
NF_HOOK include/linux/netfilter.h:301 [inline]
NF_HOOK include/linux/netfilter.h:295 [inline]
mld_sendpack+0x2a8/0x7e4 net/ipv6/mcast.c:1679
mld_send_cr net/ipv6/mcast.c:1975 [inline]
mld_ifc_timer_expire+0x1e8/0x494 net/ipv6/mcast.c:2474
call_timer_fn+0xd0/0x570 kernel/time/timer.c:1431
expire_timers kernel/time/timer.c:1476 [inline]
__run_timers kernel/time/timer.c:1745 [inline]
run_timer_softirq+0x2e4/0x384 kernel/time/timer.c:1758
__do_softirq+0x204/0x7ac kernel/softirq.c:345
do_softirq_own_stack include/asm-generic/softirq_stack.h:10 [inline]
invoke_softirq kernel/softirq.c:228 [inline]
__irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422
irq_exit+0x10/0x3c kernel/softirq.c:446
__handle_domain_irq+0xb4/0x120 kernel/irq/irqdesc.c:692
handle_domain_irq include/linux/irqdesc.h:176 [inline]
gic_handle_irq+0x84/0xac drivers/irqchip/irq-gic.c:370
__irq_svc+0x5c/0x94 arch/arm/kernel/entry-armv.S:205
debug_smp_processor_id+0x0/0x24 lib/smp_processor_id.c:53
rcu_read_lock_held_common kernel/rcu/update.c:108 [inline]
rcu_read_lock_sched_held+0x24/0x7c kernel/rcu/update.c:123
trace_lock_acquire+0x24c/0x278 include/trace/events/lock.h:13
lock_acquire+0x3c/0x74 kernel/locking/lockdep.c:5481
rcu_lock_acquire include/linux/rcupdate.h:267 [inline]
rcu_read_lock include/linux/rcupdate.h:656 [inline]
avc_has_perm_noaudit+0x6c/0x260 security/selinux/avc.c:1150
selinux_inode_permission+0x140/0x220 security/selinux/hooks.c:3141
security_inode_permission+0x44/0x60 security/security.c:1268
inode_permission.part.0+0x5c/0x13c fs/namei.c:521
inode_permission fs/namei.c:494 [inline]
may_lookup fs/namei.c:1652 [inline]
link_path_walk.part.0+0xd4/0x38c fs/namei.c:2208
link_path_walk fs/namei.c:2189 [inline]
path_lookupat+0x3c/0x1b8 fs/namei.c:2419
filename_lookup+0xa8/0x1a4 fs/namei.c:2453
user_path_at_empty+0x74/0x90 fs/namei.c:2733
do_readlinkat+0x5c/0x12c fs/stat.c:417
__do_sys_readlink fs/stat.c:450 [inline]
sys_readlink+0x24/0x28 fs/stat.c:447
ret_fast_syscall+0x0/0x2c arch/arm/mm/proc-v7.S:64
0x7eaa4974
irq event stamp: 298277
hardirqs last enabled at (298277): [<
802000d0>] no_work_pending+0x4/0x34
hardirqs last disabled at (298276): [<
8020c9b8>] do_work_pending+0x9c/0x648 arch/arm/kernel/signal.c:676
softirqs last enabled at (298216): [<
8020167c>] __do_softirq+0x584/0x7ac kernel/softirq.c:372
softirqs last disabled at (298201): [<
8024dff4>] do_softirq_own_stack include/asm-generic/softirq_stack.h:10 [inline]
softirqs last disabled at (298201): [<
8024dff4>] invoke_softirq kernel/softirq.c:228 [inline]
softirqs last disabled at (298201): [<
8024dff4>] __irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&pstats->syncp)->seq);
<Interrupt>
lock(&(&pstats->syncp)->seq);
*** DEADLOCK ***
1 lock held by udevd/4013:
#0:
82b09c5c (rcu_read_lock){....}-{1:2}, at: sk_filter_trim_cap+0x54/0x434 net/core/filter.c:139
stack backtrace:
CPU: 1 PID: 4013 Comm: udevd Not tainted 5.12.0-rc3-syzkaller #0
Hardware name: ARM-Versatile Express
Backtrace:
[<
81802550>] (dump_backtrace) from [<
818027c4>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:252)
r7:
00000080 r6:
600d0093 r5:
00000000 r4:
82b58344
[<
818027ac>] (show_stack) from [<
81809e98>] (__dump_stack lib/dump_stack.c:79 [inline])
[<
818027ac>] (show_stack) from [<
81809e98>] (dump_stack+0xb8/0xe8 lib/dump_stack.c:120)
[<
81809de0>] (dump_stack) from [<
81804a00>] (print_usage_bug.part.0+0x228/0x230 kernel/locking/lockdep.c:3806)
r7:
86bcb768 r6:
81a0326c r5:
830f96a8 r4:
86bcb0c0
[<
818047d8>] (print_usage_bug.part.0) from [<
802bb1b8>] (print_usage_bug kernel/locking/lockdep.c:3776 [inline])
[<
818047d8>] (print_usage_bug.part.0) from [<
802bb1b8>] (valid_state kernel/locking/lockdep.c:3818 [inline])
[<
818047d8>] (print_usage_bug.part.0) from [<
802bb1b8>] (mark_lock_irq kernel/locking/lockdep.c:4021 [inline])
[<
818047d8>] (print_usage_bug.part.0) from [<
802bb1b8>] (mark_lock.part.0+0xc34/0x136c kernel/locking/lockdep.c:4478)
r10:
83278fe8 r9:
82c6d748 r8:
00000000 r7:
82c6d2d4 r6:
00000004 r5:
86bcb768
r4:
00000006
[<
802ba584>] (mark_lock.part.0) from [<
802bc644>] (mark_lock kernel/locking/lockdep.c:4442 [inline])
[<
802ba584>] (mark_lock.part.0) from [<
802bc644>] (mark_usage kernel/locking/lockdep.c:4391 [inline])
[<
802ba584>] (mark_lock.part.0) from [<
802bc644>] (__lock_acquire+0x9bc/0x3318 kernel/locking/lockdep.c:4854)
r10:
86bcb768 r9:
86bcb0c0 r8:
00000001 r7:
00040000 r6:
0000075a r5:
830f96a8
r4:
00000000
[<
802bbc88>] (__lock_acquire) from [<
802bfb90>] (lock_acquire.part.0+0xf0/0x41c kernel/locking/lockdep.c:5510)
r10:
00000000 r9:
600d0013 r8:
00000000 r7:
00000000 r6:
828a2680 r5:
828a2680
r4:
861e5bc8
[<
802bfaa0>] (lock_acquire.part.0) from [<
802bff28>] (lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5483)
r10:
8146137c r9:
00000000 r8:
00000001 r7:
00000000 r6:
00000000 r5:
00000000
r4:
ff7c9dec
[<
802bfebc>] (lock_acquire) from [<
81381eb4>] (do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline])
[<
802bfebc>] (lock_acquire) from [<
81381eb4>] (do_write_seqcount_begin include/linux/seqlock.h:545 [inline])
[<
802bfebc>] (lock_acquire) from [<
81381eb4>] (u64_stats_update_begin include/linux/u64_stats_sync.h:129 [inline])
[<
802bfebc>] (lock_acquire) from [<
81381eb4>] (__bpf_prog_run_save_cb include/linux/filter.h:727 [inline])
[<
802bfebc>] (lock_acquire) from [<
81381eb4>] (bpf_prog_run_save_cb include/linux/filter.h:741 [inline])
[<
802bfebc>] (lock_acquire) from [<
81381eb4>] (sk_filter_trim_cap+0x26c/0x434 net/core/filter.c:149)
r10:
a4095dd0 r9:
ff7c9dd0 r8:
e44be000 r7:
8146137c r6:
00000001 r5:
8611ba80
r4:
00000000
[<
81381c48>] (sk_filter_trim_cap) from [<
8146137c>] (sk_filter include/linux/filter.h:867 [inline])
[<
81381c48>] (sk_filter_trim_cap) from [<
8146137c>] (do_one_broadcast net/netlink/af_netlink.c:1468 [inline])
[<
81381c48>] (sk_filter_trim_cap) from [<
8146137c>] (netlink_broadcast_filtered+0x27c/0x4fc net/netlink/af_netlink.c:1520)
r10:
00000001 r9:
833d6b1c r8:
00000000 r7:
8572f864 r6:
8611ba80 r5:
8698d800
r4:
8572f800
[<
81461100>] (netlink_broadcast_filtered) from [<
81463e60>] (netlink_broadcast net/netlink/af_netlink.c:1544 [inline])
[<
81461100>] (netlink_broadcast_filtered) from [<
81463e60>] (netlink_sendmsg+0x3d0/0x478 net/netlink/af_netlink.c:1925)
r10:
00000000 r9:
00000002 r8:
8698d800 r7:
000000b7 r6:
8611b900 r5:
861e5f50
r4:
86aa3000
[<
81463a90>] (netlink_sendmsg) from [<
81321f54>] (sock_sendmsg_nosec net/socket.c:654 [inline])
[<
81463a90>] (netlink_sendmsg) from [<
81321f54>] (sock_sendmsg+0x3c/0x4c net/socket.c:674)
r10:
00000000 r9:
861e5dd4 r8:
00000000 r7:
86570000 r6:
00000000 r5:
86570000
r4:
861e5f50
[<
81321f18>] (sock_sendmsg) from [<
813234d0>] (____sys_sendmsg+0x230/0x29c net/socket.c:2350)
r5:
00000040 r4:
861e5f50
[<
813232a0>] (____sys_sendmsg) from [<
8132549c>] (___sys_sendmsg+0xac/0xe4 net/socket.c:2404)
r10:
00000128 r9:
861e4000 r8:
00000000 r7:
00000000 r6:
86570000 r5:
861e5f50
r4:
00000000
[<
813253f0>] (___sys_sendmsg) from [<
81325684>] (__sys_sendmsg net/socket.c:2433 [inline])
[<
813253f0>] (___sys_sendmsg) from [<
81325684>] (__do_sys_sendmsg net/socket.c:2442 [inline])
[<
813253f0>] (___sys_sendmsg) from [<
81325684>] (sys_sendmsg+0x58/0xa0 net/socket.c:2440)
r8:
80200224 r7:
00000128 r6:
00000000 r5:
7eaa541c r4:
86570000
[<
8132562c>] (sys_sendmsg) from [<
80200060>] (ret_fast_syscall+0x0/0x2c arch/arm/mm/proc-v7.S:64)
Exception stack(0x861e5fa8 to 0x861e5ff0)
5fa0:
00000000 00000000 0000000c 7eaa541c 00000000 00000000
5fc0:
00000000 00000000 76fbf840 00000128 00000000 0000008f 7eaa541c 000563f8
5fe0:
00056110 7eaa53e0 00036cec 76c9bf44
r6:
76fbf840 r5:
00000000 r4:
00000000
Fixes:
492ecee892c2 ("bpf: enable program stats")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211026214133.3114279-2-eric.dumazet@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Loic Poulain [Mon, 25 Oct 2021 08:25:36 +0000 (10:25 +0200)]
wcn36xx: Fix discarded frames due to wrong sequence number
[ Upstream commit
113f304dbc1627c6ec9d5329d839964095768980 ]
The firmware is offering features such as ARP offload, for which
firmware crafts its own (QoS)packets without waking up the host.
Point is that the sequence numbers generated by the firmware are
not in sync with the host mac80211 layer and can cause packets
such as firmware ARP reponses to be dropped by the AP (too old SN).
To fix this we need to let the firmware manages the sequence
numbers by its own (except for QoS null frames). There is a SN
counter for each QoS queue and one global/baseline counter for
Non-QoS.
Fixes:
84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Benjamin Li [Sat, 23 Oct 2021 00:15:28 +0000 (17:15 -0700)]
wcn36xx: add proper DMA memory barriers in rx path
[ Upstream commit
9bfe38e064af5decba2ffce66a2958ab8b10eaa4 ]
This is essentially exactly following the dma_wmb()/dma_rmb() usage
instructions in Documentation/memory-barriers.txt.
The theoretical races here are:
1. DXE (the DMA Transfer Engine in the Wi-Fi subsystem) seeing the
dxe->ctrl & WCN36xx_DXE_CTRL_VLD write before the dxe->dst_addr_l
write, thus performing DMA into the wrong address.
2. CPU reading dxe->dst_addr_l before DXE unsets dxe->ctrl &
WCN36xx_DXE_CTRL_VLD. This should generally be harmless since DXE
doesn't write dxe->dst_addr_l (no risk of freeing the wrong skb).
Fixes:
8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
Signed-off-by: Benjamin Li <benl@squareup.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211023001528.3077822-1-benl@squareup.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Wed, 20 Oct 2021 12:03:45 +0000 (20:03 +0800)]
libertas: Fix possible memory leak in probe and disconnect
[ Upstream commit
9692151e2fe7a326bafe99836fd1f20a2cc3a049 ]
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88812c7d7400 (size 512):
comm "kworker/6:1", pid 176, jiffies
4295003332 (age 822.830s)
hex dump (first 32 bytes):
00 68 1e 04 81 88 ff ff 01 00 00 00 00 00 00 00 .h..............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490
[<
ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470
[<
ffffffffa02c9873>] if_usb_probe+0x63/0x446 [usb8xxx]
[<
ffffffffa022668a>] usb_probe_interface+0x1aa/0x3c0 [usbcore]
[<
ffffffff82b59630>] really_probe+0x190/0x480
[<
ffffffff82b59a19>] __driver_probe_device+0xf9/0x180
[<
ffffffff82b59af3>] driver_probe_device+0x53/0x130
[<
ffffffff82b5a075>] __device_attach_driver+0x105/0x130
[<
ffffffff82b55949>] bus_for_each_drv+0x129/0x190
[<
ffffffff82b593c9>] __device_attach+0x1c9/0x270
[<
ffffffff82b5a250>] device_initial_probe+0x20/0x30
[<
ffffffff82b579c2>] bus_probe_device+0x142/0x160
[<
ffffffff82b52e49>] device_add+0x829/0x1300
[<
ffffffffa02229b1>] usb_set_configuration+0xb01/0xcc0 [usbcore]
[<
ffffffffa0235c4e>] usb_generic_driver_probe+0x6e/0x90 [usbcore]
[<
ffffffffa022641f>] usb_probe_device+0x6f/0x130 [usbcore]
cardp is missing being freed in the error handling path of the probe
and the path of the disconnect, which will cause memory leak.
This patch adds the missing kfree().
Fixes:
876c9d3aeb98 ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211020120345.2016045-3-wanghai38@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Wed, 20 Oct 2021 12:03:44 +0000 (20:03 +0800)]
libertas_tf: Fix possible memory leak in probe and disconnect
[ Upstream commit
d549107305b4634c81223a853701c06bcf657bc3 ]
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88810a2ddc00 (size 512):
comm "kworker/6:1", pid 176, jiffies
4295009893 (age 757.220s)
hex dump (first 32 bytes):
00 50 05 18 81 88 ff ff 00 00 00 00 00 00 00 00 .P..............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
ffffffff8167939c>] slab_post_alloc_hook+0x9c/0x490
[<
ffffffff8167f627>] kmem_cache_alloc_trace+0x1f7/0x470
[<
ffffffffa02a1530>] if_usb_probe+0x60/0x37c [libertas_tf_usb]
[<
ffffffffa022668a>] usb_probe_interface+0x1aa/0x3c0 [usbcore]
[<
ffffffff82b59630>] really_probe+0x190/0x480
[<
ffffffff82b59a19>] __driver_probe_device+0xf9/0x180
[<
ffffffff82b59af3>] driver_probe_device+0x53/0x130
[<
ffffffff82b5a075>] __device_attach_driver+0x105/0x130
[<
ffffffff82b55949>] bus_for_each_drv+0x129/0x190
[<
ffffffff82b593c9>] __device_attach+0x1c9/0x270
[<
ffffffff82b5a250>] device_initial_probe+0x20/0x30
[<
ffffffff82b579c2>] bus_probe_device+0x142/0x160
[<
ffffffff82b52e49>] device_add+0x829/0x1300
[<
ffffffffa02229b1>] usb_set_configuration+0xb01/0xcc0 [usbcore]
[<
ffffffffa0235c4e>] usb_generic_driver_probe+0x6e/0x90 [usbcore]
[<
ffffffffa022641f>] usb_probe_device+0x6f/0x130 [usbcore]
cardp is missing being freed in the error handling path of the probe
and the path of the disconnect, which will cause memory leak.
This patch adds the missing kfree().
Fixes:
c305a19a0d0a ("libertas_tf: usb specific functions")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211020120345.2016045-2-wanghai38@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Janis Schoetterl-Glausch [Fri, 22 Oct 2021 15:26:48 +0000 (17:26 +0200)]
KVM: s390: Fix handle_sske page fault handling
[ Upstream commit
85f517b29418158d3e6e90c3f0fc01b306d2f1a1 ]
If handle_sske cannot set the storage key, because there is no
page table entry or no present large page entry, it calls
fixup_user_fault.
However, currently, if the call succeeds, handle_sske returns
-EAGAIN, without having set the storage key.
Instead, retry by continue'ing the loop without incrementing the
address.
The same issue in handle_pfmf was fixed by
a11bdb1a6b78 ("KVM: s390: Fix pfmf and conditional skey emulation").
Fixes:
bd096f644319 ("KVM: s390: Add skey emulation fault handling")
Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Link: https://lore.kernel.org/r/20211022152648.26536-1-scgl@linux.ibm.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tiezhu Yang [Tue, 26 Oct 2021 01:51:28 +0000 (09:51 +0800)]
samples/kretprobes: Fix return value if register_kretprobe() failed
[ Upstream commit
f76fbbbb5061fe14824ba5807c44bd7400a6b4e1 ]
Use the actual return value instead of always -1 if register_kretprobe()
failed.
E.g. without this patch:
# insmod samples/kprobes/kretprobe_example.ko func=no_such_func
insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Operation not permitted
With this patch:
# insmod samples/kprobes/kretprobe_example.ko func=no_such_func
insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Unknown symbol in module
Link: https://lkml.kernel.org/r/1635213091-24387-2-git-send-email-yangtiezhu@loongson.cn
Fixes:
804defea1c02 ("Kprobes: move kprobe examples to samples/")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lad Prabhakar [Mon, 25 Oct 2021 20:56:27 +0000 (21:56 +0100)]
spi: spi-rpc-if: Check return value of rpcif_sw_init()
[ Upstream commit
0b0a281ed7001d4c4f4c47bdc84680c4997761ca ]
rpcif_sw_init() can fail so make sure we check the return value
of it and on error exit rpcif_spi_probe() callback with error code.
Fixes:
eb8d6d464a27 ("spi: add Renesas RPC-IF driver")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20211025205631.21151-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Rui [Tue, 26 Oct 2021 08:32:42 +0000 (16:32 +0800)]
cpufreq: intel_pstate: Fix cpu->pstate.turbo_freq initialization
[ Upstream commit
c72bcf0ab87a92634e58af62e89af0f40dfd0b88 ]
Fix a problem in active mode that cpu->pstate.turbo_freq is initialized
only if HWP-to-frequency scaling factor is refined.
In passive mode, this problem is not exposed, because
cpu->pstate.turbo_freq is set again, later in
intel_cpufreq_cpu_init()->intel_pstate_get_hwp_cap().
Fixes:
eb3693f0521e ("cpufreq: intel_pstate: hybrid: CPU-specific scaling factor")
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mathieu Desnoyers [Fri, 15 Oct 2021 19:55:50 +0000 (15:55 -0400)]
tracing: Fix missing trace_boot_init_histograms kstrdup NULL checks
[ Upstream commit
3c20bd3af535d64771b193bb4dd41ed662c464ce ]
trace_boot_init_histograms misses NULL pointer checks for kstrdup
failure.
Link: https://lkml.kernel.org/r/20211015195550.22742-1-mathieu.desnoyers@efficios.com
Fixes:
64dc7f6958ef5 ("tracing/boot: Show correct histogram error command")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jon Maxwell [Sun, 24 Oct 2021 23:59:03 +0000 (10:59 +1100)]
tcp: don't free a FIN sk_buff in tcp_remove_empty_skb()
[ Upstream commit
cf12e6f9124629b18a6182deefc0315f0a73a199 ]
v1: Implement a more general statement as recommended by Eric Dumazet. The
sequence number will be advanced, so this check will fix the FIN case and
other cases.
A customer reported sockets stuck in the CLOSING state. A Vmcore revealed that
the write_queue was not empty as determined by tcp_write_queue_empty() but the
sk_buff containing the FIN flag had been freed and the socket was zombied in
that state. Corresponding pcaps show no FIN from the Linux kernel on the wire.
Some instrumentation was added to the kernel and it was found that there is a
timing window where tcp_sendmsg() can run after tcp_send_fin().
tcp_sendmsg() will hit an error, for example:
1269 ▹ if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))↩
1270 ▹ ▹ goto do_error;↩
tcp_remove_empty_skb() will then free the FIN sk_buff as "skb->len == 0". The
TCP socket is now wedged in the FIN-WAIT-1 state because the FIN is never sent.
If the other side sends a FIN packet the socket will transition to CLOSING and
remain that way until the system is rebooted.
Fix this by checking for the FIN flag in the sk_buff and don't free it if that
is the case. Testing confirmed that fixed the issue.
Fixes:
fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases")
Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
Reported-by: Monir Zouaoui <Monir.Zouaoui@mail.schwarz>
Reported-by: Simon Stier <simon.stier@mail.schwarz>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ilya Leoshkevich [Tue, 26 Oct 2021 01:08:26 +0000 (03:08 +0200)]
libbpf: Fix endianness detection in BPF_CORE_READ_BITFIELD_PROBED()
[ Upstream commit
45f2bebc8079788f62f22d9e8b2819afb1789d7b ]
__BYTE_ORDER is supposed to be defined by a libc, and __BYTE_ORDER__ -
by a compiler. bpf_core_read.h checks __BYTE_ORDER == __LITTLE_ENDIAN,
which is true if neither are defined, leading to incorrect behavior on
big-endian hosts if libc headers are not included, which is often the
case.
Fixes:
ee26dade0e3b ("libbpf: Add support for relocatable bitfields")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211026010831.748682-2-iii@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mark Brown [Fri, 24 Sep 2021 14:41:11 +0000 (15:41 +0100)]
tpm_tis_spi: Add missing SPI ID
[ Upstream commit
7eba41fe8c7bb01ff3d4b757bd622375792bc720 ]
In commit
c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
we added SPI IDs for all the DT aliases to handle the fact that we always
use SPI modaliases to load modules even when probed via DT however the
mentioned commit missed that the SPI and OF device ID entries did not
match and were different and so DT nodes with compatible
"tcg,tpm_tis-spi" will not match. Add an extra ID for tpm_tis-spi
rather than just fix the existing one since what's currently there is
going to be better for anyone actually using SPI IDs to instantiate.
Fixes:
c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
Fixes:
96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hao Wu [Wed, 8 Sep 2021 09:26:06 +0000 (02:26 -0700)]
tpm: fix Atmel TPM crash caused by too frequent queries
[ Upstream commit
79ca6f74dae067681a779fd573c2eb59649989bc ]
The Atmel TPM 1.2 chips crash with error
`tpm_try_transmit: send(): error -62` since kernel 4.14.
It is observed from the kernel log after running `tpm_sealdata -z`.
The error thrown from the command is as follows
```
$ tpm_sealdata -z
Tspi_Key_LoadKey failed: 0x00001087 - layer=tddl,
code=0087 (135), I/O error
```
The issue was reproduced with the following Atmel TPM chip:
```
$ tpm_version
T0 TPM 1.2 Version Info:
Chip Version: 1.2.66.1
Spec Level: 2
Errata Revision: 3
TPM Vendor ID: ATML
TPM Version:
01010000
Manufacturer Info:
41544d4c
```
The root cause of the issue is due to the TPM calls to msleep()
were replaced with usleep_range() [1], which reduces
the actual timeout. Via experiments, it is observed that
the original msleep(5) actually sleeps for 15ms.
Because of a known timeout issue in Atmel TPM 1.2 chip,
the shorter timeout than 15ms can cause the error described above.
A few further changes in kernel 4.16 [2] and 4.18 [3, 4] further
reduced the timeout to less than 1ms. With experiments,
the problematic timeout in the latest kernel is the one
for `wait_for_tpm_stat`.
To fix it, the patch reverts the timeout of `wait_for_tpm_stat`
to 15ms for all Atmel TPM 1.2 chips, but leave it untouched
for Ateml TPM 2.0 chip, and chips from other vendors.
As explained above, the chosen 15ms timeout is
the actual timeout before this issue introduced,
thus the old value is used here.
Particularly, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 14700us,
TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 15000us according to
the existing TPM_TIMEOUT_RANGE_US (300us).
The fixed has been tested in the system with the affected Atmel chip
with no issues observed after boot up.
References:
[1]
9f3fc7bcddcb tpm: replace msleep() with usleep_range() in TPM
1.2/2.0 generic drivers
[2]
cf151a9a44d5 tpm: reduce tpm polling delay in tpm_tis_core
[3]
59f5a6b07f64 tpm: reduce poll sleep time in tpm_transmit()
[4]
424eaf910c32 tpm: reduce polling time to usecs for even finer
granularity
Fixes:
9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers")
Link: https://patchwork.kernel.org/project/linux-integrity/patch/20200926223150.109645-1-hao.wu@rubrik.com/
Signed-off-by: Hao Wu <hao.wu@rubrik.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Mon, 25 Oct 2021 22:45:28 +0000 (15:45 -0700)]
libbpf: Fix off-by-one bug in bpf_core_apply_relo()
[ Upstream commit
de5d0dcef602de39070c31c7e56c58249c56ba37 ]
Fix instruction index validity check which has off-by-one error.
Fixes:
3ee4f5335511 ("libbpf: Split bpf_core_apply_relo() into bpf_program independent helper.")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211025224531.1088894-2-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yu Kuai [Wed, 20 Oct 2021 01:40:36 +0000 (09:40 +0800)]
blk-cgroup: synchronize blkg creation against policy deactivation
[ Upstream commit
0c9d338c8443b06da8e8d3bfce824c5ea6d3488f ]
Our test reports a null pointer dereference:
[ 168.534653] ==================================================================
[ 168.535614] Disabling lock debugging due to kernel taint
[ 168.536346] BUG: kernel NULL pointer dereference, address:
0000000000000008
[ 168.537274] #PF: supervisor read access in kernel mode
[ 168.537964] #PF: error_code(0x0000) - not-present page
[ 168.538667] PGD 0 P4D 0
[ 168.539025] Oops: 0000 [#1] PREEMPT SMP KASAN
[ 168.539656] CPU: 13 PID: 759 Comm: bash Tainted: G B 5.15.0-rc2-next-202100
[ 168.540954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_0738364
[ 168.542736] RIP: 0010:bfq_pd_init+0x88/0x1e0
[ 168.543318] Code: 98 00 00 00 e8 c9 e4 5b ff 4c 8b 65 00 49 8d 7c 24 08 e8 bb e4 5b ff 4d0
[ 168.545803] RSP: 0018:
ffff88817095f9c0 EFLAGS:
00010002
[ 168.546497] RAX:
0000000000000001 RBX:
ffff888101a1c000 RCX:
0000000000000000
[ 168.547438] RDX:
0000000000000003 RSI:
0000000000000002 RDI:
ffff888106553428
[ 168.548402] RBP:
ffff888106553400 R08:
ffffffff961bcaf4 R09:
0000000000000001
[ 168.549365] R10:
ffffffffa2e16c27 R11:
fffffbfff45c2d84 R12:
0000000000000000
[ 168.550291] R13:
ffff888101a1c098 R14:
ffff88810c7a08c8 R15:
ffffffffa55541a0
[ 168.551221] FS:
00007fac75227700(0000) GS:
ffff88839ba80000(0000) knlGS:
0000000000000000
[ 168.552278] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 168.553040] CR2:
0000000000000008 CR3:
0000000165ce7000 CR4:
00000000000006e0
[ 168.554000] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 168.554929] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 168.555888] Call Trace:
[ 168.556221] <TASK>
[ 168.556510] blkg_create+0x1c0/0x8c0
[ 168.556989] blkg_conf_prep+0x574/0x650
[ 168.557502] ? stack_trace_save+0x99/0xd0
[ 168.558033] ? blkcg_conf_open_bdev+0x1b0/0x1b0
[ 168.558629] tg_set_conf.constprop.0+0xb9/0x280
[ 168.559231] ? kasan_set_track+0x29/0x40
[ 168.559758] ? kasan_set_free_info+0x30/0x60
[ 168.560344] ? tg_set_limit+0xae0/0xae0
[ 168.560853] ? do_sys_openat2+0x33b/0x640
[ 168.561383] ? do_sys_open+0xa2/0x100
[ 168.561877] ? __x64_sys_open+0x4e/0x60
[ 168.562383] ? __kasan_check_write+0x20/0x30
[ 168.562951] ? copyin+0x48/0x70
[ 168.563390] ? _copy_from_iter+0x234/0x9e0
[ 168.563948] tg_set_conf_u64+0x17/0x20
[ 168.564467] cgroup_file_write+0x1ad/0x380
[ 168.565014] ? cgroup_file_poll+0x80/0x80
[ 168.565568] ? __mutex_lock_slowpath+0x30/0x30
[ 168.566165] ? pgd_free+0x100/0x160
[ 168.566649] kernfs_fop_write_iter+0x21d/0x340
[ 168.567246] ? cgroup_file_poll+0x80/0x80
[ 168.567796] new_sync_write+0x29f/0x3c0
[ 168.568314] ? new_sync_read+0x410/0x410
[ 168.568840] ? __handle_mm_fault+0x1c97/0x2d80
[ 168.569425] ? copy_page_range+0x2b10/0x2b10
[ 168.570007] ? _raw_read_lock_bh+0xa0/0xa0
[ 168.570622] vfs_write+0x46e/0x630
[ 168.571091] ksys_write+0xcd/0x1e0
[ 168.571563] ? __x64_sys_read+0x60/0x60
[ 168.572081] ? __kasan_check_write+0x20/0x30
[ 168.572659] ? do_user_addr_fault+0x446/0xff0
[ 168.573264] __x64_sys_write+0x46/0x60
[ 168.573774] do_syscall_64+0x35/0x80
[ 168.574264] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 168.574960] RIP: 0033:0x7fac74915130
[ 168.575456] Code: 73 01 c3 48 8b 0d 58 ed 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 444
[ 168.577969] RSP: 002b:
00007ffc3080e288 EFLAGS:
00000246 ORIG_RAX:
0000000000000001
[ 168.578986] RAX:
ffffffffffffffda RBX:
0000000000000009 RCX:
00007fac74915130
[ 168.579937] RDX:
0000000000000009 RSI:
000056007669f080 RDI:
0000000000000001
[ 168.580884] RBP:
000056007669f080 R08:
000000000000000a R09:
00007fac75227700
[ 168.581841] R10:
000056007655c8f0 R11:
0000000000000246 R12:
0000000000000009
[ 168.582796] R13:
0000000000000001 R14:
00007fac74be55e0 R15:
00007fac74be08c0
[ 168.583757] </TASK>
[ 168.584063] Modules linked in:
[ 168.584494] CR2:
0000000000000008
[ 168.584964] ---[ end trace
2475611ad0f77a1a ]---
This is because blkg_alloc() is called from blkg_conf_prep() without
holding 'q->queue_lock', and elevator is exited before blkg_create():
thread 1 thread 2
blkg_conf_prep
spin_lock_irq(&q->queue_lock);
blkg_lookup_check -> return NULL
spin_unlock_irq(&q->queue_lock);
blkg_alloc
blkcg_policy_enabled -> true
pd = ->pd_alloc_fn
blkg->pd[i] = pd
blk_mq_exit_sched
bfq_exit_queue
blkcg_deactivate_policy
spin_lock_irq(&q->queue_lock);
__clear_bit(pol->plid, q->blkcg_pols);
spin_unlock_irq(&q->queue_lock);
q->elevator = NULL;
spin_lock_irq(&q->queue_lock);
blkg_create
if (blkg->pd[i])
->pd_init_fn -> q->elevator is NULL
spin_unlock_irq(&q->queue_lock);
Because blkcg_deactivate_policy() requires queue to be frozen, we can
grab q_usage_counter to synchoronize blkg_conf_prep() against
blkcg_deactivate_policy().
Fixes:
e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20211020014036.2141723-1-yukuai3@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Schmitz [Sun, 24 Oct 2021 00:20:13 +0000 (13:20 +1300)]
block: ataflop: more blk-mq refactoring fixes
[ Upstream commit
d28e4dff085c5a87025c9a0a85fb798bd8e9ca17 ]
As it turns out, my earlier patch in commit
86d46fdaa12a (block:
ataflop: fix breakage introduced at blk-mq refactoring) was
incomplete. This patch fixes any remaining issues found during
more testing and code review.
Requests exceeding 4 k are handled in 4k segments but
__blk_mq_end_request() is never called on these (still
sectors outstanding on the request). With redo_fd_request()
removed, there is no provision to kick off processing of the
next segment, causing requests exceeding 4k to hang. (By
setting /sys/block/fd0/queue/max_sectors_k <= 4 as workaround,
this behaviour can be avoided).
Instead of reintroducing redo_fd_request(), requeue the remainder
of the request by calling blk_mq_requeue_request() on incomplete
requests (i.e. when blk_update_request() still returns true), and
rely on the block layer to queue the residual as new request.
Both error handling and formatting needs to release the
ST-DMA lock, so call finish_fdc() on these (this was previously
handled by redo_fd_request()). finish_fdc() may be called
legitimately without the ST-DMA lock held - make sure we only
release the lock if we actually held it. In a similar way,
early exit due to errors in ataflop_queue_rq() must release
the lock.
After minor errors, fd_error sets up to recalibrate the drive
but never re-runs the current operation (another task handled by
redo_fd_request() before). Call do_fd_action() to get the next
steps (seek, retry read/write) underway.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Fixes:
6ec3938cff95f (ataflop: convert to blk-mq)
CC: linux-block@vger.kernel.org
Link: https://lore.kernel.org/r/20211024002013.9332-1-schmitzmic@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Abinaya Kalaiselvan [Wed, 20 Oct 2021 08:59:07 +0000 (11:59 +0300)]
ath10k: fix module load regression with iram-recovery feature
[ Upstream commit
6f8c8bf4c7c9be1c42088689fd4370e06b46608a ]
Commit
9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
introduced a new firmware feature flag ATH10K_FW_FEATURE_IRAM_RECOVERY. But
this caused ath10k_pci module load to fail if ATH10K_FW_CRASH_DUMP_RAM_DATA bit
was not enabled in the ath10k coredump_mask module parameter:
[ 2209.328190] ath10k_pci 0000:02:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 2209.434414] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
[ 2209.547191] ath10k_pci 0000:02:00.0: firmware ver 10.4-3.9.0.2-00099 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32
cbade90a
[ 2210.896485] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id 0:1 crc32
a040efc2
[ 2213.603339] ath10k_pci 0000:02:00.0: failed to copy target iram contents: -12
[ 2213.839027] ath10k_pci 0000:02:00.0: could not init core (-12)
[ 2213.933910] ath10k_pci 0000:02:00.0: could not probe fw (-12)
And by default coredump_mask does not have ATH10K_FW_CRASH_DUMP_RAM_DATA
enabled so anyone using a firmware with iram-recovery feature would fail. To my
knowledge only QCA9984 firmwares starting from release 10.4-3.9.0.2-00099
enabled the feature.
The reason for regression was that ath10k_core_copy_target_iram() used
ath10k_coredump_get_mem_layout() to get the memory layout, but when
ATH10K_FW_CRASH_DUMP_RAM_DATA was disabled it would get just NULL and bail out
with an error.
While looking at all this I noticed another bug: if CONFIG_DEV_COREDUMP is
disabled but the firmware has iram-recovery enabled the module load fails with
similar error messages. I fixed that by returning 0 from
ath10k_core_copy_target_iram() when _ath10k_coredump_get_mem_layout() returns
NULL.
Tested-on: QCA9984 hw2.0 PCI 10.4-3.9.0.2-00139
Fixes:
9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
Signed-off-by: Abinaya Kalaiselvan <akalaise@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211020075054.23061-1-kvalo@codeaurora.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Mon, 18 Oct 2021 14:30:38 +0000 (15:30 +0100)]
ARM: 9142/1: kasan: work around LPAE build warning
[ Upstream commit
c2e6df3eaaf120cde5e7c3a70590dd82e427458a ]
pgd_page_vaddr() returns an 'unsigned long' address, causing a warning
with the memcpy() call in kasan_init():
arch/arm/mm/kasan_init.c: In function 'kasan_init':
include/asm-generic/pgtable-nop4d.h:44:50: error: passing argument 2 of '__memcpy' makes pointer from integer without a cast [-Werror=int-conversion]
44 | #define pgd_page_vaddr(pgd) ((unsigned long)(p4d_pgtable((p4d_t){ pgd })))
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| long unsigned int
arch/arm/include/asm/string.h:58:45: note: in definition of macro 'memcpy'
58 | #define memcpy(dst, src, len) __memcpy(dst, src, len)
| ^~~
arch/arm/mm/kasan_init.c:229:16: note: in expansion of macro 'pgd_page_vaddr'
229 | pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
| ^~~~~~~~~~~~~~
arch/arm/include/asm/string.h:21:47: note: expected 'const void *' but argument is of type 'long unsigned int'
21 | extern void *__memcpy(void *dest, const void *src, __kernel_size_t n);
| ~~~~~~~~~~~~^~~
Avoid this by adding an explicit typecast.
Link: https://lore.kernel.org/all/CACRpkdb3DMvof3-xdtss0Pc6KM36pJA-iy=WhvtNVnsDpeJ24Q@mail.gmail.com/
Fixes:
5615f69bc209 ("ARM: 9016/2: Initialize the mapping of KASan shadow memory")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vladimir Oltean [Sun, 24 Oct 2021 17:17:48 +0000 (20:17 +0300)]
net: dsa: avoid refcount warnings when ->port_{fdb,mdb}_del returns error
[ Upstream commit
232deb3f9567ce37d99b8616a6c07c1fc0436abf ]
At present, when either of ds->ops->port_fdb_del() or ds->ops->port_mdb_del()
return a non-zero error code, we attempt to save the day and keep the
data structure associated with that switchdev object, as the deletion
procedure did not complete.
However, the way in which we do this is suspicious to the checker in
lib/refcount.c, who thinks it is buggy to increment a refcount that
became zero, and that this is indicative of a use-after-free.
Fixes:
161ca59d39e9 ("net: dsa: reference count the MDB entries at the cross-chip notifier level")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mark Rutland [Wed, 20 Oct 2021 16:25:22 +0000 (17:25 +0100)]
irq: mips: avoid nested irq_enter()
[ Upstream commit
c65b52d02f6c1a06ddb20cba175ad49eccd6410d ]
As bcm6345_l1_irq_handle() is a chained irqchip handler, it will be
invoked within the context of the root irqchip handler, which must have
entered IRQ context already.
When bcm6345_l1_irq_handle() calls arch/mips's do_IRQ() , this will nest
another call to irq_enter(), and the resulting nested increment to
`rcu_data.dynticks_nmi_nesting` will cause rcu_is_cpu_rrupt_from_idle()
to fail to identify wakeups from idle, resulting in failure to preempt,
and RCU stalls.
Chained irqchip handlers must invoke IRQ handlers by way of thee core
irqchip code, i.e. generic_handle_irq() or generic_handle_domain_irq()
and should not call do_IRQ(), which is intended only for root irqchip
handlers.
Fix bcm6345_l1_irq_handle() by calling generic_handle_irq() directly.
Fixes:
c7c42ec2baa1de7a ("irqchips/bmips: Add bcm6345-l1 interrupt controller")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Claudio Imbrenda [Mon, 20 Sep 2021 13:24:51 +0000 (15:24 +0200)]
KVM: s390: pv: avoid stalls for kvm_s390_pv_init_vm
[ Upstream commit
1e2aa46de526a5adafe580bca4c25856bb06f09e ]
When the system is heavily overcommitted, kvm_s390_pv_init_vm might
generate stall notifications.
Fix this by using uv_call_sched instead of just uv_call. This is ok because
we are not holding spinlocks.
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Fixes:
214d9bbcd3a672 ("s390/mm: provide memory management functions for protected KVM guests")
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Message-Id: <
20210920132502.36111-4-imbrenda@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Claudio Imbrenda [Mon, 20 Sep 2021 13:24:50 +0000 (15:24 +0200)]
KVM: s390: pv: avoid double free of sida page
[ Upstream commit
d4074324b07a94a1fca476d452dfbb3a4e7bf656 ]
If kvm_s390_pv_destroy_cpu is called more than once, we risk calling
free_page on a random page, since the sidad field is aliased with the
gbea, which is not guaranteed to be zero.
This can happen, for example, if userspace calls the KVM_PV_DISABLE
IOCTL, and it fails, and then userspace calls the same IOCTL again.
This scenario is only possible if KVM has some serious bug or if the
hardware is broken.
The solution is to simply return successfully immediately if the vCPU
was already non secure.
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Fixes:
19e1227768863a1469797c13ef8fea1af7beac2c ("KVM: S390: protvirt: Introduce instruction data area bounce buffer")
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <
20210920132502.36111-3-imbrenda@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Hildenbrand [Thu, 9 Sep 2021 16:22:44 +0000 (18:22 +0200)]
s390/uv: fully validate the VMA before calling follow_page()
[ Upstream commit
46c22ffd2772201662350bc7b94b9ea9d3ee5ac2 ]
We should not walk/touch page tables outside of VMA boundaries when
holding only the mmap sem in read mode. Evil user space can modify the
VMA layout just before this function runs and e.g., trigger races with
page table removal code since commit
dd2283f2605e ("mm: mmap: zap pages
with read mmap_sem in munmap").
find_vma() does not check if the address is >= the VMA start address;
use vma_lookup() instead.
Fixes:
214d9bbcd3a6 ("s390/mm: provide memory management functions for protected KVM guests")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Link: https://lore.kernel.org/r/20210909162248.14969-6-david@redhat.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Hildenbrand [Thu, 9 Sep 2021 16:22:43 +0000 (18:22 +0200)]
s390/mm: fix VMA and page table handling code in storage key handling functions
[ Upstream commit
949f5c1244ee6c36d2e81c588d1200eaa83a3df6 ]
There are multiple things broken about our storage key handling
functions:
1. We should not walk/touch page tables outside of VMA boundaries when
holding only the mmap sem in read mode. Evil user space can modify the
VMA layout just before this function runs and e.g., trigger races with
page table removal code since commit
dd2283f2605e ("mm: mmap: zap pages
with read mmap_sem in munmap"). gfn_to_hva() will only translate using
KVM memory regions, but won't validate the VMA.
2. We should not allocate page tables outside of VMA boundaries: if
evil user space decides to map hugetlbfs to these ranges, bad things
will happen because we suddenly have PTE or PMD page tables where we
shouldn't have them.
3. We don't handle large PUDs that might suddenly appeared inside our page
table hierarchy.
Don't manually allocate page tables, properly validate that we have VMA and
bail out on pud_large().
All callers of page table handling functions, except
get_guest_storage_key(), call fixup_user_fault() in case they
receive an -EFAULT and retry; this will allocate the necessary page tables
if required.
To keep get_guest_storage_key() working as expected and not requiring
kvm_s390_get_skeys() to call fixup_user_fault() distinguish between
"there is simply no page table or huge page yet and the key is assumed
to be 0" and "this is a fault to be reported".
Although commit
637ff9efe5ea ("s390/mm: Add huge pmd storage key handling")
introduced most of the affected code, it was actually already broken
before when using get_locked_pte() without any VMA checks.
Note: Ever since commit
637ff9efe5ea ("s390/mm: Add huge pmd storage key
handling") we can no longer set a guest storage key (for example from
QEMU during VM live migration) without actually resolving a fault.
Although we would have created most page tables, we would choke on the
!pmd_present(), requiring a call to fixup_user_fault(). I would
have thought that this is problematic in combination with postcopy life
migration ... but nobody noticed and this patch doesn't change the
situation. So maybe it's just fine.
Fixes:
9fcf93b5de06 ("KVM: S390: Create helper function get_guest_storage_key")
Fixes:
24d5dd0208ed ("s390/kvm: Provide function for setting the guest storage key")
Fixes:
a7e19ab55ffd ("KVM: s390: handle missing storage-key facility")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Link: https://lore.kernel.org/r/20210909162248.14969-5-david@redhat.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Hildenbrand [Thu, 9 Sep 2021 16:22:42 +0000 (18:22 +0200)]
s390/mm: validate VMA in PGSTE manipulation functions
[ Upstream commit
fe3d10024073f06f04c74b9674bd71ccc1d787cf ]
We should not walk/touch page tables outside of VMA boundaries when
holding only the mmap sem in read mode. Evil user space can modify the
VMA layout just before this function runs and e.g., trigger races with
page table removal code since commit
dd2283f2605e ("mm: mmap: zap pages
with read mmap_sem in munmap"). gfn_to_hva() will only translate using
KVM memory regions, but won't validate the VMA.
Further, we should not allocate page tables outside of VMA boundaries: if
evil user space decides to map hugetlbfs to these ranges, bad things will
happen because we suddenly have PTE or PMD page tables where we
shouldn't have them.
Similarly, we have to check if we suddenly find a hugetlbfs VMA, before
calling get_locked_pte().
Fixes:
2d42f9477320 ("s390/kvm: Add PGSTE manipulation functions")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Link: https://lore.kernel.org/r/20210909162248.14969-4-david@redhat.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Hildenbrand [Thu, 9 Sep 2021 16:22:41 +0000 (18:22 +0200)]
s390/gmap: don't unconditionally call pte_unmap_unlock() in __gmap_zap()
[ Upstream commit
b159f94c86b43cf7e73e654bc527255b1f4eafc4 ]
... otherwise we will try unlocking a spinlock that was never locked via a
garbage pointer.
At the time we reach this code path, we usually successfully looked up
a PGSTE already; however, evil user space could have manipulated the VMA
layout in the meantime and triggered removal of the page table.
Fixes:
1e133ab296f3 ("s390/mm: split arch/s390/mm/pgtable.c")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Link: https://lore.kernel.org/r/20210909162248.14969-3-david@redhat.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Hildenbrand [Thu, 9 Sep 2021 16:22:40 +0000 (18:22 +0200)]
s390/gmap: validate VMA in __gmap_zap()
[ Upstream commit
2d8fb8f3914b40e3cc12f8cbb74daefd5245349d ]
We should not walk/touch page tables outside of VMA boundaries when
holding only the mmap sem in read mode. Evil user space can modify the
VMA layout just before this function runs and e.g., trigger races with
page table removal code since commit
dd2283f2605e ("mm: mmap: zap pages
with read mmap_sem in munmap"). The pure prescence in our guest_to_host
radix tree does not imply that there is a VMA.
Further, we should not allocate page tables (via get_locked_pte()) outside
of VMA boundaries: if evil user space decides to map hugetlbfs to these
ranges, bad things will happen because we suddenly have PTE or PMD page
tables where we shouldn't have them.
Similarly, we have to check if we suddenly find a hugetlbfs VMA, before
calling get_locked_pte().
Note that gmap_discard() is different:
zap_page_range()->unmap_single_vma() makes sure to stay within VMA
boundaries.
Fixes:
b31288fa83b2 ("s390/kvm: support collaborative memory management")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Link: https://lore.kernel.org/r/20210909162248.14969-2-david@redhat.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nick Hainke [Thu, 7 Oct 2021 22:57:25 +0000 (00:57 +0200)]
mt76: mt7615: mt7622: fix ibss and meshpoint
[ Upstream commit
753453afacc0243bd45de45e34218a8d17493e8f ]
commit
7f4b7920318b ("mt76: mt7615: add ibss support") introduced IBSS
and commit
f4ec7fdf7f83 ("mt76: mt7615: enable support for mesh")
meshpoint support.
Both used in the "get_omac_idx"-function:
if (~mask & BIT(HW_BSSID_0))
return HW_BSSID_0;
With commit
d8d59f66d136 ("mt76: mt7615: support 16 interfaces") the
ibss and meshpoint mode should "prefer hw bssid slot 1-3". However,
with that change the ibss or meshpoint mode will not send any beacon on
the mt7622 wifi anymore. Devices were still able to exchange data but
only if a bssid already existed. Two mt7622 devices will never be able
to communicate.
This commits reverts the preferation of slot 1-3 for ibss and
meshpoint. Only NL80211_IFTYPE_STATION will still prefer slot 1-3.
Tested on Banana Pi R64.
Fixes:
d8d59f66d136 ("mt76: mt7615: support 16 interfaces")
Signed-off-by: Nick Hainke <vincent@systemli.org>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211007225725.2615-1-vincent@systemli.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Sat, 23 Oct 2021 00:31:57 +0000 (17:31 -0700)]
libbpf: Fix BTF header parsing checks
[ Upstream commit
c825f5fee19caf301d9821cd79abaa734322de26 ]
Original code assumed fixed and correct BTF header length. That's not
always the case, though, so fix this bug with a proper additional check.
And use actual header length instead of sizeof(struct btf_header) in
sanity checks.
Fixes:
8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211023003157.726961-2-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Sat, 23 Oct 2021 00:31:56 +0000 (17:31 -0700)]
libbpf: Fix overflow in BTF sanity checks
[ Upstream commit
5245dafe3d49efba4d3285cf27ee1cc1eeafafc6 ]
btf_header's str_off+str_len or type_off+type_len can overflow as they
are u32s. This will lead to bypassing the sanity checks during BTF
parsing, resulting in crashes afterwards. Fix by using 64-bit signed
integers for comparison.
Fixes:
d8123624506c ("libbpf: Fix BTF data layout checks and allow empty BTF")
Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211023003157.726961-1-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Quentin Monnet [Fri, 22 Oct 2021 09:47:43 +0000 (10:47 +0100)]
bpftool: Avoid leaking the JSON writer prepared for program metadata
[ Upstream commit
e89ef634f81c9d90e1824ab183721f3b361472e6 ]
Bpftool creates a new JSON object for writing program metadata in plain
text mode, regardless of metadata being present or not. Then this writer
is freed if any metadata has been found and printed, but it leaks
otherwise. We cannot destroy the object unconditionally, because the
destructor prints an undesirable line break. Instead, make sure the
writer is created only after we have found program metadata to print.
Found with valgrind.
Fixes:
aff52e685eb3 ("bpftool: Support dumping metadata")
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211022094743.11052-1-quentin@isovalent.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mauricio Vásquez [Fri, 22 Oct 2021 20:20:35 +0000 (15:20 -0500)]
libbpf: Fix memory leak in btf__dedup()
[ Upstream commit
1000298c76830bc291358e98e8fa5baa3baa9b3a ]
Free btf_dedup if btf_ensure_modifiable() returns error.
Fixes:
919d2b1dbb07 ("libbpf: Allow modification of BTF and add btf__add_str API")
Signed-off-by: Mauricio Vásquez <mauricio@kinvolk.io>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211022202035.48868-1-mauricio@kinvolk.io
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jim Mattson [Thu, 30 Sep 2021 00:36:49 +0000 (17:36 -0700)]
KVM: selftests: Fix nested SVM tests when built with clang
[ Upstream commit
ed290e1c20da19fa100a3e0f421aa31b65984960 ]
Though gcc conveniently compiles a simple memset to "rep stos," clang
prefers to call the libc version of memset. If a test is dynamically
linked, the libc memset isn't available in L1 (nor is the PLT or the
GOT, for that matter). Even if the test is statically linked, the libc
memset may choose to use some CPU features, like AVX, which may not be
enabled in L1. Note that __builtin_memset doesn't solve the problem,
because (a) the compiler is free to call memset anyway, and (b)
__builtin_memset may also choose to use features like AVX, which may
not be available in L1.
To avoid a myriad of problems, use an explicit "rep stos" to clear the
VMCB in generic_svm_setup(), which is called both from L0 and L1.
Reported-by: Ricardo Koller <ricarkol@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Fixes:
20ba262f8631a ("selftests: KVM: AMD Nested test infrastructure")
Message-Id: <
20210930003649.4026553-1-jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tetsuo Handa [Tue, 19 Oct 2021 11:27:26 +0000 (20:27 +0900)]
smackfs: use netlbl_cfg_cipsov4_del() for deleting cipso_v4_doi
[ Upstream commit
0934ad42bb2c5df90a1b9de690f93de735b622fe ]
syzbot is reporting UAF at cipso_v4_doi_search() [1], for smk_cipso_doi()
is calling kfree() without removing from the cipso_v4_doi_list list after
netlbl_cfg_cipsov4_map_add() returned an error. We need to use
netlbl_cfg_cipsov4_del() in order to remove from the list and wait for
RCU grace period before kfree().
Link: https://syzkaller.appspot.com/bug?extid=93dba5b91f0fed312cbd
Reported-by: syzbot <syzbot+93dba5b91f0fed312cbd@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes:
6c2e8ac0953fccdd ("netlabel: Update kernel configuration API")
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Horia Geantă [Fri, 15 Oct 2021 07:39:18 +0000 (10:39 +0300)]
crypto: tcrypt - fix skcipher multi-buffer tests for 1420B blocks
[ Upstream commit
3ae88f676aa63366ffa9eebb8ae787c7e19f0c57 ]
Commit
ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks")
mentions:
> power-of-2 block size. So let's add 1420 bytes explicitly, and round
> it up to the next blocksize multiple of the algo in question if it
> does not support 1420 byte blocks.
but misses updating skcipher multi-buffer tests.
Fix this by using the proper (rounded) input size.
Fixes:
ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jessica Zhang [Wed, 20 Oct 2021 18:34:38 +0000 (11:34 -0700)]
drm/msm/dsi: fix wrong type in msm_dsi_host
[ Upstream commit
409af447c2a0a6e08ba190993a1153c91d3b11bd ]
Change byte_clk_rate, pixel_clk_rate, esc_clk_rate, and src_clk_rate
from u32 to unsigned long, since clk_get_rate() returns an unsigned long.
Fixes:
a6bcddbc2ee1 ("drm/msm: dsi: Handle dual-channel for 6G as well")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org>
Link: https://lore.kernel.org/r/20211020183438.32263-1-jesszhan@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jessica Zhang [Wed, 20 Oct 2021 17:57:33 +0000 (10:57 -0700)]
drm/msm: Fix potential NULL dereference in DPU SSPP
[ Upstream commit
8bf71a5719b6cc5b6ba358096081e5d50ea23ab6 ]
Move initialization of sblk in _sspp_subblk_offset() after NULL check to
avoid potential NULL pointer dereference.
Fixes:
25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org>
Link: https://lore.kernel.org/r/20211020175733.3379-1-jesszhan@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Joerg Roedel [Thu, 21 Oct 2021 08:08:32 +0000 (10:08 +0200)]
x86/sev: Fix stack type check in vc_switch_off_ist()
[ Upstream commit
5681981fb788281b09a4ea14d310d30b2bd89132 ]
The value of STACK_TYPE_EXCEPTION_LAST points to the last _valid_
exception stack. Reflect that in the check done in the
vc_switch_off_ist() function.
Fixes:
a13644f3a53de ("x86/entry/64: Add entry code for #VC handler")
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20211021080833.30875-2-joro@8bytes.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Sat, 28 Aug 2021 17:57:47 +0000 (10:57 -0700)]
clocksource/drivers/timer-ti-dm: Select TIMER_OF
[ Upstream commit
eda9a4f7af6ee47e9e131f20e4f8a41a97379293 ]
When building OMAP_DM_TIMER without TIMER_OF, there are orphan sections
due to the use of TIMER_OF_DELCARE() without CONFIG_TIMER_OF. Select
CONFIG_TIMER_OF when enaling OMAP_DM_TIMER:
arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section `__timer_of_table'
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/lkml/202108282255.tkdt4ani-lkp@intel.com/
Cc: Tony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: linux-omap@vger.kernel.org
Fixes:
52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support")
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210828175747.3777891-1-keescook@chromium.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anders Roxell [Thu, 7 Oct 2021 19:13:37 +0000 (21:13 +0200)]
PM: hibernate: fix sparse warnings
[ Upstream commit
01de5fcd8b1ac0ca28d2bb0921226a54fdd62684 ]
When building the kernel with sparse enabled 'C=1' the following
warnings shows up:
kernel/power/swap.c:390:29: warning: incorrect type in assignment (different base types)
kernel/power/swap.c:390:29: expected int ret
kernel/power/swap.c:390:29: got restricted blk_status_t
This is due to function hib_wait_io() returns a 'blk_status_t' which is
a bitwise u8. Commit
5416da01ff6e ("PM: hibernate: Remove
blk_status_to_errno in hib_wait_io") seemed to have mixed up the return
type. However, the
4e4cbee93d56 ("block: switch bios to blk_status_t")
actually broke the behaviour by returning the wrong type.
Rework so function hib_wait_io() returns a 'int' instead of
'blk_status_t' and make sure to call function
blk_status_to_errno(hb->error)' when returning from function
hib_wait_io() a int gets returned.
Fixes:
4e4cbee93d56 ("block: switch bios to blk_status_t")
Fixes:
5416da01ff6e ("PM: hibernate: Remove blk_status_to_errno in hib_wait_io")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Max Gurtovoy [Sun, 17 Oct 2021 08:58:16 +0000 (11:58 +0300)]
nvme-rdma: fix error code in nvme_rdma_setup_ctrl
[ Upstream commit
09748122009aed7bfaa7acc33c10c083a4758322 ]
In case that icdoff is not zero or mandatory keyed sgls are not
supported by the NVMe/RDMA target, we'll go to error flow but we'll
return 0 to the caller. Fix it by returning an appropriate error code.
Fixes:
c66e2998c8ca ("nvme-rdma: centralize controller setup sequence")
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ye Bin [Wed, 20 Oct 2021 07:39:59 +0000 (15:39 +0800)]
nbd: Fix use-after-free in pid_show
[ Upstream commit
0c98057be9efa32de78dbc4685fc73da9d71faa1 ]
I got issue as follows:
[ 263.886511] BUG: KASAN: use-after-free in pid_show+0x11f/0x13f
[ 263.888359] Read of size 4 at addr
ffff8880bf0648c0 by task cat/746
[ 263.890479] CPU: 0 PID: 746 Comm: cat Not tainted 4.19.90-dirty #140
[ 263.893162] Call Trace:
[ 263.893509] dump_stack+0x108/0x15f
[ 263.893999] print_address_description+0xa5/0x372
[ 263.894641] kasan_report.cold+0x236/0x2a8
[ 263.895696] __asan_report_load4_noabort+0x25/0x30
[ 263.896365] pid_show+0x11f/0x13f
[ 263.897422] dev_attr_show+0x48/0x90
[ 263.898361] sysfs_kf_seq_show+0x24d/0x4b0
[ 263.899479] kernfs_seq_show+0x14e/0x1b0
[ 263.900029] seq_read+0x43f/0x1150
[ 263.900499] kernfs_fop_read+0xc7/0x5a0
[ 263.903764] vfs_read+0x113/0x350
[ 263.904231] ksys_read+0x103/0x270
[ 263.905230] __x64_sys_read+0x77/0xc0
[ 263.906284] do_syscall_64+0x106/0x360
[ 263.906797] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reproduce this issue as follows:
1. nbd-server 8000 /tmp/disk
2. nbd-client localhost 8000 /dev/nbd1
3. cat /sys/block/nbd1/pid
Then trigger use-after-free in pid_show.
Reason is after do step '2', nbd-client progress is already exit. So
it's task_struct already freed.
To solve this issue, revert part of
6521d39a64b3's modify and remove
useless 'recv_task' member of nbd_device.
Fixes:
6521d39a64b3 ("nbd: Remove variable 'pid'")
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211020073959.2679255-1-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Agner [Tue, 19 Oct 2021 19:16:47 +0000 (21:16 +0200)]
phy: micrel: ksz8041nl: do not use power down mode
[ Upstream commit
2641b62d2fab52648e34cdc6994b2eacde2d27c1 ]
Some Micrel KSZ8041NL PHY chips exhibit continuous RX errors after using
the power down mode bit (0.11). If the PHY is taken out of power down
mode in a certain temperature range, the PHY enters a weird state which
leads to continuously reporting RX errors. In that state, the MAC is not
able to receive or send any Ethernet frames and the activity LED is
constantly blinking. Since Linux is using the suspend callback when the
interface is taken down, ending up in that state can easily happen
during a normal startup.
Micrel confirmed the issue in errata DS80000700A [*], caused by abnormal
clock recovery when using power down mode. Even the latest revision (A4,
Revision ID 0x1513) seems to suffer that problem, and according to the
errata is not going to be fixed.
Remove the suspend/resume callback to avoid using the power down mode
completely.
[*] https://ww1.microchip.com/downloads/en/DeviceDoc/
80000700A.pdf
Fixes:
1a5465f5d6a2 ("phy/micrel: Add suspend/resume support to Micrel PHYs")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tim Gardner [Tue, 19 Oct 2021 18:19:50 +0000 (12:19 -0600)]
net: enetc: unmap DMA in enetc_send_cmd()
[ Upstream commit
cd4bc63de774eee95e9bac26a565cd80e0fca421 ]
Coverity complains of a possible dereference of a null return value.
5. returned_null: kzalloc returns NULL. [show details]
6. var_assigned: Assigning: si_data = NULL return value from kzalloc.
488 si_data = kzalloc(data_size, __GFP_DMA | GFP_KERNEL);
489 cbd.length = cpu_to_le16(data_size);
490
491 dma = dma_map_single(&priv->si->pdev->dev, si_data,
492 data_size, DMA_FROM_DEVICE);
While this kzalloc() is unlikely to fail, I did notice that the function
returned without unmapping si_data.
Fix this by refactoring the error paths and checking for kzalloc()
failure.
Fixes:
888ae5a3952ba ("net: enetc: add tc flower psfp offload driver")
Cc: Claudiu Manoil <claudiu.manoil@nxp.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org (open list)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Sat, 16 Oct 2021 08:43:58 +0000 (11:43 +0300)]
iwlwifi: pnvm: read EFI data only if long enough
[ Upstream commit
e864a77f51d0d8113b49cf7d030bc9dc911c8176 ]
If the data we get from EFI is not even long enough for
the package struct we expect then ignore it entirely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes:
a1a6a4cf49ec ("iwlwifi: pnvm: implement reading PNVM from UEFI")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.33feba783518.I54a5cf33975d0330792b3d208b225d479e168f32@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Sat, 16 Oct 2021 08:43:57 +0000 (11:43 +0300)]
iwlwifi: pnvm: don't kmemdup() more than we have
[ Upstream commit
0f892441d8c353144e3669b7991fa5fe0bd353e9 ]
We shouldn't kmemdup() more data than we have, that might
cause the code to crash. Fix that by updating the length
before the kmemdup.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ab0e64c3fba9.Ic6a3295fc384750b51b4270bf0b7d94984a139f2@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Sat, 16 Oct 2021 08:43:55 +0000 (11:43 +0300)]
iwlwifi: mvm: reset PM state on unsuccessful resume
[ Upstream commit
2f629a7772e2a7bdaff25178917a40073f79702c ]
If resume fails for some reason, we need to set the PM state
back to normal so we're able to send commands during firmware
reset, rather than failing all of them because we're in D3.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes:
708a39aaca22 ("iwlwifi: mvm: don't send commands during suspend\resume transition")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.7ceb9eaca9f6.If0cbef38c6d07ec1ddce125878a4bdadcb35d2c9@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonas Dreßler [Sat, 16 Oct 2021 15:32:43 +0000 (17:32 +0200)]
mwifiex: Send DELBA requests according to spec
[ Upstream commit
cc8a8bc37466f79b24d972555237f3d591150602 ]
While looking at on-air packets using Wireshark, I noticed we're never
setting the initiator bit when sending DELBA requests to the AP: While
we set the bit on our del_ba_param_set bitmask, we forget to actually
copy that bitmask over to the command struct, which means we never
actually set the initiator bit.
Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command
struct.
Fixes:
5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Acked-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ziyang Xuan [Fri, 15 Oct 2021 04:03:35 +0000 (12:03 +0800)]
rsi: stop thread firstly in rsi_91x_init() error handling
[ Upstream commit
515e7184bdf0a3ebf1757cc77fb046b4fe282189 ]
When fail to init coex module, free 'common' and 'adapter' directly, but
common->tx_thread which will access 'common' and 'adapter' is running at
the same time. That will trigger the UAF bug.
==================================================================
BUG: KASAN: use-after-free in rsi_tx_scheduler_thread+0x50f/0x520 [rsi_91x]
Read of size 8 at addr
ffff8880076dc000 by task Tx-Thread/124777
CPU: 0 PID: 124777 Comm: Tx-Thread Not tainted 5.15.0-rc5+ #19
Call Trace:
dump_stack_lvl+0xe2/0x152
print_address_description.constprop.0+0x21/0x140
? rsi_tx_scheduler_thread+0x50f/0x520
kasan_report.cold+0x7f/0x11b
? rsi_tx_scheduler_thread+0x50f/0x520
rsi_tx_scheduler_thread+0x50f/0x520
...
Freed by task 111873:
kasan_save_stack+0x1b/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x109/0x140
kfree+0x117/0x4c0
rsi_91x_init+0x741/0x8a0 [rsi_91x]
rsi_probe+0x9f/0x1750 [rsi_usb]
Stop thread before free 'common' and 'adapter' to fix it.
Fixes:
2108df3c4b18 ("rsi: add coex support")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211015040335.1021546-1-william.xuanziyang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shayne Chen [Mon, 18 Oct 2021 08:07:04 +0000 (16:07 +0800)]
mt76: mt7915: fix muar_idx in mt7915_mcu_alloc_sta_req()
[ Upstream commit
161cc13912d3c3e8857001988dfba39be842454a ]
For broadcast/multicast wcid, the muar_idx should be 0xe.
Fixes:
e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shayne Chen [Mon, 18 Oct 2021 08:07:02 +0000 (16:07 +0800)]
mt76: mt7915: fix sta_rec_wtbl tag len
[ Upstream commit
afa0370f3a3a64af6d368da0bedd72ab2a026cd0 ]
Fix tag len error for sta_rec_wtbl, which causes fw parsing error for
the tags placed behind it.
Fixes:
e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Thu, 14 Oct 2021 15:19:53 +0000 (17:19 +0200)]
mt76: connac: fix possible NULL pointer dereference in mt76_connac_get_phy_mode_v2
[ Upstream commit
b5f2ba8a4c794e8349c0e30036352b9f685164c4 ]
Fix the following NULL pointer dereference in mt76_connac_get_phy_mode_v2
routine triggered on mt7663s device when sta is NULL
[ 5.490700] mt7663s mmc0:0001:1: N9 Firmware Version: 3.1.1, Build Time:
20200604161656
[ 5.490815] mt7663s mmc0:0001:1: Region number: 0x4
[ 5.490868] mt7663s mmc0:0001:1: Parsing tailer Region: 0
[ 5.496251] mt7663s mmc0:0001:1: Region 0, override_addr = 0x00118000
[ 5.496419] mt7663s mmc0:0001:1: Parsing tailer Region: 1
[ 5.624027] mt7663s mmc0:0001:1: Parsing tailer Region: 2
[ 5.656999] mt7663s mmc0:0001:1: Parsing tailer Region: 3
[ 5.671876] mt7663s mmc0:0001:1: override_addr = 0x00118000, option = 3
[ 9.358658] BUG: kernel NULL pointer dereference, address:
0000000000000000
[ 9.358775] #PF: supervisor read access in kernel mode
[ 9.358831] #PF: error_code(0x0000) - not-present page
[ 9.358886] PGD 0 P4D 0
[ 9.358917] Oops: 0000 [#1] SMP
[ 9.358960] CPU: 0 PID: 235 Comm: NetworkManager Not tainted 5.15.0-rc4-kvm-02151-g39e333d657f4-dirty #769
[ 9.359057] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014
[ 9.359150] RIP: 0010:mt76_connac_get_phy_mode_v2+0xc9/0x11c
[ 9.359473] RAX:
0000000000000013 RBX:
0000000000000000 RCX:
0000000000000027
[ 9.359546] RDX:
ffff8881f9c17358 RSI:
0000000000000001 RDI:
ffff8881f9c17350
[ 9.359624] RBP:
ffff88810bac1ed4 R08:
ffffffff822a4a48 R09:
0000000000000003
[ 9.359697] R10:
ffffffff82234a60 R11:
ffffffff82234a60 R12:
ffff88810bac1eec
[ 9.359779] R13:
0000000000000000 R14:
ffff88810bad1648 R15:
ffff88810bac1eb8
[ 9.359859] FS:
00007f5f1e45bbc0(0000) GS:
ffff8881f9c00000(0000) knlGS:
0000000000000000
[ 9.359939] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 9.360003] CR2:
0000000000000000 CR3:
0000000105d5d000 CR4:
00000000000006b0
[ 9.360083] Call Trace:
[ 9.360116] mt76_connac_mcu_uni_add_bss.cold+0x21/0x250
[ 9.360175] ? schedule_preempt_disabled+0xa/0x10
[ 9.360232] ? __mutex_lock.constprop.0+0x2ab/0x460
[ 9.360286] mt7615_remove_interface+0x63/0x1d0
[ 9.360342] drv_remove_interface+0x32/0xe0
[ 9.360385] ieee80211_do_stop+0x5da/0x800
[ 9.360428] ? dev_reset_queue+0x30/0x90
[ 9.360472] ieee80211_stop+0x3b/0xb0
[ 9.360516] __dev_close_many+0x7a/0xd0
[ 9.360559] __dev_change_flags+0xd6/0x1f0
[ 9.360604] dev_change_flags+0x21/0x60
[ 9.360648] do_setlink+0x259/0xfb0
[ 9.360686] ? __nla_validate_parse+0x51/0xb80
[ 9.360742] __rtnl_newlink+0x5b3/0x960
[ 9.360785] ? inet6_fill_ifla6_attrs+0x41d/0x470
[ 9.360841] ? __kmalloc_track_caller+0x57/0x3c0
[ 9.360905] ? netlink_trim+0x8a/0xb0
[ 9.360949] ? skb_queue_tail+0x1b/0x50
Fixes:
67aa27431c7f8 ("mt76: mt7921: rely on mt76_connac_mcu common library")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ryder Lee [Mon, 27 Sep 2021 04:59:49 +0000 (12:59 +0800)]
mt76: mt7615: fix monitor mode tear down crash
[ Upstream commit
a6fdbdd1ac2996a58a84672ef37efb5cbb98fadf ]
[ 103.451600] CPU 3 Unable to handle kernel paging request at virtual address
00000003, epc ==
8576591c, ra ==
857659f0
[ 103.462226] Oops[#1]:
[ 103.464499] CPU: 3 PID: 9247 Comm: ifconfig Tainted: G W 5.4.143 #0
[ 103.472031] $ 0 :
00000000 00000001 83be3854 00000000
[ 103.477239] $ 4 :
8102a374 8102a374 8102f0b0 00000200
[ 103.482444] $ 8 :
0000002d 000001e4 64373765 5d206337
[ 103.487647] $12 :
00000000 00000005 00000000 0006d1df
[ 103.492853] $16 :
83be3848 853838a8 8743d600 00010000
[ 103.498059] $20 :
00000000 00000000 8553dec0 0000007f
[ 103.503266] $24 :
00000003 80382084
[ 103.508472] $28 :
831d4000 831d5bc0 00000001 857659f0
[ 103.513678] Hi :
00000122
[ 103.516543] Lo :
d1768000
[ 103.519452] epc :
8576591c mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common]
[ 103.526306] ra :
857659f0 mt7615_mcu_add_bss+0x1a4/0x3c0 [mt7615_common]
[ 103.533232] Status:
11007c03 KERNEL EXL IE
[ 103.537402] Cause :
40800008 (ExcCode 02)
[ 103.541389] BadVA :
00000003
[ 103.544253] PrId :
0001992f (MIPS 1004Kc)
[ 103.797086] Call Trace:
[ 103.799562] [<
8576591c>] mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common]
[ 103.806082] [<
85760a14>] mt7615_remove_interface+0x74/0x1e0 [mt7615_common]
[ 103.813280] [<
85603fcc>] drv_remove_interface+0x2c/0xa0 [mac80211]
[ 103.819612] [<
8561a8e4>] ieee80211_del_virtual_monitor.part.22+0x74/0xe8 [mac80211]
[ 103.827410] [<
8561b7f0>] ieee80211_do_stop+0x4a4/0x8a0 [mac80211]
[ 103.833671] [<
8561bc00>] ieee80211_stop+0x14/0x24 [mac80211]
[ 103.839405] [<
8045a328>] __dev_close_many+0x9c/0x10c
[ 103.844364] [<
80463de4>] __dev_change_flags+0x16c/0x1e4
[ 103.849569] [<
80463e84>] dev_change_flags+0x28/0x70
[ 103.854440] [<
80521e54>] devinet_ioctl+0x280/0x774
[ 103.859222] [<
80526248>] inet_ioctl+0xa4/0x1c8
[ 103.863674] [<
80436830>] sock_ioctl+0x2d8/0x4bc
[ 103.868201] [<
801adbb4>] do_vfs_ioctl+0xb8/0x7c0
[ 103.872804] [<
801ae30c>] ksys_ioctl+0x50/0xb4
[ 103.877156] [<
80014598>] syscall_common+0x34/0x58
Fixes:
04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Wang [Tue, 14 Sep 2021 15:50:22 +0000 (23:50 +0800)]
mt76: mt7921: fix retrying release semaphore without end
[ Upstream commit
02d1c7d494d8052288bc175e4ff54b56d08a3c5f ]
We should pass the error code to the caller immediately
to avoid the possible infinite retry to release the semaphore.
Fixes:
1c099ab44727 ("mt76: mt7921: add MCU support")
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Tue, 14 Sep 2021 16:42:51 +0000 (18:42 +0200)]
mt76: mt7915: fix possible infinite loop release semaphore
[ Upstream commit
e500c9470e26be66eb2bc6de773ae9091149118a ]
Fix possible infinite loop in mt7915_load_patch if
mt7915_mcu_patch_sem_ctrl always returns an error.
Fixes:
e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>