2021-09-21 02:47:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 000/122] 5.10.68-rc1 review

This is the start of the stable review cycle for the 5.10.68 release.
There are 122 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, 22 Sep 2021 16:38:49 +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.68-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.68-rc1

Tony Luck <[email protected]>
x86/mce: Avoid infinite loop for copy from user recovery

Yoshihiro Shimoda <[email protected]>
net: renesas: sh_eth: Fix freeing wrong tx descriptor

Randy Dunlap <[email protected]>
mfd: lpc_sch: Rename GPIOBASE to prevent build error

Andy Shevchenko <[email protected]>
mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000"

Michael Chan <[email protected]>
bnxt_en: Fix possible unintended driver initiated error recovery

Michael Chan <[email protected]>
bnxt_en: Improve logging of error recovery settings information.

Michael Chan <[email protected]>
bnxt_en: Convert to use netif_level() helpers.

Michael Chan <[email protected]>
bnxt_en: Consolidate firmware reset event logging.

Edwin Peer <[email protected]>
bnxt_en: log firmware debug notifications

Michael Chan <[email protected]>
bnxt_en: Fix asic.rev in devlink dev info command

Edwin Peer <[email protected]>
bnxt_en: fix stored FW_PSID version masks

Rafał Miłecki <[email protected]>
net: dsa: b53: Fix IMP port setup on BCM5301x

Willem de Bruijn <[email protected]>
ip_gre: validate csum_start only on pull

Dinghao Liu <[email protected]>
qlcnic: Remove redundant unlock in qlcnic_pinit_from_rom

Eric Dumazet <[email protected]>
fq_codel: reject silly quantum parameters

Benjamin Hesmans <[email protected]>
netfilter: socket: icmp6: fix use-after-scope

Rafał Miłecki <[email protected]>
net: dsa: b53: Set correct number of ports in the DSA struct

Rafał Miłecki <[email protected]>
net: dsa: b53: Fix calculating number of switch ports

Ziyang Xuan <[email protected]>
net: hso: add failure handler for add_net_device

Matthieu Baerts <[email protected]>
selftests: mptcp: clean tmp files in simult_flows

Linus Walleij <[email protected]>
net: dsa: tag_rtl4_a: Fix egress tags

Christophe JAILLET <[email protected]>
gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and avoid a leak

Christophe JAILLET <[email protected]>
gpio: mpc8xxx: Fix a potential double iounmap call in 'mpc8xxx_probe()'

Christophe JAILLET <[email protected]>
gpio: mpc8xxx: Fix a resources leak in the error handling path of 'mpc8xxx_probe()'

Arnaldo Carvalho de Melo <[email protected]>
perf bench inject-buildid: Handle writen() errors

Li Huafei <[email protected]>
perf unwind: Do not overwrite FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64}

Randy Dunlap <[email protected]>
ARC: export clear_user_page() for modules

Christophe JAILLET <[email protected]>
mtd: rawnand: cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()'

Andy Shevchenko <[email protected]>
PCI: Sync __pci_register_driver() stub for CONFIG_PCI=n

Oliver Upton <[email protected]>
KVM: arm64: Handle PSCI resets before userspace touches vCPU state

Oliver Upton <[email protected]>
KVM: arm64: Fix read-side race on updates to vcpu reset state

Zhihao Cheng <[email protected]>
mtd: mtdconcat: Check _read, _write callbacks existence before assignment

Zhihao Cheng <[email protected]>
mtd: mtdconcat: Judge callback existence based on the master

Masami Hiramatsu <[email protected]>
tracing/boot: Fix a hist trigger dependency for boot time tracing

Matthias Schiffer <[email protected]>
mfd: tqmx86: Clear GPIO IRQ resource when no IRQ is set

Dan Carpenter <[email protected]>
PCI: Fix pci_dev_str_match_path() alloc while atomic bug

Anshuman Khandual <[email protected]>
KVM: arm64: Restrict IPA size to maximum 48 bits on 4K and 16K page size

Pavel Skripkin <[email protected]>
netfilter: nft_ct: protect nft_ct_pcpu_template_refcnt with mutex

Gustavo A. R. Silva <[email protected]>
netfilter: Fix fall-through warnings for Clang

Rob Herring <[email protected]>
PCI: iproc: Fix BCMA probe resource handling

Rob Herring <[email protected]>
PCI: of: Don't fail devm_pci_alloc_host_bridge() on missing 'ranges'

Linus Walleij <[email protected]>
backlight: ktd253: Stabilize backlight

Hans de Goede <[email protected]>
mfd: axp20x: Update AXP288 volatile ranges

Russell King (Oracle) <[email protected]>
net: phylink: add suspend/resume support

Yang Li <[email protected]>
NTB: perf: Fix an error code in perf_setup_inbuf()

Yang Li <[email protected]>
NTB: Fix an error code in ntb_msit_probe()

Yang Li <[email protected]>
ethtool: Fix an error code in cxgb2.c

Vishal Aslot <[email protected]>
PCI: ibmphp: Fix double unmap of io_mem

Paolo Valente <[email protected]>
block, bfq: honor already-setup queue merges

Daniele Palmas <[email protected]>
net: usb: cdc_mbim: avoid altsetting toggling for Telit LN920

Ryoga Saito <[email protected]>
Set fc_nlinfo in nh_create_ipv4, nh_create_ipv6

Smadar Fuks <[email protected]>
octeontx2-af: Add additional register check to rvu_poll_reg()

Jan Kiszka <[email protected]>
watchdog: Start watchdog in watchdog_set_last_hw_keepalive only if appropriate

George Cherian <[email protected]>
PCI: Add ACS quirks for Cavium multi-function devices

Kishon Vijay Abraham I <[email protected]>
PCI: j721e: Add PCIe support for AM64

Kishon Vijay Abraham I <[email protected]>
PCI: j721e: Add PCIe support for J7200

Nadeem Athani <[email protected]>
PCI: cadence: Add quirk flag to set minimum delay in LTSSM Detect.Quiet state

Kishon Vijay Abraham I <[email protected]>
PCI: cadence: Use bitfield for *quirk_retrain_flag* instead of bool

Masami Hiramatsu <[email protected]>
tracing/probes: Reject events which have the same name of existing one

Dinghao Liu <[email protected]>
PCI: rcar: Fix runtime PM imbalance in rcar_pcie_ep_probe()

Marc Zyngier <[email protected]>
mfd: Don't use irq_create_mapping() to resolve a mapping

Christophe JAILLET <[email protected]>
PCI: tegra: Fix OF node reference leak

Om Prakash Singh <[email protected]>
PCI: tegra194: Fix MSI-X programming

Om Prakash Singh <[email protected]>
PCI: tegra194: Fix handling BME_CHGED event

Miklos Szeredi <[email protected]>
fuse: fix use after free in fuse_read_interrupt()

Wasim Khan <[email protected]>
PCI: Add ACS quirks for NXP LX2xx0 and LX2xx2 platforms

Linus Walleij <[email protected]>
mfd: db8500-prcmu: Adjust map to reality

Miquel Raynal <[email protected]>
dt-bindings: mtd: gpmc: Fix the ECC bytes vs. OOB bytes equation

David Hildenbrand <[email protected]>
mm/memory_hotplug: use "unsigned long" for PFN in zone_for_pfn_range()

Jiaran Zhang <[email protected]>
net: hns3: fix the timing issue of VF clearing interrupt sources

Yufeng Mo <[email protected]>
net: hns3: disable mac in flr process

Yufeng Mo <[email protected]>
net: hns3: change affinity_mask to numa node range

Yufeng Mo <[email protected]>
net: hns3: pad the short tunnel frame before sending to hardware

Edwin Peer <[email protected]>
bnxt_en: make bnxt_free_skbs() safe to call after bnxt_free_mem()

Nicholas Piggin <[email protected]>
KVM: PPC: Book3S HV: Tolerate treclaim. in fake-suspend mode changing registers

Sukadev Bhattiprolu <[email protected]>
ibmvnic: check failover_pending in login response

David Heidelberg <[email protected]>
dt-bindings: arm: Fix Toradex compatible typo

Aya Levin <[email protected]>
udp_tunnel: Fix udp_tunnel_nic work-queue type

Shai Malin <[email protected]>
qed: Handle management FW error

Andrea Claudi <[email protected]>
selftest: net: fix typo in altname test

zhenggy <[email protected]>
tcp: fix tp->undo_retrans accounting in tcp_sacktag_one()

Will Deacon <[email protected]>
x86/uaccess: Fix 32-bit __get_user_asm_u64() when CC_HAS_ASM_GOTO_OUTPUT=y

Vladimir Oltean <[email protected]>
net: dsa: destroy the phylink instance on any error in dsa_slave_phy_setup

Eric Dumazet <[email protected]>
net/af_unix: fix a data-race in unix_dgram_poll

Paolo Abeni <[email protected]>
vhost_net: fix OoB on sendmsg() failure.

Kortan <[email protected]>
gen_compile_commands: fix missing 'sys' package

Alex Elder <[email protected]>
net: ipa: initialize all filter table slots

Baptiste Lepers <[email protected]>
events: Reuse value read using READ_ONCE instead of re-reading it

Keith Busch <[email protected]>
nvme-tcp: fix io_work priority inversion

Maor Gottlieb <[email protected]>
net/mlx5: Fix potential sleeping in atomic context

Saeed Mahameed <[email protected]>
net/mlx5: FWTrace, cancel work on alloc pd error flow

Michael Petlan <[email protected]>
perf machine: Initialize srcline string member in add_location struct

Arnd Bergmann <[email protected]>
drm/rockchip: cdn-dp-core: Make cdn_dp_core_resume __maybe_unused

Hoang Le <[email protected]>
tipc: increase timeout in tipc_sk_enqueue()

Florian Fainelli <[email protected]>
r6040: Restore MDIO clock frequency after MAC reset

Xiyu Yang <[email protected]>
net/l2tp: Fix reference count leak in l2tp_udp_recv_core

Lin, Zhenpeng <[email protected]>
dccp: don't duplicate ccid when cloning dccp sock

Randy Dunlap <[email protected]>
ptp: dp83640: don't define PAGE0

Eric Dumazet <[email protected]>
net-caif: avoid user-triggerable WARN_ON(1)

Eli Cohen <[email protected]>
net/{mlx5|nfp|bnxt}: Remove unnecessary RTNL lock assert

Saeed Mahameed <[email protected]>
ethtool: Fix rxnfc copy to user buffer overflow

Xin Long <[email protected]>
tipc: fix an use-after-free issue in tipc_recvmsg

Mike Rapoport <[email protected]>
x86/mm: Fix kern_addr_valid() to cope with existing but not present entries

Jeff Moyer <[email protected]>
x86/pat: Pass valid address to sanitize_phys()

Alexander Egorenkov <[email protected]>
s390/sclp: fix Secure-IPL facility detection

Lucas Stach <[email protected]>
drm/etnaviv: add missing MMU context put when reaping MMU mapping

Lucas Stach <[email protected]>
drm/etnaviv: reference MMU context when setting up hardware state

Lucas Stach <[email protected]>
drm/etnaviv: fix MMU context leak on GPU reset

Lucas Stach <[email protected]>
drm/etnaviv: exec and MMU state is lost when resetting the GPU

Lucas Stach <[email protected]>
drm/etnaviv: keep MMU context across runtime suspend/resume

Lucas Stach <[email protected]>
drm/etnaviv: stop abusing mmu_context as FE running marker

Lucas Stach <[email protected]>
drm/etnaviv: put submit prev MMU context when it exists

Lucas Stach <[email protected]>
drm/etnaviv: return context from etnaviv_iommu_context_get

Ernst Sjöstrand <[email protected]>
drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10

Evan Quan <[email protected]>
PCI: Add AMD GPU multi-function power dependencies

Juergen Gross <[email protected]>
PM: base: power: don't try to use non-existing RTC for storing data

Mark Brown <[email protected]>
arm64/sve: Use correct size when reinitialising SVE state

Adrian Bunk <[email protected]>
bnx2x: Fix enabling network interfaces without VFs

Juergen Gross <[email protected]>
xen: reset legacy rtc flag for PV domU

Jens Axboe <[email protected]>
io_uring: ensure symmetry in handling iter types in loop_rw_iter()

Anand Jain <[email protected]>
btrfs: fix upper limit for max_inline for page size 64K

Robert Foss <[email protected]>
drm/bridge: lt9611: Fix handling of 4k panels


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

Diffstat:

Documentation/devicetree/bindings/arm/tegra.yaml | 2 +-
.../devicetree/bindings/mtd/gpmc-nand.txt | 2 +-
Makefile | 4 +-
arch/arc/mm/cache.c | 2 +-
arch/arm64/kernel/fpsimd.c | 2 +-
arch/arm64/kvm/arm.c | 8 +++
arch/arm64/kvm/reset.c | 24 +++++--
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 36 +++++++++-
arch/x86/include/asm/uaccess.h | 4 +-
arch/x86/kernel/cpu/mce/core.c | 43 +++++++++---
arch/x86/mm/init_64.c | 6 +-
arch/x86/mm/pat/memtype.c | 7 +-
arch/x86/xen/enlighten_pv.c | 7 ++
block/bfq-iosched.c | 16 ++++-
drivers/base/power/trace.c | 10 +++
drivers/gpio/gpio-mpc8xxx.c | 13 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611.c | 8 ++-
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 3 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 43 +++++++-----
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 +
drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 4 ++
drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 8 +++
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 1 +
drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 4 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
drivers/mfd/ab8500-core.c | 2 +-
drivers/mfd/axp20x.c | 3 +-
drivers/mfd/db8500-prcmu.c | 14 ++--
drivers/mfd/lpc_sch.c | 36 +++-------
drivers/mfd/stmpe.c | 4 +-
drivers/mfd/tc3589x.c | 2 +-
drivers/mfd/tqmx86.c | 2 +
drivers/mfd/wm8994-irq.c | 2 +-
drivers/mtd/mtdconcat.c | 33 ++++++---
drivers/mtd/nand/raw/cafe_nand.c | 4 +-
drivers/net/dsa/b53/b53_common.c | 33 +++++++--
drivers/net/dsa/b53/b53_priv.h | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 80 ++++++++++++++-------
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 3 -
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 1 +
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8 ++-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 19 ++---
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 6 +-
drivers/net/ethernet/ibm/ibmvnic.c | 8 +++
drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 12 +++-
.../ethernet/mellanox/mlx5/core/diag/fw_tracer.c | 3 +-
.../net/ethernet/mellanox/mlx5/core/en/rep/tc.c | 3 -
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 5 +-
.../net/ethernet/netronome/nfp/flower/offload.c | 3 -
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 6 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 1 -
drivers/net/ethernet/rdc/r6040.c | 9 ++-
drivers/net/ethernet/renesas/sh_eth.c | 1 +
drivers/net/ipa/ipa_table.c | 3 +-
drivers/net/phy/dp83640_reg.h | 2 +-
drivers/net/phy/phylink.c | 82 ++++++++++++++++++++++
drivers/net/usb/cdc_mbim.c | 5 ++
drivers/net/usb/hso.c | 11 ++-
drivers/ntb/test/ntb_msi_test.c | 4 +-
drivers/ntb/test/ntb_perf.c | 1 +
drivers/nvme/host/tcp.c | 20 +++---
drivers/pci/controller/cadence/pci-j721e.c | 61 ++++++++++++++--
drivers/pci/controller/cadence/pcie-cadence-ep.c | 4 ++
drivers/pci/controller/cadence/pcie-cadence-host.c | 3 +
drivers/pci/controller/cadence/pcie-cadence.c | 16 +++++
drivers/pci/controller/cadence/pcie-cadence.h | 17 ++++-
drivers/pci/controller/dwc/pcie-tegra194.c | 32 ++++-----
drivers/pci/controller/pci-tegra.c | 13 ++--
drivers/pci/controller/pcie-iproc-bcma.c | 16 ++---
drivers/pci/controller/pcie-rcar-ep.c | 4 +-
drivers/pci/hotplug/TODO | 3 -
drivers/pci/hotplug/ibmphp_ebda.c | 5 +-
drivers/pci/of.c | 2 +-
drivers/pci/pci.c | 2 +-
drivers/pci/quirks.c | 58 ++++++++++++++-
drivers/s390/char/sclp_early.c | 3 +-
drivers/vhost/net.c | 11 ++-
drivers/video/backlight/ktd253-backlight.c | 75 ++++++++++++++------
drivers/watchdog/watchdog_dev.c | 5 +-
fs/btrfs/disk-io.c | 45 ++++++------
fs/fuse/dev.c | 4 +-
fs/io_uring.c | 9 ++-
include/linux/memory_hotplug.h | 4 +-
include/linux/pci.h | 5 +-
include/linux/pci_ids.h | 3 +-
include/linux/phylink.h | 3 +
include/linux/sched.h | 1 +
include/linux/skbuff.h | 2 +-
include/uapi/linux/pkt_sched.h | 2 +
kernel/events/core.c | 2 +-
kernel/trace/trace_boot.c | 15 ++--
kernel/trace/trace_kprobe.c | 6 +-
kernel/trace/trace_probe.c | 25 +++++++
kernel/trace/trace_probe.h | 1 +
kernel/trace/trace_uprobe.c | 6 +-
mm/memory_hotplug.c | 4 +-
net/caif/chnl_net.c | 19 +----
net/dccp/minisocks.c | 2 +
net/dsa/slave.c | 12 ++--
net/dsa/tag_rtl4_a.c | 7 +-
net/ethtool/ioctl.c | 2 +-
net/ipv4/ip_gre.c | 9 ++-
net/ipv4/nexthop.c | 2 +
net/ipv4/tcp_input.c | 2 +-
net/ipv4/udp_tunnel_nic.c | 2 +-
net/ipv6/netfilter/nf_socket_ipv6.c | 4 +-
net/l2tp/l2tp_core.c | 4 +-
net/netfilter/nf_conntrack_proto_dccp.c | 1 +
net/netfilter/nf_tables_api.c | 1 +
net/netfilter/nft_ct.c | 10 ++-
net/sched/sch_fq_codel.c | 12 +++-
net/tipc/socket.c | 10 +--
net/unix/af_unix.c | 2 +-
scripts/clang-tools/gen_compile_commands.py | 1 +
tools/perf/Makefile.config | 8 +--
tools/perf/bench/inject-buildid.c | 52 ++++++++------
tools/perf/util/machine.c | 1 +
tools/testing/selftests/net/altnames.sh | 2 +-
tools/testing/selftests/net/mptcp/simult_flows.sh | 4 +-
124 files changed, 950 insertions(+), 394 deletions(-)



2021-09-21 02:47:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 009/122] drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10

From: Ernst Sjöstrand <[email protected]>

commit 67a44e659888569a133a8f858c8230e9d7aad1d5 upstream.

Seems like newer cards can have even more instances now.
Found by UBSAN: array-index-out-of-bounds in
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:318:29
index 8 is out of range for type 'uint32_t *[8]'

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1697
Cc: [email protected]
Signed-off-by: Ernst Sjöstrand <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -717,7 +717,7 @@ enum amd_hw_ip_block_type {
MAX_HWIP
};

-#define HWIP_MAX_INSTANCE 8
+#define HWIP_MAX_INSTANCE 10

struct amd_powerplay {
void *pp_handle;


2021-09-21 02:47:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 014/122] drm/etnaviv: exec and MMU state is lost when resetting the GPU

From: Lucas Stach <[email protected]>

commit 725cbc7884c37f3b4f1777bc1aea6432cded8ca5 upstream.

When the GPU is reset both the current exec state, as well as all MMU
state is lost. Move the driver side state tracking into the reset function
to keep hardware and software state from diverging.

Cc: [email protected] # 5.4
Signed-off-by: Lucas Stach <[email protected]>
Tested-by: Michael Walle <[email protected]>
Tested-by: Marek Vasut <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -562,6 +562,8 @@ static int etnaviv_hw_reset(struct etnav
etnaviv_gpu_update_clock(gpu);

gpu->fe_running = false;
+ gpu->exec_state = -1;
+ gpu->mmu_context = NULL;

return 0;
}
@@ -818,7 +820,6 @@ int etnaviv_gpu_init(struct etnaviv_gpu
/* Now program the hardware */
mutex_lock(&gpu->lock);
etnaviv_gpu_hw_init(gpu);
- gpu->exec_state = -1;
mutex_unlock(&gpu->lock);

pm_runtime_mark_last_busy(gpu->dev);
@@ -1043,8 +1044,6 @@ void etnaviv_gpu_recover_hang(struct etn
spin_unlock(&gpu->event_spinlock);

etnaviv_gpu_hw_init(gpu);
- gpu->exec_state = -1;
- gpu->mmu_context = NULL;

mutex_unlock(&gpu->lock);
pm_runtime_mark_last_busy(gpu->dev);


2021-09-21 02:47:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 018/122] s390/sclp: fix Secure-IPL facility detection

From: Alexander Egorenkov <[email protected]>

commit d76b14f3971a0638b6cd0da289f8b48acee287d0 upstream.

Prevent out-of-range access if the returned SCLP SCCB response is smaller
in size than the address of the Secure-IPL flag.

Fixes: c9896acc7851 ("s390/ipl: Provide has_secure sysfs attribute")
Cc: [email protected] # 5.2+
Signed-off-by: Alexander Egorenkov <[email protected]>
Reviewed-by: Christian Borntraeger <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/s390/char/sclp_early.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/s390/char/sclp_early.c
+++ b/drivers/s390/char/sclp_early.c
@@ -40,13 +40,14 @@ static void __init sclp_early_facilities
sclp.has_gisaf = !!(sccb->fac118 & 0x08);
sclp.has_hvs = !!(sccb->fac119 & 0x80);
sclp.has_kss = !!(sccb->fac98 & 0x01);
- sclp.has_sipl = !!(sccb->cbl & 0x4000);
if (sccb->fac85 & 0x02)
S390_lowcore.machine_flags |= MACHINE_FLAG_ESOP;
if (sccb->fac91 & 0x40)
S390_lowcore.machine_flags |= MACHINE_FLAG_TLB_GUEST;
if (sccb->cpuoff > 134)
sclp.has_diag318 = !!(sccb->byte_134 & 0x80);
+ if (sccb->cpuoff > 137)
+ sclp.has_sipl = !!(sccb->cbl & 0x4000);
sclp.rnmax = sccb->rnmax ? sccb->rnmax : sccb->rnmax2;
sclp.rzm = sccb->rnsize ? sccb->rnsize : sccb->rnsize2;
sclp.rzm <<= 20;


2021-09-21 02:47:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 033/122] net/mlx5: Fix potential sleeping in atomic context

From: Maor Gottlieb <[email protected]>

commit ee27e330a953595903979ffdb84926843595a9fe upstream.

Fixes the below flow of sleeping in atomic context by releasing
the RCU lock before calling to free_match_list.

build_match_list() <- disables preempt
-> free_match_list()
-> tree_put_node()
-> down_write_ref_node() <- take write lock

Fixes: 693c6883bbc4 ("net/mlx5: Add hash table for flow groups in flow table")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Maor Gottlieb <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1675,14 +1675,13 @@ static int build_match_list(struct match

curr_match = kmalloc(sizeof(*curr_match), GFP_ATOMIC);
if (!curr_match) {
+ rcu_read_unlock();
free_match_list(match_head, ft_locked);
- err = -ENOMEM;
- goto out;
+ return -ENOMEM;
}
curr_match->g = g;
list_add_tail(&curr_match->list, &match_head->list);
}
-out:
rcu_read_unlock();
return err;
}


2021-09-21 02:47:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 013/122] drm/etnaviv: keep MMU context across runtime suspend/resume

From: Lucas Stach <[email protected]>

commit 8f3eea9d01d7b0f95b0fe04187c0059019ada85b upstream.

The MMU state may be kept across a runtime suspend/resume cycle, as we
avoid a full hardware reset to keep the latency of the runtime PM small.

Don't pretend that the MMU state is lost in driver state. The MMU
context is pushed out when new HW jobs with a different context are
coming in. The only exception to this is when the GPU is unbound, in
which case we need to make sure to also free the last active context.

Cc: [email protected] # 5.4
Reported-by: Michael Walle <[email protected]>
Signed-off-by: Lucas Stach <[email protected]>
Tested-by: Michael Walle <[email protected]>
Tested-by: Marek Vasut <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1578,9 +1578,6 @@ static int etnaviv_gpu_hw_suspend(struct
*/
etnaviv_gpu_wait_idle(gpu, 100);

- etnaviv_iommu_context_put(gpu->mmu_context);
- gpu->mmu_context = NULL;
-
gpu->fe_running = false;
}

@@ -1729,6 +1726,9 @@ static void etnaviv_gpu_unbind(struct de
etnaviv_gpu_hw_suspend(gpu);
#endif

+ if (gpu->mmu_context)
+ etnaviv_iommu_context_put(gpu->mmu_context);
+
if (gpu->initialized) {
etnaviv_cmdbuf_free(&gpu->buffer);
etnaviv_iommu_global_fini(gpu);


2021-09-21 02:47:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 045/122] udp_tunnel: Fix udp_tunnel_nic work-queue type

From: Aya Levin <[email protected]>

commit e50e711351bdc656a8e6ca1022b4293cae8dcd59 upstream.

Turn udp_tunnel_nic work-queue to an ordered work-queue. This queue
holds the UDP-tunnel configuration commands of the different netdevs.
When the netdevs are functions of the same NIC the order of
execution may be crucial.

Problem example:
NIC with 2 PFs, both PFs declare offload quota of up to 3 UDP-ports.
$ifconfig eth2 1.1.1.1/16 up

$ip link add eth2_19503 type vxlan id 5049 remote 1.1.1.2 dev eth2 dstport 19053
$ip link set dev eth2_19503 up

$ip link add eth2_19504 type vxlan id 5049 remote 1.1.1.3 dev eth2 dstport 19054
$ip link set dev eth2_19504 up

$ip link add eth2_19505 type vxlan id 5049 remote 1.1.1.4 dev eth2 dstport 19055
$ip link set dev eth2_19505 up

$ip link add eth2_19506 type vxlan id 5049 remote 1.1.1.5 dev eth2 dstport 19056
$ip link set dev eth2_19506 up

NIC RX port offload infrastructure offloads the first 3 UDP-ports (on
all devices which sets NETIF_F_RX_UDP_TUNNEL_PORT feature) and not
UDP-port 19056. So both PFs gets this offload configuration.

$ip link set dev eth2_19504 down

This triggers udp-tunnel-core to remove the UDP-port 19504 from
offload-ports-list and offload UDP-port 19056 instead.

In this scenario it is important that the UDP-port of 19504 will be
removed from both PFs before trying to add UDP-port 19056. The NIC can
stop offloading a UDP-port only when all references are removed.
Otherwise the NIC may report exceeding of the offload quota.

Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure")
Signed-off-by: Aya Levin <[email protected]>
Reviewed-by: Tariq Toukan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/udp_tunnel_nic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv4/udp_tunnel_nic.c
+++ b/net/ipv4/udp_tunnel_nic.c
@@ -935,7 +935,7 @@ static int __init udp_tunnel_nic_init_mo
{
int err;

- udp_tunnel_nic_workqueue = alloc_workqueue("udp_tunnel_nic", 0, 0);
+ udp_tunnel_nic_workqueue = alloc_ordered_workqueue("udp_tunnel_nic", 0);
if (!udp_tunnel_nic_workqueue)
return -ENOMEM;



2021-09-21 02:47:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 044/122] qed: Handle management FW error

From: Shai Malin <[email protected]>

commit 20e100f52730cd0db609e559799c1712b5f27582 upstream.

Handle MFW (management FW) error response in order to avoid a crash
during recovery flows.

Changes from v1:
- Add "Fixes tag".

Fixes: tag 5e7ba042fd05 ("qed: Fix reading stale configuration information")
Signed-off-by: Ariel Elior <[email protected]>
Signed-off-by: Shai Malin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -3376,6 +3376,7 @@ qed_mcp_get_nvm_image_att(struct qed_hwf
struct qed_nvm_image_att *p_image_att)
{
enum nvm_image_type type;
+ int rc;
u32 i;

/* Translate image_id into MFW definitions */
@@ -3404,7 +3405,10 @@ qed_mcp_get_nvm_image_att(struct qed_hwf
return -EINVAL;
}

- qed_mcp_nvm_info_populate(p_hwfn);
+ rc = qed_mcp_nvm_info_populate(p_hwfn);
+ if (rc)
+ return rc;
+
for (i = 0; i < p_hwfn->nvm_info.num_images; i++)
if (type == p_hwfn->nvm_info.image_att[i].image_type)
break;


2021-09-21 02:48:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 004/122] xen: reset legacy rtc flag for PV domU

From: Juergen Gross <[email protected]>

commit f68aa100d815b5b4467fd1c3abbe3b99d65fd028 upstream.

A Xen PV guest doesn't have a legacy RTC device, so reset the legacy
RTC flag. Otherwise the following WARN splat will occur at boot:

[ 1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210
[ 1.333404] Modules linked in:
[ 1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0-rc7-default+ #282
[ 1.333404] RIP: e030:mc146818_get_time+0x1be/0x210
[ 1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff
[ 1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002
[ 1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000
[ 1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d
[ 1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000
[ 1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200
[ 1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4
[ 1.333404] FS: 0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000
[ 1.333404] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660
[ 1.333404] Call Trace:
[ 1.333404] ? wakeup_sources_sysfs_init+0x30/0x30
[ 1.333404] ? rdinit_setup+0x2b/0x2b
[ 1.333404] early_resume_init+0x23/0xa4
[ 1.333404] ? cn_proc_init+0x36/0x36
[ 1.333404] do_one_initcall+0x3e/0x200
[ 1.333404] kernel_init_freeable+0x232/0x28e
[ 1.333404] ? rest_init+0xd0/0xd0
[ 1.333404] kernel_init+0x16/0x120
[ 1.333404] ret_from_fork+0x1f/0x30

Cc: <[email protected]>
Fixes: 8d152e7a5c7537 ("x86/rtc: Replace paravirt rtc check with platform legacy quirk")
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/xen/enlighten_pv.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1204,6 +1204,11 @@ static void __init xen_dom0_set_legacy_f
x86_platform.legacy.rtc = 1;
}

+static void __init xen_domu_set_legacy_features(void)
+{
+ x86_platform.legacy.rtc = 0;
+}
+
/* First C function to be called on Xen boot */
asmlinkage __visible void __init xen_start_kernel(void)
{
@@ -1356,6 +1361,8 @@ asmlinkage __visible void __init xen_sta
add_preferred_console("xenboot", 0, NULL);
if (pci_xen)
x86_init.pci.arch_init = pci_xen_init;
+ x86_platform.set_legacy_features =
+ xen_domu_set_legacy_features;
} else {
const struct dom0_vga_console_info *info =
(void *)((char *)xen_start_info +


2021-09-21 02:48:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 008/122] PCI: Add AMD GPU multi-function power dependencies

From: Evan Quan <[email protected]>

commit 60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a upstream.

Some AMD GPUs have built-in USB xHCI and USB Type-C UCSI controllers with
power dependencies between the GPU and the other functions as in
6d2e369f0d4c ("PCI: Add NVIDIA GPU multi-function power dependencies").

Add device link support for the AMD integrated USB xHCI and USB Type-C UCSI
controllers.

Without this, runtime power management, including GPU resume and temp and
fan sensors don't work correctly.

Reported-at: https://gitlab.freedesktop.org/drm/amd/-/issues/1704
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Evan Quan <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/quirks.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5346,7 +5346,7 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR
PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);

/*
- * Create device link for NVIDIA GPU with integrated USB xHCI Host
+ * Create device link for GPUs with integrated USB xHCI Host
* controller to VGA.
*/
static void quirk_gpu_usb(struct pci_dev *usb)
@@ -5355,9 +5355,11 @@ static void quirk_gpu_usb(struct pci_dev
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
PCI_CLASS_SERIAL_USB, 8, quirk_gpu_usb);
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
+ PCI_CLASS_SERIAL_USB, 8, quirk_gpu_usb);

/*
- * Create device link for NVIDIA GPU with integrated Type-C UCSI controller
+ * Create device link for GPUs with integrated Type-C UCSI controller
* to VGA. Currently there is no class code defined for UCSI device over PCI
* so using UNKNOWN class for now and it will be updated when UCSI
* over PCI gets a class code.
@@ -5370,6 +5372,9 @@ static void quirk_gpu_usb_typec_ucsi(str
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
PCI_CLASS_SERIAL_UNKNOWN, 8,
quirk_gpu_usb_typec_ucsi);
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
+ PCI_CLASS_SERIAL_UNKNOWN, 8,
+ quirk_gpu_usb_typec_ucsi);

/*
* Enable the NVIDIA GPU integrated HDA controller if the BIOS left it


2021-09-21 02:48:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 034/122] nvme-tcp: fix io_work priority inversion

From: Keith Busch <[email protected]>

commit 70f437fb4395ad4d1d16fab9a1ad9fbc9fc0579b upstream.

Dispatching requests inline with the .queue_rq() call may block while
holding the send_mutex. If the tcp io_work also happens to schedule, it
may see the req_list is non-empty, leaving "pending" true and remaining
in TASK_RUNNING. Since io_work is of higher scheduling priority, the
.queue_rq task may not get a chance to run, blocking forward progress
and leading to io timeouts.

Instead of checking for pending requests within io_work, let the queueing
restart io_work outside the send_mutex lock if there is more work to be
done.

Fixes: a0fdd1418007f ("nvme-tcp: rerun io_work if req_list is not empty")
Reported-by: Samuel Jones <[email protected]>
Signed-off-by: Keith Busch <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nvme/host/tcp.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)

--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -273,6 +273,12 @@ static inline void nvme_tcp_send_all(str
} while (ret > 0);
}

+static inline bool nvme_tcp_queue_more(struct nvme_tcp_queue *queue)
+{
+ return !list_empty(&queue->send_list) ||
+ !llist_empty(&queue->req_list) || queue->more_requests;
+}
+
static inline void nvme_tcp_queue_request(struct nvme_tcp_request *req,
bool sync, bool last)
{
@@ -293,9 +299,10 @@ static inline void nvme_tcp_queue_reques
nvme_tcp_send_all(queue);
queue->more_requests = false;
mutex_unlock(&queue->send_mutex);
- } else if (last) {
- queue_work_on(queue->io_cpu, nvme_tcp_wq, &queue->io_work);
}
+
+ if (last && nvme_tcp_queue_more(queue))
+ queue_work_on(queue->io_cpu, nvme_tcp_wq, &queue->io_work);
}

static void nvme_tcp_process_req_list(struct nvme_tcp_queue *queue)
@@ -890,12 +897,6 @@ done:
read_unlock_bh(&sk->sk_callback_lock);
}

-static inline bool nvme_tcp_queue_more(struct nvme_tcp_queue *queue)
-{
- return !list_empty(&queue->send_list) ||
- !llist_empty(&queue->req_list) || queue->more_requests;
-}
-
static inline void nvme_tcp_done_send_req(struct nvme_tcp_queue *queue)
{
queue->request = NULL;
@@ -1132,8 +1133,7 @@ static void nvme_tcp_io_work(struct work
pending = true;
else if (unlikely(result < 0))
break;
- } else
- pending = !llist_empty(&queue->req_list);
+ }

result = nvme_tcp_try_recv(queue);
if (result > 0)


2021-09-21 02:48:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 007/122] PM: base: power: dont try to use non-existing RTC for storing data

From: Juergen Gross <[email protected]>

commit 0560204b360a332c321124dbc5cdfd3364533a74 upstream.

If there is no legacy RTC device, don't try to use it for storing trace
data across suspend/resume.

Cc: <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/base/power/trace.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/base/power/trace.c
+++ b/drivers/base/power/trace.c
@@ -13,6 +13,7 @@
#include <linux/export.h>
#include <linux/rtc.h>
#include <linux/suspend.h>
+#include <linux/init.h>

#include <linux/mc146818rtc.h>

@@ -165,6 +166,9 @@ void generate_pm_trace(const void *trace
const char *file = *(const char **)(tracedata + 2);
unsigned int user_hash_value, file_hash_value;

+ if (!x86_platform.legacy.rtc)
+ return;
+
user_hash_value = user % USERHASH;
file_hash_value = hash_string(lineno, file, FILEHASH);
set_magic_time(user_hash_value, file_hash_value, dev_hash_value);
@@ -267,6 +271,9 @@ static struct notifier_block pm_trace_nb

static int __init early_resume_init(void)
{
+ if (!x86_platform.legacy.rtc)
+ return 0;
+
hash_value_early_read = read_magic_time();
register_pm_notifier(&pm_trace_nb);
return 0;
@@ -277,6 +284,9 @@ static int __init late_resume_init(void)
unsigned int val = hash_value_early_read;
unsigned int user, file, dev;

+ if (!x86_platform.legacy.rtc)
+ return 0;
+
user = val % USERHASH;
val = val / USERHASH;
file = val % FILEHASH;


2021-09-21 02:48:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 037/122] gen_compile_commands: fix missing sys package

From: Kortan <[email protected]>

commit ec783c7cb2495c5a3b8ca10db8056d43c528f940 upstream.

We need to import the 'sys' package since the script has called
sys.exit() method.

Fixes: 6ad7cbc01527 ("Makefile: Add clang-tidy and static analyzer support to makefile")
Signed-off-by: Kortan <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
scripts/clang-tools/gen_compile_commands.py | 1 +
1 file changed, 1 insertion(+)

--- a/scripts/clang-tools/gen_compile_commands.py
+++ b/scripts/clang-tools/gen_compile_commands.py
@@ -13,6 +13,7 @@ import logging
import os
import re
import subprocess
+import sys

_DEFAULT_OUTPUT = 'compile_commands.json'
_DEFAULT_LOG_LEVEL = 'WARNING'


2021-09-21 02:48:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 036/122] net: ipa: initialize all filter table slots

From: Alex Elder <[email protected]>

commit b5c102238cea985d8126b173d06b9e1de88037ee upstream.

There is an off-by-one problem in ipa_table_init_add(), when
initializing filter tables.

In that function, the number of filter table entries is determined
based on the number of set bits in the filter map. However that
count does *not* include the extra "slot" in the filter table that
holds the filter map itself. Meanwhile, ipa_table_addr() *does*
include the filter map in the memory it returns, but because the
count it's provided doesn't include it, it includes one too few
table entries.

Fix this by including the extra slot for the filter map in the count
computed in ipa_table_init_add().

Note: ipa_filter_reset_table() does not have this problem; it resets
filter table entries one by one, but does not overwrite the filter
bitmap.

Fixes: 2b9feef2b6c2 ("soc: qcom: ipa: filter and routing tables")
Signed-off-by: Alex Elder <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ipa/ipa_table.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ipa/ipa_table.c
+++ b/drivers/net/ipa/ipa_table.c
@@ -451,7 +451,8 @@ static void ipa_table_init_add(struct gs
* table region determines the number of entries it has.
*/
if (filter) {
- count = hweight32(ipa->filter_map);
+ /* Include one extra "slot" to hold the filter map itself */
+ count = 1 + hweight32(ipa->filter_map);
hash_count = hash_mem->size ? count : 0;
} else {
count = mem->size / IPA_TABLE_ENTRY_SIZE;


2021-09-21 02:48:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 086/122] KVM: arm64: Restrict IPA size to maximum 48 bits on 4K and 16K page size

From: Anshuman Khandual <[email protected]>

[ Upstream commit 5e5df9571c319fb107d7a523cc96fcc99961ee70 ]

Even though ID_AA64MMFR0.PARANGE reports 52 bit PA size support, it cannot
be enabled as guest IPA size on 4K or 16K page size configurations. Hence
kvm_ipa_limit must be restricted to 48 bits. This change achieves required
IPA capping.

Before the commit c9b69a0cf0b4 ("KVM: arm64: Don't constrain maximum IPA
size based on host configuration"), the problem here would have been just
latent via PHYS_MASK_SHIFT (which earlier in turn capped kvm_ipa_limit),
which remains capped at 48 bits on 4K and 16K configs.

Cc: Marc Zyngier <[email protected]>
Cc: James Morse <[email protected]>
Cc: Alexandru Elisei <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: c9b69a0cf0b4 ("KVM: arm64: Don't constrain maximum IPA size based on host configuration")
Signed-off-by: Anshuman Khandual <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm64/kvm/reset.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index b969c2157ad2..6058a80ec9ec 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -366,6 +366,14 @@ int kvm_set_ipa_limit(void)
mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
parange = cpuid_feature_extract_unsigned_field(mmfr0,
ID_AA64MMFR0_PARANGE_SHIFT);
+ /*
+ * IPA size beyond 48 bits could not be supported
+ * on either 4K or 16K page size. Hence let's cap
+ * it to 48 bits, in case it's reported as larger
+ * on the system.
+ */
+ if (PAGE_SIZE != SZ_64K)
+ parange = min(parange, (unsigned int)ID_AA64MMFR0_PARANGE_48);

/*
* Check with ARMv8.5-GTG that our PAGE_SIZE is supported at
--
2.30.2



2021-09-21 02:48:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 019/122] x86/pat: Pass valid address to sanitize_phys()

From: Jeff Moyer <[email protected]>

commit aeef8b5089b76852bd84889f2809e69a7cfb414e upstream.

The end address passed to memtype_reserve() is handed directly to
sanitize_phys(). However, end is exclusive and sanitize_phys() expects
an inclusive address. If end falls at the end of the physical address
space, sanitize_phys() will return 0. This can result in drivers
failing to load, and the following warning:

WARNING: CPU: 26 PID: 749 at arch/x86/mm/pat.c:354 reserve_memtype+0x262/0x450
reserve_memtype failed: [mem 0x3ffffff00000-0xffffffffffffffff], req uncached-minus
Call Trace:
[<ffffffffa427b1f2>] reserve_memtype+0x262/0x450
[<ffffffffa42764aa>] ioremap_nocache+0x1a/0x20
[<ffffffffc04620a1>] mpt3sas_base_map_resources+0x151/0xa60 [mpt3sas]
[<ffffffffc0465555>] mpt3sas_base_attach+0xf5/0xa50 [mpt3sas]
---[ end trace 6d6eea4438db89ef ]---
ioremap reserve_memtype failed -22
mpt3sas_cm0: unable to map adapter memory! or resource not found
mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10597/_scsih_probe()!

Fix this by passing the inclusive end address to sanitize_phys().

Fixes: 510ee090abc3 ("x86/mm/pat: Prepare {reserve, free}_memtype() for "decoy" addresses")
Signed-off-by: Jeff Moyer <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/mm/pat/memtype.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -583,7 +583,12 @@ int memtype_reserve(u64 start, u64 end,
int err = 0;

start = sanitize_phys(start);
- end = sanitize_phys(end);
+
+ /*
+ * The end address passed into this function is exclusive, but
+ * sanitize_phys() expects an inclusive address.
+ */
+ end = sanitize_phys(end - 1) + 1;
if (start >= end) {
WARN(1, "%s failed: [mem %#010Lx-%#010Lx], req %s\n", __func__,
start, end - 1, cattr_name(req_type));


2021-09-21 02:48:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 080/122] mfd: axp20x: Update AXP288 volatile ranges

From: Hans de Goede <[email protected]>

[ Upstream commit f949a9ebce7a18005266b859a17f10c891bb13d7 ]

On Cherry Trail devices with an AXP288 PMIC the external SD-card slot
used the AXP's DLDO2 as card-voltage and either DLDO3 or GPIO1LDO
(GPIO1 pin in low noise LDO mode) as signal-voltage.

These regulators are turned on/off and in case of the signal-voltage
also have their output-voltage changed by the _PS0 and _PS3 power-
management ACPI methods on the MMC-controllers ACPI fwnode as well as
by the _DSM ACPI method for changing the signal voltage.

The AML code implementing these methods is directly accessing the
PMIC through ACPI I2C OpRegion accesses, instead of using the special
PMIC OpRegion handled by drivers/acpi/pmic/intel_pmic_xpower.c .

This means that the contents of the involved PMIC registers can change
without the change being made through the regmap interface, so regmap
should not cache the contents of these registers.

Mark the regulator power on/off, the regulator voltage control and the
GPIO1 control registers as volatile, to avoid regmap caching them.

Specifically this fixes an issue on some models where the i915 driver
toggles another LDO using the same on/off register on/off through
MIPI sequences (through intel_soc_pmic_exec_mipi_pmic_seq_element())
which then writes back a cached on/off register-value where the
card-voltage is off causing the external sdcard slot to stop working
when the screen goes blank, or comes back on again.

The regulator register-range now marked volatile also includes the
buck regulator control registers. This is done on purpose these are
normally not touched by the AML code, but they are updated directly
by the SoC's PUNIT which means that they may also change without going
through regmap.

Note the AXP288 PMIC is only used on Bay- and Cherry-Trail platforms,
so even though this is an ACPI specific problem there is no need to
make the new volatile ranges conditional since these platforms always
use ACPI.

Fixes: dc91c3b6fe66 ("mfd: axp20x: Mark AXP20X_VBUS_IPSOUT_MGMT as volatile")
Fixes: cd53216625a0 ("mfd: axp20x: Fix axp288 volatile ranges")
Reported-and-tested-by: Clamshell <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mfd/axp20x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index aa59496e4376..9db1000944c3 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -125,12 +125,13 @@ static const struct regmap_range axp288_writeable_ranges[] = {

static const struct regmap_range axp288_volatile_ranges[] = {
regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP288_POWER_REASON),
+ regmap_reg_range(AXP22X_PWR_OUT_CTRL1, AXP22X_ALDO3_V_OUT),
regmap_reg_range(AXP288_BC_GLOBAL, AXP288_BC_GLOBAL),
regmap_reg_range(AXP288_BC_DET_STAT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_CHRG_BAK_CTRL, AXP20X_CHRG_BAK_CTRL),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IPSOUT_V_HIGH_L),
regmap_reg_range(AXP20X_TIMER_CTRL, AXP20X_TIMER_CTRL),
- regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
+ regmap_reg_range(AXP20X_GPIO1_CTRL, AXP22X_GPIO_STATE),
regmap_reg_range(AXP288_RT_BATT_V_H, AXP288_RT_BATT_V_L),
regmap_reg_range(AXP20X_FG_RES, AXP288_FG_CC_CAP_REG),
};
--
2.30.2



2021-09-21 02:48:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 077/122] NTB: Fix an error code in ntb_msit_probe()

From: Yang Li <[email protected]>

[ Upstream commit 319f83ac98d7afaabab84ce5281a819a358b9895 ]

When the value of nm->isr_ctx is false, the value of ret is 0.
So, we set ret to -ENOMEM to indicate this error.

Clean up smatch warning:
drivers/ntb/test/ntb_msi_test.c:373 ntb_msit_probe() warn: missing
error code 'ret'.

Reported-by: Abaci Robot <[email protected]>
Signed-off-by: Yang Li <[email protected]>
Reviewed-by: Logan Gunthorpe <[email protected]>
Signed-off-by: Jon Mason <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/ntb/test/ntb_msi_test.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/ntb/test/ntb_msi_test.c b/drivers/ntb/test/ntb_msi_test.c
index 7095ecd6223a..4e18e08776c9 100644
--- a/drivers/ntb/test/ntb_msi_test.c
+++ b/drivers/ntb/test/ntb_msi_test.c
@@ -369,8 +369,10 @@ static int ntb_msit_probe(struct ntb_client *client, struct ntb_dev *ntb)
if (ret)
goto remove_dbgfs;

- if (!nm->isr_ctx)
+ if (!nm->isr_ctx) {
+ ret = -ENOMEM;
goto remove_dbgfs;
+ }

ntb_link_enable(ntb, NTB_SPEED_AUTO, NTB_WIDTH_AUTO);

--
2.30.2



2021-09-21 02:48:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 060/122] PCI: tegra194: Fix MSI-X programming

From: Om Prakash Singh <[email protected]>

[ Upstream commit 43537cf7e351264a1f05ed42ad402942bfc9140e ]

Lower order MSI-X address is programmed in MSIX_ADDR_MATCH_HIGH_OFF
DBI register instead of higher order address. This patch fixes this
programming mistake.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Om Prakash Singh <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Bjorn Helgaas <[email protected]>
Acked-by: Vidya Sagar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/controller/dwc/pcie-tegra194.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index c2827a8d208f..a5b677ec0769 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1778,7 +1778,7 @@ static void pex_ep_event_pex_rst_deassert(struct tegra_pcie_dw *pcie)
val = (ep->msi_mem_phys & MSIX_ADDR_MATCH_LOW_OFF_MASK);
val |= MSIX_ADDR_MATCH_LOW_OFF_EN;
dw_pcie_writel_dbi(pci, MSIX_ADDR_MATCH_LOW_OFF, val);
- val = (lower_32_bits(ep->msi_mem_phys) & MSIX_ADDR_MATCH_HIGH_OFF_MASK);
+ val = (upper_32_bits(ep->msi_mem_phys) & MSIX_ADDR_MATCH_HIGH_OFF_MASK);
dw_pcie_writel_dbi(pci, MSIX_ADDR_MATCH_HIGH_OFF, val);

ret = dw_pcie_ep_init_complete(ep);
--
2.30.2



2021-09-21 02:48:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 043/122] selftest: net: fix typo in altname test

From: Andrea Claudi <[email protected]>

commit 1b704b27beb11ce147d64b21c914e57afbfb5656 upstream.

If altname deletion of the short alternative name fails, the error
message printed is: "Failed to add short alternative name".
This is obviously a typo, as we are testing altname deletion.

Fix this using a proper error message.

Fixes: f95e6c9c4617 ("selftest: net: add alternative names test")
Signed-off-by: Andrea Claudi <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/net/altnames.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/testing/selftests/net/altnames.sh
+++ b/tools/testing/selftests/net/altnames.sh
@@ -45,7 +45,7 @@ altnames_test()
check_err $? "Got unexpected long alternative name from link show JSON"

ip link property del $DUMMY_DEV altname $SHORT_NAME
- check_err $? "Failed to add short alternative name"
+ check_err $? "Failed to delete short alternative name"

ip -j -p link show $SHORT_NAME &>/dev/null
check_fail $? "Unexpected success while trying to do link show with deleted short alternative name"


2021-09-21 02:48:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 042/122] tcp: fix tp->undo_retrans accounting in tcp_sacktag_one()

From: zhenggy <[email protected]>

commit 4f884f3962767877d7aabbc1ec124d2c307a4257 upstream.

Commit 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit
time") may directly retrans a multiple segments TSO/GSO packet without
split, Since this commit, we can no longer assume that a retransmitted
packet is a single segment.

This patch fixes the tp->undo_retrans accounting in tcp_sacktag_one()
that use the actual segments(pcount) of the retransmitted packet.

Before that commit (10d3be569243), the assumption underlying the
tp->undo_retrans-- seems correct.

Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time")
Signed-off-by: zhenggy <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Acked-by: Yuchung Cheng <[email protected]>
Acked-by: Neal Cardwell <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1314,7 +1314,7 @@ static u8 tcp_sacktag_one(struct sock *s
if (dup_sack && (sacked & TCPCB_RETRANS)) {
if (tp->undo_marker && tp->undo_retrans > 0 &&
after(end_seq, tp->undo_marker))
- tp->undo_retrans--;
+ tp->undo_retrans = max_t(int, 0, tp->undo_retrans - pcount);
if ((sacked & TCPCB_SACKED_ACKED) &&
before(start_seq, state->reord))
state->reord = start_seq;


2021-09-21 02:48:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 022/122] ethtool: Fix rxnfc copy to user buffer overflow

From: Saeed Mahameed <[email protected]>

commit 9b29a161ef38040f000dcf9ccf78e34495edfd55 upstream.

In the cited commit, copy_to_user() got called with the wrong pointer,
instead of passing the actual buffer ptr to copy from, a pointer to
the pointer got passed, which causes a buffer overflow calltrace to pop
up when executing "ethtool -x ethX".

Fix ethtool_rxnfc_copy_to_user() to use the rxnfc pointer as passed
to the function, instead of a pointer to it.

This fixes below call trace:
[ 15.533533] ------------[ cut here ]------------
[ 15.539007] Buffer overflow detected (8 < 192)!
[ 15.544110] WARNING: CPU: 3 PID: 1801 at include/linux/thread_info.h:200 copy_overflow+0x15/0x20
[ 15.549308] Modules linked in:
[ 15.551449] CPU: 3 PID: 1801 Comm: ethtool Not tainted 5.14.0-rc2+ #1058
[ 15.553919] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 15.558378] RIP: 0010:copy_overflow+0x15/0x20
[ 15.560648] Code: e9 7c ff ff ff b8 a1 ff ff ff eb c4 66 0f 1f 84 00 00 00 00 00 55 48 89 f2 89 fe 48 c7 c7 88 55 78 8a 48 89 e5 e8 06 5c 1e 00 <0f> 0b 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55
[ 15.565114] RSP: 0018:ffffad49c0523bd0 EFLAGS: 00010286
[ 15.566231] RAX: 0000000000000000 RBX: 00000000000000c0 RCX: 0000000000000000
[ 15.567616] RDX: 0000000000000001 RSI: ffffffff8a7912e7 RDI: 00000000ffffffff
[ 15.569050] RBP: ffffad49c0523bd0 R08: ffffffff8ab2ae28 R09: 00000000ffffdfff
[ 15.570534] R10: ffffffff8aa4ae40 R11: ffffffff8aa4ae40 R12: 0000000000000000
[ 15.571899] R13: 00007ffd4cc2a230 R14: ffffad49c0523c00 R15: 0000000000000000
[ 15.573584] FS: 00007f538112f740(0000) GS:ffff96d5bdd80000(0000) knlGS:0000000000000000
[ 15.575639] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 15.577092] CR2: 00007f5381226d40 CR3: 0000000013542000 CR4: 00000000001506e0
[ 15.578929] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 15.580695] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 15.582441] Call Trace:
[ 15.582970] ethtool_rxnfc_copy_to_user+0x30/0x46
[ 15.583815] ethtool_get_rxnfc.cold+0x23/0x2b
[ 15.584584] dev_ethtool+0x29c/0x25f0
[ 15.585286] ? security_netlbl_sid_to_secattr+0x77/0xd0
[ 15.586728] ? do_set_pte+0xc4/0x110
[ 15.587349] ? _raw_spin_unlock+0x18/0x30
[ 15.588118] ? __might_sleep+0x49/0x80
[ 15.588956] dev_ioctl+0x2c1/0x490
[ 15.589616] sock_ioctl+0x18e/0x330
[ 15.591143] __x64_sys_ioctl+0x41c/0x990
[ 15.591823] ? irqentry_exit_to_user_mode+0x9/0x20
[ 15.592657] ? irqentry_exit+0x33/0x40
[ 15.593308] ? exc_page_fault+0x32f/0x770
[ 15.593877] ? exit_to_user_mode_prepare+0x3c/0x130
[ 15.594775] do_syscall_64+0x35/0x80
[ 15.595397] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 15.596037] RIP: 0033:0x7f5381226d4b
[ 15.596492] Code: 0f 1e fa 48 8b 05 3d b1 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 0d b1 0c 00 f7 d8 64 89 01 48
[ 15.598743] RSP: 002b:00007ffd4cc2a1f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 15.599804] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5381226d4b
[ 15.600795] RDX: 00007ffd4cc2a350 RSI: 0000000000008946 RDI: 0000000000000003
[ 15.601712] RBP: 00007ffd4cc2a340 R08: 00007ffd4cc2a350 R09: 0000000000000001
[ 15.602751] R10: 00007f538128a990 R11: 0000000000000246 R12: 0000000000000000
[ 15.603882] R13: 00007ffd4cc2a350 R14: 00007ffd4cc2a4b0 R15: 0000000000000000
[ 15.605042] ---[ end trace 325cf185e2795048 ]---

Fixes: dd98d2895de6 ("ethtool: improve compat ioctl handling")
Reported-by: Shannon Nelson <[email protected]>
CC: Arnd Bergmann <[email protected]>
CC: Christoph Hellwig <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Tested-by: Shannon Nelson <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ethtool/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -906,7 +906,7 @@ static int ethtool_rxnfc_copy_to_user(vo
rule_buf);
useraddr += offsetof(struct compat_ethtool_rxnfc, rule_locs);
} else {
- ret = copy_to_user(useraddr, &rxnfc, size);
+ ret = copy_to_user(useraddr, rxnfc, size);
useraddr += offsetof(struct ethtool_rxnfc, rule_locs);
}



2021-09-21 02:48:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 056/122] mfd: db8500-prcmu: Adjust map to reality

From: Linus Walleij <[email protected]>

[ Upstream commit ec343111c056ec3847800302f6dbc57281f833fa ]

These are the actual frequencies reported by the PLL, so let's
report these. The roundoffs are inappropriate, we should round
to the frequency that the clock will later report.

Drop some whitespace at the same time.

Cc: [email protected]
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mfd/db8500-prcmu.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index a5983d515db0..8d5f8f07d8a6 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -1622,22 +1622,20 @@ static long round_clock_rate(u8 clock, unsigned long rate)
}

static const unsigned long db8500_armss_freqs[] = {
- 200000000,
- 400000000,
- 800000000,
+ 199680000,
+ 399360000,
+ 798720000,
998400000
};

/* The DB8520 has slightly higher ARMSS max frequency */
static const unsigned long db8520_armss_freqs[] = {
- 200000000,
- 400000000,
- 800000000,
+ 199680000,
+ 399360000,
+ 798720000,
1152000000
};

-
-
static long round_armss_rate(unsigned long rate)
{
unsigned long freq = 0;
--
2.30.2



2021-09-21 02:48:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 005/122] bnx2x: Fix enabling network interfaces without VFs

From: Adrian Bunk <[email protected]>

commit 52ce14c134a003fee03d8fc57442c05a55b53715 upstream.

This function is called to enable SR-IOV when available,
not enabling interfaces without VFs was a regression.

Fixes: 65161c35554f ("bnx2x: Fix missing error code in bnx2x_iov_init_one()")
Signed-off-by: Adrian Bunk <[email protected]>
Reported-by: YunQiang Su <[email protected]>
Tested-by: YunQiang Su <[email protected]>
Cc: [email protected]
Acked-by: Shai Malin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -1225,7 +1225,7 @@ int bnx2x_iov_init_one(struct bnx2x *bp,

/* SR-IOV capability was enabled but there are no VFs*/
if (iov->total == 0) {
- err = -EINVAL;
+ err = 0;
goto failed;
}



2021-09-21 02:48:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 059/122] PCI: tegra194: Fix handling BME_CHGED event

From: Om Prakash Singh <[email protected]>

[ Upstream commit ceb1412c1c8ca5b28c4252bdb15f2f1f17b4a1b0 ]

In tegra_pcie_ep_hard_irq(), APPL_INTR_STATUS_L0 is stored in val and again
APPL_INTR_STATUS_L1_0_0 is also stored in val. So when execution reaches
"if (val & APPL_INTR_STATUS_L0_PCI_CMD_EN_INT)", val is not correct.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Om Prakash Singh <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Bjorn Helgaas <[email protected]>
Acked-by: Vidya Sagar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/controller/dwc/pcie-tegra194.c | 30 +++++++++++-----------
1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index 506f6a294eac..c2827a8d208f 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -515,19 +515,19 @@ static irqreturn_t tegra_pcie_ep_hard_irq(int irq, void *arg)
struct tegra_pcie_dw *pcie = arg;
struct dw_pcie_ep *ep = &pcie->pci.ep;
int spurious = 1;
- u32 val, tmp;
+ u32 status_l0, status_l1, link_status;

- val = appl_readl(pcie, APPL_INTR_STATUS_L0);
- if (val & APPL_INTR_STATUS_L0_LINK_STATE_INT) {
- val = appl_readl(pcie, APPL_INTR_STATUS_L1_0_0);
- appl_writel(pcie, val, APPL_INTR_STATUS_L1_0_0);
+ status_l0 = appl_readl(pcie, APPL_INTR_STATUS_L0);
+ if (status_l0 & APPL_INTR_STATUS_L0_LINK_STATE_INT) {
+ status_l1 = appl_readl(pcie, APPL_INTR_STATUS_L1_0_0);
+ appl_writel(pcie, status_l1, APPL_INTR_STATUS_L1_0_0);

- if (val & APPL_INTR_STATUS_L1_0_0_HOT_RESET_DONE)
+ if (status_l1 & APPL_INTR_STATUS_L1_0_0_HOT_RESET_DONE)
pex_ep_event_hot_rst_done(pcie);

- if (val & APPL_INTR_STATUS_L1_0_0_RDLH_LINK_UP_CHGED) {
- tmp = appl_readl(pcie, APPL_LINK_STATUS);
- if (tmp & APPL_LINK_STATUS_RDLH_LINK_UP) {
+ if (status_l1 & APPL_INTR_STATUS_L1_0_0_RDLH_LINK_UP_CHGED) {
+ link_status = appl_readl(pcie, APPL_LINK_STATUS);
+ if (link_status & APPL_LINK_STATUS_RDLH_LINK_UP) {
dev_dbg(pcie->dev, "Link is up with Host\n");
dw_pcie_ep_linkup(ep);
}
@@ -536,11 +536,11 @@ static irqreturn_t tegra_pcie_ep_hard_irq(int irq, void *arg)
spurious = 0;
}

- if (val & APPL_INTR_STATUS_L0_PCI_CMD_EN_INT) {
- val = appl_readl(pcie, APPL_INTR_STATUS_L1_15);
- appl_writel(pcie, val, APPL_INTR_STATUS_L1_15);
+ if (status_l0 & APPL_INTR_STATUS_L0_PCI_CMD_EN_INT) {
+ status_l1 = appl_readl(pcie, APPL_INTR_STATUS_L1_15);
+ appl_writel(pcie, status_l1, APPL_INTR_STATUS_L1_15);

- if (val & APPL_INTR_STATUS_L1_15_CFG_BME_CHGED)
+ if (status_l1 & APPL_INTR_STATUS_L1_15_CFG_BME_CHGED)
return IRQ_WAKE_THREAD;

spurious = 0;
@@ -548,8 +548,8 @@ static irqreturn_t tegra_pcie_ep_hard_irq(int irq, void *arg)

if (spurious) {
dev_warn(pcie->dev, "Random interrupt (STATUS = 0x%08X)\n",
- val);
- appl_writel(pcie, val, APPL_INTR_STATUS_L0);
+ status_l0);
+ appl_writel(pcie, status_l0, APPL_INTR_STATUS_L0);
}

return IRQ_HANDLED;
--
2.30.2



2021-09-21 02:48:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 091/122] mtd: mtdconcat: Check _read, _write callbacks existence before assignment

From: Zhihao Cheng <[email protected]>

[ Upstream commit a89d69a44e282be95ae76125dddc79515541efeb ]

Since 2431c4f5b46c3 ("mtd: Implement mtd_{read,write}() as wrappers
around mtd_{read,write}_oob()") don't allow _write|_read and
_write_oob|_read_oob existing at the same time, we should check the
existence of callbacks "_read and _write" from subdev's master device
(We can trust master device since it has been registered) before
assigning, otherwise following warning occurs while making
concatenated device:

WARNING: CPU: 2 PID: 6728 at drivers/mtd/mtdcore.c:595
add_mtd_device+0x7f/0x7b0

Fixes: 2431c4f5b46c3 ("mtd: Implement mtd_{read,write}() around ...")
Signed-off-by: Zhihao Cheng <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mtd/mtdconcat.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index af51eee6b5e8..f685a581df48 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -694,6 +694,10 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[], /* subdevices to c
concat->mtd._block_markbad = concat_block_markbad;
if (subdev_master->_panic_write)
concat->mtd._panic_write = concat_panic_write;
+ if (subdev_master->_read)
+ concat->mtd._read = concat_read;
+ if (subdev_master->_write)
+ concat->mtd._write = concat_write;

concat->mtd.ecc_stats.badblocks = subdev[0]->ecc_stats.badblocks;

@@ -755,8 +759,6 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[], /* subdevices to c
concat->mtd.name = name;

concat->mtd._erase = concat_erase;
- concat->mtd._read = concat_read;
- concat->mtd._write = concat_write;
concat->mtd._sync = concat_sync;
concat->mtd._lock = concat_lock;
concat->mtd._unlock = concat_unlock;
--
2.30.2



2021-09-21 02:48:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 023/122] net/{mlx5|nfp|bnxt}: Remove unnecessary RTNL lock assert

From: Eli Cohen <[email protected]>

commit 7c3a0a018e672a9723a79b128227272562300055 upstream.

Remove the assert from the callback priv lookup function since it does
not require RTNL lock and is already protected by flow_indr_block_lock.

This will avoid warnings from being emitted to dmesg if the driver
registers its callback after an ingress qdisc was created for a
netdevice.

The warnings started after the following patch was merged:
commit 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation")

Signed-off-by: Eli Cohen <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 3 ---
drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c | 3 ---
drivers/net/ethernet/netronome/nfp/flower/offload.c | 3 ---
3 files changed, 9 deletions(-)

--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c
@@ -1870,9 +1870,6 @@ bnxt_tc_indr_block_cb_lookup(struct bnxt
{
struct bnxt_flower_indr_block_cb_priv *cb_priv;

- /* All callback list access should be protected by RTNL. */
- ASSERT_RTNL();
-
list_for_each_entry(cb_priv, &bp->tc_indr_block_list, list)
if (cb_priv->tunnel_netdev == netdev)
return cb_priv;
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c
@@ -298,9 +298,6 @@ mlx5e_rep_indr_block_priv_lookup(struct
{
struct mlx5e_rep_indr_block_priv *cb_priv;

- /* All callback list access should be protected by RTNL. */
- ASSERT_RTNL();
-
list_for_each_entry(cb_priv,
&rpriv->uplink_priv.tc_indr_block_priv_list,
list)
--- a/drivers/net/ethernet/netronome/nfp/flower/offload.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c
@@ -1732,9 +1732,6 @@ nfp_flower_indr_block_cb_priv_lookup(str
struct nfp_flower_indr_block_cb_priv *cb_priv;
struct nfp_flower_priv *priv = app->priv;

- /* All callback list access should be protected by RTNL. */
- ASSERT_RTNL();
-
list_for_each_entry(cb_priv, &priv->indr_block_cb_priv, list)
if (cb_priv->netdev == netdev)
return cb_priv;


2021-09-21 02:48:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 083/122] PCI: iproc: Fix BCMA probe resource handling

From: Rob Herring <[email protected]>

[ Upstream commit aeaea8969b402e0081210cc9144404d13996efed ]

In commit 7ef1c871da16 ("PCI: iproc: Use
pci_parse_request_of_pci_ranges()"), calling
devm_request_pci_bus_resources() was dropped from the common iProc
probe code, but is still needed for BCMA bus probing. Without it, there
will be lots of warnings like this:

pci 0000:00:00.0: BAR 8: no space for [mem size 0x00c00000]
pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00c00000]

Add back calling devm_request_pci_bus_resources() and adding the
resources to pci_host_bridge.windows for BCMA bus probe.

Link: https://lore.kernel.org/r/[email protected]
Fixes: 7ef1c871da16 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()")
Reported-by: Rafał Miłecki <[email protected]>
Tested-by: Rafał Miłecki <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Cc: Srinath Mannam <[email protected]>
Cc: Roman Bacik <[email protected]>
Cc: Bharat Gooty <[email protected]>
Cc: Abhishek Shah <[email protected]>
Cc: Jitendra Bhivare <[email protected]>
Cc: Ray Jui <[email protected]>
Cc: Florian Fainelli <[email protected]>
Cc: BCM Kernel Feedback <[email protected]>
Cc: Scott Branden <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: "Krzysztof Wilczyński" <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/controller/pcie-iproc-bcma.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc-bcma.c b/drivers/pci/controller/pcie-iproc-bcma.c
index 56b8ee7bf330..f918c713afb0 100644
--- a/drivers/pci/controller/pcie-iproc-bcma.c
+++ b/drivers/pci/controller/pcie-iproc-bcma.c
@@ -35,7 +35,6 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
{
struct device *dev = &bdev->dev;
struct iproc_pcie *pcie;
- LIST_HEAD(resources);
struct pci_host_bridge *bridge;
int ret;

@@ -60,19 +59,16 @@ static int iproc_pcie_bcma_probe(struct bcma_device *bdev)
pcie->mem.end = bdev->addr_s[0] + SZ_128M - 1;
pcie->mem.name = "PCIe MEM space";
pcie->mem.flags = IORESOURCE_MEM;
- pci_add_resource(&resources, &pcie->mem);
+ pci_add_resource(&bridge->windows, &pcie->mem);
+ ret = devm_request_pci_bus_resources(dev, &bridge->windows);
+ if (ret)
+ return ret;

pcie->map_irq = iproc_pcie_bcma_map_irq;

- ret = iproc_pcie_setup(pcie, &resources);
- if (ret) {
- dev_err(dev, "PCIe controller setup failed\n");
- pci_free_resource_list(&resources);
- return ret;
- }
-
bcma_set_drvdata(bdev, pcie);
- return 0;
+
+ return iproc_pcie_setup(pcie, &bridge->windows);
}

static void iproc_pcie_bcma_remove(struct bcma_device *bdev)
--
2.30.2



2021-09-21 02:48:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 031/122] perf machine: Initialize srcline string member in add_location struct

From: Michael Petlan <[email protected]>

commit 57f0ff059e3daa4e70a811cb1d31a49968262d20 upstream.

It's later supposed to be either a correct address or NULL. Without the
initialization, it may contain an undefined value which results in the
following segmentation fault:

# perf top --sort comm -g --ignore-callees=do_idle

terminates with:

#0 0x00007ffff56b7685 in __strlen_avx2 () from /lib64/libc.so.6
#1 0x00007ffff55e3802 in strdup () from /lib64/libc.so.6
#2 0x00005555558cb139 in hist_entry__init (callchain_size=<optimized out>, sample_self=true, template=0x7fffde7fb110, he=0x7fffd801c250) at util/hist.c:489
#3 hist_entry__new (template=template@entry=0x7fffde7fb110, sample_self=sample_self@entry=true) at util/hist.c:564
#4 0x00005555558cb4ba in hists__findnew_entry (hists=hists@entry=0x5555561d9e38, entry=entry@entry=0x7fffde7fb110, al=al@entry=0x7fffde7fb420,
sample_self=sample_self@entry=true) at util/hist.c:657
#5 0x00005555558cba1b in __hists__add_entry (hists=hists@entry=0x5555561d9e38, al=0x7fffde7fb420, sym_parent=<optimized out>, bi=bi@entry=0x0, mi=mi@entry=0x0,
sample=sample@entry=0x7fffde7fb4b0, sample_self=true, ops=0x0, block_info=0x0) at util/hist.c:288
#6 0x00005555558cbb70 in hists__add_entry (sample_self=true, sample=0x7fffde7fb4b0, mi=0x0, bi=0x0, sym_parent=<optimized out>, al=<optimized out>, hists=0x5555561d9e38)
at util/hist.c:1056
#7 iter_add_single_cumulative_entry (iter=0x7fffde7fb460, al=<optimized out>) at util/hist.c:1056
#8 0x00005555558cc8a4 in hist_entry_iter__add (iter=iter@entry=0x7fffde7fb460, al=al@entry=0x7fffde7fb420, max_stack_depth=<optimized out>, arg=arg@entry=0x7fffffff7db0)
at util/hist.c:1231
#9 0x00005555557cdc9a in perf_event__process_sample (machine=<optimized out>, sample=0x7fffde7fb4b0, evsel=<optimized out>, event=<optimized out>, tool=0x7fffffff7db0)
at builtin-top.c:842
#10 deliver_event (qe=<optimized out>, qevent=<optimized out>) at builtin-top.c:1202
#11 0x00005555558a9318 in do_flush (show_progress=false, oe=0x7fffffff80e0) at util/ordered-events.c:244
#12 __ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP, timestamp=timestamp@entry=0) at util/ordered-events.c:323
#13 0x00005555558a9789 in __ordered_events__flush (timestamp=<optimized out>, how=<optimized out>, oe=<optimized out>) at util/ordered-events.c:339
#14 ordered_events__flush (how=OE_FLUSH__TOP, oe=0x7fffffff80e0) at util/ordered-events.c:341
#15 ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP) at util/ordered-events.c:339
#16 0x00005555557cd631 in process_thread (arg=0x7fffffff7db0) at builtin-top.c:1114
#17 0x00007ffff7bb817a in start_thread () from /lib64/libpthread.so.0
#18 0x00007ffff5656dc3 in clone () from /lib64/libc.so.6

If you look at the frame #2, the code is:

488 if (he->srcline) {
489 he->srcline = strdup(he->srcline);
490 if (he->srcline == NULL)
491 goto err_rawdata;
492 }

If he->srcline is not NULL (it is not NULL if it is uninitialized rubbish),
it gets strdupped and strdupping a rubbish random string causes the problem.

Also, if you look at the commit 1fb7d06a509e, it adds the srcline property
into the struct, but not initializing it everywhere needed.

Committer notes:

Now I see, when using --ignore-callees=do_idle we end up here at line
2189 in add_callchain_ip():

2181 if (al.sym != NULL) {
2182 if (perf_hpp_list.parent && !*parent &&
2183 symbol__match_regex(al.sym, &parent_regex))
2184 *parent = al.sym;
2185 else if (have_ignore_callees && root_al &&
2186 symbol__match_regex(al.sym, &ignore_callees_regex)) {
2187 /* Treat this symbol as the root,
2188 forgetting its callees. */
2189 *root_al = al;
2190 callchain_cursor_reset(cursor);
2191 }
2192 }

And the al that doesn't have the ->srcline field initialized will be
copied to the root_al, so then, back to:

1211 int hist_entry_iter__add(struct hist_entry_iter *iter, struct addr_location *al,
1212 int max_stack_depth, void *arg)
1213 {
1214 int err, err2;
1215 struct map *alm = NULL;
1216
1217 if (al)
1218 alm = map__get(al->map);
1219
1220 err = sample__resolve_callchain(iter->sample, &callchain_cursor, &iter->parent,
1221 iter->evsel, al, max_stack_depth);
1222 if (err) {
1223 map__put(alm);
1224 return err;
1225 }
1226
1227 err = iter->ops->prepare_entry(iter, al);
1228 if (err)
1229 goto out;
1230
1231 err = iter->ops->add_single_entry(iter, al);
1232 if (err)
1233 goto out;
1234

That al at line 1221 is what hist_entry_iter__add() (called from
sample__resolve_callchain()) saw as 'root_al', and then:

iter->ops->add_single_entry(iter, al);

will go on with al->srcline with a bogus value, I'll add the above
sequence to the cset and apply, thanks!

Signed-off-by: Michael Petlan <[email protected]>
CC: Milian Wolff <[email protected]>
Cc: Jiri Olsa <[email protected]>
Fixes: 1fb7d06a509e ("perf report Use srcline from callchain for hist entries")
Link: https //lore.kernel.org/r/[email protected]
Reported-by: Juri Lelli <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/perf/util/machine.c | 1 +
1 file changed, 1 insertion(+)

--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2100,6 +2100,7 @@ static int add_callchain_ip(struct threa

al.filtered = 0;
al.sym = NULL;
+ al.srcline = NULL;
if (!cpumode) {
thread__find_cpumode_addr_location(thread, ip, &al);
} else {


2021-09-21 02:48:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 081/122] backlight: ktd253: Stabilize backlight

From: Linus Walleij <[email protected]>

[ Upstream commit daa37361518bf2d1f591bbdaa7c68b2a43d7af48 ]

Remove interrupt disablement during backlight setting. It is
way to dangerous and makes platforms instable by having it
miss vblank IRQs leading to the graphics derailing.

The code is using ndelay() which is not available on
platforms such as ARM and will result in 32 * udelay(1)
which is substantial.

Add some code to detect if an interrupt occurs during the
tight loop and in that case just redo it from the top.

Fixes: 5317f37e48b9 ("backlight: Add Kinetic KTD253 backlight driver")
Cc: Stephan Gerhold <[email protected]>
Reported-by: [email protected]
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/video/backlight/ktd253-backlight.c | 75 ++++++++++++++++------
1 file changed, 55 insertions(+), 20 deletions(-)

diff --git a/drivers/video/backlight/ktd253-backlight.c b/drivers/video/backlight/ktd253-backlight.c
index e3fee3f1f582..9d355fd989d8 100644
--- a/drivers/video/backlight/ktd253-backlight.c
+++ b/drivers/video/backlight/ktd253-backlight.c
@@ -25,6 +25,7 @@

#define KTD253_T_LOW_NS (200 + 10) /* Additional 10ns as safety factor */
#define KTD253_T_HIGH_NS (200 + 10) /* Additional 10ns as safety factor */
+#define KTD253_T_OFF_CRIT_NS 100000 /* 100 us, now it doesn't look good */
#define KTD253_T_OFF_MS 3

struct ktd253_backlight {
@@ -34,13 +35,50 @@ struct ktd253_backlight {
u16 ratio;
};

+static void ktd253_backlight_set_max_ratio(struct ktd253_backlight *ktd253)
+{
+ gpiod_set_value_cansleep(ktd253->gpiod, 1);
+ ndelay(KTD253_T_HIGH_NS);
+ /* We always fall back to this when we power on */
+}
+
+static int ktd253_backlight_stepdown(struct ktd253_backlight *ktd253)
+{
+ /*
+ * These GPIO operations absolutely can NOT sleep so no _cansleep
+ * suffixes, and no using GPIO expanders on slow buses for this!
+ *
+ * The maximum number of cycles of the loop is 32 so the time taken
+ * should nominally be:
+ * (T_LOW_NS + T_HIGH_NS + loop_time) * 32
+ *
+ * Architectures do not always support ndelay() and we will get a few us
+ * instead. If we get to a critical time limit an interrupt has likely
+ * occured in the low part of the loop and we need to restart from the
+ * top so we have the backlight in a known state.
+ */
+ u64 ns;
+
+ ns = ktime_get_ns();
+ gpiod_set_value(ktd253->gpiod, 0);
+ ndelay(KTD253_T_LOW_NS);
+ gpiod_set_value(ktd253->gpiod, 1);
+ ns = ktime_get_ns() - ns;
+ if (ns >= KTD253_T_OFF_CRIT_NS) {
+ dev_err(ktd253->dev, "PCM on backlight took too long (%llu ns)\n", ns);
+ return -EAGAIN;
+ }
+ ndelay(KTD253_T_HIGH_NS);
+ return 0;
+}
+
static int ktd253_backlight_update_status(struct backlight_device *bl)
{
struct ktd253_backlight *ktd253 = bl_get_data(bl);
int brightness = backlight_get_brightness(bl);
u16 target_ratio;
u16 current_ratio = ktd253->ratio;
- unsigned long flags;
+ int ret;

dev_dbg(ktd253->dev, "new brightness/ratio: %d/32\n", brightness);

@@ -62,37 +100,34 @@ static int ktd253_backlight_update_status(struct backlight_device *bl)
}

if (current_ratio == 0) {
- gpiod_set_value_cansleep(ktd253->gpiod, 1);
- ndelay(KTD253_T_HIGH_NS);
- /* We always fall back to this when we power on */
+ ktd253_backlight_set_max_ratio(ktd253);
current_ratio = KTD253_MAX_RATIO;
}

- /*
- * WARNING:
- * The loop to set the correct current level is performed
- * with interrupts disabled as it is timing critical.
- * The maximum number of cycles of the loop is 32
- * so the time taken will be (T_LOW_NS + T_HIGH_NS + loop_time) * 32,
- */
- local_irq_save(flags);
while (current_ratio != target_ratio) {
/*
* These GPIO operations absolutely can NOT sleep so no
* _cansleep suffixes, and no using GPIO expanders on
* slow buses for this!
*/
- gpiod_set_value(ktd253->gpiod, 0);
- ndelay(KTD253_T_LOW_NS);
- gpiod_set_value(ktd253->gpiod, 1);
- ndelay(KTD253_T_HIGH_NS);
- /* After 1/32 we loop back to 32/32 */
- if (current_ratio == KTD253_MIN_RATIO)
+ ret = ktd253_backlight_stepdown(ktd253);
+ if (ret == -EAGAIN) {
+ /*
+ * Something disturbed the backlight setting code when
+ * running so we need to bring the PWM back to a known
+ * state. This shouldn't happen too much.
+ */
+ gpiod_set_value_cansleep(ktd253->gpiod, 0);
+ msleep(KTD253_T_OFF_MS);
+ ktd253_backlight_set_max_ratio(ktd253);
+ current_ratio = KTD253_MAX_RATIO;
+ } else if (current_ratio == KTD253_MIN_RATIO) {
+ /* After 1/32 we loop back to 32/32 */
current_ratio = KTD253_MAX_RATIO;
- else
+ } else {
current_ratio--;
+ }
}
- local_irq_restore(flags);
ktd253->ratio = current_ratio;

dev_dbg(ktd253->dev, "new ratio set to %d/32\n", target_ratio);
--
2.30.2



2021-09-21 02:48:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 084/122] netfilter: Fix fall-through warnings for Clang

From: Gustavo A. R. Silva <[email protected]>

[ Upstream commit c2168e6bd7ec50cedb69b3be1ba6146e28893c69 ]

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Acked-by: Florian Westphal <[email protected]>
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/netfilter/nf_conntrack_proto_dccp.c | 1 +
net/netfilter/nf_tables_api.c | 1 +
net/netfilter/nft_ct.c | 1 +
3 files changed, 3 insertions(+)

diff --git a/net/netfilter/nf_conntrack_proto_dccp.c b/net/netfilter/nf_conntrack_proto_dccp.c
index b3f4a334f9d7..94001eb51ffe 100644
--- a/net/netfilter/nf_conntrack_proto_dccp.c
+++ b/net/netfilter/nf_conntrack_proto_dccp.c
@@ -397,6 +397,7 @@ dccp_new(struct nf_conn *ct, const struct sk_buff *skb,
msg = "not picking up existing connection ";
goto out_invalid;
}
+ break;
case CT_DCCP_REQUEST:
break;
case CT_DCCP_INVALID:
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 2b5f97e1d40b..c605a3e713e7 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -8394,6 +8394,7 @@ static int nf_tables_check_loops(const struct nft_ctx *ctx,
data->verdict.chain);
if (err < 0)
return err;
+ break;
default:
break;
}
diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c
index 70d46e0bbf06..7af822a02ce9 100644
--- a/net/netfilter/nft_ct.c
+++ b/net/netfilter/nft_ct.c
@@ -528,6 +528,7 @@ static void __nft_ct_set_destroy(const struct nft_ctx *ctx, struct nft_ct *priv)
case NFT_CT_ZONE:
if (--nft_ct_pcpu_template_refcnt == 0)
nft_ct_tmpl_put_pcpu();
+ break;
#endif
default:
break;
--
2.30.2



2021-09-21 02:49:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 104/122] net: hso: add failure handler for add_net_device

From: Ziyang Xuan <[email protected]>

[ Upstream commit ecdc28defc46af476566fffd9e5cb4495a2f176e ]

If the network devices connected to the system beyond
HSO_MAX_NET_DEVICES. add_net_device() in hso_create_net_device()
will be failed for the network_table is full. It will lead to
business failure which rely on network_table, for example,
hso_suspend() and hso_resume(). It will also lead to memory leak
because resource release process can not search the hso_device
object from network_table in hso_free_interface().

Add failure handler for add_net_device() in hso_create_net_device()
to solve the above problems.

Fixes: 72dc1c096c70 ("HSO: add option hso driver")
Signed-off-by: Ziyang Xuan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/usb/hso.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 5b3aff2c279f..f269337c82c5 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2537,13 +2537,17 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,
if (!hso_net->mux_bulk_tx_buf)
goto err_free_tx_urb;

- add_net_device(hso_dev);
+ result = add_net_device(hso_dev);
+ if (result) {
+ dev_err(&interface->dev, "Failed to add net device\n");
+ goto err_free_tx_buf;
+ }

/* registering our net device */
result = register_netdev(net);
if (result) {
dev_err(&interface->dev, "Failed to register device\n");
- goto err_free_tx_buf;
+ goto err_rmv_ndev;
}

hso_log_port(hso_dev);
@@ -2552,8 +2556,9 @@ static struct hso_device *hso_create_net_device(struct usb_interface *interface,

return hso_dev;

-err_free_tx_buf:
+err_rmv_ndev:
remove_net_device(hso_dev);
+err_free_tx_buf:
kfree(hso_net->mux_bulk_tx_buf);
err_free_tx_urb:
usb_free_urb(hso_net->mux_bulk_tx_urb);
--
2.30.2



2021-09-21 02:49:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 095/122] mtd: rawnand: cafe: Fix a resource leak in the error handling path of cafe_nand_probe()

From: Christophe JAILLET <[email protected]>

[ Upstream commit 6b430c7595e4eb95fae8fb54adc3c3ce002e75ae ]

A successful 'init_rs_non_canonical()' call should be balanced by a
corresponding 'free_rs()' call in the error handling path of the probe, as
already done in the remove function.

Update the error handling path accordingly.

Fixes: 8c61b7a7f4d4 ("[MTD] [NAND] Use rslib for CAFÉ ECC")
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mtd/nand/raw/cafe_nand.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/cafe_nand.c b/drivers/mtd/nand/raw/cafe_nand.c
index 2b94f385a1a8..04502d22efc9 100644
--- a/drivers/mtd/nand/raw/cafe_nand.c
+++ b/drivers/mtd/nand/raw/cafe_nand.c
@@ -751,7 +751,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
"CAFE NAND", mtd);
if (err) {
dev_warn(&pdev->dev, "Could not register IRQ %d\n", pdev->irq);
- goto out_ior;
+ goto out_free_rs;
}

/* Disable master reset, enable NAND clock */
@@ -795,6 +795,8 @@ static int cafe_nand_probe(struct pci_dev *pdev,
/* Disable NAND IRQ in global IRQ mask register */
cafe_writel(cafe, ~1 & cafe_readl(cafe, GLOBAL_IRQ_MASK), GLOBAL_IRQ_MASK);
free_irq(pdev->irq, mtd);
+ out_free_rs:
+ free_rs(cafe->rs);
out_ior:
pci_iounmap(pdev, cafe->mmio);
out_free_mtd:
--
2.30.2



2021-09-21 02:49:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 069/122] PCI: Add ACS quirks for Cavium multi-function devices

From: George Cherian <[email protected]>

[ Upstream commit 32837d8a8f63eb95dcb9cd005524a27f06478832 ]

Some Cavium endpoints are implemented as multi-function devices without ACS
capability, but they actually don't support peer-to-peer transactions.

Add ACS quirks to declare DMA isolation for the following devices:

- BGX device found on Octeon-TX (8xxx)
- CGX device found on Octeon-TX2 (9xxx)
- RPM device found on Octeon-TX3 (10xxx)

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: George Cherian <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/quirks.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f2e95944f681..5d2acebc3e96 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4864,6 +4864,10 @@ static const struct pci_dev_acs_enabled {
{ 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
/* Cavium ThunderX */
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
+ /* Cavium multi-function devices */
+ { PCI_VENDOR_ID_CAVIUM, 0xA026, pci_quirk_mf_endpoint_acs },
+ { PCI_VENDOR_ID_CAVIUM, 0xA059, pci_quirk_mf_endpoint_acs },
+ { PCI_VENDOR_ID_CAVIUM, 0xA060, pci_quirk_mf_endpoint_acs },
/* APM X-Gene */
{ PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
/* Ampere Computing */
--
2.30.2



2021-09-21 02:49:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 078/122] NTB: perf: Fix an error code in perf_setup_inbuf()

From: Yang Li <[email protected]>

[ Upstream commit 0097ae5f7af5684f961a5f803ff7ad3e6f933668 ]

When the function IS_ALIGNED() returns false, the value of ret is 0.
So, we set ret to -EINVAL to indicate this error.

Clean up smatch warning:
drivers/ntb/test/ntb_perf.c:602 perf_setup_inbuf() warn: missing error
code 'ret'.

Reported-by: Abaci Robot <[email protected]>
Signed-off-by: Yang Li <[email protected]>
Reviewed-by: Serge Semin <[email protected]>
Signed-off-by: Jon Mason <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/ntb/test/ntb_perf.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index 89df1350fefd..65e1e5cf1b29 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -598,6 +598,7 @@ static int perf_setup_inbuf(struct perf_peer *peer)
return -ENOMEM;
}
if (!IS_ALIGNED(peer->inbuf_xlat, xlat_align)) {
+ ret = -EINVAL;
dev_err(&perf->ntb->dev, "Unaligned inbuf allocated\n");
goto err_free_inbuf;
}
--
2.30.2



2021-09-21 02:49:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 089/122] tracing/boot: Fix a hist trigger dependency for boot time tracing

From: Masami Hiramatsu <[email protected]>

[ Upstream commit 6fe7c745f2acb73e4cc961d7f91125eef5a8861f ]

Fixes a build error when CONFIG_HIST_TRIGGERS=n with boot-time
tracing. Since the trigger_process_regex() is defined only
when CONFIG_HIST_TRIGGERS=y, if it is disabled, the 'actions'
event option also must be disabled.

Link: https://lkml.kernel.org/r/162856123376.203126.582144262622247352.stgit@devnote2

Fixes: 81a59555ff15 ("tracing/boot: Add per-event settings")
Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/trace/trace_boot.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/kernel/trace/trace_boot.c b/kernel/trace/trace_boot.c
index a82f03f385f8..0996d59750ff 100644
--- a/kernel/trace/trace_boot.c
+++ b/kernel/trace/trace_boot.c
@@ -205,12 +205,15 @@ trace_boot_init_one_event(struct trace_array *tr, struct xbc_node *gnode,
pr_err("Failed to apply filter: %s\n", buf);
}

- xbc_node_for_each_array_value(enode, "actions", anode, p) {
- if (strlcpy(buf, p, ARRAY_SIZE(buf)) >= ARRAY_SIZE(buf))
- pr_err("action string is too long: %s\n", p);
- else if (trigger_process_regex(file, buf) < 0)
- pr_err("Failed to apply an action: %s\n", buf);
- }
+ if (IS_ENABLED(CONFIG_HIST_TRIGGERS)) {
+ xbc_node_for_each_array_value(enode, "actions", anode, p) {
+ if (strlcpy(buf, p, ARRAY_SIZE(buf)) >= ARRAY_SIZE(buf))
+ pr_err("action string is too long: %s\n", p);
+ else if (trigger_process_regex(file, buf) < 0)
+ pr_err("Failed to apply an action: %s\n", buf);
+ }
+ } else if (xbc_node_find_value(enode, "actions", NULL))
+ pr_err("Failed to apply event actions because CONFIG_HIST_TRIGGERS is not set.\n");

if (xbc_node_find_value(enode, "enable", NULL)) {
if (trace_event_enable_disable(file, 1, 0) < 0)
--
2.30.2



2021-09-21 02:49:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 001/122] drm/bridge: lt9611: Fix handling of 4k panels

From: Robert Foss <[email protected]>

commit d1a97648ae028a44536927c87837c45ada7141c9 upstream.

4k requires two dsi pipes, so don't report MODE_OK when only a
single pipe is configured. But rather report MODE_PANEL to
signal that requirements of the panel are not being met.

Reported-by: Peter Collingbourne <[email protected]>
Suggested-by: Peter Collingbourne <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Tested-by: John Stultz <[email protected]>
Tested-by: Anibal Limon <[email protected]>
Tested-by: Peter Collingbourne <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Cc: Peter Collingbourne <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -867,8 +867,14 @@ static enum drm_mode_status lt9611_bridg
const struct drm_display_mode *mode)
{
struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode);
+ struct lt9611 *lt9611 = bridge_to_lt9611(bridge);

- return lt9611_mode ? MODE_OK : MODE_BAD;
+ if (!lt9611_mode)
+ return MODE_BAD;
+ else if (lt9611_mode->intfs > 1 && !lt9611->dsi1)
+ return MODE_PANEL;
+ else
+ return MODE_OK;
}

static void lt9611_bridge_pre_enable(struct drm_bridge *bridge)


2021-09-21 02:49:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 010/122] drm/etnaviv: return context from etnaviv_iommu_context_get

From: Lucas Stach <[email protected]>

commit 78edefc05e41352099ffb8f06f8d9b2d091e29cd upstream.

Being able to have the refcount manipulation in an assignment makes
it much easier to parse the code.

Cc: [email protected] # 5.4
Signed-off-by: Lucas Stach <[email protected]>
Tested-by: Michael Walle <[email protected]>
Tested-by: Marek Vasut <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 4 +++-
5 files changed, 8 insertions(+), 11 deletions(-)

--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -397,8 +397,7 @@ void etnaviv_buffer_queue(struct etnaviv
if (switch_mmu_context) {
struct etnaviv_iommu_context *old_context = gpu->mmu_context;

- etnaviv_iommu_context_get(mmu_context);
- gpu->mmu_context = mmu_context;
+ gpu->mmu_context = etnaviv_iommu_context_get(mmu_context);
etnaviv_iommu_context_put(old_context);
}

--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -305,8 +305,7 @@ struct etnaviv_vram_mapping *etnaviv_gem
list_del(&mapping->obj_node);
}

- etnaviv_iommu_context_get(mmu_context);
- mapping->context = mmu_context;
+ mapping->context = etnaviv_iommu_context_get(mmu_context);
mapping->use = 1;

ret = etnaviv_iommu_map_gem(mmu_context, etnaviv_obj,
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -532,8 +532,7 @@ int etnaviv_ioctl_gem_submit(struct drm_
goto err_submit_objects;

submit->ctx = file->driver_priv;
- etnaviv_iommu_context_get(submit->ctx->mmu);
- submit->mmu_context = submit->ctx->mmu;
+ submit->mmu_context = etnaviv_iommu_context_get(submit->ctx->mmu);
submit->exec_state = args->exec_state;
submit->flags = args->flags;

--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1353,12 +1353,10 @@ struct dma_fence *etnaviv_gpu_submit(str
}

if (!gpu->mmu_context) {
- etnaviv_iommu_context_get(submit->mmu_context);
- gpu->mmu_context = submit->mmu_context;
+ gpu->mmu_context = etnaviv_iommu_context_get(submit->mmu_context);
etnaviv_gpu_start_fe_idleloop(gpu);
} else {
- etnaviv_iommu_context_get(gpu->mmu_context);
- submit->prev_mmu_context = gpu->mmu_context;
+ submit->prev_mmu_context = etnaviv_iommu_context_get(gpu->mmu_context);
}

if (submit->nr_pmrs) {
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
@@ -105,9 +105,11 @@ void etnaviv_iommu_dump(struct etnaviv_i
struct etnaviv_iommu_context *
etnaviv_iommu_context_init(struct etnaviv_iommu_global *global,
struct etnaviv_cmdbuf_suballoc *suballoc);
-static inline void etnaviv_iommu_context_get(struct etnaviv_iommu_context *ctx)
+static inline struct etnaviv_iommu_context *
+etnaviv_iommu_context_get(struct etnaviv_iommu_context *ctx)
{
kref_get(&ctx->refcount);
+ return ctx;
}
void etnaviv_iommu_context_put(struct etnaviv_iommu_context *ctx);
void etnaviv_iommu_restore(struct etnaviv_gpu *gpu,


2021-09-21 02:49:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 006/122] arm64/sve: Use correct size when reinitialising SVE state

From: Mark Brown <[email protected]>

commit e35ac9d0b56e9efefaeeb84b635ea26c2839ea86 upstream.

When we need a buffer for SVE register state we call sve_alloc() to make
sure that one is there. In order to avoid repeated allocations and frees
we keep the buffer around unless we change vector length and just memset()
it to ensure a clean register state. The function that deals with this
takes the task to operate on as an argument, however in the case where we
do a memset() we initialise using the SVE state size for the current task
rather than the task passed as an argument.

This is only an issue in the case where we are setting the register state
for a task via ptrace and the task being configured has a different vector
length to the task tracing it. In the case where the buffer is larger in
the traced process we will leak old state from the traced process to
itself, in the case where the buffer is smaller in the traced process we
will overflow the buffer and corrupt memory.

Fixes: bc0ee4760364 ("arm64/sve: Core task context handling")
Cc: <[email protected]> # 4.15.x
Signed-off-by: Mark Brown <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kernel/fpsimd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -510,7 +510,7 @@ size_t sve_state_size(struct task_struct
void sve_alloc(struct task_struct *task)
{
if (task->thread.sve_state) {
- memset(task->thread.sve_state, 0, sve_state_size(current));
+ memset(task->thread.sve_state, 0, sve_state_size(task));
return;
}



2021-09-21 02:49:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 038/122] vhost_net: fix OoB on sendmsg() failure.

From: Paolo Abeni <[email protected]>

commit 3c4cea8fa7f71f00c5279547043a84bc2a4d8b8c upstream.

If the sendmsg() call in vhost_tx_batch() fails, both the 'batched_xdp'
and 'done_idx' indexes are left unchanged. If such failure happens
when batched_xdp == VHOST_NET_BATCH, the next call to
vhost_net_build_xdp() will access and write memory outside the xdp
buffers area.

Since sendmsg() can only error with EBADFD, this change addresses the
issue explicitly freeing the XDP buffers batch on error.

Fixes: 0a0be13b8fe2 ("vhost_net: batch submitting XDP buffers to underlayer sockets")
Suggested-by: Jason Wang <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Acked-by: Jason Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/vhost/net.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -466,7 +466,7 @@ static void vhost_tx_batch(struct vhost_
.num = nvq->batched_xdp,
.ptr = nvq->xdp,
};
- int err;
+ int i, err;

if (nvq->batched_xdp == 0)
goto signal_used;
@@ -475,6 +475,15 @@ static void vhost_tx_batch(struct vhost_
err = sock->ops->sendmsg(sock, msghdr, 0);
if (unlikely(err < 0)) {
vq_err(&nvq->vq, "Fail to batch sending packets\n");
+
+ /* free pages owned by XDP; since this is an unlikely error path,
+ * keep it simple and avoid more complex bulk update for the
+ * used pages
+ */
+ for (i = 0; i < nvq->batched_xdp; ++i)
+ put_page(virt_to_head_page(nvq->xdp[i].data));
+ nvq->batched_xdp = 0;
+ nvq->done_idx = 0;
return;
}



2021-09-21 02:49:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 116/122] bnxt_en: Convert to use netif_level() helpers.

From: Michael Chan <[email protected]>

[ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ]

Use the various netif_level() helpers to simplify the C code. This was
suggested by Joe Perches.

Cc: Joe Perches <[email protected]>
Signed-off-by: Michael Chan <[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/broadcom/bnxt/bnxt.c | 34 ++++++++++-------------
1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 4ee77e1c8de0..563a169e06ca 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1305,8 +1305,7 @@ static void bnxt_tpa_start(struct bnxt *bp, struct bnxt_rx_ring_info *rxr,
} else {
tpa_info->hash_type = PKT_HASH_TYPE_NONE;
tpa_info->gso_type = 0;
- if (netif_msg_rx_err(bp))
- netdev_warn(bp->dev, "TPA packet without valid hash\n");
+ netif_warn(bp, rx_err, bp->dev, "TPA packet without valid hash\n");
}
tpa_info->flags2 = le32_to_cpu(tpa_start1->rx_tpa_start_cmp_flags2);
tpa_info->metadata = le32_to_cpu(tpa_start1->rx_tpa_start_cmp_metadata);
@@ -2099,12 +2098,11 @@ static int bnxt_async_event_process(struct bnxt *bp,
fatal_str = "fatal";
set_bit(BNXT_STATE_FW_FATAL_COND, &bp->state);
}
- if (netif_msg_hw(bp)) {
- netdev_warn(bp->dev, "Firmware %s reset event, data1: 0x%x, data2: 0x%x, min wait %u ms, max wait %u ms\n",
- fatal_str, data1, data2,
- bp->fw_reset_min_dsecs * 100,
- bp->fw_reset_max_dsecs * 100);
- }
+ netif_warn(bp, hw, bp->dev,
+ "Firmware %s reset event, data1: 0x%x, data2: 0x%x, min wait %u ms, max wait %u ms\n",
+ fatal_str, data1, data2,
+ bp->fw_reset_min_dsecs * 100,
+ bp->fw_reset_max_dsecs * 100);
set_bit(BNXT_FW_RESET_NOTIFY_SP_EVENT, &bp->sp_event);
break;
}
@@ -2119,13 +2117,11 @@ static int bnxt_async_event_process(struct bnxt *bp,
if (!fw_health->enabled)
break;

- if (netif_msg_drv(bp))
- netdev_info(bp->dev, "Error recovery info: error recovery[%d], master[%d], reset count[0x%x], health status: 0x%x\n",
- fw_health->enabled, fw_health->master,
- bnxt_fw_health_readl(bp,
- BNXT_FW_RESET_CNT_REG),
- bnxt_fw_health_readl(bp,
- BNXT_FW_HEALTH_REG));
+ netif_info(bp, drv, bp->dev,
+ "Error recovery info: error recovery[%d], master[%d], reset count[0x%x], health status: 0x%x\n",
+ fw_health->enabled, fw_health->master,
+ bnxt_fw_health_readl(bp, BNXT_FW_RESET_CNT_REG),
+ bnxt_fw_health_readl(bp, BNXT_FW_HEALTH_REG));
fw_health->tmr_multiplier =
DIV_ROUND_UP(fw_health->polling_dsecs * HZ,
bp->current_interval * 10);
@@ -2137,11 +2133,9 @@ static int bnxt_async_event_process(struct bnxt *bp,
goto async_event_process_exit;
}
case ASYNC_EVENT_CMPL_EVENT_ID_DEBUG_NOTIFICATION:
- if (netif_msg_hw(bp)) {
- netdev_notice(bp->dev,
- "Received firmware debug notification, data1: 0x%x, data2: 0x%x\n",
- data1, data2);
- }
+ netif_notice(bp, hw, bp->dev,
+ "Received firmware debug notification, data1: 0x%x, data2: 0x%x\n",
+ data1, data2);
goto async_event_process_exit;
case ASYNC_EVENT_CMPL_EVENT_ID_RING_MONITOR_MSG: {
struct bnxt_rx_ring_info *rxr;
--
2.30.2



2021-09-21 02:49:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 111/122] net: dsa: b53: Fix IMP port setup on BCM5301x

From: Rafał Miłecki <[email protected]>

[ Upstream commit 63f8428b4077de3664eb0b252393c839b0b293ec ]

Broadcom's b53 switches have one IMP (Inband Management Port) that needs
to be programmed using its own designed register. IMP port may be
different than CPU port - especially on devices with multiple CPU ports.

For that reason it's required to explicitly note IMP port index and
check for it when choosing a register to use.

This commit fixes BCM5301x support. Those switches use CPU port 5 while
their IMP port is 8. Before this patch b53 was trying to program port 5
with B53_PORT_OVERRIDE_CTRL instead of B53_GMII_PORT_OVERRIDE_CTRL(5).

It may be possible to also replace "cpu_port" usages with
dsa_is_cpu_port() but that is out of the scope of thix BCM5301x fix.

Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/dsa/b53/b53_common.c | 27 ++++++++++++++++++++++++---
drivers/net/dsa/b53/b53_priv.h | 1 +
2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 54558f47b633..d3b37cebcfde 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1083,7 +1083,7 @@ static void b53_force_link(struct b53_device *dev, int port, int link)
u8 reg, val, off;

/* Override the port settings */
- if (port == dev->cpu_port) {
+ if (port == dev->imp_port) {
off = B53_PORT_OVERRIDE_CTRL;
val = PORT_OVERRIDE_EN;
} else {
@@ -1107,7 +1107,7 @@ static void b53_force_port_config(struct b53_device *dev, int port,
u8 reg, val, off;

/* Override the port settings */
- if (port == dev->cpu_port) {
+ if (port == dev->imp_port) {
off = B53_PORT_OVERRIDE_CTRL;
val = PORT_OVERRIDE_EN;
} else {
@@ -1175,7 +1175,7 @@ static void b53_adjust_link(struct dsa_switch *ds, int port,
b53_force_link(dev, port, phydev->link);

if (is531x5(dev) && phy_interface_is_rgmii(phydev)) {
- if (port == 8)
+ if (port == dev->imp_port)
off = B53_RGMII_CTRL_IMP;
else
off = B53_RGMII_CTRL_P(port);
@@ -2238,6 +2238,7 @@ struct b53_chip_data {
const char *dev_name;
u16 vlans;
u16 enabled_ports;
+ u8 imp_port;
u8 cpu_port;
u8 vta_regs[3];
u8 arl_bins;
@@ -2262,6 +2263,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 2,
.arl_buckets = 1024,
+ .imp_port = 5,
.cpu_port = B53_CPU_PORT_25,
.duplex_reg = B53_DUPLEX_STAT_FE,
},
@@ -2272,6 +2274,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 2,
.arl_buckets = 1024,
+ .imp_port = 5,
.cpu_port = B53_CPU_PORT_25,
.duplex_reg = B53_DUPLEX_STAT_FE,
},
@@ -2282,6 +2285,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2295,6 +2299,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2308,6 +2313,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS_9798,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2321,6 +2327,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x7f,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS_9798,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2335,6 +2342,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.arl_bins = 4,
.arl_buckets = 1024,
.vta_regs = B53_VTA_REGS,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.duplex_reg = B53_DUPLEX_STAT_GE,
.jumbo_pm_reg = B53_JUMBO_PORT_MASK,
@@ -2347,6 +2355,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0xff,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2360,6 +2369,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1ff,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2373,6 +2383,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0, /* pdata must provide them */
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS_63XX,
.duplex_reg = B53_DUPLEX_STAT_63XX,
@@ -2386,6 +2397,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT_25, /* TODO: auto detect */
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2399,6 +2411,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1bf,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT_25, /* TODO: auto detect */
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2412,6 +2425,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1bf,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT_25, /* TODO: auto detect */
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2425,6 +2439,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT_25, /* TODO: auto detect */
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2438,6 +2453,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1f,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT_25, /* TODO: auto detect */
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2451,6 +2467,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1ff,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2464,6 +2481,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x103,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2477,6 +2495,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1ff,
.arl_bins = 4,
.arl_buckets = 1024,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2490,6 +2509,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.enabled_ports = 0x1ff,
.arl_bins = 4,
.arl_buckets = 256,
+ .imp_port = 8,
.cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
@@ -2515,6 +2535,7 @@ static int b53_switch_init(struct b53_device *dev)
dev->vta_regs[1] = chip->vta_regs[1];
dev->vta_regs[2] = chip->vta_regs[2];
dev->jumbo_pm_reg = chip->jumbo_pm_reg;
+ dev->imp_port = chip->imp_port;
dev->cpu_port = chip->cpu_port;
dev->num_vlans = chip->vlans;
dev->num_arl_bins = chip->arl_bins;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 7c67409bb186..bdb2ade7ad62 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -122,6 +122,7 @@ struct b53_device {

/* used ports mask */
u16 enabled_ports;
+ unsigned int imp_port;
unsigned int cpu_port;

/* connect specific data */
--
2.30.2



2021-09-21 02:49:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 011/122] drm/etnaviv: put submit prev MMU context when it exists

From: Lucas Stach <[email protected]>

commit cda7532916f7bc860b36a1806cb8352e6f63dacb upstream.

The prev context is the MMU context at the time of the job
queueing in hardware. As a job might be queued multiple times
due to recovery after a GPU hang, we need to make sure to put
the stale prev MMU context from a prior queuing, to avoid the
reference and thus the MMU context leaking.

Cc: [email protected] # 5.4
Signed-off-by: Lucas Stach <[email protected]>
Tested-by: Michael Walle <[email protected]>
Tested-by: Marek Vasut <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1356,6 +1356,8 @@ struct dma_fence *etnaviv_gpu_submit(str
gpu->mmu_context = etnaviv_iommu_context_get(submit->mmu_context);
etnaviv_gpu_start_fe_idleloop(gpu);
} else {
+ if (submit->prev_mmu_context)
+ etnaviv_iommu_context_put(submit->prev_mmu_context);
submit->prev_mmu_context = etnaviv_iommu_context_get(gpu->mmu_context);
}



2021-09-21 02:49:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 090/122] mtd: mtdconcat: Judge callback existence based on the master

From: Zhihao Cheng <[email protected]>

[ Upstream commit f9e109a209a8e01e16f37e1252304f1eb3908be4 ]

Since commit 46b5889cc2c5("mtd: implement proper partition handling")
applied, mtd partition device won't hold some callback functions, such
as _block_isbad, _block_markbad, etc. Besides, function mtd_block_isbad()
will get mtd device's master mtd device, then invokes master mtd device's
callback function. So, following process may result mtd_block_isbad()
always return 0, even though mtd device has bad blocks:

1. Split a mtd device into 3 partitions: PA, PB, PC
[ Each mtd partition device won't has callback function _block_isbad(). ]
2. Concatenate PA and PB as a new mtd device PN
[ mtd_concat_create() finds out each subdev has no callback function
_block_isbad(), so PN won't be assigned callback function
concat_block_isbad(). ]
Then, mtd_block_isbad() checks "!master->_block_isbad" is true, will
always return 0.

Reproducer:
// reproduce.c
static int __init init_diy_module(void)
{
struct mtd_info *mtd[2];
struct mtd_info *mtd_combine = NULL;

mtd[0] = get_mtd_device_nm("NAND simulator partition 0");
if (!mtd[0]) {
pr_err("cannot find mtd1\n");
return -EINVAL;
}
mtd[1] = get_mtd_device_nm("NAND simulator partition 1");
if (!mtd[1]) {
pr_err("cannot find mtd2\n");
return -EINVAL;
}

put_mtd_device(mtd[0]);
put_mtd_device(mtd[1]);

mtd_combine = mtd_concat_create(mtd, 2, "Combine mtd");
if (mtd_combine == NULL) {
pr_err("combine failed\n");
return -EINVAL;
}

mtd_device_register(mtd_combine, NULL, 0);
pr_info("Combine success\n");

return 0;
}

1. ID="0x20,0xac,0x00,0x15"
2. modprobe nandsim id_bytes=$ID parts=50,100 badblocks=100
3. insmod reproduce.ko
4. flash_erase /dev/mtd3 0 0
libmtd: error!: MEMERASE64 ioctl failed for eraseblock 100 (mtd3)
error 5 (Input/output error)
// Should be "flash_erase: Skipping bad block at 00c80000"

Fixes: 46b5889cc2c54bac ("mtd: implement proper partition handling")
Signed-off-by: Zhihao Cheng <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mtd/mtdconcat.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 6e4d0017c0bd..af51eee6b5e8 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -641,6 +641,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[], /* subdevices to c
int i;
size_t size;
struct mtd_concat *concat;
+ struct mtd_info *subdev_master = NULL;
uint32_t max_erasesize, curr_erasesize;
int num_erase_region;
int max_writebufsize = 0;
@@ -679,17 +680,19 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[], /* subdevices to c
concat->mtd.subpage_sft = subdev[0]->subpage_sft;
concat->mtd.oobsize = subdev[0]->oobsize;
concat->mtd.oobavail = subdev[0]->oobavail;
- if (subdev[0]->_writev)
+
+ subdev_master = mtd_get_master(subdev[0]);
+ if (subdev_master->_writev)
concat->mtd._writev = concat_writev;
- if (subdev[0]->_read_oob)
+ if (subdev_master->_read_oob)
concat->mtd._read_oob = concat_read_oob;
- if (subdev[0]->_write_oob)
+ if (subdev_master->_write_oob)
concat->mtd._write_oob = concat_write_oob;
- if (subdev[0]->_block_isbad)
+ if (subdev_master->_block_isbad)
concat->mtd._block_isbad = concat_block_isbad;
- if (subdev[0]->_block_markbad)
+ if (subdev_master->_block_markbad)
concat->mtd._block_markbad = concat_block_markbad;
- if (subdev[0]->_panic_write)
+ if (subdev_master->_panic_write)
concat->mtd._panic_write = concat_panic_write;

concat->mtd.ecc_stats.badblocks = subdev[0]->ecc_stats.badblocks;
@@ -721,14 +724,22 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[], /* subdevices to c
subdev[i]->flags & MTD_WRITEABLE;
}

+ subdev_master = mtd_get_master(subdev[i]);
concat->mtd.size += subdev[i]->size;
concat->mtd.ecc_stats.badblocks +=
subdev[i]->ecc_stats.badblocks;
if (concat->mtd.writesize != subdev[i]->writesize ||
concat->mtd.subpage_sft != subdev[i]->subpage_sft ||
concat->mtd.oobsize != subdev[i]->oobsize ||
- !concat->mtd._read_oob != !subdev[i]->_read_oob ||
- !concat->mtd._write_oob != !subdev[i]->_write_oob) {
+ !concat->mtd._read_oob != !subdev_master->_read_oob ||
+ !concat->mtd._write_oob != !subdev_master->_write_oob) {
+ /*
+ * Check against subdev[i] for data members, because
+ * subdev's attributes may be different from master
+ * mtd device. Check against subdev's master mtd
+ * device for callbacks, because the existence of
+ * subdev's callbacks is decided by master mtd device.
+ */
kfree(concat);
printk("Incompatible OOB or ECC data on \"%s\"\n",
subdev[i]->name);
--
2.30.2



2021-09-21 02:49:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 099/122] gpio: mpc8xxx: Fix a resources leak in the error handling path of mpc8xxx_probe()

From: Christophe JAILLET <[email protected]>

[ Upstream commit 555bda42b0c1a5ffb72d3227c043e8afde778f1f ]

Commit 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal")
has introduced a new 'goto err;' at the very end of the function, but has
not updated the error handling path accordingly.

Add the now missing 'irq_domain_remove()' call which balances a previous
'irq_domain_create_linear() call.

Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal")
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpio/gpio-mpc8xxx.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 3c2fa44d9279..5b2a919a6644 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -406,6 +406,8 @@ static int mpc8xxx_probe(struct platform_device *pdev)

return 0;
err:
+ if (mpc8xxx_gc->irq)
+ irq_domain_remove(mpc8xxx_gc->irq);
iounmap(mpc8xxx_gc->regs);
return ret;
}
--
2.30.2



2021-09-21 02:49:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 100/122] gpio: mpc8xxx: Fix a potential double iounmap call in mpc8xxx_probe()

From: Christophe JAILLET <[email protected]>

[ Upstream commit 7d6588931ccd4c09e70a08175cf2e0cf7fc3b869 ]

Commit 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") has switched to a
managed version when dealing with 'mpc8xxx_gc->regs'. So the corresponding
'iounmap()' call in the error handling path and in the remove should be
removed to avoid a double unmap.

This also allows some simplification in the probe. All the error handling
paths related to managed resources can be direct returns and a NULL check
in what remains in the error handling path can be removed.

Fixes: 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support")
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpio/gpio-mpc8xxx.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 5b2a919a6644..a4983c5d1f16 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -329,7 +329,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)
mpc8xxx_gc->regs + GPIO_DIR, NULL,
BGPIOF_BIG_ENDIAN);
if (ret)
- goto err;
+ return ret;
dev_dbg(&pdev->dev, "GPIO registers are LITTLE endian\n");
} else {
ret = bgpio_init(gc, &pdev->dev, 4,
@@ -339,7 +339,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)
BGPIOF_BIG_ENDIAN
| BGPIOF_BIG_ENDIAN_BYTE_ORDER);
if (ret)
- goto err;
+ return ret;
dev_dbg(&pdev->dev, "GPIO registers are BIG endian\n");
}

@@ -378,7 +378,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)
if (ret) {
pr_err("%pOF: GPIO chip registration failed with status %d\n",
np, ret);
- goto err;
+ return ret;
}

mpc8xxx_gc->irqn = irq_of_parse_and_map(np, 0);
@@ -406,9 +406,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)

return 0;
err:
- if (mpc8xxx_gc->irq)
- irq_domain_remove(mpc8xxx_gc->irq);
- iounmap(mpc8xxx_gc->regs);
+ irq_domain_remove(mpc8xxx_gc->irq);
return ret;
}

@@ -422,7 +420,6 @@ static int mpc8xxx_remove(struct platform_device *pdev)
}

gpiochip_remove(&mpc8xxx_gc->gc);
- iounmap(mpc8xxx_gc->regs);

return 0;
}
--
2.30.2



2021-09-21 02:49:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 074/122] block, bfq: honor already-setup queue merges

From: Paolo Valente <[email protected]>

[ Upstream commit 2d52c58b9c9bdae0ca3df6a1eab5745ab3f7d80b ]

The function bfq_setup_merge prepares the merging between two
bfq_queues, say bfqq and new_bfqq. To this goal, it assigns
bfqq->new_bfqq = new_bfqq. Then, each time some I/O for bfqq arrives,
the process that generated that I/O is disassociated from bfqq and
associated with new_bfqq (merging is actually a redirection). In this
respect, bfq_setup_merge increases new_bfqq->ref in advance, adding
the number of processes that are expected to be associated with
new_bfqq.

Unfortunately, the stable-merging mechanism interferes with this
setup. After bfqq->new_bfqq has been set by bfq_setup_merge, and
before all the expected processes have been associated with
bfqq->new_bfqq, bfqq may happen to be stably merged with a different
queue than the current bfqq->new_bfqq. In this case, bfqq->new_bfqq
gets changed. So, some of the processes that have been already
accounted for in the ref counter of the previous new_bfqq will not be
associated with that queue. This creates an unbalance, because those
references will never be decremented.

This commit fixes this issue by reestablishing the previous, natural
behaviour: once bfqq->new_bfqq has been set, it will not be changed
until all expected redirections have occurred.

Signed-off-by: Davide Zini <[email protected]>
Signed-off-by: Paolo Valente <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
block/bfq-iosched.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index b8c2ddc01aec..65c200e0ecb5 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2526,6 +2526,15 @@ bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq)
* are likely to increase the throughput.
*/
bfqq->new_bfqq = new_bfqq;
+ /*
+ * The above assignment schedules the following redirections:
+ * each time some I/O for bfqq arrives, the process that
+ * generated that I/O is disassociated from bfqq and
+ * associated with new_bfqq. Here we increases new_bfqq->ref
+ * in advance, adding the number of processes that are
+ * expected to be associated with new_bfqq as they happen to
+ * issue I/O.
+ */
new_bfqq->ref += process_refs;
return new_bfqq;
}
@@ -2585,6 +2594,10 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq,
{
struct bfq_queue *in_service_bfqq, *new_bfqq;

+ /* if a merge has already been setup, then proceed with that first */
+ if (bfqq->new_bfqq)
+ return bfqq->new_bfqq;
+
/*
* Do not perform queue merging if the device is non
* rotational and performs internal queueing. In fact, such a
@@ -2639,9 +2652,6 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq,
if (bfq_too_late_for_merging(bfqq))
return NULL;

- if (bfqq->new_bfqq)
- return bfqq->new_bfqq;
-
if (!io_struct || unlikely(bfqq == &bfqd->oom_bfqq))
return NULL;

--
2.30.2



2021-09-21 02:49:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 076/122] ethtool: Fix an error code in cxgb2.c

From: Yang Li <[email protected]>

[ Upstream commit 7db8263a12155c7ae4ad97e850f1e499c73765fc ]

When adapter->registered_device_map is NULL, the value of err is
uncertain, we set err to -EINVAL to avoid ambiguity.

Clean up smatch warning:
drivers/net/ethernet/chelsio/cxgb/cxgb2.c:1114 init_one() warn: missing
error code 'err'

Reported-by: Abaci Robot <[email protected]>
Signed-off-by: Yang Li <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
index 0e4a0f413960..c6db85fe1629 100644
--- a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
+++ b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
@@ -1153,6 +1153,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!adapter->registered_device_map) {
pr_err("%s: could not register any net devices\n",
pci_name(pdev));
+ err = -EINVAL;
goto out_release_adapter_res;
}

--
2.30.2



2021-09-21 02:49:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 064/122] tracing/probes: Reject events which have the same name of existing one

From: Masami Hiramatsu <[email protected]>

[ Upstream commit 8e242060c6a4947e8ae7d29794af6a581db08841 ]

Since kprobe_events and uprobe_events only check whether the
other same-type probe event has the same name or not, if the
user gives the same name of the existing tracepoint event (or
the other type of probe events), it silently fails to create
the tracefs entry (but registered.) as below.

/sys/kernel/tracing # ls events/task/task_rename
enable filter format hist id trigger
/sys/kernel/tracing # echo p:task/task_rename vfs_read >> kprobe_events
[ 113.048508] Could not create tracefs 'task_rename' directory
/sys/kernel/tracing # cat kprobe_events
p:task/task_rename vfs_read

To fix this issue, check whether the existing events have the
same name or not in trace_probe_register_event_call(). If exists,
it rejects to register the new event.

Link: https://lkml.kernel.org/r/162936876189.187130.17558311387542061930.stgit@devnote2

Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/trace/trace_kprobe.c | 6 +++++-
kernel/trace/trace_probe.c | 25 +++++++++++++++++++++++++
kernel/trace/trace_probe.h | 1 +
kernel/trace/trace_uprobe.c | 6 +++++-
4 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 68150b9cbde9..552dbc9d5226 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -647,7 +647,11 @@ static int register_trace_kprobe(struct trace_kprobe *tk)
/* Register new event */
ret = register_kprobe_event(tk);
if (ret) {
- pr_warn("Failed to register probe event(%d)\n", ret);
+ if (ret == -EEXIST) {
+ trace_probe_log_set_index(0);
+ trace_probe_log_err(0, EVENT_EXIST);
+ } else
+ pr_warn("Failed to register probe event(%d)\n", ret);
goto end;
}

diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index d2867ccc6aca..1d31bc4acf7a 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -1029,11 +1029,36 @@ error:
return ret;
}

+static struct trace_event_call *
+find_trace_event_call(const char *system, const char *event_name)
+{
+ struct trace_event_call *tp_event;
+ const char *name;
+
+ list_for_each_entry(tp_event, &ftrace_events, list) {
+ if (!tp_event->class->system ||
+ strcmp(system, tp_event->class->system))
+ continue;
+ name = trace_event_name(tp_event);
+ if (!name || strcmp(event_name, name))
+ continue;
+ return tp_event;
+ }
+
+ return NULL;
+}
+
int trace_probe_register_event_call(struct trace_probe *tp)
{
struct trace_event_call *call = trace_probe_event_call(tp);
int ret;

+ lockdep_assert_held(&event_mutex);
+
+ if (find_trace_event_call(trace_probe_group_name(tp),
+ trace_probe_name(tp)))
+ return -EEXIST;
+
ret = register_trace_event(&call->event);
if (!ret)
return -ENODEV;
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index 2f703a20c724..6d41e20c47ce 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -398,6 +398,7 @@ extern int traceprobe_define_arg_fields(struct trace_event_call *event_call,
C(NO_EVENT_NAME, "Event name is not specified"), \
C(EVENT_TOO_LONG, "Event name is too long"), \
C(BAD_EVENT_NAME, "Event name must follow the same rules as C identifiers"), \
+ C(EVENT_EXIST, "Given group/event name is already used by another event"), \
C(RETVAL_ON_PROBE, "$retval is not available on probe"), \
C(BAD_STACK_NUM, "Invalid stack number"), \
C(BAD_ARG_NUM, "Invalid argument number"), \
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 3cf7128e1ad3..0dd6e286e519 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -514,7 +514,11 @@ static int register_trace_uprobe(struct trace_uprobe *tu)

ret = register_uprobe_event(tu);
if (ret) {
- pr_warn("Failed to register probe event(%d)\n", ret);
+ if (ret == -EEXIST) {
+ trace_probe_log_set_index(0);
+ trace_probe_log_err(0, EVENT_EXIST);
+ } else
+ pr_warn("Failed to register probe event(%d)\n", ret);
goto end;
}

--
2.30.2



2021-09-21 02:49:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 021/122] tipc: fix an use-after-free issue in tipc_recvmsg

From: Xin Long <[email protected]>

commit cc19862ffe454a5b632ca202e5a51bfec9f89fd2 upstream.

syzbot reported an use-after-free crash:

BUG: KASAN: use-after-free in tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979
Call Trace:
tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979
sock_recvmsg_nosec net/socket.c:943 [inline]
sock_recvmsg net/socket.c:961 [inline]
sock_recvmsg+0xca/0x110 net/socket.c:957
tipc_conn_rcv_from_sock+0x162/0x2f0 net/tipc/topsrv.c:398
tipc_conn_recv_work+0xeb/0x190 net/tipc/topsrv.c:421
process_one_work+0x98d/0x1630 kernel/workqueue.c:2276
worker_thread+0x658/0x11f0 kernel/workqueue.c:2422

As Hoang pointed out, it was caused by skb_cb->bytes_read still accessed
after calling tsk_advance_rx_queue() to free the skb in tipc_recvmsg().

This patch is to fix it by accessing skb_cb->bytes_read earlier than
calling tsk_advance_rx_queue().

Fixes: f4919ff59c28 ("tipc: keep the skb in rcv queue until the whole data is read")
Reported-by: [email protected]
Signed-off-by: Xin Long <[email protected]>
Acked-by: Jon Maloy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tipc/socket.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1980,10 +1980,12 @@ static int tipc_recvmsg(struct socket *s
tipc_node_distr_xmit(sock_net(sk), &xmitq);
}

- if (!skb_cb->bytes_read)
- tsk_advance_rx_queue(sk);
+ if (skb_cb->bytes_read)
+ goto exit;
+
+ tsk_advance_rx_queue(sk);

- if (likely(!connected) || skb_cb->bytes_read)
+ if (likely(!connected))
goto exit;

/* Send connection flow control advertisement when applicable */


2021-09-21 02:49:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 065/122] PCI: cadence: Use bitfield for *quirk_retrain_flag* instead of bool

From: Kishon Vijay Abraham I <[email protected]>

[ Upstream commit f4455748b2126a9ba2bcc9cfb2fbcaa08de29bb2 ]

No functional change. As we are intending to add additional 1-bit
members in struct j721e_pcie_data/struct cdns_pcie_rc, use bitfields
instead of bool since it takes less space. As discussed in [1],
the preference is to use bitfileds instead of bool inside structures.

[1] -> https://lore.kernel.org/linux-fsdevel/CA+55aFzKQ6Pj18TB8p4Yr0M4t+S+BsiHH=BJNmn=76-NcjTj-g@mail.gmail.com/

Suggested-by: Bjorn Helgaas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/controller/cadence/pci-j721e.c | 2 +-
drivers/pci/controller/cadence/pcie-cadence.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
index d34ca0fda0f6..973b309ac9ba 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -63,7 +63,7 @@ enum j721e_pcie_mode {

struct j721e_pcie_data {
enum j721e_pcie_mode mode;
- bool quirk_retrain_flag;
+ unsigned int quirk_retrain_flag:1;
};

static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
index 6705a5fedfbb..60981877f65b 100644
--- a/drivers/pci/controller/cadence/pcie-cadence.h
+++ b/drivers/pci/controller/cadence/pcie-cadence.h
@@ -299,7 +299,7 @@ struct cdns_pcie_rc {
u32 vendor_id;
u32 device_id;
bool avail_ib_bar[CDNS_PCIE_RP_MAX_IB];
- bool quirk_retrain_flag;
+ unsigned int quirk_retrain_flag:1;
};

/**
--
2.30.2



2021-09-21 02:49:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 058/122] fuse: fix use after free in fuse_read_interrupt()

From: Miklos Szeredi <[email protected]>

[ Upstream commit e1e71c168813564be0f6ea3d6740a059ca42d177 ]

There is a potential race between fuse_read_interrupt() and
fuse_request_end().

TASK1
in fuse_read_interrupt(): delete req->intr_entry (while holding
fiq->lock)

TASK2
in fuse_request_end(): req->intr_entry is empty -> skip fiq->lock
wake up TASK3

TASK3
request is freed

TASK1
in fuse_read_interrupt(): dereference req->in.h.unique ***BAM***

Fix by always grabbing fiq->lock if the request was ever interrupted
(FR_INTERRUPTED set) thereby serializing with concurrent
fuse_read_interrupt() calls.

FR_INTERRUPTED is set before the request is queued on fiq->interrupts.
Dequeing the request is done with list_del_init() but FR_INTERRUPTED is not
cleared in this case.

Reported-by: lijiazi <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/fuse/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 4140d5c3ab5a..f943eea9fe4e 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -288,10 +288,10 @@ void fuse_request_end(struct fuse_req *req)

/*
* test_and_set_bit() implies smp_mb() between bit
- * changing and below intr_entry check. Pairs with
+ * changing and below FR_INTERRUPTED check. Pairs with
* smp_mb() from queue_interrupt().
*/
- if (!list_empty(&req->intr_entry)) {
+ if (test_bit(FR_INTERRUPTED, &req->flags)) {
spin_lock(&fiq->lock);
list_del_init(&req->intr_entry);
spin_unlock(&fiq->lock);
--
2.30.2



2021-09-21 02:49:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 024/122] net-caif: avoid user-triggerable WARN_ON(1)

From: Eric Dumazet <[email protected]>

commit 550ac9c1aaaaf51fd42e20d461f0b1cdbd55b3d2 upstream.

syszbot triggers this warning, which looks something
we can easily prevent.

If we initialize priv->list_field in chnl_net_init(),
then always use list_del_init(), we can remove robust_list_del()
completely.

WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 robust_list_del net/caif/chnl_net.c:67 [inline]
WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375
Modules linked in:
CPU: 0 PID: 3233 Comm: syz-executor.3 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:robust_list_del net/caif/chnl_net.c:67 [inline]
RIP: 0010:chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375
Code: 89 eb e8 3a a3 ba f8 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 bf 01 00 00 48 81 fb 00 14 4e 8d 48 8b 2b 75 d0 e8 17 a3 ba f8 <0f> 0b 5b 5d 41 5c 41 5d e9 0a a3 ba f8 4c 89 e3 e8 02 a3 ba f8 4c
RSP: 0018:ffffc90009067248 EFLAGS: 00010202
RAX: 0000000000008780 RBX: ffffffff8d4e1400 RCX: ffffc9000fd34000
RDX: 0000000000040000 RSI: ffffffff88bb6e49 RDI: 0000000000000003
RBP: ffff88802cd9ee08 R08: 0000000000000000 R09: ffffffff8d0e6647
R10: ffffffff88bb6dc2 R11: 0000000000000000 R12: ffff88803791ae08
R13: dffffc0000000000 R14: 00000000e600ffce R15: ffff888073ed3480
FS: 00007fed10fa0700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2c322000 CR3: 00000000164a6000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
register_netdevice+0xadf/0x1500 net/core/dev.c:10347
ipcaif_newlink+0x4c/0x260 net/caif/chnl_net.c:468
__rtnl_newlink+0x106d/0x1750 net/core/rtnetlink.c:3458
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3506
rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
__sys_sendto+0x21c/0x320 net/socket.c:2036
__do_sys_sendto net/socket.c:2048 [inline]
__se_sys_sendto net/socket.c:2044 [inline]
__x64_sys_sendto+0xdd/0x1b0 net/socket.c:2044
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes: cc36a070b590 ("net-caif: add CAIF netdevice")
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/caif/chnl_net.c | 19 +++----------------
1 file changed, 3 insertions(+), 16 deletions(-)

--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -53,20 +53,6 @@ struct chnl_net {
enum caif_states state;
};

-static void robust_list_del(struct list_head *delete_node)
-{
- struct list_head *list_node;
- struct list_head *n;
- ASSERT_RTNL();
- list_for_each_safe(list_node, n, &chnl_net_list) {
- if (list_node == delete_node) {
- list_del(list_node);
- return;
- }
- }
- WARN_ON(1);
-}
-
static int chnl_recv_cb(struct cflayer *layr, struct cfpkt *pkt)
{
struct sk_buff *skb;
@@ -369,6 +355,7 @@ static int chnl_net_init(struct net_devi
ASSERT_RTNL();
priv = netdev_priv(dev);
strncpy(priv->name, dev->name, sizeof(priv->name));
+ INIT_LIST_HEAD(&priv->list_field);
return 0;
}

@@ -377,7 +364,7 @@ static void chnl_net_uninit(struct net_d
struct chnl_net *priv;
ASSERT_RTNL();
priv = netdev_priv(dev);
- robust_list_del(&priv->list_field);
+ list_del_init(&priv->list_field);
}

static const struct net_device_ops netdev_ops = {
@@ -542,7 +529,7 @@ static void __exit chnl_exit_module(void
rtnl_lock();
list_for_each_safe(list_node, _tmp, &chnl_net_list) {
dev = list_entry(list_node, struct chnl_net, list_field);
- list_del(list_node);
+ list_del_init(list_node);
delete_device(dev);
}
rtnl_unlock();


2021-09-21 02:49:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 106/122] net: dsa: b53: Set correct number of ports in the DSA struct

From: Rafał Miłecki <[email protected]>

[ Upstream commit d12e1c4649883e8ca5e8ff341e1948b3b6313259 ]

Setting DSA_MAX_PORTS caused DSA to call b53 callbacks (e.g.
b53_disable_port() during dsa_register_switch()) for invalid
(non-existent) ports. That made b53 modify unrelated registers and is
one of reasons for a broken BCM5301x support.

This problem exists for years but DSA_MAX_PORTS usage has changed few
times. It seems the most accurate to reference commit dropping
dsa_switch_alloc() in the Fixes tag.

Fixes: 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper")
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/dsa/b53/b53_common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index a8e915dd826a..54558f47b633 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -2559,6 +2559,8 @@ static int b53_switch_init(struct b53_device *dev)
dev->enabled_ports |= BIT(dev->cpu_port);
dev->num_ports = fls(dev->enabled_ports);

+ dev->ds->num_ports = min_t(unsigned int, dev->num_ports, DSA_MAX_PORTS);
+
/* Include non standard CPU port built-in PHYs to be probed */
if (is539x(dev) || is531x5(dev)) {
for (i = 0; i < dev->num_ports; i++) {
@@ -2603,7 +2605,6 @@ struct b53_device *b53_switch_alloc(struct device *base,
return NULL;

ds->dev = base;
- ds->num_ports = DSA_MAX_PORTS;

dev = devm_kzalloc(base, sizeof(*dev), GFP_KERNEL);
if (!dev)
--
2.30.2



2021-09-21 02:49:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 105/122] net: dsa: b53: Fix calculating number of switch ports

From: Rafał Miłecki <[email protected]>

[ Upstream commit cdb067d31c0fe4cce98b9d15f1f2ef525acaa094 ]

It isn't true that CPU port is always the last one. Switches BCM5301x
have 9 ports (port 6 being inactive) and they use port 5 as CPU by
default (depending on design some other may be CPU ports too).

A more reliable way of determining number of ports is to check for the
last set bit in the "enabled_ports" bitfield.

This fixes b53 internal state, it will allow providing accurate info to
the DSA and is required to fix BCM5301x support.

Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/dsa/b53/b53_common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 52100d4fe5a2..a8e915dd826a 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -2556,9 +2556,8 @@ static int b53_switch_init(struct b53_device *dev)
dev->cpu_port = 5;
}

- /* cpu port is always last */
- dev->num_ports = dev->cpu_port + 1;
dev->enabled_ports |= BIT(dev->cpu_port);
+ dev->num_ports = fls(dev->enabled_ports);

/* Include non standard CPU port built-in PHYs to be probed */
if (is539x(dev) || is531x5(dev)) {
--
2.30.2



2021-09-21 02:49:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 035/122] events: Reuse value read using READ_ONCE instead of re-reading it

From: Baptiste Lepers <[email protected]>

commit b89a05b21f46150ac10a962aa50109250b56b03b upstream.

In perf_event_addr_filters_apply, the task associated with
the event (event->ctx->task) is read using READ_ONCE at the beginning
of the function, checked, and then re-read from event->ctx->task,
voiding all guarantees of the checks. Reuse the value that was read by
READ_ONCE to ensure the consistency of the task struct throughout the
function.

Fixes: 375637bc52495 ("perf/core: Introduce address range filtering")
Signed-off-by: Baptiste Lepers <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -9973,7 +9973,7 @@ static void perf_event_addr_filters_appl
return;

if (ifh->nr_file_filters) {
- mm = get_task_mm(event->ctx->task);
+ mm = get_task_mm(task);
if (!mm)
goto restart;



2021-09-21 02:49:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 039/122] net/af_unix: fix a data-race in unix_dgram_poll

From: Eric Dumazet <[email protected]>

commit 04f08eb44b5011493d77b602fdec29ff0f5c6cd5 upstream.

syzbot reported another data-race in af_unix [1]

Lets change __skb_insert() to use WRITE_ONCE() when changing
skb head qlen.

Also, change unix_dgram_poll() to use lockless version
of unix_recvq_full()

It is verry possible we can switch all/most unix_recvq_full()
to the lockless version, this will be done in a future kernel version.

[1] HEAD commit: 8596e589b787732c8346f0482919e83cc9362db1

BUG: KCSAN: data-race in skb_queue_tail / unix_dgram_poll

write to 0xffff88814eeb24e0 of 4 bytes by task 25815 on cpu 0:
__skb_insert include/linux/skbuff.h:1938 [inline]
__skb_queue_before include/linux/skbuff.h:2043 [inline]
__skb_queue_tail include/linux/skbuff.h:2076 [inline]
skb_queue_tail+0x80/0xa0 net/core/skbuff.c:3264
unix_dgram_sendmsg+0xff2/0x1600 net/unix/af_unix.c:1850
sock_sendmsg_nosec net/socket.c:703 [inline]
sock_sendmsg net/socket.c:723 [inline]
____sys_sendmsg+0x360/0x4d0 net/socket.c:2392
___sys_sendmsg net/socket.c:2446 [inline]
__sys_sendmmsg+0x315/0x4b0 net/socket.c:2532
__do_sys_sendmmsg net/socket.c:2561 [inline]
__se_sys_sendmmsg net/socket.c:2558 [inline]
__x64_sys_sendmmsg+0x53/0x60 net/socket.c:2558
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae

read to 0xffff88814eeb24e0 of 4 bytes by task 25834 on cpu 1:
skb_queue_len include/linux/skbuff.h:1869 [inline]
unix_recvq_full net/unix/af_unix.c:194 [inline]
unix_dgram_poll+0x2bc/0x3e0 net/unix/af_unix.c:2777
sock_poll+0x23e/0x260 net/socket.c:1288
vfs_poll include/linux/poll.h:90 [inline]
ep_item_poll fs/eventpoll.c:846 [inline]
ep_send_events fs/eventpoll.c:1683 [inline]
ep_poll fs/eventpoll.c:1798 [inline]
do_epoll_wait+0x6ad/0xf00 fs/eventpoll.c:2226
__do_sys_epoll_wait fs/eventpoll.c:2238 [inline]
__se_sys_epoll_wait fs/eventpoll.c:2233 [inline]
__x64_sys_epoll_wait+0xf6/0x120 fs/eventpoll.c:2233
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae

value changed: 0x0000001b -> 0x00000001

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 25834 Comm: syz-executor.1 Tainted: G W 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Fixes: 86b18aaa2b5b ("skbuff: fix a data race in skb_queue_len()")
Cc: Qian Cai <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/skbuff.h | 2 +-
net/unix/af_unix.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1908,7 +1908,7 @@ static inline void __skb_insert(struct s
WRITE_ONCE(newsk->prev, prev);
WRITE_ONCE(next->prev, newsk);
WRITE_ONCE(prev->next, newsk);
- list->qlen++;
+ WRITE_ONCE(list->qlen, list->qlen + 1);
}

static inline void __skb_queue_splice(const struct sk_buff_head *list,
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2769,7 +2769,7 @@ static __poll_t unix_dgram_poll(struct f

other = unix_peer(sk);
if (other && unix_peer(other) != sk &&
- unix_recvq_full(other) &&
+ unix_recvq_full_lockless(other) &&
unix_dgram_peer_wake_me(sk, other))
writable = 0;



2021-09-21 02:49:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 119/122] mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000"

From: Andy Shevchenko <[email protected]>

[ Upstream commit 922e8ce883e59b52786b2c11656d84dc58ef084a ]

The IRQ support for SCH GPIO is not specific to the Intel Quark SoC.
Moreover the IRQ routing is quite interesting there, so while it's
needs a special support, the driver haven't it anyway yet.

Due to above remove basically redundant code of IRQ support.

This reverts commit ec689a8a8155ce8b966bd5d7737a3916f5e48be3.

Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mfd/lpc_sch.c | 32 ++++++--------------------------
1 file changed, 6 insertions(+), 26 deletions(-)

diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
index f27eb8dabc1c..428a526cbe86 100644
--- a/drivers/mfd/lpc_sch.c
+++ b/drivers/mfd/lpc_sch.c
@@ -26,9 +26,6 @@
#define GPIO_IO_SIZE 64
#define GPIO_IO_SIZE_CENTERTON 128

-/* Intel Quark X1000 GPIO IRQ Number */
-#define GPIO_IRQ_QUARK_X1000 9
-
#define WDTBASE 0x84
#define WDT_IO_SIZE 64

@@ -43,30 +40,25 @@ struct lpc_sch_info {
unsigned int io_size_smbus;
unsigned int io_size_gpio;
unsigned int io_size_wdt;
- int irq_gpio;
};

static struct lpc_sch_info sch_chipset_info[] = {
[LPC_SCH] = {
.io_size_smbus = SMBUS_IO_SIZE,
.io_size_gpio = GPIO_IO_SIZE,
- .irq_gpio = -1,
},
[LPC_ITC] = {
.io_size_smbus = SMBUS_IO_SIZE,
.io_size_gpio = GPIO_IO_SIZE,
.io_size_wdt = WDT_IO_SIZE,
- .irq_gpio = -1,
},
[LPC_CENTERTON] = {
.io_size_smbus = SMBUS_IO_SIZE,
.io_size_gpio = GPIO_IO_SIZE_CENTERTON,
.io_size_wdt = WDT_IO_SIZE,
- .irq_gpio = -1,
},
[LPC_QUARK_X1000] = {
.io_size_gpio = GPIO_IO_SIZE,
- .irq_gpio = GPIO_IRQ_QUARK_X1000,
.io_size_wdt = WDT_IO_SIZE,
},
};
@@ -113,13 +105,13 @@ static int lpc_sch_get_io(struct pci_dev *pdev, int where, const char *name,
}

static int lpc_sch_populate_cell(struct pci_dev *pdev, int where,
- const char *name, int size, int irq,
- int id, struct mfd_cell *cell)
+ const char *name, int size, int id,
+ struct mfd_cell *cell)
{
struct resource *res;
int ret;

- res = devm_kcalloc(&pdev->dev, 2, sizeof(*res), GFP_KERNEL);
+ res = devm_kzalloc(&pdev->dev, sizeof(*res), GFP_KERNEL);
if (!res)
return -ENOMEM;

@@ -135,18 +127,6 @@ static int lpc_sch_populate_cell(struct pci_dev *pdev, int where,
cell->ignore_resource_conflicts = true;
cell->id = id;

- /* Check if we need to add an IRQ resource */
- if (irq < 0)
- return 0;
-
- res++;
-
- res->start = irq;
- res->end = irq;
- res->flags = IORESOURCE_IRQ;
-
- cell->num_resources++;
-
return 0;
}

@@ -158,7 +138,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const struct pci_device_id *id)
int ret;

ret = lpc_sch_populate_cell(dev, SMBASE, "isch_smbus",
- info->io_size_smbus, -1,
+ info->io_size_smbus,
id->device, &lpc_sch_cells[cells]);
if (ret < 0)
return ret;
@@ -166,7 +146,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const struct pci_device_id *id)
cells++;

ret = lpc_sch_populate_cell(dev, GPIOBASE, "sch_gpio",
- info->io_size_gpio, info->irq_gpio,
+ info->io_size_gpio,
id->device, &lpc_sch_cells[cells]);
if (ret < 0)
return ret;
@@ -174,7 +154,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const struct pci_device_id *id)
cells++;

ret = lpc_sch_populate_cell(dev, WDTBASE, "ie6xx_wdt",
- info->io_size_wdt, -1,
+ info->io_size_wdt,
id->device, &lpc_sch_cells[cells]);
if (ret < 0)
return ret;
--
2.30.2



2021-09-21 02:50:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 122/122] x86/mce: Avoid infinite loop for copy from user recovery

From: Tony Luck <[email protected]>

commit 81065b35e2486c024c7aa86caed452e1f01a59d4 upstream.

There are two cases for machine check recovery:

1) The machine check was triggered by ring3 (application) code.
This is the simpler case. The machine check handler simply queues
work to be executed on return to user. That code unmaps the page
from all users and arranges to send a SIGBUS to the task that
triggered the poison.

2) The machine check was triggered in kernel code that is covered by
an exception table entry. In this case the machine check handler
still queues a work entry to unmap the page, etc. but this will
not be called right away because the #MC handler returns to the
fix up code address in the exception table entry.

Problems occur if the kernel triggers another machine check before the
return to user processes the first queued work item.

Specifically, the work is queued using the ->mce_kill_me callback
structure in the task struct for the current thread. Attempting to queue
a second work item using this same callback results in a loop in the
linked list of work functions to call. So when the kernel does return to
user, it enters an infinite loop processing the same entry for ever.

There are some legitimate scenarios where the kernel may take a second
machine check before returning to the user.

1) Some code (e.g. futex) first tries a get_user() with page faults
disabled. If this fails, the code retries with page faults enabled
expecting that this will resolve the page fault.

2) Copy from user code retries a copy in byte-at-time mode to check
whether any additional bytes can be copied.

On the other side of the fence are some bad drivers that do not check
the return value from individual get_user() calls and may access
multiple user addresses without noticing that some/all calls have
failed.

Fix by adding a counter (current->mce_count) to keep track of repeated
machine checks before task_work() is called. First machine check saves
the address information and calls task_work_add(). Subsequent machine
checks before that task_work call back is executed check that the address
is in the same page as the first machine check (since the callback will
offline exactly one page).

Expected worst case is four machine checks before moving on (e.g. one
user access with page faults disabled, then a repeat to the same address
with page faults enabled ... repeat in copy tail bytes). Just in case
there is some code that loops forever enforce a limit of 10.

[ bp: Massage commit message, drop noinstr, fix typo, extend panic
messages. ]

Fixes: 5567d11c21a1 ("x86/mce: Send #MC singal from task work")
Signed-off-by: Tony Luck <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: <[email protected]>
Link: https://lkml.kernel.org/r/YT/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/cpu/mce/core.c | 45 ++++++++++++++++++++++++++++++-----------
include/linux/sched.h | 1
2 files changed, 34 insertions(+), 12 deletions(-)

--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1241,6 +1241,9 @@ static void __mc_scan_banks(struct mce *

static void kill_me_now(struct callback_head *ch)
{
+ struct task_struct *p = container_of(ch, struct task_struct, mce_kill_me);
+
+ p->mce_count = 0;
force_sig(SIGBUS);
}

@@ -1249,6 +1252,7 @@ static void kill_me_maybe(struct callbac
struct task_struct *p = container_of(cb, struct task_struct, mce_kill_me);
int flags = MF_ACTION_REQUIRED;

+ p->mce_count = 0;
pr_err("Uncorrected hardware memory error in user-access at %llx", p->mce_addr);

if (!p->mce_ripv)
@@ -1269,17 +1273,34 @@ static void kill_me_maybe(struct callbac
}
}

-static void queue_task_work(struct mce *m, int kill_it)
+static void queue_task_work(struct mce *m, char *msg, int kill_current_task)
{
- current->mce_addr = m->addr;
- current->mce_kflags = m->kflags;
- current->mce_ripv = !!(m->mcgstatus & MCG_STATUS_RIPV);
- current->mce_whole_page = whole_page(m);
-
- if (kill_it)
- current->mce_kill_me.func = kill_me_now;
- else
- current->mce_kill_me.func = kill_me_maybe;
+ int count = ++current->mce_count;
+
+ /* First call, save all the details */
+ if (count == 1) {
+ current->mce_addr = m->addr;
+ current->mce_kflags = m->kflags;
+ current->mce_ripv = !!(m->mcgstatus & MCG_STATUS_RIPV);
+ current->mce_whole_page = whole_page(m);
+
+ if (kill_current_task)
+ current->mce_kill_me.func = kill_me_now;
+ else
+ current->mce_kill_me.func = kill_me_maybe;
+ }
+
+ /* Ten is likely overkill. Don't expect more than two faults before task_work() */
+ if (count > 10)
+ mce_panic("Too many consecutive machine checks while accessing user data", m, msg);
+
+ /* Second or later call, make sure page address matches the one from first call */
+ if (count > 1 && (current->mce_addr >> PAGE_SHIFT) != (m->addr >> PAGE_SHIFT))
+ mce_panic("Consecutive machine checks to different user pages", m, msg);
+
+ /* Do not call task_work_add() more than once */
+ if (count > 1)
+ return;

task_work_add(current, &current->mce_kill_me, TWA_RESUME);
}
@@ -1427,7 +1448,7 @@ noinstr void do_machine_check(struct pt_
/* If this triggers there is no way to recover. Die hard. */
BUG_ON(!on_thread_stack() || !user_mode(regs));

- queue_task_work(&m, kill_it);
+ queue_task_work(&m, msg, kill_it);

} else {
/*
@@ -1445,7 +1466,7 @@ noinstr void do_machine_check(struct pt_
}

if (m.kflags & MCE_IN_KERNEL_COPYIN)
- queue_task_work(&m, kill_it);
+ queue_task_work(&m, msg, kill_it);
}
out:
mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1354,6 +1354,7 @@ struct task_struct {
mce_whole_page : 1,
__mce_reserved : 62;
struct callback_head mce_kill_me;
+ int mce_count;
#endif

/*


2021-09-21 02:50:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 121/122] net: renesas: sh_eth: Fix freeing wrong tx descriptor

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit 0341d5e3d1ee2a36dd5a49b5bef2ce4ad1cfa6b4 ]

The cur_tx counter must be incremented after TACT bit of
txdesc->status was set. However, a CPU is possible to reorder
instructions and/or memory accesses between cur_tx and
txdesc->status. And then, if TX interrupt happened at such a
timing, the sh_eth_tx_free() may free the descriptor wrongly.
So, add wmb() before cur_tx++.
Otherwise NETDEV WATCHDOG timeout is possible to happen.

Fixes: 86a74ff21a7a ("net: sh_eth: add support for Renesas SuperH Ethernet")
Signed-off-by: Yoshihiro Shimoda <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 5cab2d3c0023..8927d5997745 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -2533,6 +2533,7 @@ static netdev_tx_t sh_eth_start_xmit(struct sk_buff *skb,
else
txdesc->status |= cpu_to_le32(TD_TACT);

+ wmb(); /* cur_tx must be incremented after TACT bit was set */
mdp->cur_tx++;

if (!(sh_eth_read(ndev, EDTRR) & mdp->cd->edtrr_trns))
--
2.30.2



2021-09-21 02:50:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 067/122] PCI: j721e: Add PCIe support for J7200

From: Kishon Vijay Abraham I <[email protected]>

[ Upstream commit f1de58802f0fff364cf49f5e47d1be744baa434f ]

J7200 has the same PCIe IP as in J721E with minor changes in the
wrapper. J7200 allows byte access of bridge configuration space
registers and the register field for LINK_DOWN interrupt is different.
J7200 also requires "quirk_detect_quiet_flag" to be set. Configure these
changes as part of driver data applicable only to J7200.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/controller/cadence/pci-j721e.c | 40 +++++++++++++++++++---
1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
index 973b309ac9ba..2f5a49c77074 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -25,6 +25,7 @@
#define STATUS_REG_SYS_2 0x508
#define STATUS_CLR_REG_SYS_2 0x708
#define LINK_DOWN BIT(1)
+#define J7200_LINK_DOWN BIT(10)

#define J721E_PCIE_USER_CMD_STATUS 0x4
#define LINK_TRAINING_ENABLE BIT(0)
@@ -54,6 +55,7 @@ struct j721e_pcie {
struct cdns_pcie *cdns_pcie;
void __iomem *user_cfg_base;
void __iomem *intd_cfg_base;
+ u32 linkdown_irq_regfield;
};

enum j721e_pcie_mode {
@@ -64,6 +66,9 @@ enum j721e_pcie_mode {
struct j721e_pcie_data {
enum j721e_pcie_mode mode;
unsigned int quirk_retrain_flag:1;
+ unsigned int quirk_detect_quiet_flag:1;
+ u32 linkdown_irq_regfield;
+ unsigned int byte_access_allowed:1;
};

static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
@@ -95,12 +100,12 @@ static irqreturn_t j721e_pcie_link_irq_handler(int irq, void *priv)
u32 reg;

reg = j721e_pcie_intd_readl(pcie, STATUS_REG_SYS_2);
- if (!(reg & LINK_DOWN))
+ if (!(reg & pcie->linkdown_irq_regfield))
return IRQ_NONE;

dev_err(dev, "LINK DOWN!\n");

- j721e_pcie_intd_writel(pcie, STATUS_CLR_REG_SYS_2, LINK_DOWN);
+ j721e_pcie_intd_writel(pcie, STATUS_CLR_REG_SYS_2, pcie->linkdown_irq_regfield);
return IRQ_HANDLED;
}

@@ -109,7 +114,7 @@ static void j721e_pcie_config_link_irq(struct j721e_pcie *pcie)
u32 reg;

reg = j721e_pcie_intd_readl(pcie, ENABLE_REG_SYS_2);
- reg |= LINK_DOWN;
+ reg |= pcie->linkdown_irq_regfield;
j721e_pcie_intd_writel(pcie, ENABLE_REG_SYS_2, reg);
}

@@ -272,10 +277,25 @@ static struct pci_ops cdns_ti_pcie_host_ops = {
static const struct j721e_pcie_data j721e_pcie_rc_data = {
.mode = PCI_MODE_RC,
.quirk_retrain_flag = true,
+ .byte_access_allowed = false,
+ .linkdown_irq_regfield = LINK_DOWN,
};

static const struct j721e_pcie_data j721e_pcie_ep_data = {
.mode = PCI_MODE_EP,
+ .linkdown_irq_regfield = LINK_DOWN,
+};
+
+static const struct j721e_pcie_data j7200_pcie_rc_data = {
+ .mode = PCI_MODE_RC,
+ .quirk_detect_quiet_flag = true,
+ .linkdown_irq_regfield = J7200_LINK_DOWN,
+ .byte_access_allowed = true,
+};
+
+static const struct j721e_pcie_data j7200_pcie_ep_data = {
+ .mode = PCI_MODE_EP,
+ .quirk_detect_quiet_flag = true,
};

static const struct of_device_id of_j721e_pcie_match[] = {
@@ -287,6 +307,14 @@ static const struct of_device_id of_j721e_pcie_match[] = {
.compatible = "ti,j721e-pcie-ep",
.data = &j721e_pcie_ep_data,
},
+ {
+ .compatible = "ti,j7200-pcie-host",
+ .data = &j7200_pcie_rc_data,
+ },
+ {
+ .compatible = "ti,j7200-pcie-ep",
+ .data = &j7200_pcie_ep_data,
+ },
{},
};

@@ -319,6 +347,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)

pcie->dev = dev;
pcie->mode = mode;
+ pcie->linkdown_irq_regfield = data->linkdown_irq_regfield;

base = devm_platform_ioremap_resource_byname(pdev, "intd_cfg");
if (IS_ERR(base))
@@ -378,9 +407,11 @@ static int j721e_pcie_probe(struct platform_device *pdev)
goto err_get_sync;
}

- bridge->ops = &cdns_ti_pcie_host_ops;
+ if (!data->byte_access_allowed)
+ bridge->ops = &cdns_ti_pcie_host_ops;
rc = pci_host_bridge_priv(bridge);
rc->quirk_retrain_flag = data->quirk_retrain_flag;
+ rc->quirk_detect_quiet_flag = data->quirk_detect_quiet_flag;

cdns_pcie = &rc->pcie;
cdns_pcie->dev = dev;
@@ -430,6 +461,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)
ret = -ENOMEM;
goto err_get_sync;
}
+ ep->quirk_detect_quiet_flag = data->quirk_detect_quiet_flag;

cdns_pcie = &ep->pcie;
cdns_pcie->dev = dev;
--
2.30.2



2021-09-21 02:50:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 102/122] net: dsa: tag_rtl4_a: Fix egress tags

From: Linus Walleij <[email protected]>

[ Upstream commit 0e90dfa7a8d817db755c7b5d89d77b9c485e4180 ]

I noticed that only port 0 worked on the RTL8366RB since we
started to use custom tags.

It turns out that the format of egress custom tags is actually
different from ingress custom tags. While the lower bits just
contain the port number in ingress tags, egress tags need to
indicate destination port by setting the bit for the
corresponding port.

It was working on port 0 because port 0 added 0x00 as port
number in the lower bits, and if you do this the packet appears
at all ports, including the intended port. Ooops.

Fix this and all ports work again. Use the define for shifting
the "type A" into place while we're at it.

Tested on the D-Link DIR-685 by sending traffic to each of
the ports in turn. It works.

Fixes: 86dd9868b878 ("net: dsa: tag_rtl4_a: Support also egress tags")
Cc: DENG Qingfang <[email protected]>
Cc: Mauri Sandberg <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/dsa/tag_rtl4_a.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/dsa/tag_rtl4_a.c b/net/dsa/tag_rtl4_a.c
index e9176475bac8..24375ebd684e 100644
--- a/net/dsa/tag_rtl4_a.c
+++ b/net/dsa/tag_rtl4_a.c
@@ -54,9 +54,10 @@ static struct sk_buff *rtl4a_tag_xmit(struct sk_buff *skb,
p = (__be16 *)tag;
*p = htons(RTL4_A_ETHERTYPE);

- out = (RTL4_A_PROTOCOL_RTL8366RB << 12) | (2 << 8);
- /* The lower bits is the port number */
- out |= (u8)dp->index;
+ out = (RTL4_A_PROTOCOL_RTL8366RB << RTL4_A_PROTOCOL_SHIFT) | (2 << 8);
+ /* The lower bits indicate the port number */
+ out |= BIT(dp->index);
+
p = (__be16 *)(tag + 2);
*p = htons(out);

--
2.30.2



2021-09-21 02:50:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 030/122] drm/rockchip: cdn-dp-core: Make cdn_dp_core_resume __maybe_unused

From: Arnd Bergmann <[email protected]>

commit 040b8907ccf1c78d020aca29800036565d761d73 upstream.

With the new static annotation, the compiler warns when the functions
are actually unused:

drivers/gpu/drm/rockchip/cdn-dp-core.c:1123:12: error: 'cdn_dp_resume' defined but not used [-Werror=unused-function]
1123 | static int cdn_dp_resume(struct device *dev)
| ^~~~~~~~~~~~~

Mark them __maybe_unused to suppress that warning as well.

[ Not so 'new' static annotations any more, and I removed the part of
the patch that added __maybe_unused to cdn_dp_suspend(), because it's
used by the shutdown/remove code.

So only the resume function ends up possibly unused if CONFIG_PM isn't
set - Linus ]

Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1122,7 +1122,7 @@ static int cdn_dp_suspend(struct device
return ret;
}

-static int cdn_dp_resume(struct device *dev)
+static __maybe_unused int cdn_dp_resume(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);



2021-09-21 02:50:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 085/122] netfilter: nft_ct: protect nft_ct_pcpu_template_refcnt with mutex

From: Pavel Skripkin <[email protected]>

[ Upstream commit e3245a7b7b34bd2e97f744fd79463add6e9d41f4 ]

Syzbot hit use-after-free in nf_tables_dump_sets. The problem was in
missing lock protection for nft_ct_pcpu_template_refcnt.

Before commit f102d66b335a ("netfilter: nf_tables: use dedicated
mutex to guard transactions") all transactions were serialized by global
mutex, but then global mutex was changed to local per netnamespace
commit_mutex.

This change causes use-after-free bug, when 2 netnamespaces concurently
changing nft_ct_pcpu_template_refcnt without proper locking. Fix it by
adding nft_ct_pcpu_mutex and protect all nft_ct_pcpu_template_refcnt
changes with it.

Fixes: f102d66b335a ("netfilter: nf_tables: use dedicated mutex to guard transactions")
Reported-and-tested-by: [email protected]
Signed-off-by: Pavel Skripkin <[email protected]>
Acked-by: Florian Westphal <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/netfilter/nft_ct.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c
index 7af822a02ce9..7fcb73ac2e6e 100644
--- a/net/netfilter/nft_ct.c
+++ b/net/netfilter/nft_ct.c
@@ -41,6 +41,7 @@ struct nft_ct_helper_obj {
#ifdef CONFIG_NF_CONNTRACK_ZONES
static DEFINE_PER_CPU(struct nf_conn *, nft_ct_pcpu_template);
static unsigned int nft_ct_pcpu_template_refcnt __read_mostly;
+static DEFINE_MUTEX(nft_ct_pcpu_mutex);
#endif

static u64 nft_ct_get_eval_counter(const struct nf_conn_counter *c,
@@ -526,8 +527,10 @@ static void __nft_ct_set_destroy(const struct nft_ctx *ctx, struct nft_ct *priv)
#endif
#ifdef CONFIG_NF_CONNTRACK_ZONES
case NFT_CT_ZONE:
+ mutex_lock(&nft_ct_pcpu_mutex);
if (--nft_ct_pcpu_template_refcnt == 0)
nft_ct_tmpl_put_pcpu();
+ mutex_unlock(&nft_ct_pcpu_mutex);
break;
#endif
default:
@@ -565,9 +568,13 @@ static int nft_ct_set_init(const struct nft_ctx *ctx,
#endif
#ifdef CONFIG_NF_CONNTRACK_ZONES
case NFT_CT_ZONE:
- if (!nft_ct_tmpl_alloc_pcpu())
+ mutex_lock(&nft_ct_pcpu_mutex);
+ if (!nft_ct_tmpl_alloc_pcpu()) {
+ mutex_unlock(&nft_ct_pcpu_mutex);
return -ENOMEM;
+ }
nft_ct_pcpu_template_refcnt++;
+ mutex_unlock(&nft_ct_pcpu_mutex);
len = sizeof(u16);
break;
#endif
--
2.30.2



2021-09-21 02:50:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

From: Russell King (Oracle) <[email protected]>

[ Upstream commit f97493657c6372eeefe70faadd214bf31488c44e ]

Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
when moving the incorrect handling of mac link state out of mac_config().
This reason this breaks is because the stmmac's WoL is handled by the MAC
rather than the PHY, and phylink doesn't cater for that scenario.

This patch adds the necessary phylink code to handle suspend/resume events
according to whether the MAC still needs a valid link or not. This is the
barest minimum for this support.

Reported-by: Joakim Zhang <[email protected]>
Tested-by: Joakim Zhang <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
Signed-off-by: Joakim Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/phy/phylink.c | 82 +++++++++++++++++++++++++++++++++++++++
include/linux/phylink.h | 3 ++
2 files changed, 85 insertions(+)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 6072e87ed6c3..42826ce0e0bf 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -32,6 +32,7 @@
enum {
PHYLINK_DISABLE_STOPPED,
PHYLINK_DISABLE_LINK,
+ PHYLINK_DISABLE_MAC_WOL,
};

/**
@@ -1251,6 +1252,9 @@ EXPORT_SYMBOL_GPL(phylink_start);
* network device driver's &struct net_device_ops ndo_stop() method. The
* network device's carrier state should not be changed prior to calling this
* function.
+ *
+ * This will synchronously bring down the link if the link is not already
+ * down (in other words, it will trigger a mac_link_down() method call.)
*/
void phylink_stop(struct phylink *pl)
{
@@ -1270,6 +1274,84 @@ void phylink_stop(struct phylink *pl)
}
EXPORT_SYMBOL_GPL(phylink_stop);

+/**
+ * phylink_suspend() - handle a network device suspend event
+ * @pl: a pointer to a &struct phylink returned from phylink_create()
+ * @mac_wol: true if the MAC needs to receive packets for Wake-on-Lan
+ *
+ * Handle a network device suspend event. There are several cases:
+ * - If Wake-on-Lan is not active, we can bring down the link between
+ * the MAC and PHY by calling phylink_stop().
+ * - If Wake-on-Lan is active, and being handled only by the PHY, we
+ * can also bring down the link between the MAC and PHY.
+ * - If Wake-on-Lan is active, but being handled by the MAC, the MAC
+ * still needs to receive packets, so we can not bring the link down.
+ */
+void phylink_suspend(struct phylink *pl, bool mac_wol)
+{
+ ASSERT_RTNL();
+
+ if (mac_wol && (!pl->netdev || pl->netdev->wol_enabled)) {
+ /* Wake-on-Lan enabled, MAC handling */
+ mutex_lock(&pl->state_mutex);
+
+ /* Stop the resolver bringing the link up */
+ __set_bit(PHYLINK_DISABLE_MAC_WOL, &pl->phylink_disable_state);
+
+ /* Disable the carrier, to prevent transmit timeouts,
+ * but one would hope all packets have been sent. This
+ * also means phylink_resolve() will do nothing.
+ */
+ netif_carrier_off(pl->netdev);
+
+ /* We do not call mac_link_down() here as we want the
+ * link to remain up to receive the WoL packets.
+ */
+ mutex_unlock(&pl->state_mutex);
+ } else {
+ phylink_stop(pl);
+ }
+}
+EXPORT_SYMBOL_GPL(phylink_suspend);
+
+/**
+ * phylink_resume() - handle a network device resume event
+ * @pl: a pointer to a &struct phylink returned from phylink_create()
+ *
+ * Undo the effects of phylink_suspend(), returning the link to an
+ * operational state.
+ */
+void phylink_resume(struct phylink *pl)
+{
+ ASSERT_RTNL();
+
+ if (test_bit(PHYLINK_DISABLE_MAC_WOL, &pl->phylink_disable_state)) {
+ /* Wake-on-Lan enabled, MAC handling */
+
+ /* Call mac_link_down() so we keep the overall state balanced.
+ * Do this under the state_mutex lock for consistency. This
+ * will cause a "Link Down" message to be printed during
+ * resume, which is harmless - the true link state will be
+ * printed when we run a resolve.
+ */
+ mutex_lock(&pl->state_mutex);
+ phylink_link_down(pl);
+ mutex_unlock(&pl->state_mutex);
+
+ /* Re-apply the link parameters so that all the settings get
+ * restored to the MAC.
+ */
+ phylink_mac_initial_config(pl, true);
+
+ /* Re-enable and re-resolve the link parameters */
+ clear_bit(PHYLINK_DISABLE_MAC_WOL, &pl->phylink_disable_state);
+ phylink_run_resolve(pl);
+ } else {
+ phylink_start(pl);
+ }
+}
+EXPORT_SYMBOL_GPL(phylink_resume);
+
/**
* phylink_ethtool_get_wol() - get the wake on lan parameters for the PHY
* @pl: a pointer to a &struct phylink returned from phylink_create()
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index d81a714cfbbd..ff56e3e373f0 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -446,6 +446,9 @@ void phylink_mac_change(struct phylink *, bool up);
void phylink_start(struct phylink *);
void phylink_stop(struct phylink *);

+void phylink_suspend(struct phylink *pl, bool mac_wol);
+void phylink_resume(struct phylink *pl);
+
void phylink_ethtool_get_wol(struct phylink *, struct ethtool_wolinfo *);
int phylink_ethtool_set_wol(struct phylink *, struct ethtool_wolinfo *);

--
2.30.2



2021-09-21 02:50:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 075/122] PCI: ibmphp: Fix double unmap of io_mem

From: Vishal Aslot <[email protected]>

[ Upstream commit faa2e05ad0dccf37f995bcfbb8d1980d66c02c11 ]

ebda_rsrc_controller() calls iounmap(io_mem) on the error path. Its caller,
ibmphp_access_ebda(), also calls iounmap(io_mem) on good and error paths.

Remove the iounmap(io_mem) invocation from ebda_rsrc_controller().

[bhelgaas: remove item from TODO]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vishal Aslot <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/hotplug/TODO | 3 ---
drivers/pci/hotplug/ibmphp_ebda.c | 5 +----
2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/pci/hotplug/TODO b/drivers/pci/hotplug/TODO
index a32070be5adf..cc6194aa24c1 100644
--- a/drivers/pci/hotplug/TODO
+++ b/drivers/pci/hotplug/TODO
@@ -40,9 +40,6 @@ ibmphp:

* The return value of pci_hp_register() is not checked.

-* iounmap(io_mem) is called in the error path of ebda_rsrc_controller()
- and once more in the error path of its caller ibmphp_access_ebda().
-
* The various slot data structures are difficult to follow and need to be
simplified. A lot of functions are too large and too complex, they need
to be broken up into smaller, manageable pieces. Negative examples are
diff --git a/drivers/pci/hotplug/ibmphp_ebda.c b/drivers/pci/hotplug/ibmphp_ebda.c
index 11a2661dc062..7fb75401ad8a 100644
--- a/drivers/pci/hotplug/ibmphp_ebda.c
+++ b/drivers/pci/hotplug/ibmphp_ebda.c
@@ -714,8 +714,7 @@ static int __init ebda_rsrc_controller(void)
/* init hpc structure */
hpc_ptr = alloc_ebda_hpc(slot_num, bus_num);
if (!hpc_ptr) {
- rc = -ENOMEM;
- goto error_no_hpc;
+ return -ENOMEM;
}
hpc_ptr->ctlr_id = ctlr_id;
hpc_ptr->ctlr_relative_id = ctlr;
@@ -910,8 +909,6 @@ error:
kfree(tmp_slot);
error_no_slot:
free_ebda_hpc(hpc_ptr);
-error_no_hpc:
- iounmap(io_mem);
return rc;
}

--
2.30.2



2021-09-21 02:50:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 088/122] mfd: tqmx86: Clear GPIO IRQ resource when no IRQ is set

From: Matthias Schiffer <[email protected]>

[ Upstream commit a946506c48f3bd09363c9d2b0a178e55733bcbb6 ]

The driver was registering IRQ 0 when no IRQ was set. This leads to
warnings with newer kernels.

Clear the resource flags, so no resource is registered at all in this
case.

Fixes: 2f17dd34ffed ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO")
Signed-off-by: Matthias Schiffer <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/mfd/tqmx86.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/tqmx86.c b/drivers/mfd/tqmx86.c
index ddddf08b6a4c..732013f40e4e 100644
--- a/drivers/mfd/tqmx86.c
+++ b/drivers/mfd/tqmx86.c
@@ -209,6 +209,8 @@ static int tqmx86_probe(struct platform_device *pdev)

/* Assumes the IRQ resource is first. */
tqmx_gpio_resources[0].start = gpio_irq;
+ } else {
+ tqmx_gpio_resources[0].flags = 0;
}

ocores_platfom_data.clock_khz = tqmx86_board_id_to_clk_rate(board_id);
--
2.30.2



2021-09-21 02:51:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 063/122] PCI: rcar: Fix runtime PM imbalance in rcar_pcie_ep_probe()

From: Dinghao Liu <[email protected]>

[ Upstream commit 1e29cd9983eba1b596bc07f94d81d728007f8a25 ]

pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dinghao Liu <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/pci/controller/pcie-rcar-ep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/pcie-rcar-ep.c b/drivers/pci/controller/pcie-rcar-ep.c
index b4a288e24aaf..c91d85b15129 100644
--- a/drivers/pci/controller/pcie-rcar-ep.c
+++ b/drivers/pci/controller/pcie-rcar-ep.c
@@ -492,9 +492,9 @@ static int rcar_pcie_ep_probe(struct platform_device *pdev)
pcie->dev = dev;

pm_runtime_enable(dev);
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
- dev_err(dev, "pm_runtime_get_sync failed\n");
+ dev_err(dev, "pm_runtime_resume_and_get failed\n");
goto err_pm_disable;
}

--
2.30.2



2021-09-21 02:51:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 107/122] netfilter: socket: icmp6: fix use-after-scope

From: Benjamin Hesmans <[email protected]>

[ Upstream commit 730affed24bffcd1eebd5903171960f5ff9f1f22 ]

Bug reported by KASAN:

BUG: KASAN: use-after-scope in inet6_ehashfn (net/ipv6/inet6_hashtables.c:40)
Call Trace:
(...)
inet6_ehashfn (net/ipv6/inet6_hashtables.c:40)
(...)
nf_sk_lookup_slow_v6 (net/ipv6/netfilter/nf_socket_ipv6.c:91
net/ipv6/netfilter/nf_socket_ipv6.c:146)

It seems that this bug has already been fixed by Eric Dumazet in the
past in:
commit 78296c97ca1f ("netfilter: xt_socket: fix a stack corruption bug")

But a variant of the same issue has been introduced in
commit d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match")

`daddr` and `saddr` potentially hold a reference to ipv6_var that is no
longer in scope when the call to `nf_socket_get_sock_v6` is made.

Fixes: d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match")
Acked-by: Matthieu Baerts <[email protected]>
Signed-off-by: Benjamin Hesmans <[email protected]>
Reviewed-by: Florian Westphal <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/ipv6/netfilter/nf_socket_ipv6.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/net/ipv6/netfilter/nf_socket_ipv6.c b/net/ipv6/netfilter/nf_socket_ipv6.c
index 6fd54744cbc3..aa5bb8789ba0 100644
--- a/net/ipv6/netfilter/nf_socket_ipv6.c
+++ b/net/ipv6/netfilter/nf_socket_ipv6.c
@@ -99,7 +99,7 @@ struct sock *nf_sk_lookup_slow_v6(struct net *net, const struct sk_buff *skb,
{
__be16 dport, sport;
const struct in6_addr *daddr = NULL, *saddr = NULL;
- struct ipv6hdr *iph = ipv6_hdr(skb);
+ struct ipv6hdr *iph = ipv6_hdr(skb), ipv6_var;
struct sk_buff *data_skb = NULL;
int doff = 0;
int thoff = 0, tproto;
@@ -129,8 +129,6 @@ struct sock *nf_sk_lookup_slow_v6(struct net *net, const struct sk_buff *skb,
thoff + sizeof(*hp);

} else if (tproto == IPPROTO_ICMPV6) {
- struct ipv6hdr ipv6_var;
-
if (extract_icmp6_fields(skb, thoff, &tproto, &saddr, &daddr,
&sport, &dport, &ipv6_var))
return NULL;
--
2.30.2



2021-09-21 02:51:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 097/122] perf unwind: Do not overwrite FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64}

From: Li Huafei <[email protected]>

[ Upstream commit cdf32b44678c382a31dc183d9a767306915cda7b ]

When setting LIBUNWIND_DIR, we first set

FEATURE_CHECK_LDFLAGS-libunwind-{aarch64,x86} = -L$(LIBUNWIND_DIR)/lib.

<committer note>
This happens a bit before, the overwritting, in:

libunwind_arch_set_flags = $(eval $(libunwind_arch_set_flags_code))
define libunwind_arch_set_flags_code
FEATURE_CHECK_CFLAGS-libunwind-$(1) = -I$(LIBUNWIND_DIR)/include
FEATURE_CHECK_LDFLAGS-libunwind-$(1) = -L$(LIBUNWIND_DIR)/lib
endef

ifdef LIBUNWIND_DIR
LIBUNWIND_CFLAGS = -I$(LIBUNWIND_DIR)/include
LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib
LIBUNWIND_ARCHS = x86 x86_64 arm aarch64 debug-frame-arm debug-frame-aarch64
$(foreach libunwind_arch,$(LIBUNWIND_ARCHS),$(call libunwind_arch_set_flags,$(libunwind_arch)))
endif

Look at that 'foreach' on all the LIBUNWIND_ARCHS.
</>

After commit 5c4d7c82c0dc ("perf unwind: Do not put libunwind-{x86,aarch64}
in FEATURE_TESTS_BASIC"), FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64} is
overwritten. As a result, the remote libunwind libraries cannot be searched
from $(LIBUNWIND_DIR)/lib directory during feature check tests. Fix it with
variable appending.

Before this patch:

perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64
BUILD: Doing 'make -j16' parallel build
<SNIP>
...
... libopencsd: [ OFF ]
... libunwind-x86: [ OFF ]
... libunwind-x86_64: [ OFF ]
... libunwind-arm: [ OFF ]
... libunwind-aarch64: [ OFF ]
... libunwind-debug-frame: [ OFF ]
... libunwind-debug-frame-arm: [ OFF ]
... libunwind-debug-frame-aarch64: [ OFF ]
... cxx: [ OFF ]
<SNIP>

perf$ cat ../build/feature/test-libunwind-aarch64.make.output
/usr/bin/ld: cannot find -lunwind-aarch64
/usr/bin/ld: cannot find -lunwind-aarch64
collect2: error: ld returned 1 exit status

After this patch:

perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64
BUILD: Doing 'make -j16' parallel build
<SNIP>
... libopencsd: [ OFF ]
... libunwind-x86: [ OFF ]
... libunwind-x86_64: [ OFF ]
... libunwind-arm: [ OFF ]
... libunwind-aarch64: [ on ]
... libunwind-debug-frame: [ OFF ]
... libunwind-debug-frame-arm: [ OFF ]
... libunwind-debug-frame-aarch64: [ OFF ]
... cxx: [ OFF ]
<SNIP>

perf$ cat ../build/feature/test-libunwind-aarch64.make.output

perf$ ldd ./perf
linux-vdso.so.1 (0x00007ffdf07da000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30953dc000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f30951d4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3094e36000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3094c32000)
libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f3094a18000)
libdw.so.1 => /usr/lib/x86_64-linux-gnu/libdw.so.1 (0x00007f30947cc000)
libunwind-x86_64.so.8 => /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8 (0x00007f30945ad000)
libunwind.so.8 => /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007f3094392000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f309416c000)
libunwind-aarch64.so.8 => not found
libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 (0x00007f3093c8a000)
libpython2.7.so.1.0 => /usr/local/lib/libpython2.7.so.1.0 (0x00007f309386b000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f309364e000)
libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f3093443000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3093052000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3096097000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3092e42000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3092c3f000)

Fixes: 5c4d7c82c0dceccf ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC")
Signed-off-by: Li Huafei <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: He Kuang <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Zhang Jinhao <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
tools/perf/Makefile.config | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 2abbd75fbf2e..014b959575ca 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -127,10 +127,10 @@ FEATURE_CHECK_LDFLAGS-libunwind = $(LIBUNWIND_LDFLAGS) $(LIBUNWIND_LIBS)
FEATURE_CHECK_CFLAGS-libunwind-debug-frame = $(LIBUNWIND_CFLAGS)
FEATURE_CHECK_LDFLAGS-libunwind-debug-frame = $(LIBUNWIND_LDFLAGS) $(LIBUNWIND_LIBS)

-FEATURE_CHECK_LDFLAGS-libunwind-arm = -lunwind -lunwind-arm
-FEATURE_CHECK_LDFLAGS-libunwind-aarch64 = -lunwind -lunwind-aarch64
-FEATURE_CHECK_LDFLAGS-libunwind-x86 = -lunwind -llzma -lunwind-x86
-FEATURE_CHECK_LDFLAGS-libunwind-x86_64 = -lunwind -llzma -lunwind-x86_64
+FEATURE_CHECK_LDFLAGS-libunwind-arm += -lunwind -lunwind-arm
+FEATURE_CHECK_LDFLAGS-libunwind-aarch64 += -lunwind -lunwind-aarch64
+FEATURE_CHECK_LDFLAGS-libunwind-x86 += -lunwind -llzma -lunwind-x86
+FEATURE_CHECK_LDFLAGS-libunwind-x86_64 += -lunwind -llzma -lunwind-x86_64

FEATURE_CHECK_LDFLAGS-libcrypto = -lcrypto

--
2.30.2



2021-09-21 02:51:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 103/122] selftests: mptcp: clean tmp files in simult_flows

From: Matthieu Baerts <[email protected]>

[ Upstream commit bfd862a7e9318dd906844807a713d27cdd1a72b1 ]

'$cin' and '$sin' variables are local to a function: they are then not
available from the cleanup trap.

Instead, we need to use '$large' and '$small' that are not local and
defined just before setting the trap.

Without this patch, running this script in a loop might cause a:

write: No space left on device

issue.

Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests")
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: Mat Martineau <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
tools/testing/selftests/net/mptcp/simult_flows.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/testing/selftests/net/mptcp/simult_flows.sh
index 2f649b431456..8fcb28927818 100755
--- a/tools/testing/selftests/net/mptcp/simult_flows.sh
+++ b/tools/testing/selftests/net/mptcp/simult_flows.sh
@@ -21,8 +21,8 @@ usage() {

cleanup()
{
- rm -f "$cin" "$cout"
- rm -f "$sin" "$sout"
+ rm -f "$cout" "$sout"
+ rm -f "$large" "$small"
rm -f "$capout"

local netns
--
2.30.2



2021-09-21 02:51:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 101/122] gpio: mpc8xxx: Use devm_gpiochip_add_data() to simplify the code and avoid a leak

From: Christophe JAILLET <[email protected]>

[ Upstream commit 889a1b3f35db6ba5ba6a0c23a3a55594570b6a17 ]

If an error occurs after a 'gpiochip_add_data()' call it must be undone by
a corresponding 'gpiochip_remove()' as already done in the remove function.

To simplify the code a fix a leak in the error handling path of the probe,
use the managed version instead (i.e. 'devm_gpiochip_add_data()')

Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal")
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpio/gpio-mpc8xxx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index a4983c5d1f16..023b99bf098d 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -374,7 +374,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)
of_device_is_compatible(np, "fsl,ls1088a-gpio"))
gc->write_reg(mpc8xxx_gc->regs + GPIO_IBE, 0xffffffff);

- ret = gpiochip_add_data(gc, mpc8xxx_gc);
+ ret = devm_gpiochip_add_data(&pdev->dev, gc, mpc8xxx_gc);
if (ret) {
pr_err("%pOF: GPIO chip registration failed with status %d\n",
np, ret);
@@ -419,8 +419,6 @@ static int mpc8xxx_remove(struct platform_device *pdev)
irq_domain_remove(mpc8xxx_gc->irq);
}

- gpiochip_remove(&mpc8xxx_gc->gc);
-
return 0;
}

--
2.30.2



2021-09-21 02:52:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 094/122] PCI: Sync __pci_register_driver() stub for CONFIG_PCI=n

From: Andy Shevchenko <[email protected]>

[ Upstream commit 817f9916a6e96ae43acdd4e75459ef4f92d96eb1 ]

The CONFIG_PCI=y case got a new parameter long time ago. Sync the stub as
well.

[bhelgaas: add parameter names]
Fixes: 725522b5453d ("PCI: add the sysfs driver name to all modules")
Link: https://lore.kernel.org/r/[email protected]
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
include/linux/pci.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 22207a79762c..a55097b4d992 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1713,8 +1713,9 @@ static inline void pci_disable_device(struct pci_dev *dev) { }
static inline int pcim_enable_device(struct pci_dev *pdev) { return -EIO; }
static inline int pci_assign_resource(struct pci_dev *dev, int i)
{ return -EBUSY; }
-static inline int __pci_register_driver(struct pci_driver *drv,
- struct module *owner)
+static inline int __must_check __pci_register_driver(struct pci_driver *drv,
+ struct module *owner,
+ const char *mod_name)
{ return 0; }
static inline int pci_register_driver(struct pci_driver *drv)
{ return 0; }
--
2.30.2



2021-09-21 03:26:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 015/122] drm/etnaviv: fix MMU context leak on GPU reset

From: Lucas Stach <[email protected]>

commit f978a5302f5566480c58ffae64a16d34456801bd upstream.

After a reset the GPU is no longer using the MMU context and may be
restarted with a different context. While the mmu_state proeprly was
cleared, the context wasn't unreferenced, leading to a memory leak.

Cc: [email protected] # 5.4
Reported-by: Michael Walle <[email protected]>
Signed-off-by: Lucas Stach <[email protected]>
Tested-by: Michael Walle <[email protected]>
Tested-by: Marek Vasut <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -563,6 +563,8 @@ static int etnaviv_hw_reset(struct etnav

gpu->fe_running = false;
gpu->exec_state = -1;
+ if (gpu->mmu_context)
+ etnaviv_iommu_context_put(gpu->mmu_context);
gpu->mmu_context = NULL;

return 0;


2021-09-21 03:26:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 041/122] x86/uaccess: Fix 32-bit __get_user_asm_u64() when CC_HAS_ASM_GOTO_OUTPUT=y

From: Will Deacon <[email protected]>

commit a69ae291e1cc2d08ae77c2029579c59c9bde5061 upstream.

Commit 865c50e1d279 ("x86/uaccess: utilize CONFIG_CC_HAS_ASM_GOTO_OUTPUT")
added an optimised version of __get_user_asm() for x86 using 'asm goto'.

Like the non-optimised code, the 32-bit implementation of 64-bit
get_user() expands to a pair of 32-bit accesses. Unlike the
non-optimised code, the _original_ pointer is incremented to copy the
high word instead of loading through a new pointer explicitly
constructed to point at a 32-bit type. Consequently, if the pointer
points at a 64-bit type then we end up loading the wrong data for the
upper 32-bits.

This was observed as a mount() failure in Android targeting i686 after
b0cfcdd9b967 ("d_path: make 'prepend()' fill up the buffer exactly on
overflow") because the call to copy_from_kernel_nofault() from
prepend_copy() ends up in __get_kernel_nofault() and casts the source
pointer to a 'u64 __user *'. An attempt to mount at "/debug_ramdisk"
therefore ends up failing trying to mount "/debumdismdisk".

Use the existing '__gu_ptr' source pointer to unsigned int for 32-bit
__get_user_asm_u64() instead of the original pointer.

Cc: Bill Wendling <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Reported-by: Greg Kroah-Hartman <[email protected]>
Fixes: 865c50e1d279 ("x86/uaccess: utilize CONFIG_CC_HAS_ASM_GOTO_OUTPUT")
Signed-off-by: Will Deacon <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -301,8 +301,8 @@ do { \
unsigned int __gu_low, __gu_high; \
const unsigned int __user *__gu_ptr; \
__gu_ptr = (const void __user *)(ptr); \
- __get_user_asm(__gu_low, ptr, "l", "=r", label); \
- __get_user_asm(__gu_high, ptr+1, "l", "=r", label); \
+ __get_user_asm(__gu_low, __gu_ptr, "l", "=r", label); \
+ __get_user_asm(__gu_high, __gu_ptr+1, "l", "=r", label); \
(x) = ((unsigned long long)__gu_high << 32) | __gu_low; \
} while (0)
#else


2021-09-21 03:58:54

by Fox Chen

[permalink] [raw]
Subject: RE: [PATCH 5.10 000/122] 5.10.68-rc1 review

On Mon, 20 Sep 2021 18:42:52 +0200, Greg Kroah-Hartman <[email protected]> wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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.68-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

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

2021-09-21 04:05:07

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

On 9/20/21 9:42 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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-09-21 04:08:33

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

On 9/20/21 9:42 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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

[snip]

> Rafał Miłecki <[email protected]>
> net: dsa: b53: Set correct number of ports in the DSA struct

This patch will cause an out of bounds access on two platforms that use
the b53 driver, you would need to wait for this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=02319bf15acf54004216e40ac9c171437f24be24

to land in Linus' tree and then you can also take Rafal's b53 change.
This is applicable to both the 5.14 and 5.10 trees and any tree where
this change would be back ported to in between.

Thank you!
--
Florian

2021-09-21 04:08:52

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

On 9/20/21 11:39 AM, Florian Fainelli wrote:
> On 9/20/21 9:42 AM, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 5.10.68 release.
>> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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]>
>

Sorry taking that back, the merge did not really happen so I was not
testing 5.10.68 but 5.10.67, see my other comment about one of the
patches causing a regression, thanks!
--
Florian

2021-09-21 04:17:24

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

Hi!

> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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) (663.00 B)
signature.asc (201.00 B)
Download all attachments

2021-09-21 14:33:03

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH 5.10 116/122] bnxt_en: Convert to use netif_level() helpers.

On Mon, 2021-09-20 at 18:44 +0200, Greg Kroah-Hartman wrote:
> From: Michael Chan <[email protected]>
>
> [ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ]
>
> Use the various netif_level() helpers to simplify the C code. This was
> suggested by Joe Perches.

There isn't an actual change here.

Unless this is a precursor to another patch, this isn't anything
that should go into stable.


2021-09-21 15:06:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 116/122] bnxt_en: Convert to use netif_level() helpers.

On Tue, Sep 21, 2021 at 07:30:42AM -0700, Joe Perches wrote:
> On Mon, 2021-09-20 at 18:44 +0200, Greg Kroah-Hartman wrote:
> > From: Michael Chan <[email protected]>
> >
> > [ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ]
> >
> > Use the various netif_level() helpers to simplify the C code. This was
> > suggested by Joe Perches.
>
> There isn't an actual change here.
>
> Unless this is a precursor to another patch, this isn't anything
> that should go into stable.
>
>

It is a dependancy for other fixes.

thanks,

greg k-h

2021-09-21 15:34:32

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

On 9/20/21 10:42 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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-09-21 15:53:08

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH 5.10 116/122] bnxt_en: Convert to use netif_level() helpers.

On Tue, 2021-09-21 at 17:04 +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 21, 2021 at 07:30:42AM -0700, Joe Perches wrote:
> > On Mon, 2021-09-20 at 18:44 +0200, Greg Kroah-Hartman wrote:
> > > From: Michael Chan <[email protected]>
> > >
> > > [ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ]
> > >
> > > Use the various netif_level() helpers to simplify the C code. This was
> > > suggested by Joe Perches.
> >
> > There isn't an actual change here.
> >
> > Unless this is a precursor to another patch, this isn't anything
> > that should go into stable.
> >
> It is a dependancy for other fixes.

Then it's useful/necessary to mark it as such when applying it.

2021-09-21 15:58:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 116/122] bnxt_en: Convert to use netif_level() helpers.

On Tue, Sep 21, 2021 at 08:49:52AM -0700, Joe Perches wrote:
> On Tue, 2021-09-21 at 17:04 +0200, Greg Kroah-Hartman wrote:
> > On Tue, Sep 21, 2021 at 07:30:42AM -0700, Joe Perches wrote:
> > > On Mon, 2021-09-20 at 18:44 +0200, Greg Kroah-Hartman wrote:
> > > > From: Michael Chan <[email protected]>
> > > >
> > > > [ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ]
> > > >
> > > > Use the various netif_level() helpers to simplify the C code. This was
> > > > suggested by Joe Perches.
> > >
> > > There isn't an actual change here.
> > >
> > > Unless this is a precursor to another patch, this isn't anything
> > > that should go into stable.
> > >
> > It is a dependancy for other fixes.
>
> Then it's useful/necessary to mark it as such when applying it.
>

That's hard/difficult/messy to do :)

2021-09-21 16:07:28

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH 5.10 116/122] bnxt_en: Convert to use netif_level() helpers.

On Tue, 2021-09-21 at 17:53 +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 21, 2021 at 08:49:52AM -0700, Joe Perches wrote:
> > On Tue, 2021-09-21 at 17:04 +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Sep 21, 2021 at 07:30:42AM -0700, Joe Perches wrote:
> > > > On Mon, 2021-09-20 at 18:44 +0200, Greg Kroah-Hartman wrote:
> > > > > From: Michael Chan <[email protected]>
> > > > >
> > > > > [ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ]
> > > > >
> > > > > Use the various netif_level() helpers to simplify the C code. This was
> > > > > suggested by Joe Perches.
> > > >
> > > > There isn't an actual change here.
> > > >
> > > > Unless this is a precursor to another patch, this isn't anything
> > > > that should go into stable.
> > > >
> > > It is a dependancy for other fixes.
> >
> > Then it's useful/necessary to mark it as such when applying it.
> >
>
> That's hard/difficult/messy to do :)

Smiley faces don't make the work you do any easier.

Nor better.

You are specifically pulling dependencies.
It doesn't seem particularly difficult to script.

2021-09-21 16:37:21

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

On 9/20/21 12:00 PM, Florian Fainelli wrote:
> On 9/20/21 11:39 AM, Florian Fainelli wrote:
>> On 9/20/21 9:42 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.10.68 release.
>>> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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]>
>>
>
> Sorry taking that back, the merge did not really happen so I was not
> testing 5.10.68 but 5.10.67, see my other comment about one of the
> patches causing a regression, thanks!

With the updated v5.10.68-rc1 tag at:

commit bb6d31464809e017d8cfd65963f6e802d7d1c66b
(linux-stable-rc/linux-5.10.y)
Author: Greg Kroah-Hartman <[email protected]>
Date: Tue Sep 21 08:59:30 2021 +0200

Linux 5.10.68-rc1


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

Thanks Greg!
--
Florian

2021-09-21 19:53:38

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

Hi Greg,

On Mon, Sep 20, 2021 at 06:42:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +0000.
> Anything received after that time might be too late.

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

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]

[1]. https://openqa.qa.codethink.co.uk/tests/164


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

--
Regards
Sudip

2021-09-21 23:07:30

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

On Mon, Sep 20, 2021 at 06:42:52PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +0000.
> Anything received after that time might be too late.
>

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

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

Guenter

2021-09-21 23:54:08

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 100/122] gpio: mpc8xxx: Fix a potential double iounmap call in mpc8xxx_probe()

Hi!

> [ Upstream commit 7d6588931ccd4c09e70a08175cf2e0cf7fc3b869 ]
>
> Commit 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") has switched to a
> managed version when dealing with 'mpc8xxx_gc->regs'. So the corresponding
> 'iounmap()' call in the error handling path and in the remove should be
> removed to avoid a double unmap.

This is wrong, AFAICT. 5.10 does not have 76c47d1449fc ("gpio:
mpc8xxx: Add ACPI support") so iounmap is still neccessary and this
adds a memory leak.

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


Attachments:
(No filename) (682.00 B)
signature.asc (201.00 B)
Download all attachments

2021-09-22 00:07:05

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

Hi!

> Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
> when moving the incorrect handling of mac link state out of mac_config().
> This reason this breaks is because the stmmac's WoL is handled by the MAC
> rather than the PHY, and phylink doesn't cater for that scenario.
>
> This patch adds the necessary phylink code to handle suspend/resume events
> according to whether the MAC still needs a valid link or not. This is the
> barest minimum for this support.

This adds functions that end up being unused in 5.10. AFAICT we do not
need this in 5.10.

Best regards,
Pavel


> +++ b/include/linux/phylink.h
> @@ -446,6 +446,9 @@ void phylink_mac_change(struct phylink *, bool up);
> void phylink_start(struct phylink *);
> void phylink_stop(struct phylink *);
>
> +void phylink_suspend(struct phylink *pl, bool mac_wol);
> +void phylink_resume(struct phylink *pl);
> +
> void phylink_ethtool_get_wol(struct phylink *, struct ethtool_wolinfo *);
> int phylink_ethtool_set_wol(struct phylink *, struct ethtool_wolinfo *);


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


Attachments:
(No filename) (1.22 kB)
signature.asc (201.00 B)
Download all attachments

2021-09-22 00:07:23

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

On Tue, Sep 21, 2021 at 11:28:37PM +0200, Pavel Machek wrote:
> Hi!
>
> > Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
> > when moving the incorrect handling of mac link state out of mac_config().
> > This reason this breaks is because the stmmac's WoL is handled by the MAC
> > rather than the PHY, and phylink doesn't cater for that scenario.
> >
> > This patch adds the necessary phylink code to handle suspend/resume events
> > according to whether the MAC still needs a valid link or not. This is the
> > barest minimum for this support.
>
> This adds functions that end up being unused in 5.10. AFAICT we do not
> need this in 5.10.

It needs to be backported to any kernel that also has
"net: stmmac: fix MAC not working when system resume back with WoL active"
backported to. From what I can tell, the fixes line in that commit
refers to a commit (46f69ded988d) in v5.7-rc1.

If "net: stmmac: fix MAC not working when system resume back with WoL
active" is not being backported to 5.10, then there is no need to
backport this patch.

As I'm not being copied on the stmmac commit, I've no idea which kernels
this patch should be backported to.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

2021-09-22 00:11:40

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

On Tue, Sep 21, 2021 at 11:45:28PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
> > > > when moving the incorrect handling of mac link state out of mac_config().
> > > > This reason this breaks is because the stmmac's WoL is handled by the MAC
> > > > rather than the PHY, and phylink doesn't cater for that scenario.
> > > >
> > > > This patch adds the necessary phylink code to handle suspend/resume events
> > > > according to whether the MAC still needs a valid link or not. This is the
> > > > barest minimum for this support.
> > >
> > > This adds functions that end up being unused in 5.10. AFAICT we do not
> > > need this in 5.10.
> >
> > It needs to be backported to any kernel that also has
> > "net: stmmac: fix MAC not working when system resume back with WoL active"
> > backported to. From what I can tell, the fixes line in that commit
> > refers to a commit (46f69ded988d) in v5.7-rc1.
> >
> > If "net: stmmac: fix MAC not working when system resume back with WoL
> > active" is not being backported to 5.10, then there is no need to
> > backport this patch.
>
> Agreed.
>
> > As I'm not being copied on the stmmac commit, I've no idea which kernels
> > this patch should be backported to.
>
> AFAICT "net: stmmac: fix MAC not working when..." is not queued for
> 5.10.68-rc1 or 5.14.7-rc1.

Okay, this is madness. What is going on with stable's patch selection?
The logic seems completely reversed.

"net: phylink: Update SFP selected interface on advertising changes"
does not have a Fixes tag, and is not a fix in itself, yet has been
picked up by the stable team. It lays the necessary work for its
counter-part patch, which is...

"net: stmmac: fix system hang caused by eee_ctrl_timer during
suspend/resume" _has_ a Fixes tag, but has *not* been picked up by
the stable team.

It seems there's something very wrong process-wise here. Why would
a patch _without_ a Fixes line and isn't a fix in itself be picked
out for stable backport when patches with a Fixes line are ignored?

Not unless the stable plan is to apply "net: phylink: Update SFP
selected interface on advertising changes" and then sometime later
apply "net: stmmac: fix system hang caused by eee_ctrl_timer during
suspend/resume". No idea.

It all seems very weird and the process seems broken to me.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

2021-09-22 02:01:00

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

Hi!

> > > Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
> > > when moving the incorrect handling of mac link state out of mac_config().
> > > This reason this breaks is because the stmmac's WoL is handled by the MAC
> > > rather than the PHY, and phylink doesn't cater for that scenario.
> > >
> > > This patch adds the necessary phylink code to handle suspend/resume events
> > > according to whether the MAC still needs a valid link or not. This is the
> > > barest minimum for this support.
> >
> > This adds functions that end up being unused in 5.10. AFAICT we do not
> > need this in 5.10.
>
> It needs to be backported to any kernel that also has
> "net: stmmac: fix MAC not working when system resume back with WoL active"
> backported to. From what I can tell, the fixes line in that commit
> refers to a commit (46f69ded988d) in v5.7-rc1.
>
> If "net: stmmac: fix MAC not working when system resume back with WoL
> active" is not being backported to 5.10, then there is no need to
> backport this patch.

Agreed.

> As I'm not being copied on the stmmac commit, I've no idea which kernels
> this patch should be backported to.

AFAICT "net: stmmac: fix MAC not working when..." is not queued for
5.10.68-rc1 or 5.14.7-rc1.

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


Attachments:
(No filename) (1.44 kB)
signature.asc (201.00 B)
Download all attachments

2021-09-22 02:12:55

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review



On 2021/9/21 0:42, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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.68-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.68-rc1
Commit: bb6d31464809e017d8cfd65963f6e802d7d1c66b
Compiler: gcc version 7.3.0 (GCC)

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

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

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

2021-09-22 04:59:14

by Daniel Díaz

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

Hello!

On 9/20/21 11:42 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.68 release.
> There are 122 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, 22 Sep 2021 16:38:49 +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.68-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.

## Build
* kernel: 5.10.68-rc1
* git: ['https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc', 'https://gitlab.com/Linaro/lkft/users/daniel.diaz/linux']
* git branch: linux-5.10.y
* git commit: bb6d31464809e017d8cfd65963f6e802d7d1c66b
* git describe: v5.10.67-125-gbb6d31464809
* test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.67-125-gbb6d31464809

## No regressions (compared to v5.10.67)

## No fixes (compared to v5.10.67)

## Test result summary
total: 164462, pass: 138894, fail: 765, skip: 23000, xfail: 1803

## Build Summary
* arc: 20 total, 20 passed, 0 failed
* arm: 578 total, 578 passed, 0 failed
* arm64: 77 total, 77 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 75 total, 75 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 102 total, 102 passed, 0 failed
* parisc: 24 total, 24 passed, 0 failed
* powerpc: 72 total, 70 passed, 2 failed
* riscv: 60 total, 60 passed, 0 failed
* s390: 36 total, 36 passed, 0 failed
* sh: 48 total, 48 passed, 0 failed
* sparc: 24 total, 24 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 77 total, 77 passed, 0 failed

## Test suites summary
* fwts
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-arm64
* 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
* prep-tmp-disk
* rcutorture
* ssuite
* v4l2-compliance


Greetings!

Daniel Díaz
[email protected]

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

2021-09-22 05:32:52

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/122] 5.10.68-rc1 review

On Wed, 22 Sept 2021 at 10:25, Daniel Díaz <[email protected]> wrote:
>
> Hello!
>
> On 9/20/21 11:42 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.68 release.
> > There are 122 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, 22 Sep 2021 16:38:49 +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.68-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.68-rc1
> * git: ['https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc', 'https://gitlab.com/Linaro/lkft/users/daniel.diaz/linux']
> * git branch: linux-5.10.y
> * git commit: bb6d31464809e017d8cfd65963f6e802d7d1c66b
> * git describe: v5.10.67-125-gbb6d31464809
> * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.67-125-gbb6d31464809
>
> ## No regressions (compared to v5.10.67)
>
> ## No fixes (compared to v5.10.67)
>
> ## Test result summary
> total: 164462, pass: 138894, fail: 765, skip: 23000, xfail: 1803
>
> ## Build Summary
> * arc: 20 total, 20 passed, 0 failed
> * arm: 578 total, 578 passed, 0 failed
> * arm64: 77 total, 77 passed, 0 failed
> * dragonboard-410c: 1 total, 1 passed, 0 failed
> * hi6220-hikey: 1 total, 1 passed, 0 failed
> * i386: 75 total, 75 passed, 0 failed
> * juno-r2: 1 total, 1 passed, 0 failed
> * mips: 102 total, 102 passed, 0 failed
> * parisc: 24 total, 24 passed, 0 failed
> * powerpc: 72 total, 70 passed, 2 failed
> * riscv: 60 total, 60 passed, 0 failed
> * s390: 36 total, 36 passed, 0 failed
> * sh: 48 total, 48 passed, 0 failed
> * sparc: 24 total, 24 passed, 0 failed
> * x15: 1 total, 1 passed, 0 failed
> * x86: 1 total, 1 passed, 0 failed
> * x86_64: 77 total, 77 passed, 0 failed
>
> ## Test suites summary
> * fwts
> * install-android-platform-tools-r2600
> * kselftest-android
> * kselftest-arm64
> * 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
> * prep-tmp-disk
> * rcutorture
> * ssuite
> * v4l2-compliance
>
>
> Greetings!
>
> Daniel Díaz
> [email protected]
>
> --
> Linaro LKFT
> https://lkft.linaro.org

2021-09-22 08:59:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

On Tue, Sep 21, 2021 at 11:45:28PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
> > > > when moving the incorrect handling of mac link state out of mac_config().
> > > > This reason this breaks is because the stmmac's WoL is handled by the MAC
> > > > rather than the PHY, and phylink doesn't cater for that scenario.
> > > >
> > > > This patch adds the necessary phylink code to handle suspend/resume events
> > > > according to whether the MAC still needs a valid link or not. This is the
> > > > barest minimum for this support.
> > >
> > > This adds functions that end up being unused in 5.10. AFAICT we do not
> > > need this in 5.10.
> >
> > It needs to be backported to any kernel that also has
> > "net: stmmac: fix MAC not working when system resume back with WoL active"
> > backported to. From what I can tell, the fixes line in that commit
> > refers to a commit (46f69ded988d) in v5.7-rc1.
> >
> > If "net: stmmac: fix MAC not working when system resume back with WoL
> > active" is not being backported to 5.10, then there is no need to
> > backport this patch.
>
> Agreed.
>
> > As I'm not being copied on the stmmac commit, I've no idea which kernels
> > this patch should be backported to.
>
> AFAICT "net: stmmac: fix MAC not working when..." is not queued for
> 5.10.68-rc1 or 5.14.7-rc1.

I can easily do that, thanks!

greg k-h

2021-09-22 09:00:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

On Tue, Sep 21, 2021 at 11:02:52PM +0100, Russell King (Oracle) wrote:
> On Tue, Sep 21, 2021 at 11:45:28PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
> > > > > when moving the incorrect handling of mac link state out of mac_config().
> > > > > This reason this breaks is because the stmmac's WoL is handled by the MAC
> > > > > rather than the PHY, and phylink doesn't cater for that scenario.
> > > > >
> > > > > This patch adds the necessary phylink code to handle suspend/resume events
> > > > > according to whether the MAC still needs a valid link or not. This is the
> > > > > barest minimum for this support.
> > > >
> > > > This adds functions that end up being unused in 5.10. AFAICT we do not
> > > > need this in 5.10.
> > >
> > > It needs to be backported to any kernel that also has
> > > "net: stmmac: fix MAC not working when system resume back with WoL active"
> > > backported to. From what I can tell, the fixes line in that commit
> > > refers to a commit (46f69ded988d) in v5.7-rc1.
> > >
> > > If "net: stmmac: fix MAC not working when system resume back with WoL
> > > active" is not being backported to 5.10, then there is no need to
> > > backport this patch.
> >
> > Agreed.
> >
> > > As I'm not being copied on the stmmac commit, I've no idea which kernels
> > > this patch should be backported to.
> >
> > AFAICT "net: stmmac: fix MAC not working when..." is not queued for
> > 5.10.68-rc1 or 5.14.7-rc1.
>
> Okay, this is madness. What is going on with stable's patch selection?
> The logic seems completely reversed.
>
> "net: phylink: Update SFP selected interface on advertising changes"
> does not have a Fixes tag, and is not a fix in itself, yet has been
> picked up by the stable team. It lays the necessary work for its
> counter-part patch, which is...
>
> "net: stmmac: fix system hang caused by eee_ctrl_timer during
> suspend/resume" _has_ a Fixes tag, but has *not* been picked up by
> the stable team.
>
> It seems there's something very wrong process-wise here. Why would
> a patch _without_ a Fixes line and isn't a fix in itself be picked
> out for stable backport when patches with a Fixes line are ignored?

Because they came in through two different sets of processes. And
during the -rc1 merge window madness, we have lots to still catch up on
because of all of the "fixes" that people wait to get into the tree
then.

> Not unless the stable plan is to apply "net: phylink: Update SFP
> selected interface on advertising changes" and then sometime later
> apply "net: stmmac: fix system hang caused by eee_ctrl_timer during
> suspend/resume". No idea.
>
> It all seems very weird and the process seems broken to me.

Help is always gladly accepted. Marking patches explicitly for stable
with a cc: stable is always the easiest way into the tree. Otherwise we
have to do hueristics in looking at changelog text and Fixes: tags to
try to guess what is, and is not, valid for stable trees.

thanks,

greg k-h

2021-09-22 09:04:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 079/122] net: phylink: add suspend/resume support

On Wed, Sep 22, 2021 at 10:58:02AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 21, 2021 at 11:45:28PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > Joakim Zhang reports that Wake-on-Lan with the stmmac ethernet driver broke
> > > > > when moving the incorrect handling of mac link state out of mac_config().
> > > > > This reason this breaks is because the stmmac's WoL is handled by the MAC
> > > > > rather than the PHY, and phylink doesn't cater for that scenario.
> > > > >
> > > > > This patch adds the necessary phylink code to handle suspend/resume events
> > > > > according to whether the MAC still needs a valid link or not. This is the
> > > > > barest minimum for this support.
> > > >
> > > > This adds functions that end up being unused in 5.10. AFAICT we do not
> > > > need this in 5.10.
> > >
> > > It needs to be backported to any kernel that also has
> > > "net: stmmac: fix MAC not working when system resume back with WoL active"
> > > backported to. From what I can tell, the fixes line in that commit
> > > refers to a commit (46f69ded988d) in v5.7-rc1.
> > >
> > > If "net: stmmac: fix MAC not working when system resume back with WoL
> > > active" is not being backported to 5.10, then there is no need to
> > > backport this patch.
> >
> > Agreed.
> >
> > > As I'm not being copied on the stmmac commit, I've no idea which kernels
> > > this patch should be backported to.
> >
> > AFAICT "net: stmmac: fix MAC not working when..." is not queued for
> > 5.10.68-rc1 or 5.14.7-rc1.
>
> I can easily do that, thanks!

Only applied to 5.14, so I'll drop this patch from the 5.10 queue.

thanks,

greg k-h

2021-09-22 09:07:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 100/122] gpio: mpc8xxx: Fix a potential double iounmap call in mpc8xxx_probe()

On Tue, Sep 21, 2021 at 11:25:26PM +0200, Pavel Machek wrote:
> Hi!
>
> > [ Upstream commit 7d6588931ccd4c09e70a08175cf2e0cf7fc3b869 ]
> >
> > Commit 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") has switched to a
> > managed version when dealing with 'mpc8xxx_gc->regs'. So the corresponding
> > 'iounmap()' call in the error handling path and in the remove should be
> > removed to avoid a double unmap.
>
> This is wrong, AFAICT. 5.10 does not have 76c47d1449fc ("gpio:
> mpc8xxx: Add ACPI support") so iounmap is still neccessary and this
> adds a memory leak.

Ah, but then I have to drop 889a1b3f35db ("gpio: mpc8xxx: Use
'devm_gpiochip_add_data()' to simplify the code and avoid a leak") from
the 5.10 queue as it depends on this one.

Can you provide a working backport of that commit so that I can queue up
the fix?

thanks,

greg k-h

2021-09-22 09:10:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 100/122] gpio: mpc8xxx: Fix a potential double iounmap call in mpc8xxx_probe()

On Wed, Sep 22, 2021 at 11:05:19AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 21, 2021 at 11:25:26PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > [ Upstream commit 7d6588931ccd4c09e70a08175cf2e0cf7fc3b869 ]
> > >
> > > Commit 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") has switched to a
> > > managed version when dealing with 'mpc8xxx_gc->regs'. So the corresponding
> > > 'iounmap()' call in the error handling path and in the remove should be
> > > removed to avoid a double unmap.
> >
> > This is wrong, AFAICT. 5.10 does not have 76c47d1449fc ("gpio:
> > mpc8xxx: Add ACPI support") so iounmap is still neccessary and this
> > adds a memory leak.
>
> Ah, but then I have to drop 889a1b3f35db ("gpio: mpc8xxx: Use
> 'devm_gpiochip_add_data()' to simplify the code and avoid a leak") from
> the 5.10 queue as it depends on this one.
>
> Can you provide a working backport of that commit so that I can queue up
> the fix?

Oh nevermind, I fixed it up myself.

greg k-h

2021-09-22 21:03:41

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 100/122] gpio: mpc8xxx: Fix a potential double iounmap call in mpc8xxx_probe()

Hi!

> > > > Commit 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") has switched to a
> > > > managed version when dealing with 'mpc8xxx_gc->regs'. So the corresponding
> > > > 'iounmap()' call in the error handling path and in the remove should be
> > > > removed to avoid a double unmap.
> > >
> > > This is wrong, AFAICT. 5.10 does not have 76c47d1449fc ("gpio:
> > > mpc8xxx: Add ACPI support") so iounmap is still neccessary and this
> > > adds a memory leak.
> >
> > Ah, but then I have to drop 889a1b3f35db ("gpio: mpc8xxx: Use
> > 'devm_gpiochip_add_data()' to simplify the code and avoid a leak") from
> > the 5.10 queue as it depends on this one.
> >
> > Can you provide a working backport of that commit so that I can queue up
> > the fix?
>
> Oh nevermind, I fixed it up myself.

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


Attachments:
(No filename) (991.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments