2021-11-29 22:52:19

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 000/121] 5.10.83-rc1 review

This is the start of the stable review cycle for the 5.10.83 release.
There are 121 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.83-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.10.83-rc1

Alex Deucher <[email protected]>
drm/amdgpu/gfx9: switch to golden tsc registers for renoir+

Joakim Zhang <[email protected]>
net: stmmac: platform: fix build warning when with !CONFIG_PM_SLEEP

Alexander Mikhalitsyn <[email protected]>
shm: extend forced shm destroy to support objects from several IPC nses

David Hildenbrand <[email protected]>
s390/mm: validate VMA in PGSTE manipulation functions

Juergen Gross <[email protected]>
tty: hvc: replace BUG_ON() with negative return value

Juergen Gross <[email protected]>
xen/netfront: don't trust the backend response data blindly

Juergen Gross <[email protected]>
xen/netfront: disentangle tx_skb_freelist

Juergen Gross <[email protected]>
xen/netfront: don't read data from request on the ring page

Juergen Gross <[email protected]>
xen/netfront: read response from backend only once

Juergen Gross <[email protected]>
xen/blkfront: don't trust the backend response data blindly

Juergen Gross <[email protected]>
xen/blkfront: don't take local copy of a request from the ring page

Juergen Gross <[email protected]>
xen/blkfront: read response from backend only once

Juergen Gross <[email protected]>
xen: sync include/xen/interface/io/ring.h with Xen's newest version

Steven Rostedt (VMware) <[email protected]>
tracing: Check pid filtering when creating events

Stefano Garzarella <[email protected]>
vhost/vsock: fix incorrect used length reported to the guest

Joerg Roedel <[email protected]>
iommu/amd: Clarify AMD IOMMUv2 initialization messages

Steve French <[email protected]>
smb3: do not error on fsync when readonly

Jeff Layton <[email protected]>
ceph: properly handle statfs on multifs setups

Weichao Guo <[email protected]>
f2fs: set SBI_NEED_FSCK flag when inconsistent node block found

Mark Rutland <[email protected]>
sched/scs: Reset task stack state in bringup_cpu()

Arjun Roy <[email protected]>
tcp: correctly handle increased zerocopy args struct size

Vladimir Oltean <[email protected]>
net: mscc: ocelot: correctly report the timestamping RX filters in ethtool

Vladimir Oltean <[email protected]>
net: mscc: ocelot: don't downgrade timestamping RX filters in SIOCSHWTSTAMP

Guangbin Huang <[email protected]>
net: hns3: fix VF RSS failed problem after PF enable multi-TCs

Tony Lu <[email protected]>
net/smc: Don't call clcsock shutdown twice when smc shutdown

Ziyang Xuan <[email protected]>
net: vlan: fix underflow for the real_dev refcnt

Davide Caratti <[email protected]>
net/sched: sch_ets: don't peek at classes beyond 'nbands'

Jakub Kicinski <[email protected]>
tls: fix replacing proto_ops

Jakub Kicinski <[email protected]>
tls: splice_read: fix record type check

Huang Pei <[email protected]>
MIPS: use 3-level pgtable for 64KB page size on MIPS_VA_BITS_48

Huang Pei <[email protected]>
MIPS: loongson64: fix FTLB configuration

Jesse Brandeburg <[email protected]>
igb: fix netpoll exit with traffic

Maurizio Lombardi <[email protected]>
nvmet: use IOCB_NOWAIT only if the filesystem supports it

Guo DaXing <[email protected]>
net/smc: Fix loop in smc_listen

Karsten Graul <[email protected]>
net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()

Russell King (Oracle) <[email protected]>
net: phylink: Force retrigger in case of latched link-fail indicator

Russell King (Oracle) <[email protected]>
net: phylink: Force link down and retrigger resolve on interface change

Heiner Kallweit <[email protected]>
lan743x: fix deadlock in lan743x_phy_link_status_change()

Eric Dumazet <[email protected]>
tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flows

Nicholas Kazlauskas <[email protected]>
drm/amd/display: Set plane update flags for all planes in reset

Thomas Zeitlhofer <[email protected]>
PM: hibernate: use correct mode for swsusp_close()

Kumar Thangavel <[email protected]>
net/ncsi : Add payload to be 32-bit aligned to fix dropped packets

Varun Prakash <[email protected]>
nvmet-tcp: fix incomplete data digest send

Marek Behún <[email protected]>
net: marvell: mvpp2: increase MTU limit when XDP enabled

Amit Cohen <[email protected]>
mlxsw: spectrum: Protect driver from buggy firmware

Danielle Ratson <[email protected]>
mlxsw: Verify the accessed index doesn't exceed the array length

Tony Lu <[email protected]>
net/smc: Ensure the active closing peer first closes clcsock

Huang Jianan <[email protected]>
erofs: fix deadlock when shrink erofs slab

Shin'ichiro Kawasaki <[email protected]>
scsi: scsi_debug: Zero clear zones at reset write pointer

Mike Christie <[email protected]>
scsi: core: sysfs: Fix setting device state to SDEV_RUNNING

Marta Plantykow <[email protected]>
ice: avoid bpf_prog refcount underflow

Maciej Fijalkowski <[email protected]>
ice: fix vsi->txq_map sizing

Nikolay Aleksandrov <[email protected]>
net: nexthop: release IPv6 per-cpu dsts when replacing a nexthop group

Nikolay Aleksandrov <[email protected]>
net: ipv6: add fib6_nh_release_dsts stub

Holger Assmann <[email protected]>
net: stmmac: retain PTP clock time during SIOCSHWTSTAMP ioctls

Joakim Zhang <[email protected]>
net: stmmac: fix system hang caused by eee_ctrl_timer during suspend/resume

Diana Wang <[email protected]>
nfp: checking parameter process for rx-usecs/tx-usecs is invalid

Eric Dumazet <[email protected]>
ipv6: fix typos in __ip6_finish_output()

Michael Kelley <[email protected]>
firmware: smccc: Fix check for ARCH_SOC_ID not implemented

Eric Dumazet <[email protected]>
mptcp: fix delack timer

Pierre-Louis Bossart <[email protected]>
ALSA: intel-dsp-config: add quirk for JSL devices based on ES8336 codec

Nitesh B Venkatesh <[email protected]>
iavf: Prevent changing static ITR values if adaptive moderation is on

Volodymyr Mytnyk <[email protected]>
net: marvell: prestera: fix double free issue on err path

Dan Carpenter <[email protected]>
drm/vc4: fix error code in vc4_create_object()

Sreekanth Reddy <[email protected]>
scsi: mpt3sas: Fix kernel panic during drive powercycle test

Dan Carpenter <[email protected]>
drm/nouveau/acr: fix a couple NULL vs IS_ERR() checks

Takashi Iwai <[email protected]>
ARM: socfpga: Fix crash with CONFIG_FORTIRY_SOURCE

Trond Myklebust <[email protected]>
NFSv42: Don't fail clone() unless the OP_CLONE operation failed

Peng Fan <[email protected]>
firmware: arm_scmi: pm: Propagate return value to caller

Alexander Aring <[email protected]>
net: ieee802154: handle iftypes as u32

Srinivas Kandagatla <[email protected]>
ASoC: codecs: wcd934x: return error code correctly from hw_params

Takashi Iwai <[email protected]>
ASoC: topology: Add missing rwsem around snd_ctl_remove() calls

Srinivas Kandagatla <[email protected]>
ASoC: qdsp6: q6asm: fix q6asm_dai_prepare error handling

Srinivas Kandagatla <[email protected]>
ASoC: qdsp6: q6routing: Conditionally reset FrontEnd Mixer

Florian Fainelli <[email protected]>
ARM: dts: bcm2711: Fix PCIe interrupts

Florian Fainelli <[email protected]>
ARM: dts: BCM5301X: Add interrupt properties to GPIO node

Florian Fainelli <[email protected]>
ARM: dts: BCM5301X: Fix I2C controller interrupt

Will Mortensen <[email protected]>
netfilter: flowtable: fix IPv6 tunnel addr match

yangxingwu <[email protected]>
netfilter: ipvs: Fix reuse connection if RS weight is 0

Florent Fourcot <[email protected]>
netfilter: ctnetlink: do not erase error code with EINVAL

Florent Fourcot <[email protected]>
netfilter: ctnetlink: fix filtering with CTA_TUPLE_REPLY

David Hildenbrand <[email protected]>
proc/vmcore: fix clearing user buffer by properly using clear_user()

Pali Rohár <[email protected]>
PCI: aardvark: Fix link training

Pali Rohár <[email protected]>
PCI: aardvark: Simplify initialization of rootcap on virtual bridge

Pali Rohár <[email protected]>
PCI: aardvark: Implement re-issuing config requests on CRS response

Pali Rohár <[email protected]>
PCI: aardvark: Update comment about disabling link training

Marek Behún <[email protected]>
PCI: aardvark: Deduplicate code in advk_pcie_rd_conf()

Christophe Leroy <[email protected]>
powerpc/32: Fix hardlockup on vmap stack overflow

Dylan Hung <[email protected]>
mdio: aspeed: Fix "Link is Down" issue

Adrian Hunter <[email protected]>
mmc: sdhci: Fix ADMA for PAGE_SIZE >= 64KiB

Tim Harvey <[email protected]>
mmc: sdhci-esdhc-imx: disable CMDQ support

Steven Rostedt (VMware) <[email protected]>
tracing: Fix pid filtering when triggers are attached

Jiri Olsa <[email protected]>
tracing/uprobe: Fix uprobe_perf_open probes iteration

Nicholas Piggin <[email protected]>
KVM: PPC: Book3S HV: Prevent POWER7/8 TLB flush flushing SLB

Stefano Stabellini <[email protected]>
xen: detect uninitialized xenbus in xenbus_init

Stefano Stabellini <[email protected]>
xen: don't continue xenstore initialization in case of errors

Miklos Szeredi <[email protected]>
fuse: release pipe buf after last use

Dan Carpenter <[email protected]>
staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()

Takashi Iwai <[email protected]>
staging: greybus: Add missing rwsem around snd_ctl_remove() calls

Noralf Trønnes <[email protected]>
staging/fbtft: Fix backlight

Jason Gerecke <[email protected]>
HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts

Helge Deller <[email protected]>
Revert "parisc: Fix backtrace to always include init funtion names"

Hans Verkuil <[email protected]>
media: cec: copy sequence field for the reply

Takashi Iwai <[email protected]>
ALSA: hda/realtek: Fix LED on HP ProBook 435 G7

Werner Sembach <[email protected]>
ALSA: hda/realtek: Add quirk for ASRock NUC Box 1100

Takashi Iwai <[email protected]>
ALSA: ctxfi: Fix out-of-range access

Todd Kjos <[email protected]>
binder: fix test regression due to sender_euid change

Mathias Nyman <[email protected]>
usb: hub: Fix locking issues with address0_mutex

Mathias Nyman <[email protected]>
usb: hub: Fix usb enumeration issue due to address0 race

Ondrej Jirman <[email protected]>
usb: typec: fusb302: Fix masking of comparator and bc_lvl interrupts

Dan Carpenter <[email protected]>
usb: chipidea: ci_hdrc_imx: fix potential error pointer dereference in probe

Nikolay Aleksandrov <[email protected]>
net: nexthop: fix null pointer dereference when IPv6 is not enabled

Albert Wang <[email protected]>
usb: dwc3: gadget: Fix null pointer exception

Thinh Nguyen <[email protected]>
usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer

Thinh Nguyen <[email protected]>
usb: dwc3: gadget: Ignore NoStream after End Transfer

Nathan Chancellor <[email protected]>
usb: dwc2: hcd_queue: Fix use of floating point literal

Minas Harutyunyan <[email protected]>
usb: dwc2: gadget: Fix ISOC flow for elapsed frames

Mingjie Zhang <[email protected]>
USB: serial: option: add Fibocom FM101-GL variants

Daniele Palmas <[email protected]>
USB: serial: option: add Telit LE910S1 0x9200 composition

Sakari Ailus <[email protected]>
ACPI: Get acpi_device's parent from the parent field

Daniel Borkmann <[email protected]>
bpf: Fix toctou on read-only map's constant scalar tracking


-------------

Diffstat:

Documentation/networking/ipvs-sysctl.rst | 3 +-
Makefile | 4 +-
arch/arm/boot/dts/bcm2711.dtsi | 8 +-
arch/arm/boot/dts/bcm5301x.dtsi | 4 +-
arch/arm/mach-socfpga/core.h | 2 +-
arch/arm/mach-socfpga/platsmp.c | 8 +-
arch/mips/Kconfig | 2 +-
arch/mips/kernel/cpu-probe.c | 4 +-
arch/parisc/kernel/vmlinux.lds.S | 3 +-
arch/powerpc/kernel/head_32.h | 6 +-
arch/powerpc/kvm/book3s_hv_builtin.c | 5 +-
arch/s390/mm/pgtable.c | 13 +
drivers/acpi/property.c | 11 +-
drivers/android/binder.c | 2 +-
drivers/block/xen-blkfront.c | 126 ++++++----
drivers/firmware/arm_scmi/scmi_pm_domain.c | 4 +-
drivers/firmware/smccc/soc_id.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 46 +++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.c | 6 +-
drivers/gpu/drm/nouveau/nvkm/subdev/acr/gp102.c | 6 +-
drivers/gpu/drm/vc4/vc4_bo.c | 2 +-
drivers/hid/wacom_wac.c | 8 +-
drivers/hid/wacom_wac.h | 1 +
drivers/iommu/amd/iommu_v2.c | 6 +-
drivers/media/cec/core/cec-adap.c | 1 +
drivers/mmc/host/sdhci-esdhc-imx.c | 2 -
drivers/mmc/host/sdhci.c | 21 +-
drivers/mmc/host/sdhci.h | 4 +-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 4 +-
drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 30 ++-
drivers/net/ethernet/intel/ice/ice_lib.c | 9 +-
drivers/net/ethernet/intel/ice/ice_main.c | 18 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 +-
.../ethernet/marvell/prestera/prestera_switchdev.c | 6 +-
drivers/net/ethernet/mellanox/mlxsw/minimal.c | 4 +
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 +
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 3 +
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 3 +
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 4 +
drivers/net/ethernet/microchip/lan743x_main.c | 12 +-
drivers/net/ethernet/mscc/ocelot.c | 11 +-
drivers/net/ethernet/netronome/nfp/nfp_net.h | 3 -
.../net/ethernet/netronome/nfp/nfp_net_ethtool.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 139 ++++++-----
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 44 ++++
drivers/net/mdio/mdio-aspeed.c | 7 +
drivers/net/phy/phylink.c | 26 +-
drivers/net/xen-netfront.c | 272 ++++++++++++--------
drivers/nvme/target/io-cmd-file.c | 4 +-
drivers/nvme/target/tcp.c | 7 +-
drivers/pci/controller/pci-aardvark.c | 235 ++++++++---------
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +-
drivers/scsi/scsi_debug.c | 5 +
drivers/scsi/scsi_sysfs.c | 2 +-
drivers/staging/fbtft/fb_ssd1351.c | 4 -
drivers/staging/fbtft/fbtft-core.c | 9 +-
drivers/staging/greybus/audio_helper.c | 8 +-
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 3 +-
drivers/tty/hvc/hvc_xen.c | 17 +-
drivers/usb/chipidea/ci_hdrc_imx.c | 18 +-
drivers/usb/core/hub.c | 24 +-
drivers/usb/dwc2/gadget.c | 17 +-
drivers/usb/dwc2/hcd_queue.c | 2 +-
drivers/usb/dwc3/gadget.c | 39 ++-
drivers/usb/serial/option.c | 5 +
drivers/usb/typec/tcpm/fusb302.c | 6 +-
drivers/vhost/vsock.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 27 +-
fs/ceph/super.c | 11 +-
fs/cifs/file.c | 35 ++-
fs/erofs/utils.c | 8 +-
fs/f2fs/node.c | 1 +
fs/fuse/dev.c | 10 +-
fs/nfs/nfs42xdr.c | 3 +-
fs/proc/vmcore.c | 16 +-
include/linux/bpf.h | 3 +-
include/linux/ipc_namespace.h | 15 ++
include/linux/sched/task.h | 2 +-
include/net/ip6_fib.h | 1 +
include/net/ipv6_stubs.h | 1 +
include/net/nl802154.h | 7 +-
include/xen/interface/io/ring.h | 278 ++++++++++++---------
ipc/shm.c | 189 ++++++++++----
kernel/bpf/syscall.c | 57 +++--
kernel/bpf/verifier.c | 17 +-
kernel/cpu.c | 7 +
kernel/power/hibernate.c | 6 +-
kernel/sched/core.c | 4 -
kernel/trace/trace.h | 24 +-
kernel/trace/trace_events.c | 10 +
kernel/trace/trace_uprobe.c | 1 +
net/8021q/vlan.c | 3 -
net/8021q/vlan_dev.c | 3 +
net/ipv4/nexthop.c | 35 ++-
net/ipv4/tcp.c | 4 +-
net/ipv4/tcp_cubic.c | 5 +-
net/ipv6/af_inet6.c | 1 +
net/ipv6/ip6_output.c | 2 +-
net/ipv6/route.c | 19 ++
net/mptcp/options.c | 3 +-
net/ncsi/ncsi-cmd.c | 24 +-
net/netfilter/ipvs/ip_vs_core.c | 8 +-
net/netfilter/nf_conntrack_netlink.c | 6 +-
net/netfilter/nf_flow_table_offload.c | 4 +-
net/sched/sch_ets.c | 8 +-
net/smc/af_smc.c | 12 +-
net/smc/smc_close.c | 6 +
net/smc/smc_core.c | 35 +--
net/tls/tls_main.c | 47 +++-
net/tls/tls_sw.c | 23 +-
sound/hda/intel-dsp-config.c | 9 +
sound/pci/ctxfi/ctamixer.c | 14 +-
sound/pci/ctxfi/ctdaio.c | 16 +-
sound/pci/ctxfi/ctresource.c | 7 +-
sound/pci/ctxfi/ctresource.h | 4 +-
sound/pci/ctxfi/ctsrc.c | 7 +-
sound/pci/hda/patch_realtek.c | 28 +++
sound/soc/codecs/wcd934x.c | 3 +-
sound/soc/qcom/qdsp6/q6asm-dai.c | 19 +-
sound/soc/qcom/qdsp6/q6routing.c | 6 +-
sound/soc/soc-topology.c | 3 +
124 files changed, 1597 insertions(+), 842 deletions(-)




2021-11-29 22:52:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 083/121] tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flows

From: Eric Dumazet <[email protected]>

[ Upstream commit 4e1fddc98d2585ddd4792b5e44433dcee7ece001 ]

While testing BIG TCP patch series, I was expecting that TCP_RR workloads
with 80KB requests/answers would send one 80KB TSO packet,
then being received as a single GRO packet.

It turns out this was not happening, and the root cause was that
cubic Hystart ACK train was triggering after a few (2 or 3) rounds of RPC.

Hystart was wrongly setting CWND/SSTHRESH to 30, while my RPC
needed a budget of ~20 segments.

Ideally these TCP_RR flows should not exit slow start.

Cubic Hystart should reset itself at each round, instead of assuming
every TCP flow is a bulk one.

Note that even after this patch, Hystart can still trigger, depending
on scheduling artifacts, but at a higher CWND/SSTHRESH threshold,
keeping optimal TSO packet sizes.

Tested:

ip link set dev eth0 gro_ipv6_max_size 131072 gso_ipv6_max_size 131072
nstat -n; netperf -H ... -t TCP_RR -l 5 -- -r 80000,80000 -K cubic; nstat|egrep "Ip6InReceives|Hystart|Ip6OutRequests"

Before:

8605
Ip6InReceives 87541 0.0
Ip6OutRequests 129496 0.0
TcpExtTCPHystartTrainDetect 1 0.0
TcpExtTCPHystartTrainCwnd 30 0.0

After:

8760
Ip6InReceives 88514 0.0
Ip6OutRequests 87975 0.0

Fixes: ae27e98a5152 ("[TCP] CUBIC v2.3")
Co-developed-by: Neal Cardwell <[email protected]>
Signed-off-by: Neal Cardwell <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Cc: Yuchung Cheng <[email protected]>
Cc: Soheil Hassas Yeganeh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/ipv4/tcp_cubic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
index c7bf5b26bf0c2..fffa011a007d4 100644
--- a/net/ipv4/tcp_cubic.c
+++ b/net/ipv4/tcp_cubic.c
@@ -337,8 +337,6 @@ static void bictcp_cong_avoid(struct sock *sk, u32 ack, u32 acked)
return;

if (tcp_in_slow_start(tp)) {
- if (hystart && after(ack, ca->end_seq))
- bictcp_hystart_reset(sk);
acked = tcp_slow_start(tp, acked);
if (!acked)
return;
@@ -398,6 +396,9 @@ static void hystart_update(struct sock *sk, u32 delay)
struct bictcp *ca = inet_csk_ca(sk);
u32 threshold;

+ if (after(tp->snd_una, ca->end_seq))
+ bictcp_hystart_reset(sk);
+
if (hystart_detect & HYSTART_ACK_TRAIN) {
u32 now = bictcp_clock_us(sk);

--
2.33.0




2021-11-29 22:54:41

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 116/121] xen/netfront: dont trust the backend response data blindly

From: Juergen Gross <[email protected]>

commit a884daa61a7d91650987e855464526aef219590f upstream.

Today netfront will trust the backend to send only sane response data.
In order to avoid privilege escalations or crashes in case of malicious
backends verify the data to be within expected limits. Especially make
sure that the response always references an outstanding request.

Note that only the tx queue needs special id handling, as for the rx
queue the id is equal to the index in the ring page.

Introduce a new indicator for the device whether it is broken and let
the device stop working when it is set. Set this indicator in case the
backend sets any weird data.

Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/xen-netfront.c | 89 ++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 84 insertions(+), 5 deletions(-)

--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -131,10 +131,12 @@ struct netfront_queue {
struct sk_buff *tx_skbs[NET_TX_RING_SIZE];
unsigned short tx_link[NET_TX_RING_SIZE];
#define TX_LINK_NONE 0xffff
+#define TX_PENDING 0xfffe
grant_ref_t gref_tx_head;
grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
struct page *grant_tx_page[NET_TX_RING_SIZE];
unsigned tx_skb_freelist;
+ unsigned int tx_pend_queue;

spinlock_t rx_lock ____cacheline_aligned_in_smp;
struct xen_netif_rx_front_ring rx;
@@ -167,6 +169,9 @@ struct netfront_info {
bool netback_has_xdp_headroom;
bool netfront_xdp_enabled;

+ /* Is device behaving sane? */
+ bool broken;
+
atomic_t rx_gso_checksum_fixup;
};

@@ -349,7 +354,7 @@ static int xennet_open(struct net_device
unsigned int i = 0;
struct netfront_queue *queue = NULL;

- if (!np->queues)
+ if (!np->queues || np->broken)
return -ENODEV;

for (i = 0; i < num_queues; ++i) {
@@ -377,11 +382,17 @@ static void xennet_tx_buf_gc(struct netf
unsigned short id;
struct sk_buff *skb;
bool more_to_do;
+ const struct device *dev = &queue->info->netdev->dev;

BUG_ON(!netif_carrier_ok(queue->info->netdev));

do {
prod = queue->tx.sring->rsp_prod;
+ if (RING_RESPONSE_PROD_OVERFLOW(&queue->tx, prod)) {
+ dev_alert(dev, "Illegal number of responses %u\n",
+ prod - queue->tx.rsp_cons);
+ goto err;
+ }
rmb(); /* Ensure we see responses up to 'rp'. */

for (cons = queue->tx.rsp_cons; cons != prod; cons++) {
@@ -391,14 +402,27 @@ static void xennet_tx_buf_gc(struct netf
if (txrsp.status == XEN_NETIF_RSP_NULL)
continue;

- id = txrsp.id;
+ id = txrsp.id;
+ if (id >= RING_SIZE(&queue->tx)) {
+ dev_alert(dev,
+ "Response has incorrect id (%u)\n",
+ id);
+ goto err;
+ }
+ if (queue->tx_link[id] != TX_PENDING) {
+ dev_alert(dev,
+ "Response for inactive request\n");
+ goto err;
+ }
+
+ queue->tx_link[id] = TX_LINK_NONE;
skb = queue->tx_skbs[id];
queue->tx_skbs[id] = NULL;
if (unlikely(gnttab_query_foreign_access(
queue->grant_tx_ref[id]) != 0)) {
- pr_alert("%s: warning -- grant still in use by backend domain\n",
- __func__);
- BUG();
+ dev_alert(dev,
+ "Grant still in use by backend domain\n");
+ goto err;
}
gnttab_end_foreign_access_ref(
queue->grant_tx_ref[id], GNTMAP_readonly);
@@ -416,6 +440,12 @@ static void xennet_tx_buf_gc(struct netf
} while (more_to_do);

xennet_maybe_wake_tx(queue);
+
+ return;
+
+ err:
+ queue->info->broken = true;
+ dev_alert(dev, "Disabled for further use\n");
}

struct xennet_gnttab_make_txreq {
@@ -459,6 +489,12 @@ static void xennet_tx_setup_grant(unsign

*tx = info->tx_local;

+ /*
+ * Put the request in the pending queue, it will be set to be pending
+ * when the producer index is about to be raised.
+ */
+ add_id_to_list(&queue->tx_pend_queue, queue->tx_link, id);
+
info->tx = tx;
info->size += info->tx_local.size;
}
@@ -551,6 +587,15 @@ static u16 xennet_select_queue(struct ne
return queue_idx;
}

+static void xennet_mark_tx_pending(struct netfront_queue *queue)
+{
+ unsigned int i;
+
+ while ((i = get_id_from_list(&queue->tx_pend_queue, queue->tx_link)) !=
+ TX_LINK_NONE)
+ queue->tx_link[i] = TX_PENDING;
+}
+
static int xennet_xdp_xmit_one(struct net_device *dev,
struct netfront_queue *queue,
struct xdp_frame *xdpf)
@@ -568,6 +613,8 @@ static int xennet_xdp_xmit_one(struct ne
offset_in_page(xdpf->data),
xdpf->len);

+ xennet_mark_tx_pending(queue);
+
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&queue->tx, notify);
if (notify)
notify_remote_via_irq(queue->tx_irq);
@@ -592,6 +639,8 @@ static int xennet_xdp_xmit(struct net_de
int drops = 0;
int i, err;

+ if (unlikely(np->broken))
+ return -ENODEV;
if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
return -EINVAL;

@@ -638,6 +687,8 @@ static netdev_tx_t xennet_start_xmit(str
/* Drop the packet if no queues are set up */
if (num_queues < 1)
goto drop;
+ if (unlikely(np->broken))
+ goto drop;
/* Determine which queue to transmit this SKB on */
queue_index = skb_get_queue_mapping(skb);
queue = &np->queues[queue_index];
@@ -744,6 +795,8 @@ static netdev_tx_t xennet_start_xmit(str
/* timestamp packet in software */
skb_tx_timestamp(skb);

+ xennet_mark_tx_pending(queue);
+
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&queue->tx, notify);
if (notify)
notify_remote_via_irq(queue->tx_irq);
@@ -1143,6 +1196,13 @@ static int xennet_poll(struct napi_struc
skb_queue_head_init(&tmpq);

rp = queue->rx.sring->rsp_prod;
+ if (RING_RESPONSE_PROD_OVERFLOW(&queue->rx, rp)) {
+ dev_alert(&dev->dev, "Illegal number of responses %u\n",
+ rp - queue->rx.rsp_cons);
+ queue->info->broken = true;
+ spin_unlock(&queue->rx_lock);
+ return 0;
+ }
rmb(); /* Ensure we see queued responses up to 'rp'. */

i = queue->rx.rsp_cons;
@@ -1364,6 +1424,9 @@ static irqreturn_t xennet_tx_interrupt(i
struct netfront_queue *queue = dev_id;
unsigned long flags;

+ if (queue->info->broken)
+ return IRQ_HANDLED;
+
spin_lock_irqsave(&queue->tx_lock, flags);
xennet_tx_buf_gc(queue);
spin_unlock_irqrestore(&queue->tx_lock, flags);
@@ -1376,6 +1439,9 @@ static irqreturn_t xennet_rx_interrupt(i
struct netfront_queue *queue = dev_id;
struct net_device *dev = queue->info->netdev;

+ if (queue->info->broken)
+ return IRQ_HANDLED;
+
if (likely(netif_carrier_ok(dev) &&
RING_HAS_UNCONSUMED_RESPONSES(&queue->rx)))
napi_schedule(&queue->napi);
@@ -1397,6 +1463,10 @@ static void xennet_poll_controller(struc
struct netfront_info *info = netdev_priv(dev);
unsigned int num_queues = dev->real_num_tx_queues;
unsigned int i;
+
+ if (info->broken)
+ return;
+
for (i = 0; i < num_queues; ++i)
xennet_interrupt(0, &info->queues[i]);
}
@@ -1468,6 +1538,11 @@ static int xennet_xdp_set(struct net_dev

static int xennet_xdp(struct net_device *dev, struct netdev_bpf *xdp)
{
+ struct netfront_info *np = netdev_priv(dev);
+
+ if (np->broken)
+ return -ENODEV;
+
switch (xdp->command) {
case XDP_SETUP_PROG:
return xennet_xdp_set(dev, xdp->prog, xdp->extack);
@@ -1847,6 +1922,7 @@ static int xennet_init_queue(struct netf

/* Initialise tx_skb_freelist as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
+ queue->tx_pend_queue = TX_LINK_NONE;
for (i = 0; i < NET_TX_RING_SIZE; i++) {
queue->tx_link[i] = i + 1;
queue->grant_tx_ref[i] = GRANT_INVALID_REF;
@@ -2121,6 +2197,9 @@ static int talk_to_netback(struct xenbus
if (info->queues)
xennet_destroy_queues(info);

+ /* For the case of a reconnect reset the "broken" indicator. */
+ info->broken = false;
+
err = xennet_create_queues(info, &num_queues);
if (err < 0) {
xenbus_dev_fatal(dev, err, "creating queues");



2021-11-29 22:54:48

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 022/121] staging/fbtft: Fix backlight

From: Noralf Trønnes <[email protected]>

commit 7865dd24934ad580d1bcde8f63c39f324211a23b upstream.

Commit b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") forgot to
update fbtft breaking its backlight support when FB_BACKLIGHT is a module.

Since FB_TFT selects FB_BACKLIGHT there's no need for this conditional
so just remove it and we're good.

Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate")
Cc: <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Signed-off-by: Noralf Trønnes <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/fbtft/fb_ssd1351.c | 4 ----
drivers/staging/fbtft/fbtft-core.c | 9 +--------
2 files changed, 1 insertion(+), 12 deletions(-)

--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -187,7 +187,6 @@ static struct fbtft_display display = {
},
};

-#ifdef CONFIG_FB_BACKLIGHT
static int update_onboard_backlight(struct backlight_device *bd)
{
struct fbtft_par *par = bl_get_data(bd);
@@ -231,9 +230,6 @@ static void register_onboard_backlight(s
if (!par->fbtftops.unregister_backlight)
par->fbtftops.unregister_backlight = fbtft_unregister_backlight;
}
-#else
-static void register_onboard_backlight(struct fbtft_par *par) { };
-#endif

FBTFT_REGISTER_DRIVER(DRVNAME, "solomon,ssd1351", &display);

--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -128,7 +128,6 @@ static int fbtft_request_gpios(struct fb
return 0;
}

-#ifdef CONFIG_FB_BACKLIGHT
static int fbtft_backlight_update_status(struct backlight_device *bd)
{
struct fbtft_par *par = bl_get_data(bd);
@@ -161,6 +160,7 @@ void fbtft_unregister_backlight(struct f
par->info->bl_dev = NULL;
}
}
+EXPORT_SYMBOL(fbtft_unregister_backlight);

static const struct backlight_ops fbtft_bl_ops = {
.get_brightness = fbtft_backlight_get_brightness,
@@ -198,12 +198,7 @@ void fbtft_register_backlight(struct fbt
if (!par->fbtftops.unregister_backlight)
par->fbtftops.unregister_backlight = fbtft_unregister_backlight;
}
-#else
-void fbtft_register_backlight(struct fbtft_par *par) { };
-void fbtft_unregister_backlight(struct fbtft_par *par) { };
-#endif
EXPORT_SYMBOL(fbtft_register_backlight);
-EXPORT_SYMBOL(fbtft_unregister_backlight);

static void fbtft_set_addr_win(struct fbtft_par *par, int xs, int ys, int xe,
int ye)
@@ -853,13 +848,11 @@ int fbtft_register_framebuffer(struct fb
fb_info->fix.smem_len >> 10, text1,
HZ / fb_info->fbdefio->delay, text2);

-#ifdef CONFIG_FB_BACKLIGHT
/* Turn on backlight if available */
if (fb_info->bl_dev) {
fb_info->bl_dev->props.power = FB_BLANK_UNBLANK;
fb_info->bl_dev->ops->update_status(fb_info->bl_dev);
}
-#endif

return 0;




2021-11-29 22:55:01

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 061/121] ALSA: intel-dsp-config: add quirk for JSL devices based on ES8336 codec

From: Pierre-Louis Bossart <[email protected]>

[ Upstream commit fa9730b4f28b7bd183d28a0bf636ab7108de35d7 ]

These devices are based on an I2C/I2S device, we need to force the use
of the SOF driver otherwise the legacy HDaudio driver will be loaded -
only HDMI will be supported.

We previously added support for other Intel platforms but missed
JasperLake.

BugLink: https://github.com/thesofproject/linux/issues/3210
Fixes: 9d36ceab9415 ('ALSA: intel-dsp-config: add quirk for APL/GLK/TGL devices based on ES8336 codec')
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Signed-off-by: Bard Liao <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
sound/hda/intel-dsp-config.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
index 6cdb3db7507b1..fc61571a3ac73 100644
--- a/sound/hda/intel-dsp-config.c
+++ b/sound/hda/intel-dsp-config.c
@@ -298,6 +298,15 @@ static const struct config_entry config_table[] = {
},
#endif

+/* JasperLake */
+#if IS_ENABLED(CONFIG_SND_SOC_SOF_JASPERLAKE)
+ {
+ .flags = FLAG_SOF,
+ .device = 0x4dc8,
+ .codec_hid = "ESSX8336",
+ },
+#endif
+
/* Tigerlake */
#if IS_ENABLED(CONFIG_SND_SOC_SOF_TIGERLAKE)
{
--
2.33.0




2021-11-29 22:55:13

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 097/121] net/smc: Dont call clcsock shutdown twice when smc shutdown

From: Tony Lu <[email protected]>

[ Upstream commit bacb6c1e47691cda4a95056c21b5487fb7199fcc ]

When applications call shutdown() with SHUT_RDWR in userspace,
smc_close_active() calls kernel_sock_shutdown(), and it is called
twice in smc_shutdown().

This fixes this by checking sk_state before do clcsock shutdown, and
avoids missing the application's call of smc_shutdown().

Link: https://lore.kernel.org/linux-s390/[email protected]/
Fixes: 606a63c9783a ("net/smc: Ensure the active closing peer first closes clcsock")
Signed-off-by: Tony Lu <[email protected]>
Reviewed-by: Wen Gu <[email protected]>
Acked-by: Karsten Graul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/smc/af_smc.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index a0d3f4e07b067..ac8265e35b2d2 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -2098,8 +2098,10 @@ static __poll_t smc_poll(struct file *file, struct socket *sock,
static int smc_shutdown(struct socket *sock, int how)
{
struct sock *sk = sock->sk;
+ bool do_shutdown = true;
struct smc_sock *smc;
int rc = -EINVAL;
+ int old_state;
int rc1 = 0;

smc = smc_sk(sk);
@@ -2126,7 +2128,11 @@ static int smc_shutdown(struct socket *sock, int how)
}
switch (how) {
case SHUT_RDWR: /* shutdown in both directions */
+ old_state = sk->sk_state;
rc = smc_close_active(smc);
+ if (old_state == SMC_ACTIVE &&
+ sk->sk_state == SMC_PEERCLOSEWAIT1)
+ do_shutdown = false;
break;
case SHUT_WR:
rc = smc_close_shutdown_write(smc);
@@ -2136,7 +2142,7 @@ static int smc_shutdown(struct socket *sock, int how)
/* nothing more to do because peer is not involved */
break;
}
- if (smc->clcsock)
+ if (do_shutdown && smc->clcsock)
rc1 = kernel_sock_shutdown(smc->clcsock, how);
/* map sock_shutdown_cmd constants to sk_shutdown value range */
sk->sk_shutdown |= how + 1;
--
2.33.0




2021-11-29 22:55:43

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 105/121] smb3: do not error on fsync when readonly

From: Steve French <[email protected]>

[ Upstream commit 71e6864eacbef0b2645ca043cdfbac272cb6cea3 ]

Linux allows doing a flush/fsync on a file open for read-only,
but the protocol does not allow that. If the file passed in
on the flush is read-only try to find a writeable handle for
the same inode, if that is not possible skip sending the
fsync call to the server to avoid breaking the apps.

Reported-by: Julian Sikorski <[email protected]>
Tested-by: Julian Sikorski <[email protected]>
Suggested-by: Jeremy Allison <[email protected]>
Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/cifs/file.c | 35 +++++++++++++++++++++++++++++------
1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 67139f9d583f2..6c06870f90184 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2618,12 +2618,23 @@ int cifs_strict_fsync(struct file *file, loff_t start, loff_t end,
tcon = tlink_tcon(smbfile->tlink);
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOSSYNC)) {
server = tcon->ses->server;
- if (server->ops->flush)
- rc = server->ops->flush(xid, tcon, &smbfile->fid);
- else
+ if (server->ops->flush == NULL) {
rc = -ENOSYS;
+ goto strict_fsync_exit;
+ }
+
+ if ((OPEN_FMODE(smbfile->f_flags) & FMODE_WRITE) == 0) {
+ smbfile = find_writable_file(CIFS_I(inode), FIND_WR_ANY);
+ if (smbfile) {
+ rc = server->ops->flush(xid, tcon, &smbfile->fid);
+ cifsFileInfo_put(smbfile);
+ } else
+ cifs_dbg(FYI, "ignore fsync for file not open for write\n");
+ } else
+ rc = server->ops->flush(xid, tcon, &smbfile->fid);
}

+strict_fsync_exit:
free_xid(xid);
return rc;
}
@@ -2635,6 +2646,7 @@ int cifs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
struct cifs_tcon *tcon;
struct TCP_Server_Info *server;
struct cifsFileInfo *smbfile = file->private_data;
+ struct inode *inode = file_inode(file);
struct cifs_sb_info *cifs_sb = CIFS_FILE_SB(file);

rc = file_write_and_wait_range(file, start, end);
@@ -2651,12 +2663,23 @@ int cifs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
tcon = tlink_tcon(smbfile->tlink);
if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOSSYNC)) {
server = tcon->ses->server;
- if (server->ops->flush)
- rc = server->ops->flush(xid, tcon, &smbfile->fid);
- else
+ if (server->ops->flush == NULL) {
rc = -ENOSYS;
+ goto fsync_exit;
+ }
+
+ if ((OPEN_FMODE(smbfile->f_flags) & FMODE_WRITE) == 0) {
+ smbfile = find_writable_file(CIFS_I(inode), FIND_WR_ANY);
+ if (smbfile) {
+ rc = server->ops->flush(xid, tcon, &smbfile->fid);
+ cifsFileInfo_put(smbfile);
+ } else
+ cifs_dbg(FYI, "ignore fsync for file not open for write\n");
+ } else
+ rc = server->ops->flush(xid, tcon, &smbfile->fid);
}

+fsync_exit:
free_xid(xid);
return rc;
}
--
2.33.0




2021-11-29 22:58:10

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 121/121] drm/amdgpu/gfx9: switch to golden tsc registers for renoir+

From: Alex Deucher <[email protected]>

commit 53af98c091bc42fd9ec64cfabc40da4e5f3aae93 upstream.

Renoir and newer gfx9 APUs have new TSC register that is
not part of the gfxoff tile, so it can be read without
needing to disable gfx off.

Acked-by: Luben Tuikov <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 46 +++++++++++++++++++++++++---------
1 file changed, 35 insertions(+), 11 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -137,6 +137,11 @@ MODULE_FIRMWARE("amdgpu/green_sardine_rl
#define mmTCP_CHAN_STEER_5_ARCT 0x0b0c
#define mmTCP_CHAN_STEER_5_ARCT_BASE_IDX 0

+#define mmGOLDEN_TSC_COUNT_UPPER_Renoir 0x0025
+#define mmGOLDEN_TSC_COUNT_UPPER_Renoir_BASE_IDX 1
+#define mmGOLDEN_TSC_COUNT_LOWER_Renoir 0x0026
+#define mmGOLDEN_TSC_COUNT_LOWER_Renoir_BASE_IDX 1
+
enum ta_ras_gfx_subblock {
/*CPC*/
TA_RAS_BLOCK__GFX_CPC_INDEX_START = 0,
@@ -4147,19 +4152,38 @@ failed_kiq_read:

static uint64_t gfx_v9_0_get_gpu_clock_counter(struct amdgpu_device *adev)
{
- uint64_t clock;
+ uint64_t clock, clock_lo, clock_hi, hi_check;

- amdgpu_gfx_off_ctrl(adev, false);
- mutex_lock(&adev->gfx.gpu_clock_mutex);
- if (adev->asic_type == CHIP_VEGA10 && amdgpu_sriov_runtime(adev)) {
- clock = gfx_v9_0_kiq_read_clock(adev);
- } else {
- WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
- clock = (uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_LSB) |
- ((uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_MSB) << 32ULL);
+ switch (adev->asic_type) {
+ case CHIP_RENOIR:
+ preempt_disable();
+ clock_hi = RREG32_SOC15_NO_KIQ(SMUIO, 0, mmGOLDEN_TSC_COUNT_UPPER_Renoir);
+ clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, mmGOLDEN_TSC_COUNT_LOWER_Renoir);
+ hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, mmGOLDEN_TSC_COUNT_UPPER_Renoir);
+ /* The SMUIO TSC clock frequency is 100MHz, which sets 32-bit carry over
+ * roughly every 42 seconds.
+ */
+ if (hi_check != clock_hi) {
+ clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, mmGOLDEN_TSC_COUNT_LOWER_Renoir);
+ clock_hi = hi_check;
+ }
+ preempt_enable();
+ clock = clock_lo | (clock_hi << 32ULL);
+ break;
+ default:
+ amdgpu_gfx_off_ctrl(adev, false);
+ mutex_lock(&adev->gfx.gpu_clock_mutex);
+ if (adev->asic_type == CHIP_VEGA10 && amdgpu_sriov_runtime(adev)) {
+ clock = gfx_v9_0_kiq_read_clock(adev);
+ } else {
+ WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1);
+ clock = (uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_LSB) |
+ ((uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_MSB) << 32ULL);
+ }
+ mutex_unlock(&adev->gfx.gpu_clock_mutex);
+ amdgpu_gfx_off_ctrl(adev, true);
+ break;
}
- mutex_unlock(&adev->gfx.gpu_clock_mutex);
- amdgpu_gfx_off_ctrl(adev, true);
return clock;
}




2021-11-29 22:58:14

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 035/121] PCI: aardvark: Deduplicate code in advk_pcie_rd_conf()

From: Marek Behún <[email protected]>

commit 67cb2a4c93499c2c22704998fd1fd2bc35194d8e upstream.

Avoid code repetition in advk_pcie_rd_conf() by handling errors with
goto jump, as is customary in kernel.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value")
Signed-off-by: Marek Behún <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/controller/pci-aardvark.c | 48 ++++++++++++++--------------------
1 file changed, 20 insertions(+), 28 deletions(-)

--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -1090,18 +1090,8 @@ static int advk_pcie_rd_conf(struct pci_
(le16_to_cpu(pcie->bridge.pcie_conf.rootctl) &
PCI_EXP_RTCTL_CRSSVE);

- if (advk_pcie_pio_is_running(pcie)) {
- /*
- * If it is possible return Completion Retry Status so caller
- * tries to issue the request again instead of failing.
- */
- if (allow_crs) {
- *val = CFG_RD_CRS_VAL;
- return PCIBIOS_SUCCESSFUL;
- }
- *val = 0xffffffff;
- return PCIBIOS_SET_FAILED;
- }
+ if (advk_pcie_pio_is_running(pcie))
+ goto try_crs;

/* Program the control register */
reg = advk_readl(pcie, PIO_CTRL);
@@ -1125,25 +1115,13 @@ static int advk_pcie_rd_conf(struct pci_
advk_writel(pcie, 1, PIO_START);

ret = advk_pcie_wait_pio(pcie);
- if (ret < 0) {
- /*
- * If it is possible return Completion Retry Status so caller
- * tries to issue the request again instead of failing.
- */
- if (allow_crs) {
- *val = CFG_RD_CRS_VAL;
- return PCIBIOS_SUCCESSFUL;
- }
- *val = 0xffffffff;
- return PCIBIOS_SET_FAILED;
- }
+ if (ret < 0)
+ goto try_crs;

/* Check PIO status and get the read result */
ret = advk_pcie_check_pio_status(pcie, allow_crs, val);
- if (ret < 0) {
- *val = 0xffffffff;
- return PCIBIOS_SET_FAILED;
- }
+ if (ret < 0)
+ goto fail;

if (size == 1)
*val = (*val >> (8 * (where & 3))) & 0xff;
@@ -1151,6 +1129,20 @@ static int advk_pcie_rd_conf(struct pci_
*val = (*val >> (8 * (where & 3))) & 0xffff;

return PCIBIOS_SUCCESSFUL;
+
+try_crs:
+ /*
+ * If it is possible, return Completion Retry Status so that caller
+ * tries to issue the request again instead of failing.
+ */
+ if (allow_crs) {
+ *val = CFG_RD_CRS_VAL;
+ return PCIBIOS_SUCCESSFUL;
+ }
+
+fail:
+ *val = 0xffffffff;
+ return PCIBIOS_SET_FAILED;
}

static int advk_pcie_wr_conf(struct pci_bus *bus, u32 devfn,



2021-11-29 22:58:19

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 102/121] sched/scs: Reset task stack state in bringup_cpu()

From: Mark Rutland <[email protected]>

[ Upstream commit dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3 ]

To hot unplug a CPU, the idle task on that CPU calls a few layers of C
code before finally leaving the kernel. When KASAN is in use, poisoned
shadow is left around for each of the active stack frames, and when
shadow call stacks are in use. When shadow call stacks (SCS) are in use
the task's saved SCS SP is left pointing at an arbitrary point within
the task's shadow call stack.

When a CPU is offlined than onlined back into the kernel, this stale
state can adversely affect execution. Stale KASAN shadow can alias new
stackframes and result in bogus KASAN warnings. A stale SCS SP is
effectively a memory leak, and prevents a portion of the shadow call
stack being used. Across a number of hotplug cycles the idle task's
entire shadow call stack can become unusable.

We previously fixed the KASAN issue in commit:

e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")

... by removing any stale KASAN stack poison immediately prior to
onlining a CPU.

Subsequently in commit:

f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")

... the refactoring left the KASAN and SCS cleanup in one-time idle
thread initialization code rather than something invoked prior to each
CPU being onlined, breaking both as above.

We fixed SCS (but not KASAN) in commit:

63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")

... but as this runs in the context of the idle task being offlined it's
potentially fragile.

To fix these consistently and more robustly, reset the SCS SP and KASAN
shadow of a CPU's idle task immediately before we online that CPU in
bringup_cpu(). This ensures the idle task always has a consistent state
when it is running, and removes the need to so so when exiting an idle
task.

Whenever any thread is created, dup_task_struct() will give the task a
stack which is free of KASAN shadow, and initialize the task's SCS SP,
so there's no need to specially initialize either for idle thread within
init_idle(), as this was only necessary to handle hotplug cycles.

I've tested this on arm64 with:

* gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK
* clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK

... offlining and onlining CPUS with:

| while true; do
| for C in /sys/devices/system/cpu/cpu*/online; do
| echo 0 > $C;
| echo 1 > $C;
| done
| done

Fixes: f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
Reported-by: Qian Cai <[email protected]>
Signed-off-by: Mark Rutland <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Valentin Schneider <[email protected]>
Tested-by: Qian Cai <[email protected]>
Link: https://lore.kernel.org/lkml/[email protected]/
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/cpu.c | 7 +++++++
kernel/sched/core.c | 4 ----
2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 67c22941b5f27..c06ced18f78ad 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -31,6 +31,7 @@
#include <linux/smpboot.h>
#include <linux/relay.h>
#include <linux/slab.h>
+#include <linux/scs.h>
#include <linux/percpu-rwsem.h>
#include <linux/cpuset.h>

@@ -551,6 +552,12 @@ static int bringup_cpu(unsigned int cpu)
struct task_struct *idle = idle_thread_get(cpu);
int ret;

+ /*
+ * Reset stale stack state from the last time this CPU was online.
+ */
+ scs_task_reset(idle);
+ kasan_unpoison_task_stack(idle);
+
/*
* Some architectures have to walk the irq descriptors to
* setup the vector space for the cpu which comes online.
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e456cce772a3a..304aad997da11 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6523,9 +6523,6 @@ void __init init_idle(struct task_struct *idle, int cpu)
idle->se.exec_start = sched_clock();
idle->flags |= PF_IDLE;

- scs_task_reset(idle);
- kasan_unpoison_task_stack(idle);
-
#ifdef CONFIG_SMP
/*
* Its possible that init_idle() gets called multiple times on a task,
@@ -6681,7 +6678,6 @@ void idle_task_exit(void)
finish_arch_post_lock_switch();
}

- scs_task_reset(current);
/* finish_cpu(), as ran on the BP, will clean up the active_mm state */
}

--
2.33.0




2021-11-29 22:58:54

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 013/121] usb: hub: Fix usb enumeration issue due to address0 race

From: Mathias Nyman <[email protected]>

commit 6ae6dc22d2d1ce6aa77a6da8a761e61aca216f8b upstream.

xHC hardware can only have one slot in default state with address 0
waiting for a unique address at a time, otherwise "undefined behavior
may occur" according to xhci spec 5.4.3.4

The address0_mutex exists to prevent this across both xhci roothubs.

If hub_port_init() fails, it may unlock the mutex and exit with a xhci
slot in default state. If the other xhci roothub calls hub_port_init()
at this point we end up with two slots in default state.

Make sure the address0_mutex protects the slot default state across
hub_port_init() retries, until slot is addressed or disabled.

Note, one known minor case is not fixed by this patch.
If device needs to be reset during resume, but fails all hub_port_init()
retries in usb_reset_and_verify_device(), then it's possible the slot is
still left in default state when address0_mutex is unlocked.

Cc: <[email protected]>
Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Signed-off-by: Mathias Nyman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/hub.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)

--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4628,8 +4628,6 @@ hub_port_init(struct usb_hub *hub, struc
if (oldspeed == USB_SPEED_LOW)
delay = HUB_LONG_RESET_TIME;

- mutex_lock(hcd->address0_mutex);
-
/* Reset the device; full speed may morph to high speed */
/* FIXME a USB 2.0 device may morph into SuperSpeed on reset. */
retval = hub_port_reset(hub, port1, udev, delay, false);
@@ -4940,7 +4938,6 @@ fail:
hub_port_disable(hub, port1, 0);
update_devnum(udev, devnum); /* for disconnect processing */
}
- mutex_unlock(hcd->address0_mutex);
return retval;
}

@@ -5170,6 +5167,9 @@ static void hub_port_connect(struct usb_
unit_load = 100;

status = 0;
+
+ mutex_lock(hcd->address0_mutex);
+
for (i = 0; i < PORT_INIT_TRIES; i++) {

/* reallocate for each attempt, since references
@@ -5206,6 +5206,8 @@ static void hub_port_connect(struct usb_
if (status < 0)
goto loop;

+ mutex_unlock(hcd->address0_mutex);
+
if (udev->quirks & USB_QUIRK_DELAY_INIT)
msleep(2000);

@@ -5294,6 +5296,7 @@ static void hub_port_connect(struct usb_

loop_disable:
hub_port_disable(hub, port1, 1);
+ mutex_lock(hcd->address0_mutex);
loop:
usb_ep0_reinit(udev);
release_devnum(udev);
@@ -5320,6 +5323,8 @@ loop:
}

done:
+ mutex_unlock(hcd->address0_mutex);
+
hub_port_disable(hub, port1, 1);
if (hcd->driver->relinquish_port && !hub->hdev->parent) {
if (status != -ENOTCONN && status != -ENODEV)
@@ -5839,6 +5844,8 @@ static int usb_reset_and_verify_device(s
bos = udev->bos;
udev->bos = NULL;

+ mutex_lock(hcd->address0_mutex);
+
for (i = 0; i < PORT_INIT_TRIES; ++i) {

/* ep0 maxpacket size may change; let the HCD know about it.
@@ -5848,6 +5855,7 @@ static int usb_reset_and_verify_device(s
if (ret >= 0 || ret == -ENOTCONN || ret == -ENODEV)
break;
}
+ mutex_unlock(hcd->address0_mutex);

if (ret < 0)
goto re_enumerate;



2021-11-29 22:58:51

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 031/121] mmc: sdhci-esdhc-imx: disable CMDQ support

From: Tim Harvey <[email protected]>

commit adab993c25191b839b415781bdc7173a77315240 upstream.

On IMX SoC's which support CMDQ the following can occur during high a
high cpu load:

mmc2: cqhci: ============ CQHCI REGISTER DUMP ===========
mmc2: cqhci: Caps: 0x0000310a | Version: 0x00000510
mmc2: cqhci: Config: 0x00001001 | Control: 0x00000000
mmc2: cqhci: Int stat: 0x00000000 | Int enab: 0x00000006
mmc2: cqhci: Int sig: 0x00000006 | Int Coal: 0x00000000
mmc2: cqhci: TDL base: 0x8003f000 | TDL up32: 0x00000000
mmc2: cqhci: Doorbell: 0xbf01dfff | TCN: 0x00000000
mmc2: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x08000000
mmc2: cqhci: Task clr: 0x00000000 | SSC1: 0x00011000
mmc2: cqhci: SSC2: 0x00000001 | DCMD rsp: 0x00000800
mmc2: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x00000000
mmc2: cqhci: Resp idx: 0x0000000d | Resp arg: 0x00000000
mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
mmc2: sdhci: Sys addr: 0x7c722000 | Version: 0x00000002
mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000020
mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000023
mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000030
mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080
mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000000f
mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000
mmc2: sdhci: Int enab: 0x107f4000 | Sig enab: 0x107f4000
mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000502
mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x8000b407
mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff
mmc2: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0xffc003ff
mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d07f01
mmc2: sdhci: Host ctl2: 0x00000088
mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xfe179020
mmc2: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS DUMP ====
mmc2: sdhci-esdhc-imx: cmd debug status: 0x2120
mmc2: sdhci-esdhc-imx: data debug status: 0x2200
mmc2: sdhci-esdhc-imx: trans debug status: 0x2300
mmc2: sdhci-esdhc-imx: dma debug status: 0x2400
mmc2: sdhci-esdhc-imx: adma debug status: 0x2510
mmc2: sdhci-esdhc-imx: fifo debug status: 0x2680
mmc2: sdhci-esdhc-imx: async fifo debug status: 0x2750
mmc2: sdhci: ============================================

For now, disable CMDQ support on the imx8qm/imx8qxp/imx8mm until the
issue is found and resolved.

Fixes: bb6e358169bf6 ("mmc: sdhci-esdhc-imx: add CMDQ support")
Fixes: cde5e8e9ff146 ("mmc: sdhci-esdhc-imx: Add an new esdhc_soc_data for i.MX8MM")
Cc: [email protected]
Signed-off-by: Tim Harvey <[email protected]>
Reviewed-by: Haibo Chen <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mmc/host/sdhci-esdhc-imx.c | 2 --
1 file changed, 2 deletions(-)

--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -263,7 +263,6 @@ static struct esdhc_soc_data usdhc_imx8q
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
| ESDHC_FLAG_HS400 | ESDHC_FLAG_HS400_ES
- | ESDHC_FLAG_CQHCI
| ESDHC_FLAG_STATE_LOST_IN_LPMODE
| ESDHC_FLAG_CLK_RATE_LOST_IN_PM_RUNTIME,
};
@@ -272,7 +271,6 @@ static struct esdhc_soc_data usdhc_imx8m
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
| ESDHC_FLAG_HS400 | ESDHC_FLAG_HS400_ES
- | ESDHC_FLAG_CQHCI
| ESDHC_FLAG_STATE_LOST_IN_LPMODE,
};




2021-11-29 22:58:58

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 027/121] xen: detect uninitialized xenbus in xenbus_init

From: Stefano Stabellini <[email protected]>

commit 36e8f60f0867d3b70d398d653c17108459a04efe upstream.

If the xenstore page hasn't been allocated properly, reading the value
of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return
error. Instead, it will succeed and return zero. Instead of attempting
to xen_remap a bad guest physical address, detect this condition and
return early.

Note that although a guest physical address of zero for
HVM_PARAM_STORE_PFN is theoretically possible, it is not a good choice
and zero has never been validly used in that capacity.

Also recognize all bits set as an invalid value.

For 32-bit Linux, any pfn above ULONG_MAX would get truncated. Pfns
above ULONG_MAX should never be passed by the Xen tools to HVM guests
anyway, so check for this condition and return early.

Cc: [email protected]
Signed-off-by: Stefano Stabellini <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/xenbus/xenbus_probe.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -886,6 +886,29 @@ static int __init xenbus_init(void)
err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
if (err)
goto out_error;
+ /*
+ * Uninitialized hvm_params are zero and return no error.
+ * Although it is theoretically possible to have
+ * HVM_PARAM_STORE_PFN set to zero on purpose, in reality it is
+ * not zero when valid. If zero, it means that Xenstore hasn't
+ * been properly initialized. Instead of attempting to map a
+ * wrong guest physical address return error.
+ *
+ * Also recognize all bits set as an invalid value.
+ */
+ if (!v || !~v) {
+ err = -ENOENT;
+ goto out_error;
+ }
+ /* Avoid truncation on 32-bit. */
+#if BITS_PER_LONG == 32
+ if (v > ULONG_MAX) {
+ pr_err("%s: cannot handle HVM_PARAM_STORE_PFN=%llx > ULONG_MAX\n",
+ __func__, v);
+ err = -EINVAL;
+ goto out_error;
+ }
+#endif
xen_store_gfn = (unsigned long)v;
xen_store_interface =
xen_remap(xen_store_gfn << XEN_PAGE_SHIFT,



2021-11-29 22:59:04

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 020/121] Revert "parisc: Fix backtrace to always include init funtion names"

From: Helge Deller <[email protected]>

commit 98400ad75e95860e9a10ec78b0b90ab66184a2ce upstream.

This reverts commit 279917e27edc293eb645a25428c6ab3f3bca3f86.

With the CONFIG_HARDENED_USERCOPY option enabled, this patch triggers
kernel bugs at runtime:

usercopy: Kernel memory overwrite attempt detected to kernel text (offset 2084839, size 6)!
kernel BUG at mm/usercopy.c:99!
Backtrace:
IAOQ[0]: usercopy_abort+0xc4/0xe8
[<00000000406ed1c8>] __check_object_size+0x174/0x238
[<00000000407086d4>] copy_strings.isra.0+0x3e8/0x708
[<0000000040709a20>] do_execveat_common.isra.0+0x1bc/0x328
[<000000004070b760>] compat_sys_execve+0x7c/0xb8
[<0000000040303eb8>] syscall_exit+0x0/0x14

The problem is, that we have an init section of at least 2MB size which
starts at _stext and is freed after bootup.

If then later some kernel data is (temporarily) stored in this free
memory, check_kernel_text_object() will trigger a bug since the data
appears to be inside the kernel text (>=_stext) area:
if (overlaps(ptr, len, _stext, _etext))
usercopy_abort("kernel text");

Signed-off-by: Helge Deller <[email protected]>
Cc: [email protected] # 5.4+
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/kernel/vmlinux.lds.S | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/parisc/kernel/vmlinux.lds.S
+++ b/arch/parisc/kernel/vmlinux.lds.S
@@ -57,8 +57,6 @@ SECTIONS
{
. = KERNEL_BINARY_TEXT_START;

- _stext = .; /* start of kernel text, includes init code & data */
-
__init_begin = .;
HEAD_TEXT_SECTION
MLONGCALL_DISCARD(INIT_TEXT_SECTION(8))
@@ -82,6 +80,7 @@ SECTIONS
/* freed after init ends here */

_text = .; /* Text and read-only data */
+ _stext = .;
MLONGCALL_KEEP(INIT_TEXT_SECTION(8))
.text ALIGN(PAGE_SIZE) : {
TEXT_TEXT



2021-11-29 22:59:13

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 021/121] HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts

From: Jason Gerecke <[email protected]>

commit 7fb0413baa7f8a04caef0c504df9af7e0623d296 upstream.

The HID descriptor of many of Wacom's touch input devices include a
"Confidence" usage that signals if a particular touch collection contains
useful data. The driver does not look at this flag, however, which causes
even invalid contacts to be reported to userspace. A lucky combination of
kernel event filtering and device behavior (specifically: contact ID 0 ==
invalid, contact ID >0 == valid; and order all data so that all valid
contacts are reported before any invalid contacts) spare most devices from
any visibly-bad behavior.

The DTH-2452 is one example of an unlucky device that misbehaves. It uses
ID 0 for both the first valid contact and all invalid contacts. Because
we report both the valid and invalid contacts, the kernel reports that
contact 0 first goes down (valid) and then goes up (invalid) in every
report. This causes ~100 clicks per second simply by touching the screen.

This patch inroduces new `confidence` flag in our `hid_data` structure.
The value is initially set to `true` at the start of a report and can be
set to `false` if an invalid touch usage is seen.

Link: https://github.com/linuxwacom/input-wacom/issues/270
Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report")
Signed-off-by: Jason Gerecke <[email protected]>
Tested-by: Joshua Dickens <[email protected]>
Cc: <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/wacom_wac.c | 8 +++++++-
drivers/hid/wacom_wac.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -2578,6 +2578,9 @@ static void wacom_wac_finger_event(struc
return;

switch (equivalent_usage) {
+ case HID_DG_CONFIDENCE:
+ wacom_wac->hid_data.confidence = value;
+ break;
case HID_GD_X:
wacom_wac->hid_data.x = value;
break;
@@ -2610,7 +2613,8 @@ static void wacom_wac_finger_event(struc
}

if (usage->usage_index + 1 == field->report_count) {
- if (equivalent_usage == wacom_wac->hid_data.last_slot_field)
+ if (equivalent_usage == wacom_wac->hid_data.last_slot_field &&
+ wacom_wac->hid_data.confidence)
wacom_wac_finger_slot(wacom_wac, wacom_wac->touch_input);
}
}
@@ -2625,6 +2629,8 @@ static void wacom_wac_finger_pre_report(

wacom_wac->is_invalid_bt_frame = false;

+ hid_data->confidence = true;
+
for (i = 0; i < report->maxfield; i++) {
struct hid_field *field = report->field[i];
int j;
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -300,6 +300,7 @@ struct hid_data {
bool tipswitch;
bool barrelswitch;
bool barrelswitch2;
+ bool confidence;
int x;
int y;
int pressure;



2021-11-29 22:59:18

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 007/121] usb: dwc3: gadget: Ignore NoStream after End Transfer

From: Thinh Nguyen <[email protected]>

commit d74dc3e9f58c28689cef1faccf918e06587367d3 upstream.

The End Transfer command from a stream endpoint will generate a NoStream
event, and we should ignore it. Currently we set the flag
DWC3_EP_IGNORE_NEXT_NOSTREAM to track this prior to sending the command,
and it will be cleared on the next stream event. However, a stream event
may be generated before the End Transfer command completion and
prematurely clear the flag. Fix this by setting the flag on End Transfer
completion instead.

Fixes: 140ca4cfea8a ("usb: dwc3: gadget: Handle stream transfers")
Cc: <[email protected]>
Signed-off-by: Thinh Nguyen <[email protected]>
Link: https://lore.kernel.org/r/cee1253af4c3600edb878d11c9c08b040817ae23.1635203975.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc3/gadget.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3007,6 +3007,14 @@ static void dwc3_gadget_endpoint_command
if (cmd != DWC3_DEPCMD_ENDTRANSFER)
return;

+ /*
+ * The END_TRANSFER command will cause the controller to generate a
+ * NoStream Event, and it's not due to the host DP NoStream rejection.
+ * Ignore the next NoStream event.
+ */
+ if (dep->stream_capable)
+ dep->flags |= DWC3_EP_IGNORE_NEXT_NOSTREAM;
+
dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
dwc3_gadget_ep_cleanup_cancelled_requests(dep);
@@ -3229,14 +3237,6 @@ static void dwc3_stop_active_transfer(st
WARN_ON_ONCE(ret);
dep->resource_index = 0;

- /*
- * The END_TRANSFER command will cause the controller to generate a
- * NoStream Event, and it's not due to the host DP NoStream rejection.
- * Ignore the next NoStream event.
- */
- if (dep->stream_capable)
- dep->flags |= DWC3_EP_IGNORE_NEXT_NOSTREAM;
-
if (!interrupt)
dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
else



2021-11-29 22:59:21

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 108/121] tracing: Check pid filtering when creating events

From: Steven Rostedt (VMware) <[email protected]>

commit 6cb206508b621a9a0a2c35b60540e399225c8243 upstream.

When pid filtering is activated in an instance, all of the events trace
files for that instance has the PID_FILTER flag set. This determines
whether or not pid filtering needs to be done on the event, otherwise the
event is executed as normal.

If pid filtering is enabled when an event is created (via a dynamic event
or modules), its flag is not updated to reflect the current state, and the
events are not filtered properly.

Cc: [email protected]
Fixes: 3fdaf80f4a836 ("tracing: Implement event pid filtering")
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/trace_events.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2462,12 +2462,22 @@ static struct trace_event_file *
trace_create_new_event(struct trace_event_call *call,
struct trace_array *tr)
{
+ struct trace_pid_list *no_pid_list;
+ struct trace_pid_list *pid_list;
struct trace_event_file *file;

file = kmem_cache_alloc(file_cachep, GFP_TRACE);
if (!file)
return NULL;

+ pid_list = rcu_dereference_protected(tr->filtered_pids,
+ lockdep_is_held(&event_mutex));
+ no_pid_list = rcu_dereference_protected(tr->filtered_no_pids,
+ lockdep_is_held(&event_mutex));
+
+ if (pid_list || no_pid_list)
+ file->flags |= EVENT_FILE_FL_PID_FILTER;
+
file->event_call = call;
file->tr = tr;
atomic_set(&file->sm_ref, 0);



2021-11-29 22:59:44

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 028/121] KVM: PPC: Book3S HV: Prevent POWER7/8 TLB flush flushing SLB

From: Nicholas Piggin <[email protected]>

commit cf0b0e3712f7af90006f8317ff27278094c2c128 upstream.

The POWER9 ERAT flush instruction is a SLBIA with IH=7, which is a
reserved value on POWER7/8. On POWER8 this invalidates the SLB entries
above index 0, similarly to SLBIA IH=0.

If the SLB entries are invalidated, and then the guest is bypassed, the
host SLB does not get re-loaded, so the bolted entries above 0 will be
lost. This can result in kernel stack access causing a SLB fault.

Kernel stack access causing a SLB fault was responsible for the infamous
mega bug (search "Fix SLB reload bug"). Although since commit
48e7b7695745 ("powerpc/64s/hash: Convert SLB miss handlers to C") that
starts using the kernel stack in the SLB miss handler, it might only
result in an infinite loop of SLB faults. In any case it's a bug.

Fix this by only executing the instruction on >= POWER9 where IH=7 is
defined not to invalidate the SLB. POWER7/8 don't require this ERAT
flush.

Fixes: 500871125920 ("KVM: PPC: Book3S HV: Invalidate ERAT when flushing guest TLB entries")
Cc: [email protected] # v5.2+
Signed-off-by: Nicholas Piggin <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kvm/book3s_hv_builtin.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -867,6 +867,7 @@ static void flush_guest_tlb(struct kvm *
"r" (0) : "memory");
}
asm volatile("ptesync": : :"memory");
+ // POWER9 congruence-class TLBIEL leaves ERAT. Flush it now.
asm volatile(PPC_RADIX_INVALIDATE_ERAT_GUEST : : :"memory");
} else {
for (set = 0; set < kvm->arch.tlb_sets; ++set) {
@@ -877,7 +878,9 @@ static void flush_guest_tlb(struct kvm *
rb += PPC_BIT(51); /* increment set number */
}
asm volatile("ptesync": : :"memory");
- asm volatile(PPC_ISA_3_0_INVALIDATE_ERAT : : :"memory");
+ // POWER9 congruence-class TLBIEL leaves ERAT. Flush it now.
+ if (cpu_has_feature(CPU_FTR_ARCH_300))
+ asm volatile(PPC_ISA_3_0_INVALIDATE_ERAT : : :"memory");
}
}




2021-11-29 22:59:46

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 077/121] mlxsw: spectrum: Protect driver from buggy firmware

From: Amit Cohen <[email protected]>

[ Upstream commit 63b08b1f6834bbb0b4f7783bf63b80c8c8e9a047 ]

When processing port up/down events generated by the device's firmware,
the driver protects itself from events reported for non-existent local
ports, but not the CPU port (local port 0), which exists, but lacks a
netdev.

This can result in a NULL pointer dereference when calling
netif_carrier_{on,off}().

Fix this by bailing early when processing an event reported for the CPU
port. Problem was only observed when running on top of a buggy emulator.

Fixes: 28b1987ef506 ("mlxsw: spectrum: Register CPU port with devlink")
Signed-off-by: Amit Cohen <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 1a9978f501ba9..4110e15c22c79 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -2058,7 +2058,7 @@ static void mlxsw_sp_pude_event_func(const struct mlxsw_reg_info *reg,
max_ports = mlxsw_core_max_ports(mlxsw_sp->core);
local_port = mlxsw_reg_pude_local_port_get(pude_pl);

- if (WARN_ON_ONCE(local_port >= max_ports))
+ if (WARN_ON_ONCE(!local_port || local_port >= max_ports))
return;
mlxsw_sp_port = mlxsw_sp->ports[local_port];
if (!mlxsw_sp_port)
--
2.33.0




2021-11-29 22:59:48

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 034/121] powerpc/32: Fix hardlockup on vmap stack overflow

From: Christophe Leroy <[email protected]>

commit 5bb60ea611db1e04814426ed4bd1c95d1487678e upstream.

Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not
activate MMU before reading task struct") a vmap stack overflow
results in a hard lockup. This is because emergency_ctx is still
addressed with its virtual address allthough data MMU is not active
anymore at that time.

Fix it by using a physical address instead.

Fixes: c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct")
Cc: [email protected] # v5.10+
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/ce30364fb7ccda489272af4a1612b6aa147e1d23.1637227521.git.christophe.leroy@csgroup.eu
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kernel/head_32.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -333,11 +333,11 @@ label:
mfspr r1, SPRN_SPRG_THREAD
lwz r1, TASK_CPU - THREAD(r1)
slwi r1, r1, 3
- addis r1, r1, emergency_ctx@ha
+ addis r1, r1, emergency_ctx-PAGE_OFFSET@ha
#else
- lis r1, emergency_ctx@ha
+ lis r1, emergency_ctx-PAGE_OFFSET@ha
#endif
- lwz r1, emergency_ctx@l(r1)
+ lwz r1, emergency_ctx-PAGE_OFFSET@l(r1)
addi r1, r1, THREAD_SIZE - INT_FRAME_SIZE
EXCEPTION_PROLOG_2
SAVE_NVGPRS(r11)



2021-11-29 23:03:52

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 080/121] net/ncsi : Add payload to be 32-bit aligned to fix dropped packets

From: Kumar Thangavel <[email protected]>

[ Upstream commit ac132852147ad303a938dda318970dd1bbdfda4e ]

Update NC-SI command handler (both standard and OEM) to take into
account of payload paddings in allocating skb (in case of payload
size is not 32-bit aligned).

The checksum field follows payload field, without taking payload
padding into account can cause checksum being truncated, leading to
dropped packets.

Fixes: fb4ee67529ff ("net/ncsi: Add NCSI OEM command support")
Signed-off-by: Kumar Thangavel <[email protected]>
Acked-by: Samuel Mendoza-Jonas <[email protected]>
Reviewed-by: Paul Menzel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/ncsi/ncsi-cmd.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/net/ncsi/ncsi-cmd.c b/net/ncsi/ncsi-cmd.c
index ba9ae482141b0..dda8b76b77988 100644
--- a/net/ncsi/ncsi-cmd.c
+++ b/net/ncsi/ncsi-cmd.c
@@ -18,6 +18,8 @@
#include "internal.h"
#include "ncsi-pkt.h"

+static const int padding_bytes = 26;
+
u32 ncsi_calculate_checksum(unsigned char *data, int len)
{
u32 checksum = 0;
@@ -213,12 +215,17 @@ static int ncsi_cmd_handler_oem(struct sk_buff *skb,
{
struct ncsi_cmd_oem_pkt *cmd;
unsigned int len;
+ int payload;
+ /* NC-SI spec DSP_0222_1.2.0, section 8.2.2.2
+ * requires payload to be padded with 0 to
+ * 32-bit boundary before the checksum field.
+ * Ensure the padding bytes are accounted for in
+ * skb allocation
+ */

+ payload = ALIGN(nca->payload, 4);
len = sizeof(struct ncsi_cmd_pkt_hdr) + 4;
- if (nca->payload < 26)
- len += 26;
- else
- len += nca->payload;
+ len += max(payload, padding_bytes);

cmd = skb_put_zero(skb, len);
memcpy(&cmd->mfr_id, nca->data, nca->payload);
@@ -272,6 +279,7 @@ static struct ncsi_request *ncsi_alloc_command(struct ncsi_cmd_arg *nca)
struct net_device *dev = nd->dev;
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
+ int payload;
int len = hlen + tlen;
struct sk_buff *skb;
struct ncsi_request *nr;
@@ -281,14 +289,14 @@ static struct ncsi_request *ncsi_alloc_command(struct ncsi_cmd_arg *nca)
return NULL;

/* NCSI command packet has 16-bytes header, payload, 4 bytes checksum.
+ * Payload needs padding so that the checksum field following payload is
+ * aligned to 32-bit boundary.
* The packet needs padding if its payload is less than 26 bytes to
* meet 64 bytes minimal ethernet frame length.
*/
len += sizeof(struct ncsi_cmd_pkt_hdr) + 4;
- if (nca->payload < 26)
- len += 26;
- else
- len += nca->payload;
+ payload = ALIGN(nca->payload, 4);
+ len += max(payload, padding_bytes);

/* Allocate skb */
skb = alloc_skb(len, GFP_ATOMIC);
--
2.33.0




2021-11-29 23:04:54

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 006/121] usb: dwc2: hcd_queue: Fix use of floating point literal

From: Nathan Chancellor <[email protected]>

commit 310780e825f3ffd211b479b8f828885a6faedd63 upstream.

A new commit in LLVM causes an error on the use of 'long double' when
'-mno-x87' is used, which the kernel does through an alias,
'-mno-80387' (see the LLVM commit below for more details around why it
does this).

drivers/usb/dwc2/hcd_queue.c:1744:25: error: expression requires 'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
delay = ktime_set(0, DWC2_RETRY_WAIT_DELAY);
^
drivers/usb/dwc2/hcd_queue.c:62:34: note: expanded from macro 'DWC2_RETRY_WAIT_DELAY'
#define DWC2_RETRY_WAIT_DELAY (1 * 1E6L)
^
1 error generated.

This happens due to the use of a 'long double' literal. The 'E6' part of
'1E6L' causes the literal to be a 'double' then the 'L' suffix promotes
it to 'long double'.

There is no visible reason for a floating point value in this driver, as
the value is only used as a parameter to a function that expects an
integer type. Use NSEC_PER_MSEC, which is the same integer value as
'1E6L', to avoid changing functionality but fix the error.

Link: https://github.com/ClangBuiltLinux/linux/issues/1497
Link: https://github.com/llvm/llvm-project/commit/a8083d42b1c346e21623a1d36d1f0cadd7801d83
Fixes: 6ed30a7d8ec2 ("usb: dwc2: host: use hrtimer for NAK retries")
Cc: stable <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Reviewed-by: John Keeping <[email protected]>
Acked-by: Minas Harutyunyan <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc2/hcd_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -59,7 +59,7 @@
#define DWC2_UNRESERVE_DELAY (msecs_to_jiffies(5))

/* If we get a NAK, wait this long before retrying */
-#define DWC2_RETRY_WAIT_DELAY 1*1E6L
+#define DWC2_RETRY_WAIT_DELAY (1 * NSEC_PER_MSEC)

/**
* dwc2_periodic_channel_available() - Checks that a channel is available for a



2021-11-29 23:05:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 018/121] ALSA: hda/realtek: Fix LED on HP ProBook 435 G7

From: Takashi Iwai <[email protected]>

commit 05ec7161084565365ecf267e9909a897a95f243a upstream.

HP ProBook 435 G7 (SSID 103c:8735) needs the similar quirk as another
HP ProBook for enabling the mute and the mic-mute LEDs.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215021
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8604,6 +8604,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x103c, 0x8728, "HP EliteBook 840 G7", ALC285_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x8729, "HP", ALC285_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x8730, "HP ProBook 445 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8735, "HP ProBook 435 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT),
SND_PCI_QUIRK(0x103c, 0x8760, "HP", ALC285_FIXUP_HP_MUTE_LED),
SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED),



2021-11-29 23:05:10

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 076/121] mlxsw: Verify the accessed index doesnt exceed the array length

From: Danielle Ratson <[email protected]>

[ Upstream commit 837ec05cfea08284c575e8e834777b107da5ff9d ]

There are few cases in which an array index queried from a fw register,
is accessed without any validation that it doesn't exceed the array
length.

Add a proper length validation, so accessing memory past the end of an
array will be forbidden.

Signed-off-by: Danielle Ratson <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/mellanox/mlxsw/minimal.c | 4 ++++
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 +++++
drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 3 +++
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 3 +++
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 4 ++++
5 files changed, 19 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/minimal.c b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
index c010db2c9dba9..443dc44452ef8 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/minimal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/minimal.c
@@ -234,6 +234,7 @@ static void mlxsw_m_port_remove(struct mlxsw_m *mlxsw_m, u8 local_port)
static int mlxsw_m_port_module_map(struct mlxsw_m *mlxsw_m, u8 local_port,
u8 *last_module)
{
+ unsigned int max_ports = mlxsw_core_max_ports(mlxsw_m->core);
u8 module, width;
int err;

@@ -249,6 +250,9 @@ static int mlxsw_m_port_module_map(struct mlxsw_m *mlxsw_m, u8 local_port,
if (module == *last_module)
return 0;
*last_module = module;
+
+ if (WARN_ON_ONCE(module >= max_ports))
+ return -EINVAL;
mlxsw_m->module_to_port[module] = ++mlxsw_m->max_ports;

return 0;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index b08853f71b2be..1a9978f501ba9 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -2052,9 +2052,14 @@ static void mlxsw_sp_pude_event_func(const struct mlxsw_reg_info *reg,
struct mlxsw_sp *mlxsw_sp = priv;
struct mlxsw_sp_port *mlxsw_sp_port;
enum mlxsw_reg_pude_oper_status status;
+ unsigned int max_ports;
u8 local_port;

+ max_ports = mlxsw_core_max_ports(mlxsw_sp->core);
local_port = mlxsw_reg_pude_local_port_get(pude_pl);
+
+ if (WARN_ON_ONCE(local_port >= max_ports))
+ return;
mlxsw_sp_port = mlxsw_sp->ports[local_port];
if (!mlxsw_sp_port)
return;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
index ca8090a28dec6..50eca2daad843 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
@@ -568,10 +568,13 @@ void mlxsw_sp1_ptp_got_timestamp(struct mlxsw_sp *mlxsw_sp, bool ingress,
u8 domain_number, u16 sequence_id,
u64 timestamp)
{
+ unsigned int max_ports = mlxsw_core_max_ports(mlxsw_sp->core);
struct mlxsw_sp_port *mlxsw_sp_port;
struct mlxsw_sp1_ptp_key key;
u8 types;

+ if (WARN_ON_ONCE(local_port >= max_ports))
+ return;
mlxsw_sp_port = mlxsw_sp->ports[local_port];
if (!mlxsw_sp_port)
return;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
index 4381f8c6c3fb7..53128382fc2e0 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
@@ -2177,6 +2177,7 @@ static void mlxsw_sp_router_neigh_ent_ipv4_process(struct mlxsw_sp *mlxsw_sp,
char *rauhtd_pl,
int ent_index)
{
+ u64 max_rifs = MLXSW_CORE_RES_GET(mlxsw_sp->core, MAX_RIFS);
struct net_device *dev;
struct neighbour *n;
__be32 dipn;
@@ -2185,6 +2186,8 @@ static void mlxsw_sp_router_neigh_ent_ipv4_process(struct mlxsw_sp *mlxsw_sp,

mlxsw_reg_rauhtd_ent_ipv4_unpack(rauhtd_pl, ent_index, &rif, &dip);

+ if (WARN_ON_ONCE(rif >= max_rifs))
+ return;
if (!mlxsw_sp->router->rifs[rif]) {
dev_err_ratelimited(mlxsw_sp->bus_info->dev, "Incorrect RIF in neighbour entry\n");
return;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 6501ce94ace58..368fa0e5ad315 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -2410,6 +2410,7 @@ static void mlxsw_sp_fdb_notify_mac_process(struct mlxsw_sp *mlxsw_sp,
char *sfn_pl, int rec_index,
bool adding)
{
+ unsigned int max_ports = mlxsw_core_max_ports(mlxsw_sp->core);
struct mlxsw_sp_port_vlan *mlxsw_sp_port_vlan;
struct mlxsw_sp_bridge_device *bridge_device;
struct mlxsw_sp_bridge_port *bridge_port;
@@ -2422,6 +2423,9 @@ static void mlxsw_sp_fdb_notify_mac_process(struct mlxsw_sp *mlxsw_sp,
int err;

mlxsw_reg_sfn_mac_unpack(sfn_pl, rec_index, mac, &fid, &local_port);
+
+ if (WARN_ON_ONCE(local_port >= max_ports))
+ return;
mlxsw_sp_port = mlxsw_sp->ports[local_port];
if (!mlxsw_sp_port) {
dev_err_ratelimited(mlxsw_sp->bus_info->dev, "Incorrect local port in FDB notification\n");
--
2.33.0




2021-11-29 23:05:15

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 089/121] nvmet: use IOCB_NOWAIT only if the filesystem supports it

From: Maurizio Lombardi <[email protected]>

[ Upstream commit c024b226a417c4eb9353ff500b1c823165d4d508 ]

Submit I/O requests with the IOCB_NOWAIT flag set only if
the underlying filesystem supports it.

Fixes: 50a909db36f2 ("nvmet: use IOCB_NOWAIT for file-ns buffered I/O")
Signed-off-by: Maurizio Lombardi <[email protected]>
Reviewed-by: Chaitanya Kulkarni <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/nvme/target/io-cmd-file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/target/io-cmd-file.c b/drivers/nvme/target/io-cmd-file.c
index b575997244482..c81690b2a681b 100644
--- a/drivers/nvme/target/io-cmd-file.c
+++ b/drivers/nvme/target/io-cmd-file.c
@@ -8,6 +8,7 @@
#include <linux/uio.h>
#include <linux/falloc.h>
#include <linux/file.h>
+#include <linux/fs.h>
#include "nvmet.h"

#define NVMET_MAX_MPOOL_BVEC 16
@@ -266,7 +267,8 @@ static void nvmet_file_execute_rw(struct nvmet_req *req)

if (req->ns->buffered_io) {
if (likely(!req->f.mpool_alloc) &&
- nvmet_file_execute_io(req, IOCB_NOWAIT))
+ (req->ns->file->f_mode & FMODE_NOWAIT) &&
+ nvmet_file_execute_io(req, IOCB_NOWAIT))
return;
nvmet_file_submit_buffered_io(req);
} else
--
2.33.0




2021-11-29 23:05:20

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 090/121] igb: fix netpoll exit with traffic

From: Jesse Brandeburg <[email protected]>

[ Upstream commit eaeace60778e524a2820d0c0ad60bf80289e292c ]

Oleksandr brought a bug report where netpoll causes trace
messages in the log on igb.

Danielle brought this back up as still occurring, so we'll try
again.

[22038.710800] ------------[ cut here ]------------
[22038.710801] igb_poll+0x0/0x1440 [igb] exceeded budget in poll
[22038.710802] WARNING: CPU: 12 PID: 40362 at net/core/netpoll.c:155 netpoll_poll_dev+0x18a/0x1a0

As Alex suggested, change the driver to return work_done at the
exit of napi_poll, which should be safe to do in this driver
because it is not polling multiple queues in this single napi
context (multiple queues attached to one MSI-X vector). Several
other drivers contain the same simple sequence, so I hope
this will not create new problems.

Fixes: 16eb8815c235 ("igb: Refactor clean_rx_irq to reduce overhead and improve performance")
Reported-by: Oleksandr Natalenko <[email protected]>
Reported-by: Danielle Ratson <[email protected]>
Suggested-by: Alexander Duyck <[email protected]>
Signed-off-by: Jesse Brandeburg <[email protected]>
Tested-by: Oleksandr Natalenko <[email protected]>
Tested-by: Danielle Ratson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index e24fb122c03a2..d5432d1448c05 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -8032,7 +8032,7 @@ static int igb_poll(struct napi_struct *napi, int budget)
if (likely(napi_complete_done(napi, work_done)))
igb_ring_irq_enable(q_vector);

- return min(work_done, budget - 1);
+ return work_done;
}

/**
--
2.33.0




2021-11-29 23:05:29

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 099/121] net: mscc: ocelot: dont downgrade timestamping RX filters in SIOCSHWTSTAMP

From: Vladimir Oltean <[email protected]>

[ Upstream commit 8a075464d1e9317ffae0973dfe538a7511291a06 ]

The ocelot driver, when asked to timestamp all receiving packets, 1588
v1 or NTP, says "nah, here's 1588 v2 for you".

According to this discussion:
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/#24577647
drivers that downgrade from a wider request to a narrower response (or
even a response where the intersection with the request is empty) are
buggy, and should return -ERANGE instead. This patch fixes that.

Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support")
Suggested-by: Richard Cochran <[email protected]>
Signed-off-by: Vladimir Oltean <[email protected]>
Acked-by: Richard Cochran <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/mscc/ocelot.c | 6 ------
1 file changed, 6 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index 8c45b236649a9..154d67066d012 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -811,12 +811,6 @@ int ocelot_hwstamp_set(struct ocelot *ocelot, int port, struct ifreq *ifr)
switch (cfg.rx_filter) {
case HWTSTAMP_FILTER_NONE:
break;
- case HWTSTAMP_FILTER_ALL:
- case HWTSTAMP_FILTER_SOME:
- case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
- case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
- case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
- case HWTSTAMP_FILTER_NTP_ALL:
case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
--
2.33.0




2021-11-29 23:05:34

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 066/121] net: stmmac: fix system hang caused by eee_ctrl_timer during suspend/resume

From: Joakim Zhang <[email protected]>

[ Upstream commit 276aae377206d60b9b7b7df4586cd9f2a813f5d0 ]

commit 5f58591323bf ("net: stmmac: delete the eee_ctrl_timer after
napi disabled"), this patch tries to fix system hang caused by eee_ctrl_timer,
unfortunately, it only can resolve it for system reboot stress test. System
hang also can be reproduced easily during system suspend/resume stess test
when mount NFS on i.MX8MP EVK board.

In stmmac driver, eee feature is combined to phylink framework. When do
system suspend, phylink_stop() would queue delayed work, it invokes
stmmac_mac_link_down(), where to deactivate eee_ctrl_timer synchronizly.
In above commit, try to fix issue by deactivating eee_ctrl_timer obviously,
but it is not enough. Looking into eee_ctrl_timer expire callback
stmmac_eee_ctrl_timer(), it could enable hareware eee mode again. What is
unexpected is that LPI interrupt (MAC_Interrupt_Enable.LPIEN bit) is always
asserted. This interrupt has chance to be issued when LPI state entry/exit
from the MAC, and at that time, clock could have been already disabled.
The result is that system hang when driver try to touch register from
interrupt handler.

The reason why above commit can fix system hang issue in stmmac_release()
is that, deactivate eee_ctrl_timer not just after napi disabled, further
after irq freed.

In conclusion, hardware would generate LPI interrupt when clock has been
disabled during suspend or resume, since hardware is in eee mode and LPI
interrupt enabled.

Interrupts from MAC, MTL and DMA level are enabled and never been disabled
when system suspend, so postpone clocks management from suspend stage to
noirq suspend stage should be more safe.

Fixes: 5f58591323bf ("net: stmmac: delete the eee_ctrl_timer after napi disabled")
Signed-off-by: Joakim Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 14 ------
.../ethernet/stmicro/stmmac/stmmac_platform.c | 44 +++++++++++++++++++
2 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4a75e73f06bbd..b6a2bc020026a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5238,7 +5238,6 @@ int stmmac_suspend(struct device *dev)
struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
u32 chan;
- int ret;

if (!ndev || !netif_running(ndev))
return 0;
@@ -5280,13 +5279,6 @@ int stmmac_suspend(struct device *dev)

stmmac_mac_set(priv, priv->ioaddr, false);
pinctrl_pm_select_sleep_state(priv->device);
- /* Disable clock in case of PWM is off */
- clk_disable_unprepare(priv->plat->clk_ptp_ref);
- ret = pm_runtime_force_suspend(dev);
- if (ret) {
- mutex_unlock(&priv->lock);
- return ret;
- }
}
mutex_unlock(&priv->lock);

@@ -5351,12 +5343,6 @@ int stmmac_resume(struct device *dev)
priv->irq_wake = 0;
} else {
pinctrl_pm_select_default_state(priv->device);
- /* enable the clk previously disabled */
- ret = pm_runtime_force_resume(dev);
- if (ret)
- return ret;
- if (priv->plat->clk_ptp_ref)
- clk_prepare_enable(priv->plat->clk_ptp_ref);
/* reset the phy so that it's ready */
if (priv->mii)
stmmac_mdio_reset(priv->mii);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 035f9aef4308f..5c9d29c42bac8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -9,6 +9,7 @@
*******************************************************************************/

#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/module.h>
#include <linux/io.h>
#include <linux/of.h>
@@ -778,9 +779,52 @@ static int __maybe_unused stmmac_runtime_resume(struct device *dev)
return stmmac_bus_clks_config(priv, true);
}

+static int stmmac_pltfr_noirq_suspend(struct device *dev)
+{
+ struct net_device *ndev = dev_get_drvdata(dev);
+ struct stmmac_priv *priv = netdev_priv(ndev);
+ int ret;
+
+ if (!netif_running(ndev))
+ return 0;
+
+ if (!device_may_wakeup(priv->device) || !priv->plat->pmt) {
+ /* Disable clock in case of PWM is off */
+ clk_disable_unprepare(priv->plat->clk_ptp_ref);
+
+ ret = pm_runtime_force_suspend(dev);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int stmmac_pltfr_noirq_resume(struct device *dev)
+{
+ struct net_device *ndev = dev_get_drvdata(dev);
+ struct stmmac_priv *priv = netdev_priv(ndev);
+ int ret;
+
+ if (!netif_running(ndev))
+ return 0;
+
+ if (!device_may_wakeup(priv->device) || !priv->plat->pmt) {
+ /* enable the clk previously disabled */
+ ret = pm_runtime_force_resume(dev);
+ if (ret)
+ return ret;
+
+ clk_prepare_enable(priv->plat->clk_ptp_ref);
+ }
+
+ return 0;
+}
+
const struct dev_pm_ops stmmac_pltfr_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(stmmac_pltfr_suspend, stmmac_pltfr_resume)
SET_RUNTIME_PM_OPS(stmmac_runtime_suspend, stmmac_runtime_resume, NULL)
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(stmmac_pltfr_noirq_suspend, stmmac_pltfr_noirq_resume)
};
EXPORT_SYMBOL_GPL(stmmac_pltfr_pm_ops);

--
2.33.0




2021-11-29 23:05:36

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.10 094/121] tls: fix replacing proto_ops

From: Jakub Kicinski <[email protected]>

[ Upstream commit f3911f73f51d1534f4db70b516cc1fcb6be05bae ]

We replace proto_ops whenever TLS is configured for RX. But our
replacement also overrides sendpage_locked, which will crash
unless TX is also configured. Similarly we plug both of those
in for TLS_HW (NIC crypto offload) even tho TLS_HW has a completely
different implementation for TX.

Last but not least we always plug in something based on inet_stream_ops
even though a few of the callbacks differ for IPv6 (getname, release,
bind).

Use a callback building method similar to what we do for struct proto.

Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Fixes: d4ffb02dee2f ("net/tls: enable sk_msg redirect to tls socket egress")
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/tls/tls_main.c | 47 +++++++++++++++++++++++++++++++++++++++-------
1 file changed, 40 insertions(+), 7 deletions(-)

diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 32a51b20509c9..58d22d6b86ae6 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -61,7 +61,7 @@ static DEFINE_MUTEX(tcpv6_prot_mutex);
static const struct proto *saved_tcpv4_prot;
static DEFINE_MUTEX(tcpv4_prot_mutex);
static struct proto tls_prots[TLS_NUM_PROTS][TLS_NUM_CONFIG][TLS_NUM_CONFIG];
-static struct proto_ops tls_sw_proto_ops;
+static struct proto_ops tls_proto_ops[TLS_NUM_PROTS][TLS_NUM_CONFIG][TLS_NUM_CONFIG];
static void build_protos(struct proto prot[TLS_NUM_CONFIG][TLS_NUM_CONFIG],
const struct proto *base);

@@ -71,6 +71,8 @@ void update_sk_prot(struct sock *sk, struct tls_context *ctx)

WRITE_ONCE(sk->sk_prot,
&tls_prots[ip_ver][ctx->tx_conf][ctx->rx_conf]);
+ WRITE_ONCE(sk->sk_socket->ops,
+ &tls_proto_ops[ip_ver][ctx->tx_conf][ctx->rx_conf]);
}

int wait_on_pending_writer(struct sock *sk, long *timeo)
@@ -578,8 +580,6 @@ static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval,
if (tx) {
ctx->sk_write_space = sk->sk_write_space;
sk->sk_write_space = tls_write_space;
- } else {
- sk->sk_socket->ops = &tls_sw_proto_ops;
}
goto out;

@@ -637,6 +637,39 @@ struct tls_context *tls_ctx_create(struct sock *sk)
return ctx;
}

+static void build_proto_ops(struct proto_ops ops[TLS_NUM_CONFIG][TLS_NUM_CONFIG],
+ const struct proto_ops *base)
+{
+ ops[TLS_BASE][TLS_BASE] = *base;
+
+ ops[TLS_SW ][TLS_BASE] = ops[TLS_BASE][TLS_BASE];
+ ops[TLS_SW ][TLS_BASE].sendpage_locked = tls_sw_sendpage_locked;
+
+ ops[TLS_BASE][TLS_SW ] = ops[TLS_BASE][TLS_BASE];
+ ops[TLS_BASE][TLS_SW ].splice_read = tls_sw_splice_read;
+
+ ops[TLS_SW ][TLS_SW ] = ops[TLS_SW ][TLS_BASE];
+ ops[TLS_SW ][TLS_SW ].splice_read = tls_sw_splice_read;
+
+#ifdef CONFIG_TLS_DEVICE
+ ops[TLS_HW ][TLS_BASE] = ops[TLS_BASE][TLS_BASE];
+ ops[TLS_HW ][TLS_BASE].sendpage_locked = NULL;
+
+ ops[TLS_HW ][TLS_SW ] = ops[TLS_BASE][TLS_SW ];
+ ops[TLS_HW ][TLS_SW ].sendpage_locked = NULL;
+
+ ops[TLS_BASE][TLS_HW ] = ops[TLS_BASE][TLS_SW ];
+
+ ops[TLS_SW ][TLS_HW ] = ops[TLS_SW ][TLS_SW ];
+
+ ops[TLS_HW ][TLS_HW ] = ops[TLS_HW ][TLS_SW ];
+ ops[TLS_HW ][TLS_HW ].sendpage_locked = NULL;
+#endif
+#ifdef CONFIG_TLS_TOE
+ ops[TLS_HW_RECORD][TLS_HW_RECORD] = *base;
+#endif
+}
+
static void tls_build_proto(struct sock *sk)
{
int ip_ver = sk->sk_family == AF_INET6 ? TLSV6 : TLSV4;
@@ -648,6 +681,8 @@ static void tls_build_proto(struct sock *sk)
mutex_lock(&tcpv6_prot_mutex);
if (likely(prot != saved_tcpv6_prot)) {
build_protos(tls_prots[TLSV6], prot);
+ build_proto_ops(tls_proto_ops[TLSV6],
+ sk->sk_socket->ops);
smp_store_release(&saved_tcpv6_prot, prot);
}
mutex_unlock(&tcpv6_prot_mutex);
@@ -658,6 +693,8 @@ static void tls_build_proto(struct sock *sk)
mutex_lock(&tcpv4_prot_mutex);
if (likely(prot != saved_tcpv4_prot)) {
build_protos(tls_prots[TLSV4], prot);
+ build_proto_ops(tls_proto_ops[TLSV4],
+ sk->sk_socket->ops);
smp_store_release(&saved_tcpv4_prot, prot);
}
mutex_unlock(&tcpv4_prot_mutex);
@@ -868,10 +905,6 @@ static int __init tls_register(void)
if (err)
return err;

- tls_sw_proto_ops = inet_stream_ops;
- tls_sw_proto_ops.splice_read = tls_sw_splice_read;
- tls_sw_proto_ops.sendpage_locked = tls_sw_sendpage_locked;
-
tls_device_init();
tcp_register_ulp(&tcp_tls_ulp_ops);

--
2.33.0




2021-11-30 01:03:24

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/121] 5.10.83-rc1 review

On 11/29/21 11:17 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.83-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <[email protected]>

thanks,
-- Shuah

2021-11-30 01:22:40

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/121] 5.10.83-rc1 review



On 2021/11/30 2:17, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.83-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Tested on arm64 and x86 for 5.10.83-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.10.y
Version: 5.10.83-rc1
Commit: 35674c284fc5a17551d5df7c9af8a9737760dbfe
Compiler: gcc version 7.3.0 (GCC)

arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9019
passed: 9019
failed: 0
timeout: 0
--------------------------------------------------------------------

x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 9019
passed: 9019
failed: 0
timeout: 0
--------------------------------------------------------------------

Tested-by: Hulk Robot <[email protected]>

2021-11-30 04:02:28

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/121] 5.10.83-rc1 review



On 11/29/2021 10:17 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.83-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:

Tested-by: Florian Fainelli <[email protected]>
--
Florian

2021-11-30 05:56:09

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/121] 5.10.83-rc1 review

On Tue, 30 Nov 2021 at 00:01, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.83-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

## Build
* kernel: 5.10.83-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: cd4fd0597d3787df6c6771a7b41379d35a8f31b0
* git describe: v5.10.82-122-gcd4fd0597d37
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.82-122-gcd4fd0597d37

## No regressions (compared to v5.10.81-155-gf8f271281cd8)

## No fixes (compared to v5.10.81-155-gf8f271281cd8)

## Test result summary
total: 86505, pass: 73579, fail: 512, skip: 11613, xfail: 801

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 259 total, 259 passed, 0 failed
* arm64: 37 total, 37 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 36 total, 36 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 34 total, 34 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 54 total, 46 passed, 8 failed
* riscv: 24 total, 24 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 20 total, 20 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 37 total, 37 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

2021-11-30 12:04:22

by Fox Chen

[permalink] [raw]
Subject: RE: [PATCH 5.10 000/121] 5.10.83-rc1 review

On Mon, 29 Nov 2021 19:17:11 +0100, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.83-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

5.10.83-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

Tested-by: Fox Chen <[email protected]>


2021-11-30 13:36:04

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/121] 5.10.83-rc1 review

Hi Greg,

On Mon, Nov 29, 2021 at 07:17:11PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
> Anything received after that time might be too late.

Build test:
mips (gcc version 11.2.1 20211112): 63 configs -> no new failure
arm (gcc version 11.2.1 20211112): 105 configs -> no new failure
arm64 (gcc version 11.2.1 20211112): 3 configs -> no failure
x86_64 (gcc version 11.2.1 20211112): 4 configs -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]

[1]. https://openqa.qa.codethink.co.uk/tests/455
[2]. https://openqa.qa.codethink.co.uk/tests/450


Tested-by: Sudip Mukherjee <[email protected]>

--
Regards
Sudip

2021-11-30 16:03:13

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/121] 5.10.83-rc1 review

Hi!

> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (644.00 B)
signature.asc (195.00 B)
Download all attachments

2021-11-30 17:41:33

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/121] 5.10.83-rc1 review

On Mon, Nov 29, 2021 at 07:17:11PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.83 release.
> There are 121 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 01 Dec 2021 18:16:51 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 159 pass: 159 fail: 0
Qemu test results:
total: 474 pass: 474 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter