2021-02-08 17:31:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 000/120] 5.10.15-rc1 review

This is the start of the stable review cycle for the 5.10.15 release.
There are 120 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, 10 Feb 2021 14:57:55 +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.15-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.15-rc1

Alexander Ovechkin <[email protected]>
net: sched: replaced invalid qdisc tree flush helper in qdisc_replace

DENG Qingfang <[email protected]>
net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add

Dongseok Yi <[email protected]>
udp: ipv4: manipulate network header of NATed UDP GRO fraglist

Vadim Fedorenko <[email protected]>
net: ip_tunnel: fix mtu calculation

Chinmay Agarwal <[email protected]>
neighbour: Prevent a dead entry from updating gc_list

Kai-Heng Feng <[email protected]>
igc: Report speed and duplex as unknown when device is runtime suspended

Xiao Ni <[email protected]>
md: Set prev_flush_start and flush_bio in an atomic way

Marek Vasut <[email protected]>
Input: ili210x - implement pressure reporting for ILI251x

Benjamin Valentin <[email protected]>
Input: xpad - sync supported devices with fork on GitHub

AngeloGioacchino Del Regno <[email protected]>
Input: goodix - add support for Goodix GT9286 chip

Dave Hansen <[email protected]>
x86/apic: Add extra serialization for non-serializing MSRs

Lai Jiangshan <[email protected]>
x86/debug: Prevent data breakpoints on cpu_dr7

Lai Jiangshan <[email protected]>
x86/debug: Prevent data breakpoints on __per_cpu_offset

Peter Zijlstra <[email protected]>
x86/debug: Fix DR6 handling

Josh Poimboeuf <[email protected]>
x86/build: Disable CET instrumentation in the kernel

Waiman Long <[email protected]>
mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked()

Hugh Dickins <[email protected]>
mm: thp: fix MADV_REMOVE deadlock on shmem THP

Rick Edgecombe <[email protected]>
mm/vmalloc: separate put pages and flush VM flags

Rokudo Yan <[email protected]>
mm, compaction: move high_pfn to the for loop scope

Muchun Song <[email protected]>
mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active

Muchun Song <[email protected]>
mm: hugetlb: fix a race between isolating and freeing page

Muchun Song <[email protected]>
mm: hugetlb: fix a race between freeing and dissolving the page

Muchun Song <[email protected]>
mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page

Dmitry Osipenko <[email protected]>
ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor

Russell King <[email protected]>
ARM: footbridge: fix dc21285 PCI configuration accessors

H. Nikolaus Schaller <[email protected]>
ARM: dts; gta04: SPI panel chip select is active low

H. Nikolaus Schaller <[email protected]>
DTS: ARM: gta04: remove legacy spi-cs-high to make display work again

Sean Christopherson <[email protected]>
KVM: x86: Set so called 'reserved CR3 bits in LM mask' at vCPU reset

Sean Christopherson <[email protected]>
KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode

Michael Roth <[email protected]>
KVM: x86: fix CPUID entries returned by KVM_GET_CPUID2 ioctl

Paolo Bonzini <[email protected]>
KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off

Ben Gardon <[email protected]>
KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEs

Sean Christopherson <[email protected]>
KVM: SVM: Treat SVM as unsupported when running as an SEV guest

Thorsten Leemhuis <[email protected]>
nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs

Xiaoguang Wang <[email protected]>
io_uring: don't modify identity's files uncess identity is cowed

Stylon Wang <[email protected]>
drm/amd/display: Revert "Fix EDID parsing after resume from suspend"

Ville Syrjälä <[email protected]>
drm/i915: Power up combo PHY lanes for for HDMI as well

Ville Syrjälä <[email protected]>
drm/i915: Extract intel_ddi_power_up_lanes()

Andres Calderon Jaramillo <[email protected]>
drm/i915/display: Prevent double YUV range correction on HDR planes

Chris Wilson <[email protected]>
drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs

Chris Wilson <[email protected]>
drm/i915/gem: Drop lru bumping on display unpinning

Imre Deak <[email protected]>
drm/i915: Fix the MST PBN divider calculation

Imre Deak <[email protected]>
drm/dp/mst: Export drm_dp_get_vc_payload_bw()

Peter Gonda <[email protected]>
Fix unsynchronized access to sev members through svm_register_enc_region

Fengnan Chang <[email protected]>
mmc: core: Limit retries when analyse of SDIO tuples fails

Ulf Hansson <[email protected]>
mmc: sdhci-pltfm: Fix linking err for sdhci-brcmstb

Pavel Shilovsky <[email protected]>
smb3: fix crediting for compounding when only one request in flight

Gustavo A. R. Silva <[email protected]>
smb3: Fix out-of-bounds bug in SMB2_negotiate()

Joerg Roedel <[email protected]>
iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it

Aurelien Aptel <[email protected]>
cifs: report error instead of invalid when revalidating a dentry fails

Atish Patra <[email protected]>
RISC-V: Define MAXPHYSMEM_1GB only for RV32

Mathias Nyman <[email protected]>
xhci: fix bounce buffer usage for non-sg list case

Rolf Eike Beer <[email protected]>
scripts: use pkg-config to locate libcrypto

Marc Zyngier <[email protected]>
genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set

Hans de Goede <[email protected]>
genirq: Prevent [devm_]irq_alloc_desc from returning irq 0

Dan Williams <[email protected]>
libnvdimm/dimm: Avoid race between probe and available_slots_show()

Dan Williams <[email protected]>
libnvdimm/namespace: Fix visibility of namespace resource attribute

Alexey Kardashevskiy <[email protected]>
tracepoint: Fix race between tracing and removing tracepoint

Viktor Rosendahl <[email protected]>
tracing: Use pause-on-trace with the latency tracers

Wang ShaoBo <[email protected]>
kretprobe: Avoid re-registration of the same kretprobe earlier

Masami Hiramatsu <[email protected]>
tracing/kprobe: Fix to support kretprobe events on unloaded modules

Steven Rostedt (VMware) <[email protected]>
fgraph: Initialize tracing_graph_pause at task creation

Quanyang Wang <[email protected]>
gpiolib: free device name on error path to fix kmemleak

Felix Fietkau <[email protected]>
mac80211: fix station rate table updates on assoc

Sargun Dhillon <[email protected]>
ovl: implement volatile-specific fsync error behaviour

Miklos Szeredi <[email protected]>
ovl: avoid deadlock on directory ioctl

Liangyan <[email protected]>
ovl: fix dentry leak in ovl_get_redirect

Mario Limonciello <[email protected]>
thunderbolt: Fix possible NULL pointer dereference in tb_acpi_add_link()

Masahiro Yamada <[email protected]>
kbuild: fix duplicated flags in DEBUG_CFLAGS

Roman Gushchin <[email protected]>
memblock: do not start bottom-up allocations with kernel_end

Eli Cohen <[email protected]>
vdpa/mlx5: Restore the hardware used index after change map

Sagi Grimberg <[email protected]>
nvmet-tcp: fix out-of-bounds access when receiving multiple h2cdata PDUs

Hermann Lauer <[email protected]>
ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode

Dan Carpenter <[email protected]>
net: ipa: pass correct dma_handle to dma_free_coherent()

Heiner Kallweit <[email protected]>
r8169: fix WoL on shutdown if CONFIG_DEBUG_SHIRQ is set

Stefan Chulski <[email protected]>
net: mvpp2: TCAM entry enable should be written after SRAM data

Xie He <[email protected]>
net: lapb: Copy the skb before sending a packet

Maor Dickman <[email protected]>
net/mlx5e: Release skb in case of failure in tc update skb

Maxim Mikityanskiy <[email protected]>
net/mlx5e: Update max_opened_tc also when channels are closed

Maor Gottlieb <[email protected]>
net/mlx5: Fix leak upon failure of rule creation

Daniel Jurgens <[email protected]>
net/mlx5: Fix function calculation for page trees

Lijun Pan <[email protected]>
ibmvnic: device remove has higher precedence over reset

Aleksandr Loktionov <[email protected]>
i40e: Revert "i40e: don't report link up for a VF who hasn't enabled queues"

Kevin Lo <[email protected]>
igc: check return value of ret_val in igc_config_fc_after_link_up

Kevin Lo <[email protected]>
igc: set the default return value to -IGC_ERR_NVM in igc_write_nvm_srwr

Chuck Lever <[email protected]>
SUNRPC: Fix NFS READs that start at non-page-aligned offsets

Zyta Szpak <[email protected]>
arm64: dts: ls1046a: fix dcfg address range

David Howells <[email protected]>
rxrpc: Fix deadlock around release of dst cached on udp tunnel

Heiner Kallweit <[email protected]>
r8169: work around RTL8125 UDP hw bug

Marek Szyprowski <[email protected]>
arm64: dts: meson: switch TFLASH_VDD_EN pin to open drain on Odroid-C4

Quentin Monnet <[email protected]>
bpf, preload: Fix build when $(O) points to a relative path

Johannes Berg <[email protected]>
um: virtio: free vu_dev only with the contained struct device

Pan Bian <[email protected]>
bpf, inode_storage: Put file handler if no storage was found

Loris Reiff <[email protected]>
bpf, cgroup: Fix problematic bounds check

Loris Reiff <[email protected]>
bpf, cgroup: Fix optlen WARN_ON_ONCE toctou

Eli Cohen <[email protected]>
vdpa/mlx5: Fix memory key MTT population

Marek Vasut <[email protected]>
ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02

Marek Vasut <[email protected]>
ARM: dts: stm32: Disable optional TSC2004 on DRC02 board

Marek Vasut <[email protected]>
ARM: dts: stm32: Disable WP on DHCOM uSD slot

Marek Vasut <[email protected]>
ARM: dts: stm32: Connect card-detect signal on DHCOM

Marek Vasut <[email protected]>
ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detect

Simon South <[email protected]>
arm64: dts: rockchip: Use only supported PCIe link speed on Pinebook Pro

Sandy Huang <[email protected]>
arm64: dts: rockchip: fix vopl iommu irq on px30

Serge Semin <[email protected]>
arm64: dts: amlogic: meson-g12: Set FL-adj property value

Alexey Dobriyan <[email protected]>
Input: i8042 - unbreak Pegatron C15B

Shawn Guo <[email protected]>
arm64: dts: qcom: c630: keep both touchpad devices enabled

Linus Walleij <[email protected]>
ARM: OMAP1: OSK: fix ohci-omap breakage

Chunfeng Yun <[email protected]>
usb: xhci-mtk: break loop when find the endpoint to drop

Chunfeng Yun <[email protected]>
usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints

Ikjoon Jang <[email protected]>
usb: xhci-mtk: fix unreleased bandwidth data

Gary Bisson <[email protected]>
usb: dwc3: fix clock issue during resume in OTG mode

Heiko Stuebner <[email protected]>
usb: dwc2: Fix endpoint direction check in ep_from_windex

Yoshihiro Shimoda <[email protected]>
usb: renesas_usbhs: Clear pipe running flag in usbhs_pkt_pop()

Jeremy Figgins <[email protected]>
USB: usblp: don't call usb_set_interface if there's a single alt

kernel test robot <[email protected]>
usb: gadget: aspeed: add missing of_node_put

Dan Carpenter <[email protected]>
USB: gadget: legacy: fix an error code in eth_bind()

Pali Rohár <[email protected]>
usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720

Christoph Schemmel <[email protected]>
USB: serial: option: Adding support for Cinterion MV31

Chenxin Jin <[email protected]>
USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000

Pho Tran <[email protected]>
USB: serial: cp210x: add pid/vid for WSDA-200-USB


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

Diffstat:

Documentation/filesystems/overlayfs.rst | 8 ++
Makefile | 14 +--
arch/arm/boot/dts/omap3-gta04.dtsi | 3 +-
arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi | 12 +-
arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi | 3 +-
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 2 +-
arch/arm/include/debug/tegra.S | 54 ++++-----
arch/arm/mach-footbridge/dc21285.c | 12 +-
arch/arm/mach-omap1/board-osk.c | 2 +
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +-
.../arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts | 2 +-
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 2 +-
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 10 +-
arch/arm64/boot/dts/rockchip/px30.dtsi | 2 +-
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 1 -
arch/riscv/Kconfig | 2 +
arch/um/drivers/virtio_uml.c | 3 +-
arch/x86/Makefile | 3 +
arch/x86/include/asm/apic.h | 10 --
arch/x86/include/asm/barrier.h | 18 +++
arch/x86/kernel/apic/apic.c | 4 +
arch/x86/kernel/apic/x2apic_cluster.c | 6 +-
arch/x86/kernel/apic/x2apic_phys.c | 9 +-
arch/x86/kernel/hw_breakpoint.c | 61 ++++++----
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/emulate.c | 2 +
arch/x86/kvm/mmu/tdp_mmu.c | 6 +-
arch/x86/kvm/svm/sev.c | 17 +--
arch/x86/kvm/svm/svm.c | 5 +
arch/x86/kvm/vmx/vmx.c | 17 ++-
arch/x86/kvm/x86.c | 27 +++--
arch/x86/mm/mem_encrypt.c | 1 +
drivers/gpio/gpiolib.c | 10 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 -
drivers/gpu/drm/drm_dp_mst_topology.c | 24 +++-
drivers/gpu/drm/i915/display/intel_ddi.c | 37 +++---
drivers/gpu/drm/i915/display/intel_display.c | 9 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +-
drivers/gpu/drm/i915/display/intel_overlay.c | 4 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 65 ++---------
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 45 -------
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 -
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 +-
drivers/input/joystick/xpad.c | 17 ++-
drivers/input/serio/i8042-x86ia64io.h | 2 +
drivers/input/touchscreen/goodix.c | 2 +
drivers/input/touchscreen/ili210x.c | 26 +++--
drivers/md/md.c | 2 +
drivers/mmc/core/sdio_cis.c | 6 +
drivers/mmc/host/sdhci-pltfm.h | 7 +-
drivers/net/dsa/mv88e6xxx/chip.c | 6 +-
drivers/net/ethernet/ibm/ibmvnic.c | 5 -
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 13 +--
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 1 -
drivers/net/ethernet/intel/igc/igc_ethtool.c | 3 +-
drivers/net/ethernet/intel/igc/igc_i225.c | 3 +-
drivers/net/ethernet/intel/igc/igc_mac.c | 2 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 10 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 16 ++-
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 5 +
.../net/ethernet/mellanox/mlx5/core/pagealloc.c | 2 +-
drivers/net/ethernet/realtek/r8169_main.c | 75 ++++++++++--
drivers/net/ipa/gsi.c | 2 +-
drivers/nvdimm/dimm_devs.c | 18 ++-
drivers/nvdimm/namespace_devs.c | 10 +-
drivers/nvme/host/pci.c | 2 +
drivers/nvme/target/tcp.c | 3 +-
drivers/thunderbolt/acpi.c | 2 +-
drivers/usb/class/usblp.c | 19 +--
drivers/usb/dwc2/gadget.c | 8 +-
drivers/usb/dwc3/core.c | 2 +-
drivers/usb/gadget/legacy/ether.c | 4 +-
drivers/usb/gadget/udc/aspeed-vhub/hub.c | 4 +-
drivers/usb/host/xhci-mtk-sch.c | 130 +++++++++++++++------
drivers/usb/host/xhci-mtk.c | 2 +
drivers/usb/host/xhci-mtk.h | 15 +++
drivers/usb/host/xhci-mvebu.c | 42 +++++++
drivers/usb/host/xhci-mvebu.h | 6 +
drivers/usb/host/xhci-plat.c | 20 +++-
drivers/usb/host/xhci-plat.h | 1 +
drivers/usb/host/xhci-ring.c | 31 +++--
drivers/usb/host/xhci.c | 8 +-
drivers/usb/host/xhci.h | 4 +
drivers/usb/renesas_usbhs/fifo.c | 1 +
drivers/usb/serial/cp210x.c | 2 +
drivers/usb/serial/option.c | 6 +
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 1 +
drivers/vdpa/mlx5/core/mr.c | 28 ++---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 +++
fs/afs/main.c | 6 +-
fs/cifs/dir.c | 22 +++-
fs/cifs/smb2pdu.h | 2 +-
fs/cifs/transport.c | 18 ++-
fs/hugetlbfs/inode.c | 3 +-
fs/io_uring.c | 6 -
fs/overlayfs/dir.c | 2 +-
fs/overlayfs/file.c | 5 +-
fs/overlayfs/overlayfs.h | 1 +
fs/overlayfs/ovl_entry.h | 2 +
fs/overlayfs/readdir.c | 28 ++---
fs/overlayfs/super.c | 34 ++++--
fs/overlayfs/util.c | 27 +++++
include/drm/drm_dp_mst_helper.h | 1 +
include/linux/hugetlb.h | 2 +
include/linux/iommu.h | 5 +-
include/linux/irq.h | 4 +-
include/linux/kprobes.h | 2 +-
include/linux/msi.h | 6 +
include/linux/tracepoint.h | 12 +-
include/linux/vmalloc.h | 9 +-
include/net/sch_generic.h | 2 +-
include/net/udp.h | 2 +-
init/init_task.c | 3 +-
kernel/bpf/bpf_inode_storage.c | 6 +-
kernel/bpf/cgroup.c | 7 +-
kernel/bpf/preload/Makefile | 5 +-
kernel/irq/msi.c | 44 ++++---
kernel/kprobes.c | 36 ++++--
kernel/trace/fgraph.c | 2 -
kernel/trace/trace_irqsoff.c | 4 +
kernel/trace/trace_kprobe.c | 10 +-
mm/compaction.c | 3 +-
mm/filemap.c | 4 +
mm/huge_memory.c | 37 +++---
mm/hugetlb.c | 48 +++++++-
mm/memblock.c | 49 +-------
net/core/neighbour.c | 7 +-
net/ipv4/ip_tunnel.c | 16 ++-
net/ipv4/udp_offload.c | 69 ++++++++++-
net/ipv6/udp_offload.c | 2 +-
net/lapb/lapb_out.c | 3 +-
net/mac80211/driver-ops.c | 5 +-
net/mac80211/rate.c | 3 +-
net/rxrpc/af_rxrpc.c | 6 +-
net/sunrpc/svcsock.c | 7 +-
scripts/Makefile | 8 +-
137 files changed, 1106 insertions(+), 606 deletions(-)



2021-02-08 17:32:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 012/120] usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints

From: Chunfeng Yun <[email protected]>

commit 54f6a8af372213a254af6609758d99f7c0b6b5ad upstream.

For those unchecked endpoints, we don't allocate bandwidth for
them, so no need free the bandwidth, otherwise will decrease
the allocated bandwidth.
Meanwhile use xhci_dbg() instead of dev_dbg() to print logs and
rename bw_ep_list_new as bw_ep_chk_list.

Fixes: 1d69f9d901ef ("usb: xhci-mtk: fix unreleased bandwidth data")
Cc: stable <[email protected]>
Reviewed-and-tested-by: Ikjoon Jang <[email protected]>
Signed-off-by: Chunfeng Yun <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-mtk-sch.c | 61 +++++++++++++++++++++-------------------
drivers/usb/host/xhci-mtk.h | 4 +-
2 files changed, 36 insertions(+), 29 deletions(-)

--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -200,6 +200,7 @@ static struct mu3h_sch_ep_info *create_s

sch_ep->sch_tt = tt;
sch_ep->ep = ep;
+ INIT_LIST_HEAD(&sch_ep->endpoint);
INIT_LIST_HEAD(&sch_ep->tt_endpoint);

return sch_ep;
@@ -374,6 +375,7 @@ static void update_bus_bw(struct mu3h_sc
sch_ep->bw_budget_table[j];
}
}
+ sch_ep->allocated = used;
}

static int check_sch_tt(struct usb_device *udev,
@@ -542,6 +544,22 @@ static int check_sch_bw(struct usb_devic
return 0;
}

+static void destroy_sch_ep(struct usb_device *udev,
+ struct mu3h_sch_bw_info *sch_bw, struct mu3h_sch_ep_info *sch_ep)
+{
+ /* only release ep bw check passed by check_sch_bw() */
+ if (sch_ep->allocated)
+ update_bus_bw(sch_bw, sch_ep, 0);
+
+ list_del(&sch_ep->endpoint);
+
+ if (sch_ep->sch_tt) {
+ list_del(&sch_ep->tt_endpoint);
+ drop_tt(udev);
+ }
+ kfree(sch_ep);
+}
+
static bool need_bw_sch(struct usb_host_endpoint *ep,
enum usb_device_speed speed, int has_tt)
{
@@ -584,7 +602,7 @@ int xhci_mtk_sch_init(struct xhci_hcd_mt

mtk->sch_array = sch_array;

- INIT_LIST_HEAD(&mtk->bw_ep_list_new);
+ INIT_LIST_HEAD(&mtk->bw_ep_chk_list);

return 0;
}
@@ -636,29 +654,12 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd

setup_sch_info(udev, ep_ctx, sch_ep);

- list_add_tail(&sch_ep->endpoint, &mtk->bw_ep_list_new);
+ list_add_tail(&sch_ep->endpoint, &mtk->bw_ep_chk_list);

return 0;
}
EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);

-static void xhci_mtk_drop_ep(struct xhci_hcd_mtk *mtk, struct usb_device *udev,
- struct mu3h_sch_ep_info *sch_ep)
-{
- struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
- int bw_index = get_bw_index(xhci, udev, sch_ep->ep);
- struct mu3h_sch_bw_info *sch_bw = &mtk->sch_array[bw_index];
-
- update_bus_bw(sch_bw, sch_ep, 0);
- list_del(&sch_ep->endpoint);
-
- if (sch_ep->sch_tt) {
- list_del(&sch_ep->tt_endpoint);
- drop_tt(udev);
- }
- kfree(sch_ep);
-}
-
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep)
{
@@ -688,9 +689,8 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
sch_bw = &sch_array[bw_index];

list_for_each_entry_safe(sch_ep, tmp, &sch_bw->bw_ep_list, endpoint) {
- if (sch_ep->ep == ep) {
- xhci_mtk_drop_ep(mtk, udev, sch_ep);
- }
+ if (sch_ep->ep == ep)
+ destroy_sch_ep(udev, sch_bw, sch_ep);
}
}
EXPORT_SYMBOL_GPL(xhci_mtk_drop_ep_quirk);
@@ -704,9 +704,9 @@ int xhci_mtk_check_bandwidth(struct usb_
struct mu3h_sch_ep_info *sch_ep, *tmp;
int bw_index, ret;

- dev_dbg(&udev->dev, "%s\n", __func__);
+ xhci_dbg(xhci, "%s() udev %s\n", __func__, dev_name(&udev->dev));

- list_for_each_entry(sch_ep, &mtk->bw_ep_list_new, endpoint) {
+ list_for_each_entry(sch_ep, &mtk->bw_ep_chk_list, endpoint) {
bw_index = get_bw_index(xhci, udev, sch_ep->ep);
sch_bw = &mtk->sch_array[bw_index];

@@ -717,7 +717,7 @@ int xhci_mtk_check_bandwidth(struct usb_
}
}

- list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_chk_list, endpoint) {
struct xhci_ep_ctx *ep_ctx;
struct usb_host_endpoint *ep = sch_ep->ep;
unsigned int ep_index = xhci_get_endpoint_index(&ep->desc);
@@ -746,12 +746,17 @@ EXPORT_SYMBOL_GPL(xhci_mtk_check_bandwid
void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct mu3h_sch_bw_info *sch_bw;
struct mu3h_sch_ep_info *sch_ep, *tmp;
+ int bw_index;

- dev_dbg(&udev->dev, "%s\n", __func__);
+ xhci_dbg(xhci, "%s() udev %s\n", __func__, dev_name(&udev->dev));

- list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
- xhci_mtk_drop_ep(mtk, udev, sch_ep);
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_chk_list, endpoint) {
+ bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ sch_bw = &mtk->sch_array[bw_index];
+ destroy_sch_ep(udev, sch_bw, sch_ep);
}

xhci_reset_bandwidth(hcd, udev);
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -59,6 +59,7 @@ struct mu3h_sch_bw_info {
* @ep_type: endpoint type
* @maxpkt: max packet size of endpoint
* @ep: address of usb_host_endpoint struct
+ * @allocated: the bandwidth is aready allocated from bus_bw
* @offset: which uframe of the interval that transfer should be
* scheduled first time within the interval
* @repeat: the time gap between two uframes that transfers are
@@ -86,6 +87,7 @@ struct mu3h_sch_ep_info {
u32 ep_type;
u32 maxpkt;
void *ep;
+ bool allocated;
/*
* mtk xHCI scheduling information put into reserved DWs
* in ep context
@@ -130,8 +132,8 @@ struct mu3c_ippc_regs {
struct xhci_hcd_mtk {
struct device *dev;
struct usb_hcd *hcd;
- struct list_head bw_ep_list_new;
struct mu3h_sch_bw_info *sch_array;
+ struct list_head bw_ep_chk_list;
struct mu3c_ippc_regs __iomem *ippc_regs;
bool has_ippc;
int num_u2_ports;


2021-02-08 17:32:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 094/120] DTS: ARM: gta04: remove legacy spi-cs-high to make display work again

From: H. Nikolaus Schaller <[email protected]>

commit 07af7810e0a5bc4e51682c90f9fa19fc4cb93f18 upstream.

This reverts

commit f1f028ff89cb ("DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again")

which had to be intruduced after

commit 6953c57ab172 ("gpio: of: Handle SPI chipselect legacy bindings")

broke the GTA04 display. This contradicted the data sheet but was the only
way to get it as an spi client operational again.

The panel data sheet defines the chip-select to be active low.

Now, with the arrival of

commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")

the logic of interaction between spi-cs-high and the gpio descriptor flags
has been changed a second time, making the display broken again. So we have
to remove the original fix which in retrospect was a workaround of a bug in
the spi subsystem and not a feature of the panel or bug in the device tree.

With this fix the device tree is back in sync with the data sheet and
spi subsystem code.

Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
CC: [email protected]
Signed-off-by: H. Nikolaus Schaller <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 1 -
1 file changed, 1 deletion(-)

--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -124,7 +124,6 @@
spi-max-frequency = <100000>;
spi-cpol;
spi-cpha;
- spi-cs-high;

backlight= <&backlight>;
label = "lcd";


2021-02-08 17:32:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 092/120] KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode

From: Sean Christopherson <[email protected]>

commit 943dea8af21bd896e0d6c30ea221203fb3cd3265 upstream.

Set the emulator context to PROT64 if SYSENTER transitions from 32-bit
userspace (compat mode) to a 64-bit kernel, otherwise the RIP update at
the end of x86_emulate_insn() will incorrectly truncate the new RIP.

Note, this bug is mostly limited to running an Intel virtual CPU model on
an AMD physical CPU, as other combinations of virtual and physical CPUs
do not trigger full emulation. On Intel CPUs, SYSENTER in compatibility
mode is legal, and unconditionally transitions to 64-bit mode. On AMD
CPUs, SYSENTER is illegal in compatibility mode and #UDs. If the vCPU is
AMD, KVM injects a #UD on SYSENTER in compat mode. If the pCPU is Intel,
SYSENTER will execute natively and not trigger #UD->VM-Exit (ignoring
guest TLB shenanigans).

Fixes: fede8076aab4 ("KVM: x86: handle wrap around 32-bit address space")
Cc: [email protected]
Signed-off-by: Jonny Barker <[email protected]>
[sean: wrote changelog]
Signed-off-by: Sean Christopherson <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kvm/emulate.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2879,6 +2879,8 @@ static int em_sysenter(struct x86_emulat
ops->get_msr(ctxt, MSR_IA32_SYSENTER_ESP, &msr_data);
*reg_write(ctxt, VCPU_REGS_RSP) = (efer & EFER_LMA) ? msr_data :
(u32)msr_data;
+ if (efer & EFER_LMA)
+ ctxt->mode = X86EMUL_MODE_PROT64;

return X86EMUL_CONTINUE;
}


2021-02-08 17:33:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 091/120] KVM: x86: fix CPUID entries returned by KVM_GET_CPUID2 ioctl

From: Michael Roth <[email protected]>

commit 181f494888d5b178ffda41bed965f187d5e5c432 upstream.

Recent commit 255cbecfe0 modified struct kvm_vcpu_arch to make
'cpuid_entries' a pointer to an array of kvm_cpuid_entry2 entries
rather than embedding the array in the struct. KVM_SET_CPUID and
KVM_SET_CPUID2 were updated accordingly, but KVM_GET_CPUID2 was missed.

As a result, KVM_GET_CPUID2 currently returns random fields from struct
kvm_vcpu_arch to userspace rather than the expected CPUID values. Fix
this by treating 'cpuid_entries' as a pointer when copying its
contents to userspace buffer.

Fixes: 255cbecfe0c9 ("KVM: x86: allocate vcpu->arch.cpuid_entries dynamically")
Cc: Vitaly Kuznetsov <[email protected]>
Signed-off-by: Michael Roth <[email protected]>
Message-Id: <[email protected]>
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kvm/cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -320,7 +320,7 @@ int kvm_vcpu_ioctl_get_cpuid2(struct kvm
if (cpuid->nent < vcpu->arch.cpuid_nent)
goto out;
r = -EFAULT;
- if (copy_to_user(entries, &vcpu->arch.cpuid_entries,
+ if (copy_to_user(entries, vcpu->arch.cpuid_entries,
vcpu->arch.cpuid_nent * sizeof(struct kvm_cpuid_entry2)))
goto out;
return 0;


2021-02-08 17:33:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 089/120] KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEs

From: Ben Gardon <[email protected]>

commit 87aa9ec939ec7277b730786e19c161c9194cc8ca upstream.

There is a bug in the TDP MMU function to zap SPTEs which could be
replaced with a larger mapping which prevents the function from doing
anything. Fix this by correctly zapping the last level SPTEs.

Cc: [email protected]
Fixes: 14881998566d ("kvm: x86/mmu: Support disabling dirty logging for the tdp MMU")
Signed-off-by: Ben Gardon <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kvm/mmu/tdp_mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -1037,8 +1037,8 @@ bool kvm_tdp_mmu_slot_set_dirty(struct k
}

/*
- * Clear non-leaf entries (and free associated page tables) which could
- * be replaced by large mappings, for GFNs within the slot.
+ * Clear leaf entries which could be replaced by large mappings, for
+ * GFNs within the slot.
*/
static void zap_collapsible_spte_range(struct kvm *kvm,
struct kvm_mmu_page *root,
@@ -1050,7 +1050,7 @@ static void zap_collapsible_spte_range(s

tdp_root_for_each_pte(iter, root, start, end) {
if (!is_shadow_present_pte(iter.old_spte) ||
- is_last_spte(iter.old_spte, iter.level))
+ !is_last_spte(iter.old_spte, iter.level))
continue;

pfn = spte_to_pfn(iter.old_spte);


2021-02-08 17:33:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 064/120] libnvdimm/namespace: Fix visibility of namespace resource attribute

From: Dan Williams <[email protected]>

commit 13f445d65955f388499f00851dc9a86280970f7c upstream.

Legacy pmem namespaces lost support for the "resource" attribute when
the code was cleaned up to put the permission visibility in the
declaration. Restore this by listing 'resource' in the default
attributes.

A new ndctl regression test for pfn_to_online_page() corner cases builds
on this fix.

Fixes: bfd2e9140656 ("libnvdimm: Simplify root read-only definition for the 'resource' attribute")
Cc: Vishal Verma <[email protected]>
Cc: Dave Jiang <[email protected]>
Cc: Ira Weiny <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/161052334995.1805594.12054873528154362921.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nvdimm/namespace_devs.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1635,11 +1635,11 @@ static umode_t namespace_visible(struct
return a->mode;
}

- if (a == &dev_attr_nstype.attr || a == &dev_attr_size.attr
- || a == &dev_attr_holder.attr
- || a == &dev_attr_holder_class.attr
- || a == &dev_attr_force_raw.attr
- || a == &dev_attr_mode.attr)
+ /* base is_namespace_io() attributes */
+ if (a == &dev_attr_nstype.attr || a == &dev_attr_size.attr ||
+ a == &dev_attr_holder.attr || a == &dev_attr_holder_class.attr ||
+ a == &dev_attr_force_raw.attr || a == &dev_attr_mode.attr ||
+ a == &dev_attr_resource.attr)
return a->mode;

return 0;


2021-02-08 17:33:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 036/120] igc: set the default return value to -IGC_ERR_NVM in igc_write_nvm_srwr

From: Kevin Lo <[email protected]>

[ Upstream commit ebc8d125062e7dccb7922b2190b097c20d88ad96 ]

This patch sets the default return value to -IGC_ERR_NVM in
igc_write_nvm_srwr. Without this change it wouldn't lead to a shadow RAM
write EEWR timeout.

Fixes: ab4056126813 ("igc: Add NVM support")
Signed-off-by: Kevin Lo <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/intel/igc/igc_i225.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/igc/igc_i225.c b/drivers/net/ethernet/intel/igc/igc_i225.c
index 8b67d9b49a83a..7ec04e48860c6 100644
--- a/drivers/net/ethernet/intel/igc/igc_i225.c
+++ b/drivers/net/ethernet/intel/igc/igc_i225.c
@@ -219,9 +219,9 @@ static s32 igc_write_nvm_srwr(struct igc_hw *hw, u16 offset, u16 words,
u16 *data)
{
struct igc_nvm_info *nvm = &hw->nvm;
+ s32 ret_val = -IGC_ERR_NVM;
u32 attempts = 100000;
u32 i, k, eewr = 0;
- s32 ret_val = 0;

/* A check for invalid values: offset too large, too many words,
* too many words for the offset, and not enough words.
@@ -229,7 +229,6 @@ static s32 igc_write_nvm_srwr(struct igc_hw *hw, u16 offset, u16 words,
if (offset >= nvm->word_size || (words > (nvm->word_size - offset)) ||
words == 0) {
hw_dbg("nvm parameter(s) out of bounds\n");
- ret_val = -IGC_ERR_NVM;
goto out;
}

--
2.27.0



2021-02-08 17:36:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 093/120] KVM: x86: Set so called reserved CR3 bits in LM mask at vCPU reset

From: Sean Christopherson <[email protected]>

commit 031b91a5fe6f1ce61b7617614ddde9ed61e252be upstream.

Set cr3_lm_rsvd_bits, which is effectively an invalid GPA mask, at vCPU
reset. The reserved bits check needs to be done even if userspace never
configures the guest's CPUID model.

Cc: [email protected]
Fixes: 0107973a80ad ("KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch")
Signed-off-by: Sean Christopherson <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kvm/x86.c | 1 +
1 file changed, 1 insertion(+)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9915,6 +9915,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu
fx_init(vcpu);

vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
+ vcpu->arch.cr3_lm_rsvd_bits = rsvd_bits(cpuid_maxphyaddr(vcpu), 63);

vcpu->arch.pat = MSR_IA32_CR_PAT_DEFAULT;



2021-02-08 17:36:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 068/120] scripts: use pkg-config to locate libcrypto

From: Rolf Eike Beer <[email protected]>

commit 2cea4a7a1885bd0c765089afc14f7ff0eb77864e upstream.

Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer <[email protected]>
Cc: [email protected] # 5.6.x
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
scripts/Makefile | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index b5418ec587fb..9de3c03b94aa 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -3,6 +3,9 @@
# scripts contains sources for various helper programs used throughout
# the kernel for the build process.

+CRYPTO_LIBS = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto)
+CRYPTO_CFLAGS = $(shell pkg-config --cflags libcrypto 2> /dev/null)
+
hostprogs-always-$(CONFIG_BUILD_BIN2C) += bin2c
hostprogs-always-$(CONFIG_KALLSYMS) += kallsyms
hostprogs-always-$(BUILD_C_RECORDMCOUNT) += recordmcount
@@ -14,8 +17,9 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert

HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)

ifdef CONFIG_UNWINDER_ORC
ifeq ($(ARCH),x86_64)
--
2.30.0



2021-02-08 17:36:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 060/120] tracing/kprobe: Fix to support kretprobe events on unloaded modules

From: Masami Hiramatsu <[email protected]>

commit 97c753e62e6c31a404183898d950d8c08d752dbd upstream.

Fix kprobe_on_func_entry() returns error code instead of false so that
register_kretprobe() can return an appropriate error code.

append_trace_kprobe() expects the kprobe registration returns -ENOENT
when the target symbol is not found, and it checks whether the target
module is unloaded or not. If the target module doesn't exist, it
defers to probe the target symbol until the module is loaded.

However, since register_kretprobe() returns -EINVAL instead of -ENOENT
in that case, it always fail on putting the kretprobe event on unloaded
modules. e.g.

Kprobe event:
/sys/kernel/debug/tracing # echo p xfs:xfs_end_io >> kprobe_events
[ 16.515574] trace_kprobe: This probe might be able to register after target module is loaded. Continue.

Kretprobe event: (p -> r)
/sys/kernel/debug/tracing # echo r xfs:xfs_end_io >> kprobe_events
sh: write error: Invalid argument
/sys/kernel/debug/tracing # cat error_log
[ 41.122514] trace_kprobe: error: Failed to register probe event
Command: r xfs:xfs_end_io
^

To fix this bug, change kprobe_on_func_entry() to detect symbol lookup
failure and return -ENOENT in that case. Otherwise it returns -EINVAL
or 0 (succeeded, given address is on the entry).

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

Cc: [email protected]
Fixes: 59158ec4aef7 ("tracing/kprobes: Check the probe on unloaded module correctly")
Reported-by: Jianlin Lv <[email protected]>
Signed-off-by: Masami Hiramatsu <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/kprobes.h | 2 +-
kernel/kprobes.c | 34 +++++++++++++++++++++++++---------
kernel/trace/trace_kprobe.c | 10 ++++++----
3 files changed, 32 insertions(+), 14 deletions(-)

--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -251,7 +251,7 @@ extern void kprobes_inc_nmissed_count(st
extern bool arch_within_kprobe_blacklist(unsigned long addr);
extern int arch_populate_kprobe_blacklist(void);
extern bool arch_kprobe_on_func_entry(unsigned long offset);
-extern bool kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset);
+extern int kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset);

extern bool within_kprobe_blacklist(unsigned long addr);
extern int kprobe_add_ksym_blacklist(unsigned long entry);
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2082,29 +2082,45 @@ bool __weak arch_kprobe_on_func_entry(un
return !offset;
}

-bool kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset)
+/**
+ * kprobe_on_func_entry() -- check whether given address is function entry
+ * @addr: Target address
+ * @sym: Target symbol name
+ * @offset: The offset from the symbol or the address
+ *
+ * This checks whether the given @addr+@offset or @sym+@offset is on the
+ * function entry address or not.
+ * This returns 0 if it is the function entry, or -EINVAL if it is not.
+ * And also it returns -ENOENT if it fails the symbol or address lookup.
+ * Caller must pass @addr or @sym (either one must be NULL), or this
+ * returns -EINVAL.
+ */
+int kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset)
{
kprobe_opcode_t *kp_addr = _kprobe_addr(addr, sym, offset);

if (IS_ERR(kp_addr))
- return false;
+ return PTR_ERR(kp_addr);

- if (!kallsyms_lookup_size_offset((unsigned long)kp_addr, NULL, &offset) ||
- !arch_kprobe_on_func_entry(offset))
- return false;
+ if (!kallsyms_lookup_size_offset((unsigned long)kp_addr, NULL, &offset))
+ return -ENOENT;

- return true;
+ if (!arch_kprobe_on_func_entry(offset))
+ return -EINVAL;
+
+ return 0;
}

int register_kretprobe(struct kretprobe *rp)
{
- int ret = 0;
+ int ret;
struct kretprobe_instance *inst;
int i;
void *addr;

- if (!kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset))
- return -EINVAL;
+ ret = kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset);
+ if (ret)
+ return ret;

if (kretprobe_blacklist_size) {
addr = kprobe_addr(&rp->kp);
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -221,9 +221,9 @@ bool trace_kprobe_on_func_entry(struct t
{
struct trace_kprobe *tk = trace_kprobe_primary_from_call(call);

- return tk ? kprobe_on_func_entry(tk->rp.kp.addr,
+ return tk ? (kprobe_on_func_entry(tk->rp.kp.addr,
tk->rp.kp.addr ? NULL : tk->rp.kp.symbol_name,
- tk->rp.kp.addr ? 0 : tk->rp.kp.offset) : false;
+ tk->rp.kp.addr ? 0 : tk->rp.kp.offset) == 0) : false;
}

bool trace_kprobe_error_injectable(struct trace_event_call *call)
@@ -828,9 +828,11 @@ static int trace_kprobe_create(int argc,
}
if (is_return)
flags |= TPARG_FL_RETURN;
- if (kprobe_on_func_entry(NULL, symbol, offset))
+ ret = kprobe_on_func_entry(NULL, symbol, offset);
+ if (ret == 0)
flags |= TPARG_FL_FENTRY;
- if (offset && is_return && !(flags & TPARG_FL_FENTRY)) {
+ /* Defer the ENOENT case until register kprobe */
+ if (ret == -EINVAL && is_return) {
trace_probe_log_err(0, BAD_RETPROBE);
goto parse_error;
}


2021-02-08 17:36:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 065/120] libnvdimm/dimm: Avoid race between probe and available_slots_show()

From: Dan Williams <[email protected]>

commit 7018c897c2f243d4b5f1b94bc6b4831a7eab80fb upstream.

Richard reports that the following test:

(while true; do
cat /sys/bus/nd/devices/nmem*/available_slots 2>&1 > /dev/null
done) &

while true; do
for i in $(seq 0 4); do
echo nmem$i > /sys/bus/nd/drivers/nvdimm/bind
done
for i in $(seq 0 4); do
echo nmem$i > /sys/bus/nd/drivers/nvdimm/unbind
done
done

...fails with a crash signature like:

divide error: 0000 [#1] SMP KASAN PTI
RIP: 0010:nd_label_nfree+0x134/0x1a0 [libnvdimm]
[..]
Call Trace:
available_slots_show+0x4e/0x120 [libnvdimm]
dev_attr_show+0x42/0x80
? memset+0x20/0x40
sysfs_kf_seq_show+0x218/0x410

The root cause is that available_slots_show() consults driver-data, but
fails to synchronize against device-unbind setting up a TOCTOU race to
access uninitialized memory.

Validate driver-data under the device-lock.

Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure")
Cc: <[email protected]>
Cc: Vishal Verma <[email protected]>
Cc: Dave Jiang <[email protected]>
Cc: Ira Weiny <[email protected]>
Cc: Coly Li <[email protected]>
Reported-by: Richard Palethorpe <[email protected]>
Acked-by: Richard Palethorpe <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nvdimm/dimm_devs.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)

--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -335,16 +335,16 @@ static ssize_t state_show(struct device
}
static DEVICE_ATTR_RO(state);

-static ssize_t available_slots_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t __available_slots_show(struct nvdimm_drvdata *ndd, char *buf)
{
- struct nvdimm_drvdata *ndd = dev_get_drvdata(dev);
+ struct device *dev;
ssize_t rc;
u32 nfree;

if (!ndd)
return -ENXIO;

+ dev = ndd->dev;
nvdimm_bus_lock(dev);
nfree = nd_label_nfree(ndd);
if (nfree - 1 > nfree) {
@@ -356,6 +356,18 @@ static ssize_t available_slots_show(stru
nvdimm_bus_unlock(dev);
return rc;
}
+
+static ssize_t available_slots_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ ssize_t rc;
+
+ nd_device_lock(dev);
+ rc = __available_slots_show(dev_get_drvdata(dev), buf);
+ nd_device_unlock(dev);
+
+ return rc;
+}
static DEVICE_ATTR_RO(available_slots);

__weak ssize_t security_show(struct device *dev,


2021-02-08 17:37:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 105/120] mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked()

From: Waiman Long <[email protected]>

commit da74240eb3fcd806edb1643874363e954d9e948b upstream.

Commit 3fea5a499d57 ("mm: memcontrol: convert page cache to a new
mem_cgroup_charge() API") introduced a bug in __add_to_page_cache_locked()
causing the following splat:

page dumped because: VM_BUG_ON_PAGE(page_memcg(page))
pages's memcg:ffff8889a4116000
------------[ cut here ]------------
kernel BUG at mm/memcontrol.c:2924!
invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 35 PID: 12345 Comm: cat Tainted: G S W I 5.11.0-rc4-debug+ #1
Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 v01.25 12/06/2017
RIP: commit_charge+0xf4/0x130
Call Trace:
mem_cgroup_charge+0x175/0x770
__add_to_page_cache_locked+0x712/0xad0
add_to_page_cache_lru+0xc5/0x1f0
cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles]
__fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache]
__nfs_readpages_from_fscache+0x16d/0x630 [nfs]
nfs_readpages+0x24e/0x540 [nfs]
read_pages+0x5b1/0xc40
page_cache_ra_unbounded+0x460/0x750
generic_file_buffered_read_get_pages+0x290/0x1710
generic_file_buffered_read+0x2a9/0xc30
nfs_file_read+0x13f/0x230 [nfs]
new_sync_read+0x3af/0x610
vfs_read+0x339/0x4b0
ksys_read+0xf1/0x1c0
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Before that commit, there was a try_charge() and commit_charge() in
__add_to_page_cache_locked(). These two separated charge functions were
replaced by a single mem_cgroup_charge(). However, it forgot to add a
matching mem_cgroup_uncharge() when the xarray insertion failed with the
page released back to the pool.

Fix this by adding a mem_cgroup_uncharge() call when insertion error
happens.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new mem_cgroup_charge() API")
Signed-off-by: Waiman Long <[email protected]>
Reviewed-by: Alex Shi <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Miaohe Lin <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/filemap.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -835,6 +835,7 @@ noinline int __add_to_page_cache_locked(
XA_STATE(xas, &mapping->i_pages, offset);
int huge = PageHuge(page);
int error;
+ bool charged = false;

VM_BUG_ON_PAGE(!PageLocked(page), page);
VM_BUG_ON_PAGE(PageSwapBacked(page), page);
@@ -848,6 +849,7 @@ noinline int __add_to_page_cache_locked(
error = mem_cgroup_charge(page, current->mm, gfp);
if (error)
goto error;
+ charged = true;
}

gfp &= GFP_RECLAIM_MASK;
@@ -896,6 +898,8 @@ unlock:

if (xas_error(&xas)) {
error = xas_error(&xas);
+ if (charged)
+ mem_cgroup_uncharge(page);
goto error;
}



2021-02-08 17:38:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 067/120] genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set

From: Marc Zyngier <[email protected]>

commit 4c457e8cb75eda91906a4f89fc39bde3f9a43922 upstream.

When MSI_FLAG_ACTIVATE_EARLY is set (which is the case for PCI),
__msi_domain_alloc_irqs() performs the activation of the interrupt (which
in the case of PCI results in the endpoint being programmed) as soon as the
interrupt is allocated.

But it appears that this is only done for the first vector, introducing an
inconsistent behaviour for PCI Multi-MSI.

Fix it by iterating over the number of vectors allocated to each MSI
descriptor. This is easily achieved by introducing a new
"for_each_msi_vector" iterator, together with a tiny bit of refactoring.

Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-by: Shameer Kolothum <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Shameer Kolothum <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/msi.h | 6 ++++++
kernel/irq/msi.c | 44 ++++++++++++++++++++------------------------
2 files changed, 26 insertions(+), 24 deletions(-)

--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -139,6 +139,12 @@ struct msi_desc {
list_for_each_entry((desc), dev_to_msi_list((dev)), list)
#define for_each_msi_entry_safe(desc, tmp, dev) \
list_for_each_entry_safe((desc), (tmp), dev_to_msi_list((dev)), list)
+#define for_each_msi_vector(desc, __irq, dev) \
+ for_each_msi_entry((desc), (dev)) \
+ if ((desc)->irq) \
+ for (__irq = (desc)->irq; \
+ __irq < ((desc)->irq + (desc)->nvec_used); \
+ __irq++)

#ifdef CONFIG_IRQ_MSI_IOMMU
static inline const void *msi_desc_get_iommu_cookie(struct msi_desc *desc)
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -436,22 +436,22 @@ int __msi_domain_alloc_irqs(struct irq_d

can_reserve = msi_check_reservation_mode(domain, info, dev);

- for_each_msi_entry(desc, dev) {
- virq = desc->irq;
- if (desc->nvec_used == 1)
- dev_dbg(dev, "irq %d for MSI\n", virq);
- else
+ /*
+ * This flag is set by the PCI layer as we need to activate
+ * the MSI entries before the PCI layer enables MSI in the
+ * card. Otherwise the card latches a random msi message.
+ */
+ if (!(info->flags & MSI_FLAG_ACTIVATE_EARLY))
+ goto skip_activate;
+
+ for_each_msi_vector(desc, i, dev) {
+ if (desc->irq == i) {
+ virq = desc->irq;
dev_dbg(dev, "irq [%d-%d] for MSI\n",
virq, virq + desc->nvec_used - 1);
- /*
- * This flag is set by the PCI layer as we need to activate
- * the MSI entries before the PCI layer enables MSI in the
- * card. Otherwise the card latches a random msi message.
- */
- if (!(info->flags & MSI_FLAG_ACTIVATE_EARLY))
- continue;
+ }

- irq_data = irq_domain_get_irq_data(domain, desc->irq);
+ irq_data = irq_domain_get_irq_data(domain, i);
if (!can_reserve) {
irqd_clr_can_reserve(irq_data);
if (domain->flags & IRQ_DOMAIN_MSI_NOMASK_QUIRK)
@@ -462,28 +462,24 @@ int __msi_domain_alloc_irqs(struct irq_d
goto cleanup;
}

+skip_activate:
/*
* If these interrupts use reservation mode, clear the activated bit
* so request_irq() will assign the final vector.
*/
if (can_reserve) {
- for_each_msi_entry(desc, dev) {
- irq_data = irq_domain_get_irq_data(domain, desc->irq);
+ for_each_msi_vector(desc, i, dev) {
+ irq_data = irq_domain_get_irq_data(domain, i);
irqd_clr_activated(irq_data);
}
}
return 0;

cleanup:
- for_each_msi_entry(desc, dev) {
- struct irq_data *irqd;
-
- if (desc->irq == virq)
- break;
-
- irqd = irq_domain_get_irq_data(domain, desc->irq);
- if (irqd_is_activated(irqd))
- irq_domain_deactivate_irq(irqd);
+ for_each_msi_vector(desc, i, dev) {
+ irq_data = irq_domain_get_irq_data(domain, i);
+ if (irqd_is_activated(irq_data))
+ irq_domain_deactivate_irq(irq_data);
}
msi_domain_free_irqs(domain, dev);
return ret;


2021-02-08 17:38:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 066/120] genirq: Prevent [devm_]irq_alloc_desc from returning irq 0

From: Hans de Goede <[email protected]>

commit 4c7bcb51ae25f79e3733982e5d0cd8ce8640ddfc upstream.

Since commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0
is invalid"), having a linux-irq with number 0 will trigger a WARN()
when calling platform_get_irq*() to retrieve that linux-irq.

Since [devm_]irq_alloc_desc allocs a single irq and since irq 0 is not used
on some systems, it can return 0, triggering that WARN(). This happens
e.g. on Intel Bay Trail and Cherry Trail devices using the LPE audio engine
for HDMI audio:

0 is an invalid IRQ number
WARNING: CPU: 3 PID: 472 at drivers/base/platform.c:238 platform_get_irq_optional+0x108/0x180
Modules linked in: snd_hdmi_lpe_audio(+) ...

Call Trace:
platform_get_irq+0x17/0x30
hdmi_lpe_audio_probe+0x4a/0x6c0 [snd_hdmi_lpe_audio]

---[ end trace ceece38854223a0b ]---

Change the 'from' parameter passed to __[devm_]irq_alloc_descs() by the
[devm_]irq_alloc_desc macros from 0 to 1, so that these macros will no
longer return 0.

Fixes: a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid")
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/irq.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -922,7 +922,7 @@ int __devm_irq_alloc_descs(struct device
__irq_alloc_descs(irq, from, cnt, node, THIS_MODULE, NULL)

#define irq_alloc_desc(node) \
- irq_alloc_descs(-1, 0, 1, node)
+ irq_alloc_descs(-1, 1, 1, node)

#define irq_alloc_desc_at(at, node) \
irq_alloc_descs(at, at, 1, node)
@@ -937,7 +937,7 @@ int __devm_irq_alloc_descs(struct device
__devm_irq_alloc_descs(dev, irq, from, cnt, node, THIS_MODULE, NULL)

#define devm_irq_alloc_desc(dev, node) \
- devm_irq_alloc_descs(dev, -1, 0, 1, node)
+ devm_irq_alloc_descs(dev, -1, 1, 1, node)

#define devm_irq_alloc_desc_at(dev, at, node) \
devm_irq_alloc_descs(dev, at, at, 1, node)


2021-02-08 17:38:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 069/120] xhci: fix bounce buffer usage for non-sg list case

From: Mathias Nyman <[email protected]>

commit d4a610635400ccc382792f6be69427078541c678 upstream.

xhci driver may in some special cases need to copy small amounts
of payload data to a bounce buffer in order to meet the boundary
and alignment restrictions set by the xHCI specification.

In the majority of these cases the data is in a sg list, and
driver incorrectly assumed data is always in urb->sg when using
the bounce buffer.

If data instead is contiguous, and in urb->transfer_buffer, we may still
need to bounce buffer a small part if data starts very close (less than
packet size) to a 64k boundary.

Check if sg list is used before copying data to/from it.

Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Cc: [email protected]
Reported-by: Andreas Hartmann <[email protected]>
Tested-by: Andreas Hartmann <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-ring.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -699,11 +699,16 @@ static void xhci_unmap_td_bounce_buffer(
dma_unmap_single(dev, seg->bounce_dma, ring->bounce_buf_len,
DMA_FROM_DEVICE);
/* for in tranfers we need to copy the data from bounce to sg */
- len = sg_pcopy_from_buffer(urb->sg, urb->num_sgs, seg->bounce_buf,
- seg->bounce_len, seg->bounce_offs);
- if (len != seg->bounce_len)
- xhci_warn(xhci, "WARN Wrong bounce buffer read length: %zu != %d\n",
- len, seg->bounce_len);
+ if (urb->num_sgs) {
+ len = sg_pcopy_from_buffer(urb->sg, urb->num_sgs, seg->bounce_buf,
+ seg->bounce_len, seg->bounce_offs);
+ if (len != seg->bounce_len)
+ xhci_warn(xhci, "WARN Wrong bounce buffer read length: %zu != %d\n",
+ len, seg->bounce_len);
+ } else {
+ memcpy(urb->transfer_buffer + seg->bounce_offs, seg->bounce_buf,
+ seg->bounce_len);
+ }
seg->bounce_len = 0;
seg->bounce_offs = 0;
}
@@ -3275,12 +3280,16 @@ static int xhci_align_td(struct xhci_hcd

/* create a max max_pkt sized bounce buffer pointed to by last trb */
if (usb_urb_dir_out(urb)) {
- len = sg_pcopy_to_buffer(urb->sg, urb->num_sgs,
- seg->bounce_buf, new_buff_len, enqd_len);
- if (len != new_buff_len)
- xhci_warn(xhci,
- "WARN Wrong bounce buffer write length: %zu != %d\n",
- len, new_buff_len);
+ if (urb->num_sgs) {
+ len = sg_pcopy_to_buffer(urb->sg, urb->num_sgs,
+ seg->bounce_buf, new_buff_len, enqd_len);
+ if (len != new_buff_len)
+ xhci_warn(xhci, "WARN Wrong bounce buffer write length: %zu != %d\n",
+ len, new_buff_len);
+ } else {
+ memcpy(seg->bounce_buf, urb->transfer_buffer + enqd_len, new_buff_len);
+ }
+
seg->bounce_dma = dma_map_single(dev, seg->bounce_buf,
max_pkt, DMA_TO_DEVICE);
} else {


2021-02-08 17:39:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 096/120] ARM: footbridge: fix dc21285 PCI configuration accessors

From: Russell King <[email protected]>

commit 39d3454c3513840eb123b3913fda6903e45ce671 upstream.

Building with gcc 4.9.2 reveals a latent bug in the PCI accessors
for Footbridge platforms, which causes a fatal alignment fault
while accessing IO memory. Fix this by making the assembly volatile.

Cc: [email protected]
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-footbridge/dc21285.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -65,15 +65,15 @@ dc21285_read_config(struct pci_bus *bus,
if (addr)
switch (size) {
case 1:
- asm("ldrb %0, [%1, %2]"
+ asm volatile("ldrb %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 2:
- asm("ldrh %0, [%1, %2]"
+ asm volatile("ldrh %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 4:
- asm("ldr %0, [%1, %2]"
+ asm volatile("ldr %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
}
@@ -99,17 +99,17 @@ dc21285_write_config(struct pci_bus *bus
if (addr)
switch (size) {
case 1:
- asm("strb %0, [%1, %2]"
+ asm volatile("strb %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 2:
- asm("strh %0, [%1, %2]"
+ asm volatile("strh %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 4:
- asm("str %0, [%1, %2]"
+ asm volatile("str %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;


2021-02-08 17:41:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 010/120] usb: dwc3: fix clock issue during resume in OTG mode

From: Gary Bisson <[email protected]>

commit 0e5a3c8284a30f4c43fd81d7285528ece74563b5 upstream.

Commit fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3
core") introduced clock support and a new function named
dwc3_core_init_for_resume() which enables the clock before calling
dwc3_core_init() during resume as clocks get disabled during suspend.

Unfortunately in this commit the DWC3_GCTL_PRTCAP_OTG case was forgotten
and therefore during resume, a platform could call dwc3_core_init()
without re-enabling the clocks first, preventing to resume properly.

So update the resume path to call dwc3_core_init_for_resume() as it
should.

Fixes: fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3 core")
Cc: [email protected]
Signed-off-by: Gary Bisson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc3/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1758,7 +1758,7 @@ static int dwc3_resume_common(struct dwc
if (PMSG_IS_AUTO(msg))
break;

- ret = dwc3_core_init(dwc);
+ ret = dwc3_core_init_for_resume(dwc);
if (ret)
return ret;



2021-02-08 17:41:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 013/120] usb: xhci-mtk: break loop when find the endpoint to drop

From: Chunfeng Yun <[email protected]>

commit a50ea34d6dd00a12c9cd29cf7b0fa72816bffbcb upstream.

No need to check the following endpoints after finding the endpoint
wanted to drop.

Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints")
Cc: stable <[email protected]>
Reported-by: Ikjoon Jang <[email protected]>
Signed-off-by: Chunfeng Yun <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-mtk-sch.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -689,8 +689,10 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
sch_bw = &sch_array[bw_index];

list_for_each_entry_safe(sch_ep, tmp, &sch_bw->bw_ep_list, endpoint) {
- if (sch_ep->ep == ep)
+ if (sch_ep->ep == ep) {
destroy_sch_ep(udev, sch_bw, sch_ep);
+ break;
+ }
}
}
EXPORT_SYMBOL_GPL(xhci_mtk_drop_ep_quirk);


2021-02-08 17:42:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 106/120] x86/build: Disable CET instrumentation in the kernel

From: Josh Poimboeuf <[email protected]>

commit 20bf2b378729c4a0366a53e2018a0b70ace94bcd upstream.

With retpolines disabled, some configurations of GCC, and specifically
the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
to the kernel by default. That breaks certain tracing scenarios by
adding a superfluous ENDBR64 instruction before the fentry call, for
functions which can be called indirectly.

CET instrumentation isn't currently necessary in the kernel, as CET is
only supported in user space. Disable it unconditionally and move it
into the x86's Makefile as CET/CFI... enablement should be a per-arch
decision anyway.

[ bp: Massage and extend commit message. ]

Fixes: 29be86d7f9cb ("kbuild: add -fcf-protection=none when using retpoline flags")
Reported-by: Nikolay Borisov <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Nikolay Borisov <[email protected]>
Tested-by: Nikolay Borisov <[email protected]>
Cc: <[email protected]>
Cc: Seth Forshee <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Makefile | 6 ------
arch/x86/Makefile | 3 +++
2 files changed, 3 insertions(+), 6 deletions(-)

--- a/Makefile
+++ b/Makefile
@@ -950,12 +950,6 @@ KBUILD_CFLAGS += $(call cc-option,-Wer
# change __FILE__ to the relative path from the srctree
KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)

-# ensure -fcf-protection is disabled when using retpoline as it is
-# incompatible with -mindirect-branch=thunk-extern
-ifdef CONFIG_RETPOLINE
-KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
-endif
-
# include additional Makefiles when needed
include-y := scripts/Makefile.extrawarn
include-$(CONFIG_KASAN) += scripts/Makefile.kasan
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -127,6 +127,9 @@ else

KBUILD_CFLAGS += -mno-red-zone
KBUILD_CFLAGS += -mcmodel=kernel
+
+ # Intel CET isn't enabled in the kernel
+ KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
endif

ifdef CONFIG_X86_X32


2021-02-08 17:42:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 011/120] usb: xhci-mtk: fix unreleased bandwidth data

From: Ikjoon Jang <[email protected]>

commit 1d69f9d901ef14d81c3b004e3282b8cc7b456280 upstream.

xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and
drop_endpoint() to handle its own sw bandwidth management.

It stores bandwidth data into an internal table every time
add_endpoint() is called, and drops those in drop_endpoint().
But when bandwidth allocation fails at one endpoint, all earlier
allocation from the same interface could still remain at the table.

This patch moves bandwidth management codes to check_bandwidth() and
reset_bandwidth() path. To do so, this patch also adds those functions
to xhci_driver_overrides and lets mtk-xhci to release all failed
endpoints in reset_bandwidth() path.

Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT")
Signed-off-by: Ikjoon Jang <[email protected]>
Link: https://lore.kernel.org/r/20210113180444.v6.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-mtk-sch.c | 123 +++++++++++++++++++++++++++-------------
drivers/usb/host/xhci-mtk.c | 2
drivers/usb/host/xhci-mtk.h | 13 ++++
drivers/usb/host/xhci.c | 8 +-
drivers/usb/host/xhci.h | 4 +
5 files changed, 111 insertions(+), 39 deletions(-)

--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -200,6 +200,7 @@ static struct mu3h_sch_ep_info *create_s

sch_ep->sch_tt = tt;
sch_ep->ep = ep;
+ INIT_LIST_HEAD(&sch_ep->tt_endpoint);

return sch_ep;
}
@@ -583,6 +584,8 @@ int xhci_mtk_sch_init(struct xhci_hcd_mt

mtk->sch_array = sch_array;

+ INIT_LIST_HEAD(&mtk->bw_ep_list_new);
+
return 0;
}
EXPORT_SYMBOL_GPL(xhci_mtk_sch_init);
@@ -601,19 +604,14 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
struct xhci_ep_ctx *ep_ctx;
struct xhci_slot_ctx *slot_ctx;
struct xhci_virt_device *virt_dev;
- struct mu3h_sch_bw_info *sch_bw;
struct mu3h_sch_ep_info *sch_ep;
- struct mu3h_sch_bw_info *sch_array;
unsigned int ep_index;
- int bw_index;
- int ret = 0;

xhci = hcd_to_xhci(hcd);
virt_dev = xhci->devs[udev->slot_id];
ep_index = xhci_get_endpoint_index(&ep->desc);
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
- sch_array = mtk->sch_array;

xhci_dbg(xhci, "%s() type:%d, speed:%d, mpkt:%d, dir:%d, ep:%p\n",
__func__, usb_endpoint_type(&ep->desc), udev->speed,
@@ -632,39 +630,34 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
return 0;
}

- bw_index = get_bw_index(xhci, udev, ep);
- sch_bw = &sch_array[bw_index];
-
sch_ep = create_sch_ep(udev, ep, ep_ctx);
if (IS_ERR_OR_NULL(sch_ep))
return -ENOMEM;

setup_sch_info(udev, ep_ctx, sch_ep);

- ret = check_sch_bw(udev, sch_bw, sch_ep);
- if (ret) {
- xhci_err(xhci, "Not enough bandwidth!\n");
- if (is_fs_or_ls(udev->speed))
- drop_tt(udev);
-
- kfree(sch_ep);
- return -ENOSPC;
- }
+ list_add_tail(&sch_ep->endpoint, &mtk->bw_ep_list_new);

- list_add_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);

- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts)
- | EP_BCSCOUNT(sch_ep->cs_count) | EP_BBM(sch_ep->burst_mode));
- ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset)
- | EP_BREPEAT(sch_ep->repeat));
+static void xhci_mtk_drop_ep(struct xhci_hcd_mtk *mtk, struct usb_device *udev,
+ struct mu3h_sch_ep_info *sch_ep)
+{
+ struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+ int bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ struct mu3h_sch_bw_info *sch_bw = &mtk->sch_array[bw_index];

- xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",
- sch_ep->pkts, sch_ep->cs_count, sch_ep->burst_mode,
- sch_ep->offset, sch_ep->repeat);
+ update_bus_bw(sch_bw, sch_ep, 0);
+ list_del(&sch_ep->endpoint);

- return 0;
+ if (sch_ep->sch_tt) {
+ list_del(&sch_ep->tt_endpoint);
+ drop_tt(udev);
+ }
+ kfree(sch_ep);
}
-EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);

void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep)
@@ -675,7 +668,7 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
struct xhci_virt_device *virt_dev;
struct mu3h_sch_bw_info *sch_array;
struct mu3h_sch_bw_info *sch_bw;
- struct mu3h_sch_ep_info *sch_ep;
+ struct mu3h_sch_ep_info *sch_ep, *tmp;
int bw_index;

xhci = hcd_to_xhci(hcd);
@@ -694,17 +687,73 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
bw_index = get_bw_index(xhci, udev, ep);
sch_bw = &sch_array[bw_index];

- list_for_each_entry(sch_ep, &sch_bw->bw_ep_list, endpoint) {
+ list_for_each_entry_safe(sch_ep, tmp, &sch_bw->bw_ep_list, endpoint) {
if (sch_ep->ep == ep) {
- update_bus_bw(sch_bw, sch_ep, 0);
- list_del(&sch_ep->endpoint);
- if (is_fs_or_ls(udev->speed)) {
- list_del(&sch_ep->tt_endpoint);
- drop_tt(udev);
- }
- kfree(sch_ep);
- break;
+ xhci_mtk_drop_ep(mtk, udev, sch_ep);
}
}
}
EXPORT_SYMBOL_GPL(xhci_mtk_drop_ep_quirk);
+
+int xhci_mtk_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+{
+ struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct xhci_virt_device *virt_dev = xhci->devs[udev->slot_id];
+ struct mu3h_sch_bw_info *sch_bw;
+ struct mu3h_sch_ep_info *sch_ep, *tmp;
+ int bw_index, ret;
+
+ dev_dbg(&udev->dev, "%s\n", __func__);
+
+ list_for_each_entry(sch_ep, &mtk->bw_ep_list_new, endpoint) {
+ bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ sch_bw = &mtk->sch_array[bw_index];
+
+ ret = check_sch_bw(udev, sch_bw, sch_ep);
+ if (ret) {
+ xhci_err(xhci, "Not enough bandwidth!\n");
+ return -ENOSPC;
+ }
+ }
+
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
+ struct xhci_ep_ctx *ep_ctx;
+ struct usb_host_endpoint *ep = sch_ep->ep;
+ unsigned int ep_index = xhci_get_endpoint_index(&ep->desc);
+
+ bw_index = get_bw_index(xhci, udev, ep);
+ sch_bw = &mtk->sch_array[bw_index];
+
+ list_move_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list);
+
+ ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
+ ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts)
+ | EP_BCSCOUNT(sch_ep->cs_count)
+ | EP_BBM(sch_ep->burst_mode));
+ ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset)
+ | EP_BREPEAT(sch_ep->repeat));
+
+ xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",
+ sch_ep->pkts, sch_ep->cs_count, sch_ep->burst_mode,
+ sch_ep->offset, sch_ep->repeat);
+ }
+
+ return xhci_check_bandwidth(hcd, udev);
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_check_bandwidth);
+
+void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+{
+ struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ struct mu3h_sch_ep_info *sch_ep, *tmp;
+
+ dev_dbg(&udev->dev, "%s\n", __func__);
+
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
+ xhci_mtk_drop_ep(mtk, udev, sch_ep);
+ }
+
+ xhci_reset_bandwidth(hcd, udev);
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_reset_bandwidth);
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -347,6 +347,8 @@ static void usb_wakeup_set(struct xhci_h
static int xhci_mtk_setup(struct usb_hcd *hcd);
static const struct xhci_driver_overrides xhci_mtk_overrides __initconst = {
.reset = xhci_mtk_setup,
+ .check_bandwidth = xhci_mtk_check_bandwidth,
+ .reset_bandwidth = xhci_mtk_reset_bandwidth,
};

static struct hc_driver __read_mostly xhci_mtk_hc_driver;
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -130,6 +130,7 @@ struct mu3c_ippc_regs {
struct xhci_hcd_mtk {
struct device *dev;
struct usb_hcd *hcd;
+ struct list_head bw_ep_list_new;
struct mu3h_sch_bw_info *sch_array;
struct mu3c_ippc_regs __iomem *ippc_regs;
bool has_ippc;
@@ -166,6 +167,8 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
struct usb_host_endpoint *ep);
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep);
+int xhci_mtk_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
+void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);

#else
static inline int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd,
@@ -179,6 +182,16 @@ static inline void xhci_mtk_drop_ep_quir
{
}

+static inline int xhci_mtk_check_bandwidth(struct usb_hcd *hcd,
+ struct usb_device *udev)
+{
+ return 0;
+}
+
+static inline void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd,
+ struct usb_device *udev)
+{
+}
#endif

#endif /* _XHCI_MTK_H_ */
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2861,7 +2861,7 @@ static void xhci_check_bw_drop_ep_stream
* else should be touching the xhci->devs[slot_id] structure, so we
* don't need to take the xhci->lock for manipulating that.
*/
-static int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
{
int i;
int ret = 0;
@@ -2959,7 +2959,7 @@ command_cleanup:
return ret;
}

-static void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd *xhci;
struct xhci_virt_device *virt_dev;
@@ -5385,6 +5385,10 @@ void xhci_init_driver(struct hc_driver *
drv->reset = over->reset;
if (over->start)
drv->start = over->start;
+ if (over->check_bandwidth)
+ drv->check_bandwidth = over->check_bandwidth;
+ if (over->reset_bandwidth)
+ drv->reset_bandwidth = over->reset_bandwidth;
}
}
EXPORT_SYMBOL_GPL(xhci_init_driver);
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1916,6 +1916,8 @@ struct xhci_driver_overrides {
size_t extra_priv_size;
int (*reset)(struct usb_hcd *hcd);
int (*start)(struct usb_hcd *hcd);
+ int (*check_bandwidth)(struct usb_hcd *, struct usb_device *);
+ void (*reset_bandwidth)(struct usb_hcd *, struct usb_device *);
};

#define XHCI_CFC_DELAY 10
@@ -2070,6 +2072,8 @@ int xhci_gen_setup(struct usb_hcd *hcd,
void xhci_shutdown(struct usb_hcd *hcd);
void xhci_init_driver(struct hc_driver *drv,
const struct xhci_driver_overrides *over);
+int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
+void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id);
int xhci_ext_cap_init(struct xhci_hcd *xhci);



2021-02-08 17:43:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 108/120] x86/debug: Prevent data breakpoints on __per_cpu_offset

From: Lai Jiangshan <[email protected]>

commit c4bed4b96918ff1d062ee81fdae4d207da4fa9b0 upstream.

When FSGSBASE is enabled, paranoid_entry() fetches the per-CPU GSBASE value
via __per_cpu_offset or pcpu_unit_offsets.

When a data breakpoint is set on __per_cpu_offset[cpu] (read-write
operation), the specific CPU will be stuck in an infinite #DB loop.

RCU will try to send an NMI to the specific CPU, but it is not working
either since NMI also relies on paranoid_entry(). Which means it's
undebuggable.

Fixes: eaad981291ee3("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")
Signed-off-by: Lai Jiangshan <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/hw_breakpoint.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -269,6 +269,20 @@ static inline bool within_cpu_entry(unsi
CPU_ENTRY_AREA_TOTAL_SIZE))
return true;

+ /*
+ * When FSGSBASE is enabled, paranoid_entry() fetches the per-CPU
+ * GSBASE value via __per_cpu_offset or pcpu_unit_offsets.
+ */
+#ifdef CONFIG_SMP
+ if (within_area(addr, end, (unsigned long)__per_cpu_offset,
+ sizeof(unsigned long) * nr_cpu_ids))
+ return true;
+#else
+ if (within_area(addr, end, (unsigned long)&pcpu_unit_offsets,
+ sizeof(pcpu_unit_offsets)))
+ return true;
+#endif
+
for_each_possible_cpu(cpu) {
/* The original rw GDT is being used after load_direct_gdt() */
if (within_area(addr, end, (unsigned long)get_cpu_gdt_rw(cpu),


2021-02-08 17:43:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 110/120] x86/apic: Add extra serialization for non-serializing MSRs

From: Dave Hansen <[email protected]>

commit 25a068b8e9a4eb193d755d58efcb3c98928636e0 upstream.

Jan Kiszka reported that the x2apic_wrmsr_fence() function uses a plain
MFENCE while the Intel SDM (10.12.3 MSR Access in x2APIC Mode) calls for
MFENCE; LFENCE.

Short summary: we have special MSRs that have weaker ordering than all
the rest. Add fencing consistent with current SDM recommendations.

This is not known to cause any issues in practice, only in theory.

Longer story below:

The reason the kernel uses a different semantic is that the SDM changed
(roughly in late 2017). The SDM changed because folks at Intel were
auditing all of the recommended fences in the SDM and realized that the
x2apic fences were insufficient.

Why was the pain MFENCE judged insufficient?

WRMSR itself is normally a serializing instruction. No fences are needed
because the instruction itself serializes everything.

But, there are explicit exceptions for this serializing behavior written
into the WRMSR instruction documentation for two classes of MSRs:
IA32_TSC_DEADLINE and the X2APIC MSRs.

Back to x2apic: WRMSR is *not* serializing in this specific case.
But why is MFENCE insufficient? MFENCE makes writes visible, but
only affects load/store instructions. WRMSR is unfortunately not a
load/store instruction and is unaffected by MFENCE. This means that a
non-serializing WRMSR could be reordered by the CPU to execute before
the writes made visible by the MFENCE have even occurred in the first
place.

This means that an x2apic IPI could theoretically be triggered before
there is any (visible) data to process.

Does this affect anything in practice? I honestly don't know. It seems
quite possible that by the time an interrupt gets to consume the (not
yet) MFENCE'd data, it has become visible, mostly by accident.

To be safe, add the SDM-recommended fences for all x2apic WRMSRs.

This also leaves open the question of the _other_ weakly-ordered WRMSR:
MSR_IA32_TSC_DEADLINE. While it has the same ordering architecture as
the x2APIC MSRs, it seems substantially less likely to be a problem in
practice. While writes to the in-memory Local Vector Table (LVT) might
theoretically be reordered with respect to a weakly-ordered WRMSR like
TSC_DEADLINE, the SDM has this to say:

In x2APIC mode, the WRMSR instruction is used to write to the LVT
entry. The processor ensures the ordering of this write and any
subsequent WRMSR to the deadline; no fencing is required.

But, that might still leave xAPIC exposed. The safest thing to do for
now is to add the extra, recommended LFENCE.

[ bp: Massage commit message, fix typos, drop accidentally added
newline to tools/arch/x86/include/asm/barrier.h. ]

Reported-by: Jan Kiszka <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Cc: <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/include/asm/apic.h | 10 ----------
arch/x86/include/asm/barrier.h | 18 ++++++++++++++++++
arch/x86/kernel/apic/apic.c | 4 ++++
arch/x86/kernel/apic/x2apic_cluster.c | 6 ++++--
arch/x86/kernel/apic/x2apic_phys.c | 9 ++++++---
5 files changed, 32 insertions(+), 15 deletions(-)

--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -197,16 +197,6 @@ static inline bool apic_needs_pit(void)
#endif /* !CONFIG_X86_LOCAL_APIC */

#ifdef CONFIG_X86_X2APIC
-/*
- * Make previous memory operations globally visible before
- * sending the IPI through x2apic wrmsr. We need a serializing instruction or
- * mfence for this.
- */
-static inline void x2apic_wrmsr_fence(void)
-{
- asm volatile("mfence" : : : "memory");
-}
-
static inline void native_apic_msr_write(u32 reg, u32 v)
{
if (reg == APIC_DFR || reg == APIC_ID || reg == APIC_LDR ||
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -84,4 +84,22 @@ do { \

#include <asm-generic/barrier.h>

+/*
+ * Make previous memory operations globally visible before
+ * a WRMSR.
+ *
+ * MFENCE makes writes visible, but only affects load/store
+ * instructions. WRMSR is unfortunately not a load/store
+ * instruction and is unaffected by MFENCE. The LFENCE ensures
+ * that the WRMSR is not reordered.
+ *
+ * Most WRMSRs are full serializing instructions themselves and
+ * do not require this barrier. This is only required for the
+ * IA32_TSC_DEADLINE and X2APIC MSRs.
+ */
+static inline void weak_wrmsr_fence(void)
+{
+ asm volatile("mfence; lfence" : : : "memory");
+}
+
#endif /* _ASM_X86_BARRIER_H */
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -41,6 +41,7 @@
#include <asm/perf_event.h>
#include <asm/x86_init.h>
#include <linux/atomic.h>
+#include <asm/barrier.h>
#include <asm/mpspec.h>
#include <asm/i8259.h>
#include <asm/proto.h>
@@ -472,6 +473,9 @@ static int lapic_next_deadline(unsigned
{
u64 tsc;

+ /* This MSR is special and need a special fence: */
+ weak_wrmsr_fence();
+
tsc = rdtsc();
wrmsrl(MSR_IA32_TSC_DEADLINE, tsc + (((u64) delta) * TSC_DIVISOR));
return 0;
--- a/arch/x86/kernel/apic/x2apic_cluster.c
+++ b/arch/x86/kernel/apic/x2apic_cluster.c
@@ -29,7 +29,8 @@ static void x2apic_send_IPI(int cpu, int
{
u32 dest = per_cpu(x86_cpu_to_logical_apicid, cpu);

- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
__x2apic_send_IPI_dest(dest, vector, APIC_DEST_LOGICAL);
}

@@ -41,7 +42,8 @@ __x2apic_send_IPI_mask(const struct cpum
unsigned long flags;
u32 dest;

- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
local_irq_save(flags);

tmpmsk = this_cpu_cpumask_var_ptr(ipi_mask);
--- a/arch/x86/kernel/apic/x2apic_phys.c
+++ b/arch/x86/kernel/apic/x2apic_phys.c
@@ -43,7 +43,8 @@ static void x2apic_send_IPI(int cpu, int
{
u32 dest = per_cpu(x86_cpu_to_apicid, cpu);

- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
__x2apic_send_IPI_dest(dest, vector, APIC_DEST_PHYSICAL);
}

@@ -54,7 +55,8 @@ __x2apic_send_IPI_mask(const struct cpum
unsigned long this_cpu;
unsigned long flags;

- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();

local_irq_save(flags);

@@ -125,7 +127,8 @@ void __x2apic_send_IPI_shorthand(int vec
{
unsigned long cfg = __prepare_ICR(which, vector, 0);

- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
native_x2apic_icr_write(cfg, 0);
}



2021-02-08 17:43:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 001/120] USB: serial: cp210x: add pid/vid for WSDA-200-USB

From: Pho Tran <[email protected]>

commit 3c4f6ecd93442f4376a58b38bb40ee0b8c46e0e6 upstream.

Information pid/vid of WSDA-200-USB, Lord corporation company:
vid: 199b
pid: ba30

Signed-off-by: Pho Tran <[email protected]>
[ johan: amend comment with product name ]
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -204,6 +204,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x1901, 0x0194) }, /* GE Healthcare Remote Alarm Box */
{ USB_DEVICE(0x1901, 0x0195) }, /* GE B850/B650/B450 CP2104 DP UART interface */
{ USB_DEVICE(0x1901, 0x0196) }, /* GE B850 CP2105 DP UART interface */
+ { USB_DEVICE(0x199B, 0xBA30) }, /* LORD WSDA-200-USB */
{ USB_DEVICE(0x19CF, 0x3000) }, /* Parrot NMEA GPS Flight Recorder */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */


2021-02-08 17:44:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 107/120] x86/debug: Fix DR6 handling

From: Peter Zijlstra <[email protected]>

commit 9ad22e165994ccb64d85b68499eaef97342c175b upstream.

Tom reported that one of the GDB test-cases failed, and Boris bisected
it to commit:

d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6")

The debugging session led us to commit:

6c0aca288e72 ("x86: Ignore trap bits on single step exceptions")

It turns out that TF and data breakpoints are both traps and will be
merged, while instruction breakpoints are faults and will not be merged.
This means 6c0aca288e72 is wrong, only TF and instruction breakpoints
need to be excluded while TF and data breakpoints can be merged.

[ bp: Massage commit message. ]

Fixes: d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6")
Fixes: 6c0aca288e72 ("x86: Ignore trap bits on single step exceptions")
Reported-by: Tom de Vries <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: <[email protected]>
Link: https://lkml.kernel.org/r/YBMAbQGACujjfz%[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/hw_breakpoint.c | 39 ++++++++++++++++++---------------------
1 file changed, 18 insertions(+), 21 deletions(-)

--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -491,15 +491,12 @@ static int hw_breakpoint_handler(struct
struct perf_event *bp;
unsigned long *dr6_p;
unsigned long dr6;
+ bool bpx;

/* The DR6 value is pointed by args->err */
dr6_p = (unsigned long *)ERR_PTR(args->err);
dr6 = *dr6_p;

- /* If it's a single step, TRAP bits are random */
- if (dr6 & DR_STEP)
- return NOTIFY_DONE;
-
/* Do an early return if no trap bits are set in DR6 */
if ((dr6 & DR_TRAP_BITS) == 0)
return NOTIFY_DONE;
@@ -509,28 +506,29 @@ static int hw_breakpoint_handler(struct
if (likely(!(dr6 & (DR_TRAP0 << i))))
continue;

+ bp = this_cpu_read(bp_per_reg[i]);
+ if (!bp)
+ continue;
+
+ bpx = bp->hw.info.type == X86_BREAKPOINT_EXECUTE;
+
/*
- * The counter may be concurrently released but that can only
- * occur from a call_rcu() path. We can then safely fetch
- * the breakpoint, use its callback, touch its counter
- * while we are in an rcu_read_lock() path.
+ * TF and data breakpoints are traps and can be merged, however
+ * instruction breakpoints are faults and will be raised
+ * separately.
+ *
+ * However DR6 can indicate both TF and instruction
+ * breakpoints. In that case take TF as that has precedence and
+ * delay the instruction breakpoint for the next exception.
*/
- rcu_read_lock();
+ if (bpx && (dr6 & DR_STEP))
+ continue;

- bp = this_cpu_read(bp_per_reg[i]);
/*
* Reset the 'i'th TRAP bit in dr6 to denote completion of
* exception handling
*/
(*dr6_p) &= ~(DR_TRAP0 << i);
- /*
- * bp can be NULL due to lazy debug register switching
- * or due to concurrent perf counter removing.
- */
- if (!bp) {
- rcu_read_unlock();
- break;
- }

perf_bp_event(bp, args->regs);

@@ -538,11 +536,10 @@ static int hw_breakpoint_handler(struct
* Set up resume flag to avoid breakpoint recursion when
* returning back to origin.
*/
- if (bp->hw.info.type == X86_BREAKPOINT_EXECUTE)
+ if (bpx)
args->regs->flags |= X86_EFLAGS_RF;
-
- rcu_read_unlock();
}
+
/*
* Further processing in do_debug() is needed for a) user-space
* breakpoints (to generate signals) and b) when the system has


2021-02-08 17:44:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 113/120] Input: ili210x - implement pressure reporting for ILI251x

From: Marek Vasut <[email protected]>

commit 60159e9e7bc7e528c103b6b6d47dfd83af29669c upstream.

The ILI251x seems to report pressure information in the 5th byte of
each per-finger touch data element. On the available hardware, this
information has the values ranging from 0x0 to 0xa, which is also
matching the downstream example code. Report pressure information
on the ILI251x.

Signed-off-by: Marek Vasut <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/touchscreen/ili210x.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)

--- a/drivers/input/touchscreen/ili210x.c
+++ b/drivers/input/touchscreen/ili210x.c
@@ -29,11 +29,13 @@ struct ili2xxx_chip {
void *buf, size_t len);
int (*get_touch_data)(struct i2c_client *client, u8 *data);
bool (*parse_touch_data)(const u8 *data, unsigned int finger,
- unsigned int *x, unsigned int *y);
+ unsigned int *x, unsigned int *y,
+ unsigned int *z);
bool (*continue_polling)(const u8 *data, bool touch);
unsigned int max_touches;
unsigned int resolution;
bool has_calibrate_reg;
+ bool has_pressure_reg;
};

struct ili210x {
@@ -82,7 +84,8 @@ static int ili210x_read_touch_data(struc

static bool ili210x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
if (touchdata[0] & BIT(finger))
return false;
@@ -137,7 +140,8 @@ static int ili211x_read_touch_data(struc

static bool ili211x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
u32 data;

@@ -169,7 +173,8 @@ static const struct ili2xxx_chip ili211x

static bool ili212x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
u16 val;

@@ -235,7 +240,8 @@ static int ili251x_read_touch_data(struc

static bool ili251x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
u16 val;

@@ -245,6 +251,7 @@ static bool ili251x_touchdata_to_coords(

*x = val & 0x3fff;
*y = get_unaligned_be16(touchdata + 1 + (finger * 5) + 2);
+ *z = touchdata[1 + (finger * 5) + 4];

return true;
}
@@ -261,6 +268,7 @@ static const struct ili2xxx_chip ili251x
.continue_polling = ili251x_check_continue_polling,
.max_touches = 10,
.has_calibrate_reg = true,
+ .has_pressure_reg = true,
};

static bool ili210x_report_events(struct ili210x *priv, u8 *touchdata)
@@ -268,14 +276,16 @@ static bool ili210x_report_events(struct
struct input_dev *input = priv->input;
int i;
bool contact = false, touch;
- unsigned int x = 0, y = 0;
+ unsigned int x = 0, y = 0, z = 0;

for (i = 0; i < priv->chip->max_touches; i++) {
- touch = priv->chip->parse_touch_data(touchdata, i, &x, &y);
+ touch = priv->chip->parse_touch_data(touchdata, i, &x, &y, &z);

input_mt_slot(input, i);
if (input_mt_report_slot_state(input, MT_TOOL_FINGER, touch)) {
touchscreen_report_pos(input, &priv->prop, x, y, true);
+ if (priv->chip->has_pressure_reg)
+ input_report_abs(input, ABS_MT_PRESSURE, z);
contact = true;
}
}
@@ -437,6 +447,8 @@ static int ili210x_i2c_probe(struct i2c_
max_xy = (chip->resolution ?: SZ_64K) - 1;
input_set_abs_params(input, ABS_MT_POSITION_X, 0, max_xy, 0, 0);
input_set_abs_params(input, ABS_MT_POSITION_Y, 0, max_xy, 0, 0);
+ if (priv->chip->has_pressure_reg)
+ input_set_abs_params(input, ABS_MT_PRESSURE, 0, 0xa, 0, 0);
touchscreen_parse_properties(input, true, &priv->prop);

error = input_mt_init_slots(input, priv->chip->max_touches,


2021-02-08 17:46:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 111/120] Input: goodix - add support for Goodix GT9286 chip

From: AngeloGioacchino Del Regno <[email protected]>

commit 2dce6db70c77bbe639f5cd9cc796fb8f2694a7d0 upstream.

The Goodix GT9286 is a capacitive touch sensor IC based on GT1x.

This chip can be found on a number of smartphones, including the
F(x)tec Pro 1 and the Elephone U.

This has been tested on F(x)Tec Pro1 (MSM8998).

Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bastien Nocera <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -157,6 +157,7 @@ static const struct goodix_chip_id goodi
{ .id = "5663", .data = &gt1x_chip_data },
{ .id = "5688", .data = &gt1x_chip_data },
{ .id = "917S", .data = &gt1x_chip_data },
+ { .id = "9286", .data = &gt1x_chip_data },

{ .id = "911", .data = &gt911_chip_data },
{ .id = "9271", .data = &gt911_chip_data },
@@ -1445,6 +1446,7 @@ static const struct of_device_id goodix_
{ .compatible = "goodix,gt927" },
{ .compatible = "goodix,gt9271" },
{ .compatible = "goodix,gt928" },
+ { .compatible = "goodix,gt9286" },
{ .compatible = "goodix,gt967" },
{ }
};


2021-02-08 17:47:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 112/120] Input: xpad - sync supported devices with fork on GitHub

From: Benjamin Valentin <[email protected]>

commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.

There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.

Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.

[0] https://github.com/paroj/xpad

Signed-off-by: Benjamin Valentin <[email protected]>
Link: https://lore.kernel.org/r/20210121142523.1b6b050f@rechenknecht2k11
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/joystick/xpad.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)

--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -215,9 +215,17 @@ static const struct xpad_device {
{ 0x0e6f, 0x0213, "Afterglow Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x021f, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x0246, "Rock Candy Gamepad for Xbox One 2015", 0, XTYPE_XBOXONE },
- { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a0, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a1, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a2, "PDP Wired Controller for Xbox One - Crimson Red", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x02a4, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x02a6, "PDP Wired Controller for Xbox One - Camo Series", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a7, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a8, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02ad, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02b3, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02b8, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x0346, "Rock Candy Gamepad for Xbox One 2016", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 },
@@ -296,6 +304,9 @@ static const struct xpad_device {
{ 0x1bad, 0xfa01, "MadCatz GamePad", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 },
+ { 0x20d6, 0x2001, "BDA Xbox Series X Wired Controller", 0, XTYPE_XBOXONE },
+ { 0x20d6, 0x281f, "PowerA Wired Controller For Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x2e24, 0x0652, "Hyperkin Duke X-Box One pad", 0, XTYPE_XBOXONE },
{ 0x24c6, 0x5000, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x24c6, 0x5300, "PowerA MINI PROEX Controller", 0, XTYPE_XBOX360 },
{ 0x24c6, 0x5303, "Xbox Airflo wired controller", 0, XTYPE_XBOX360 },
@@ -429,8 +440,12 @@ static const struct usb_device_id xpad_t
XPAD_XBOX360_VENDOR(0x162e), /* Joytech X-Box 360 controllers */
XPAD_XBOX360_VENDOR(0x1689), /* Razer Onza */
XPAD_XBOX360_VENDOR(0x1bad), /* Harminix Rock Band Guitar and Drums */
+ XPAD_XBOX360_VENDOR(0x20d6), /* PowerA Controllers */
+ XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA Controllers */
XPAD_XBOX360_VENDOR(0x24c6), /* PowerA Controllers */
XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */
+ XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */
+ XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */
{ }
};



2021-02-08 17:47:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 114/120] md: Set prev_flush_start and flush_bio in an atomic way

From: Xiao Ni <[email protected]>

commit dc5d17a3c39b06aef866afca19245a9cfb533a79 upstream.

One customer reports a crash problem which causes by flush request. It
triggers a warning before crash.

/* new request after previous flush is completed */
if (ktime_after(req_start, mddev->prev_flush_start)) {
WARN_ON(mddev->flush_bio);
mddev->flush_bio = bio;
bio = NULL;
}

The WARN_ON is triggered. We use spin lock to protect prev_flush_start and
flush_bio in md_flush_request. But there is no lock protection in
md_submit_flush_data. It can set flush_bio to NULL first because of
compiler reordering write instructions.

For example, flush bio1 sets flush bio to NULL first in
md_submit_flush_data. An interrupt or vmware causing an extended stall
happen between updating flush_bio and prev_flush_start. Because flush_bio
is NULL, flush bio2 can get the lock and submit to underlayer disks. Then
flush bio1 updates prev_flush_start after the interrupt or extended stall.

Then flush bio3 enters in md_flush_request. The start time req_start is
behind prev_flush_start. The flush_bio is not NULL(flush bio2 hasn't
finished). So it can trigger the WARN_ON now. Then it calls INIT_WORK
again. INIT_WORK() will re-initialize the list pointers in the
work_struct, which then can result in a corrupted work list and the
work_struct queued a second time. With the work list corrupted, it can
lead in invalid work items being used and cause a crash in
process_one_work.

We need to make sure only one flush bio can be handled at one same time.
So add spin lock in md_submit_flush_data to protect prev_flush_start and
flush_bio in an atomic way.

Reviewed-by: David Jeffery <[email protected]>
Signed-off-by: Xiao Ni <[email protected]>
Signed-off-by: Song Liu <[email protected]>
Signed-off-by: Jack Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/md.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -639,8 +639,10 @@ static void md_submit_flush_data(struct
* could wait for this and below md_handle_request could wait for those
* bios because of suspend check
*/
+ spin_lock_irq(&mddev->lock);
mddev->last_flush = mddev->start_flush;
mddev->flush_bio = NULL;
+ spin_unlock_irq(&mddev->lock);
wake_up(&mddev->sb_wait);

if (bio->bi_iter.bi_size == 0) {


2021-02-08 17:49:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 116/120] neighbour: Prevent a dead entry from updating gc_list

From: Chinmay Agarwal <[email protected]>

commit eb4e8fac00d1e01ada5e57c05d24739156086677 upstream.

Following race condition was detected:
<CPU A, t0> - neigh_flush_dev() is under execution and calls
neigh_mark_dead(n) marking the neighbour entry 'n' as dead.

<CPU B, t1> - Executing: __netif_receive_skb() ->
__netif_receive_skb_core() -> arp_rcv() -> arp_process().arp_process()
calls __neigh_lookup() which takes a reference on neighbour entry 'n'.

<CPU A, t2> - Moves further along neigh_flush_dev() and calls
neigh_cleanup_and_release(n), but since reference count increased in t2,
'n' couldn't be destroyed.

<CPU B, t3> - Moves further along, arp_process() and calls
neigh_update()-> __neigh_update() -> neigh_update_gc_list(), which adds
the neighbour entry back in gc_list(neigh_mark_dead(), removed it
earlier in t0 from gc_list)

<CPU B, t4> - arp_process() finally calls neigh_release(n), destroying
the neighbour entry.

This leads to 'n' still being part of gc_list, but the actual
neighbour structure has been freed.

The situation can be prevented from happening if we disallow a dead
entry to have any possibility of updating gc_list. This is what the
patch intends to achieve.

Fixes: 9c29a2f55ec0 ("neighbor: Fix locking order for gc_list changes")
Signed-off-by: Chinmay Agarwal <[email protected]>
Reviewed-by: Cong Wang <[email protected]>
Reviewed-by: David Ahern <[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]>
---
net/core/neighbour.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1245,13 +1245,14 @@ static int __neigh_update(struct neighbo
old = neigh->nud_state;
err = -EPERM;

- if (!(flags & NEIGH_UPDATE_F_ADMIN) &&
- (old & (NUD_NOARP | NUD_PERMANENT)))
- goto out;
if (neigh->dead) {
NL_SET_ERR_MSG(extack, "Neighbor entry is now dead");
+ new = old;
goto out;
}
+ if (!(flags & NEIGH_UPDATE_F_ADMIN) &&
+ (old & (NUD_NOARP | NUD_PERMANENT)))
+ goto out;

ext_learn_change = neigh_update_ext_learned(neigh, flags, &notify);



2021-02-08 17:50:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 097/120] ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor

From: Dmitry Osipenko <[email protected]>

commit 538eea5362a1179dfa7770dd2b6607dc30cc50c6 upstream.

The tegra_uart_config of the DEBUG_LL code is now placed right at the
start of the .text section after commit which enabled debug output in the
decompressor. Tegra devices are not booting anymore if DEBUG_LL is enabled
since tegra_uart_config data is executes as a code. Fix the misplaced
tegra_uart_config storage by embedding it into the code.

Cc: [email protected]
Fixes: 2596a72d3384 ("ARM: 9009/1: uncompress: Enable debug in head.S")
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/include/debug/tegra.S | 54 ++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 27 deletions(-)

--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -149,7 +149,34 @@

.align
99: .word .
+#if defined(ZIMAGE)
+ .word . + 4
+/*
+ * Storage for the state maintained by the macro.
+ *
+ * In the kernel proper, this data is located in arch/arm/mach-tegra/tegra.c.
+ * That's because this header is included from multiple files, and we only
+ * want a single copy of the data. In particular, the UART probing code above
+ * assumes it's running using physical addresses. This is true when this file
+ * is included from head.o, but not when included from debug.o. So we need
+ * to share the probe results between the two copies, rather than having
+ * to re-run the probing again later.
+ *
+ * In the decompressor, we put the storage right here, since common.c
+ * isn't included in the decompressor build. This storage data gets put in
+ * .text even though it's really data, since .data is discarded from the
+ * decompressor. Luckily, .text is writeable in the decompressor, unless
+ * CONFIG_ZBOOT_ROM. That dependency is handled in arch/arm/Kconfig.debug.
+ */
+ /* Debug UART initialization required */
+ .word 1
+ /* Debug UART physical address */
+ .word 0
+ /* Debug UART virtual address */
+ .word 0
+#else
.word tegra_uart_config
+#endif
.ltorg

/* Load previously selected UART address */
@@ -189,30 +216,3 @@

.macro waituarttxrdy,rd,rx
.endm
-
-/*
- * Storage for the state maintained by the macros above.
- *
- * In the kernel proper, this data is located in arch/arm/mach-tegra/tegra.c.
- * That's because this header is included from multiple files, and we only
- * want a single copy of the data. In particular, the UART probing code above
- * assumes it's running using physical addresses. This is true when this file
- * is included from head.o, but not when included from debug.o. So we need
- * to share the probe results between the two copies, rather than having
- * to re-run the probing again later.
- *
- * In the decompressor, we put the symbol/storage right here, since common.c
- * isn't included in the decompressor build. This symbol gets put in .text
- * even though it's really data, since .data is discarded from the
- * decompressor. Luckily, .text is writeable in the decompressor, unless
- * CONFIG_ZBOOT_ROM. That dependency is handled in arch/arm/Kconfig.debug.
- */
-#if defined(ZIMAGE)
-tegra_uart_config:
- /* Debug UART initialization required */
- .word 1
- /* Debug UART physical address */
- .word 0
- /* Debug UART virtual address */
- .word 0
-#endif


2021-02-08 17:50:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 115/120] igc: Report speed and duplex as unknown when device is runtime suspended

From: Kai-Heng Feng <[email protected]>

commit 2e99dedc73f004f650b197c9b269c15c7e01ad15 upstream.

Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime suspended, igc will complain and
stops working:

[ 123.449883] igc 0000:03:00.0 enp3s0: PCIe link lost, device now detached
[ 123.450052] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 123.450056] #PF: supervisor read access in kernel mode
[ 123.450058] #PF: error_code(0x0000) - not-present page
[ 123.450059] PGD 0 P4D 0
[ 123.450064] Oops: 0000 [#1] SMP NOPTI
[ 123.450068] CPU: 0 PID: 2525 Comm: udevadm Tainted: G U W OE 5.10.0-1002-oem #2+rkl2-Ubuntu
[ 123.450078] RIP: 0010:igc_rd32+0x1c/0x90 [igc]
[ 123.450080] Code: c0 5d c3 b8 fd ff ff ff c3 0f 1f 44 00 00 0f 1f 44 00 00 55 89 f0 48 89 e5 41 56 41 55 41 54 49 89 c4 53 48 8b 57 08 48 01 d0 <44> 8b 28 41 83 fd ff 74 0c 5b 44 89 e8 41 5c 41 5d 4

[ 123.450083] RSP: 0018:ffffb0d100d6fcc0 EFLAGS: 00010202
[ 123.450085] RAX: 0000000000000008 RBX: ffffb0d100d6fd30 RCX: 0000000000000000
[ 123.450087] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff945a12716c10
[ 123.450089] RBP: ffffb0d100d6fce0 R08: ffff945a12716550 R09: ffff945a09874000
[ 123.450090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000008
[ 123.450092] R13: ffff945a12716000 R14: ffff945a037da280 R15: ffff945a037da290
[ 123.450094] FS: 00007f3b34c868c0(0000) GS:ffff945b89200000(0000) knlGS:0000000000000000
[ 123.450096] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 123.450098] CR2: 0000000000000008 CR3: 00000001144de006 CR4: 0000000000770ef0
[ 123.450100] PKRU: 55555554
[ 123.450101] Call Trace:
[ 123.450111] igc_ethtool_get_link_ksettings+0xd6/0x1b0 [igc]
[ 123.450118] __ethtool_get_link_ksettings+0x71/0xb0
[ 123.450123] duplex_show+0x74/0xc0
[ 123.450129] dev_attr_show+0x1d/0x40
[ 123.450134] sysfs_kf_seq_show+0xa1/0x100
[ 123.450137] kernfs_seq_show+0x27/0x30
[ 123.450142] seq_read+0xb7/0x400
[ 123.450148] ? common_file_perm+0x72/0x170
[ 123.450151] kernfs_fop_read+0x35/0x1b0
[ 123.450155] vfs_read+0xb5/0x1b0
[ 123.450157] ksys_read+0x67/0xe0
[ 123.450160] __x64_sys_read+0x1a/0x20
[ 123.450164] do_syscall_64+0x38/0x90
[ 123.450168] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 123.450170] RIP: 0033:0x7f3b351fe142
[ 123.450173] Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[ 123.450174] RSP: 002b:00007fffef2ec138 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 123.450177] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3b351fe142
[ 123.450179] RDX: 0000000000001001 RSI: 00005644c047f070 RDI: 0000000000000003
[ 123.450180] RBP: 00007fffef2ec340 R08: 00005644c047f070 R09: 00007f3b352d9320
[ 123.450182] R10: 00005644c047c010 R11: 0000000000000246 R12: 00005644c047cbf0
[ 123.450184] R13: 00005644c047e6d0 R14: 0000000000000003 R15: 00007fffef2ec140
[ 123.450189] Modules linked in: rfcomm ccm cmac algif_hash algif_skcipher af_alg bnep toshiba_acpi industrialio toshiba_haps hp_accel lis3lv02d btusb btrtl btbcm btintel bluetooth ecdh_generic ecc joydev input_leds nls_iso8859_1 snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_hda_codec_hdmi snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation soundwire_cadence snd_hda_codec snd_hda_core ath10k_pci snd_hwdep intel_rapl_msr intel_rapl_common ath10k_core soundwire_bus snd_soc_core x86_pkg_temp_thermal ath intel_powerclamp snd_compress ac97_bus snd_pcm_dmaengine mac80211 snd_pcm coretemp snd_seq_midi snd_seq_midi_event snd_rawmidi kvm_intel cfg80211 snd_seq snd_seq_device snd_timer mei_hdcp kvm libarc4 snd crct10dif_pclmul ghash_clmulni_intel aesni_intel
mei_me dell_wmi
[ 123.450266] dell_smbios soundcore sparse_keymap dcdbas crypto_simd cryptd mei dell_uart_backlight glue_helper ee1004 wmi_bmof intel_wmi_thunderbolt dell_wmi_descriptor mac_hid efi_pstore acpi_pad acpi_tad intel_cstate sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crc32_pclmul rc_core drm intel_lpss_pci i2c_i801 ahci igc intel_lpss i2c_smbus idma64 xhci_pci libahci virt_dma xhci_pci_renesas wmi video pinctrl_tigerlake
[ 123.450335] CR2: 0000000000000008
[ 123.450338] ---[ end trace 9f731e38b53c35cc ]---

The more generic approach will be wrap get_link_ksettings() with begin()
and complete() callbacks, and calls runtime resume and runtime suspend
routine respectively. However, igc is like igb, runtime resume routine
uses rtnl_lock() which upper ethtool layer also uses.

So to prevent a deadlock on rtnl, take a different approach, use
pm_runtime_suspended() to avoid reading register while device is runtime
suspended.

Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
Signed-off-by: Kai-Heng Feng <[email protected]>
Acked-by: Sasha Neftin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/igc/igc_ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
+++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
@@ -1714,7 +1714,8 @@ static int igc_ethtool_get_link_ksetting
Asym_Pause);
}

- status = rd32(IGC_STATUS);
+ status = pm_runtime_suspended(&adapter->pdev->dev) ?
+ 0 : rd32(IGC_STATUS);

if (status & IGC_STATUS_LU) {
if (status & IGC_STATUS_SPEED_1000) {


2021-02-08 17:51:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 109/120] x86/debug: Prevent data breakpoints on cpu_dr7

From: Lai Jiangshan <[email protected]>

commit 3943abf2dbfae9ea4d2da05c1db569a0603f76da upstream.

local_db_save() is called at the start of exc_debug_kernel(), reads DR7 and
disables breakpoints to prevent recursion.

When running in a guest (X86_FEATURE_HYPERVISOR), local_db_save() reads the
per-cpu variable cpu_dr7 to check whether a breakpoint is active or not
before it accesses DR7.

A data breakpoint on cpu_dr7 therefore results in infinite #DB recursion.

Disallow data breakpoints on cpu_dr7 to prevent that.

Fixes: 84b6a3491567a("x86/entry: Optimize local_db_save() for virt")
Signed-off-by: Lai Jiangshan <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/hw_breakpoint.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -307,6 +307,14 @@ static inline bool within_cpu_entry(unsi
(unsigned long)&per_cpu(cpu_tlbstate, cpu),
sizeof(struct tlb_state)))
return true;
+
+ /*
+ * When in guest (X86_FEATURE_HYPERVISOR), local_db_save()
+ * will read per-cpu cpu_dr7 before clear dr7 register.
+ */
+ if (within_area(addr, end, (unsigned long)&per_cpu(cpu_dr7, cpu),
+ sizeof(cpu_dr7)))
+ return true;
}

return false;


2021-02-08 17:51:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 117/120] net: ip_tunnel: fix mtu calculation

From: Vadim Fedorenko <[email protected]>

commit 28e104d00281ade30250b24e098bf50887671ea4 upstream.

dev->hard_header_len for tunnel interface is set only when header_ops
are set too and already contains full overhead of any tunnel encapsulation.
That's why there is not need to use this overhead twice in mtu calc.

Fixes: fdafed459998 ("ip_gre: set dev->hard_header_len and dev->needed_headroom properly")
Reported-by: Slava Bacherikov <[email protected]>
Signed-off-by: Vadim Fedorenko <[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]>
---
net/ipv4/ip_tunnel.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)

--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -317,7 +317,7 @@ static int ip_tunnel_bind_dev(struct net
}

dev->needed_headroom = t_hlen + hlen;
- mtu -= (dev->hard_header_len + t_hlen);
+ mtu -= t_hlen;

if (mtu < IPV4_MIN_MTU)
mtu = IPV4_MIN_MTU;
@@ -347,7 +347,7 @@ static struct ip_tunnel *ip_tunnel_creat
nt = netdev_priv(dev);
t_hlen = nt->hlen + sizeof(struct iphdr);
dev->min_mtu = ETH_MIN_MTU;
- dev->max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
+ dev->max_mtu = IP_MAX_MTU - t_hlen;
ip_tunnel_add(itn, nt);
return nt;

@@ -488,11 +488,10 @@ static int tnl_update_pmtu(struct net_de
int mtu;

tunnel_hlen = md ? tunnel_hlen : tunnel->hlen;
- pkt_size = skb->len - tunnel_hlen - dev->hard_header_len;
+ pkt_size = skb->len - tunnel_hlen;

if (df)
- mtu = dst_mtu(&rt->dst) - dev->hard_header_len
- - sizeof(struct iphdr) - tunnel_hlen;
+ mtu = dst_mtu(&rt->dst) - (sizeof(struct iphdr) + tunnel_hlen);
else
mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;

@@ -972,7 +971,7 @@ int __ip_tunnel_change_mtu(struct net_de
{
struct ip_tunnel *tunnel = netdev_priv(dev);
int t_hlen = tunnel->hlen + sizeof(struct iphdr);
- int max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
+ int max_mtu = IP_MAX_MTU - t_hlen;

if (new_mtu < ETH_MIN_MTU)
return -EINVAL;
@@ -1149,10 +1148,9 @@ int ip_tunnel_newlink(struct net_device

mtu = ip_tunnel_bind_dev(dev);
if (tb[IFLA_MTU]) {
- unsigned int max = IP_MAX_MTU - dev->hard_header_len - nt->hlen;
+ unsigned int max = IP_MAX_MTU - (nt->hlen + sizeof(struct iphdr));

- mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU,
- (unsigned int)(max - sizeof(struct iphdr)));
+ mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU, max);
}

err = dev_set_mtu(dev, mtu);


2021-02-08 17:52:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 119/120] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add

From: DENG Qingfang <[email protected]>

commit f72f2fb8fb6be095b98af5d740ac50cffd0b0cae upstream.

Having multiple destination ports for a unicast address does not make
sense.
Make port_db_load_purge override existent unicast portvec instead of
adding a new port bit.

Fixes: 884729399260 ("net: dsa: mv88e6xxx: handle multiple ports in ATU")
Signed-off-by: DENG Qingfang <[email protected]>
Reviewed-by: Vladimir Oltean <[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/dsa/mv88e6xxx/chip.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1669,7 +1669,11 @@ static int mv88e6xxx_port_db_load_purge(
if (!entry.portvec)
entry.state = 0;
} else {
- entry.portvec |= BIT(port);
+ if (state == MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC)
+ entry.portvec = BIT(port);
+ else
+ entry.portvec |= BIT(port);
+
entry.state = state;
}



2021-02-08 17:52:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 101/120] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active

From: Muchun Song <[email protected]>

commit ecbf4724e6061b4b01be20f6d797d64d462b2bc8 upstream.

The page_huge_active() can be called from scan_movable_pages() which do
not hold a reference count to the HugeTLB page. So when we call
page_huge_active() from scan_movable_pages(), the HugeTLB page can be
freed parallel. Then we will trigger a BUG_ON which is in the
page_huge_active() when CONFIG_DEBUG_VM is enabled. Just remove the
VM_BUG_ON_PAGE.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()")
Signed-off-by: Muchun Song <[email protected]>
Reviewed-by: Mike Kravetz <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
Cc: David Hildenbrand <[email protected]>
Cc: Yang Shi <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1361,8 +1361,7 @@ struct hstate *size_to_hstate(unsigned l
*/
bool page_huge_active(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
- return PageHead(page) && PagePrivate(&page[1]);
+ return PageHeadHuge(page) && PagePrivate(&page[1]);
}

/* never called for tail page */


2021-02-08 17:53:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 120/120] net: sched: replaced invalid qdisc tree flush helper in qdisc_replace

From: Alexander Ovechkin <[email protected]>

commit 938e0fcd3253efdef8924714158911286d08cfe1 upstream.

Commit e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
introduced qdisc tree flush/purge helpers, but erroneously used flush helper
instead of purge helper in qdisc_replace function.
This issue was found in our CI, that tests various qdisc setups by configuring
qdisc and sending data through it. Call of invalid helper sporadically leads
to corruption of vt_tree/cf_tree of hfsc_class that causes kernel oops:

Oops: 0000 [#1] SMP PTI
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.11.0-8f6859df #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:rb_insert_color+0x18/0x190
Code: c3 31 c0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 07 48 85 c0 0f 84 05 01 00 00 48 8b 10 f6 c2 01 0f 85 34 01 00 00 <48> 8b 4a 08 49 89 d0 48 39 c1 74 7d 48 85 c9 74 32 f6 01 01 75 2d
RSP: 0018:ffffc900000b8bb0 EFLAGS: 00010246
RAX: ffff8881ef4c38b0 RBX: ffff8881d956e400 RCX: ffff8881ef4c38b0
RDX: 0000000000000000 RSI: ffff8881d956f0a8 RDI: ffff8881d956e4b0
RBP: 0000000000000000 R08: 000000d5c4e249da R09: 1600000000000000
R10: ffffc900000b8be0 R11: ffffc900000b8b28 R12: 0000000000000001
R13: 000000000000005a R14: ffff8881f0905000 R15: ffff8881f0387d00
FS: 0000000000000000(0000) GS:ffff8881f8b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000001f4796004 CR4: 0000000000060ee0
Call Trace:
<IRQ>
init_vf.isra.19+0xec/0x250 [sch_hfsc]
hfsc_enqueue+0x245/0x300 [sch_hfsc]
? fib_rules_lookup+0x12a/0x1d0
? __dev_queue_xmit+0x4b6/0x930
? hfsc_delete_class+0x250/0x250 [sch_hfsc]
__dev_queue_xmit+0x4b6/0x930
? ip6_finish_output2+0x24d/0x590
ip6_finish_output2+0x24d/0x590
? ip6_output+0x6c/0x130
ip6_output+0x6c/0x130
? __ip6_finish_output+0x110/0x110
mld_sendpack+0x224/0x230
mld_ifc_timer_expire+0x186/0x2c0
? igmp6_group_dropped+0x200/0x200
call_timer_fn+0x2d/0x150
run_timer_softirq+0x20c/0x480
? tick_sched_do_timer+0x60/0x60
? tick_sched_timer+0x37/0x70
__do_softirq+0xf7/0x2cb
irq_exit+0xa0/0xb0
smp_apic_timer_interrupt+0x74/0x150
apic_timer_interrupt+0xf/0x20
</IRQ>

Fixes: e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
Signed-off-by: Alexander Ovechkin <[email protected]>
Reported-by: Alexander Kuznetsov <[email protected]>
Acked-by: Dmitry Monakhov <[email protected]>
Acked-by: Dmitry Yakunin <[email protected]>
Acked-by: Cong Wang <[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]>
---
include/net/sch_generic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -1155,7 +1155,7 @@ static inline struct Qdisc *qdisc_replac
old = *pold;
*pold = new;
if (old != NULL)
- qdisc_tree_flush_backlog(old);
+ qdisc_purge_queue(old);
sch_tree_unlock(sch);

return old;


2021-02-08 17:53:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 098/120] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page

From: Muchun Song <[email protected]>

commit 585fc0d2871c9318c949fbf45b1f081edd489e96 upstream.

If a new hugetlb page is allocated during fallocate it will not be
marked as active (set_page_huge_active) which will result in a later
isolate_huge_page failure when the page migration code would like to
move that page. Such a failure would be unexpected and wrong.

Only export set_page_huge_active, just leave clear_page_huge_active as
static. Because there are no external users.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate())
Signed-off-by: Muchun Song <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reviewed-by: Mike Kravetz <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
Cc: David Hildenbrand <[email protected]>
Cc: Yang Shi <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/hugetlbfs/inode.c | 3 ++-
include/linux/hugetlb.h | 2 ++
mm/hugetlb.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)

--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -735,9 +735,10 @@ static long hugetlbfs_fallocate(struct f

mutex_unlock(&hugetlb_fault_mutex_table[hash]);

+ set_page_huge_active(page);
/*
* unlock_page because locked by add_to_page_cache()
- * page_put due to reference from alloc_huge_page()
+ * put_page() due to reference from alloc_huge_page()
*/
unlock_page(page);
put_page(page);
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -770,6 +770,8 @@ static inline void huge_ptep_modify_prot
}
#endif

+void set_page_huge_active(struct page *page);
+
#else /* CONFIG_HUGETLB_PAGE */
struct hstate {};

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1349,7 +1349,7 @@ bool page_huge_active(struct page *page)
}

/* never called for tail page */
-static void set_page_huge_active(struct page *page)
+void set_page_huge_active(struct page *page)
{
VM_BUG_ON_PAGE(!PageHeadHuge(page), page);
SetPagePrivate(&page[1]);


2021-02-08 17:54:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 103/120] mm/vmalloc: separate put pages and flush VM flags

From: Rick Edgecombe <[email protected]>

commit 4f6ec8602341e97b364e4e0d41a1ed08148f5e98 upstream.

When VM_MAP_PUT_PAGES was added, it was defined with the same value as
VM_FLUSH_RESET_PERMS. This doesn't seem like it will cause any big
functional problems other than some excess flushing for VM_MAP_PUT_PAGES
allocations.

Redefine VM_MAP_PUT_PAGES to have its own value. Also, rearrange things
so flags are less likely to be missed in the future.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: b944afc9d64d ("mm: add a VM_MAP_PUT_PAGES flag for vmap")
Signed-off-by: Rick Edgecombe <[email protected]>
Suggested-by: Matthew Wilcox <[email protected]>
Cc: Miaohe Lin <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Daniel Axtens <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/vmalloc.h | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)

--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -24,7 +24,8 @@ struct notifier_block; /* in notifier.h
#define VM_UNINITIALIZED 0x00000020 /* vm_struct is not fully initialized */
#define VM_NO_GUARD 0x00000040 /* don't add guard page */
#define VM_KASAN 0x00000080 /* has allocated kasan shadow memory */
-#define VM_MAP_PUT_PAGES 0x00000100 /* put pages and free array in vfree */
+#define VM_FLUSH_RESET_PERMS 0x00000100 /* reset direct map and flush TLB on unmap, can't be freed in atomic context */
+#define VM_MAP_PUT_PAGES 0x00000200 /* put pages and free array in vfree */

/*
* VM_KASAN is used slighly differently depending on CONFIG_KASAN_VMALLOC.
@@ -37,12 +38,6 @@ struct notifier_block; /* in notifier.h
* determine which allocations need the module shadow freed.
*/

-/*
- * Memory with VM_FLUSH_RESET_PERMS cannot be freed in an interrupt or with
- * vfree_atomic().
- */
-#define VM_FLUSH_RESET_PERMS 0x00000100 /* Reset direct map and flush TLB on unmap */
-
/* bits [20..32] reserved for arch specific ioremap internals */

/*


2021-02-08 17:54:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 102/120] mm, compaction: move high_pfn to the for loop scope

From: Rokudo Yan <[email protected]>

commit 74e21484e40bb8ce0f9828bbfe1c9fc9b04249c6 upstream.

In fast_isolate_freepages, high_pfn will be used if a prefered one (ie
PFN >= low_fn) not found.

But the high_pfn is not reset before searching an free area, so when it
was used as freepage, it may from another free area searched before. As
a result move_freelist_head(freelist, freepage) will have unexpected
behavior (eg corrupt the MOVABLE freelist)

Unable to handle kernel paging request at virtual address dead000000000200
Mem abort info:
ESR = 0x96000044
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000044
CM = 0, WnR = 1
[dead000000000200] address between user and kernel address ranges

-000|list_cut_before(inline)
-000|move_freelist_head(inline)
-000|fast_isolate_freepages(inline)
-000|isolate_freepages(inline)
-000|compaction_alloc(?, ?)
-001|unmap_and_move(inline)
-001|migrate_pages([NSD:0xFFFFFF80088CBBD0] from = 0xFFFFFF80088CBD88, [NSD:0xFFFFFF80088CBBC8] get_new_p
-002|__read_once_size(inline)
-002|static_key_count(inline)
-002|static_key_false(inline)
-002|trace_mm_compaction_migratepages(inline)
-002|compact_zone(?, [NSD:0xFFFFFF80088CBCB0] capc = 0x0)
-003|kcompactd_do_work(inline)
-003|kcompactd([X19] p = 0xFFFFFF93227FBC40)
-004|kthread([X20] _create = 0xFFFFFFE1AFB26380)
-005|ret_from_fork(asm)

The issue was reported on an smart phone product with 6GB ram and 3GB
zram as swap device.

This patch fixes the issue by reset high_pfn before searching each free
area, which ensure freepage and freelist match when call
move_freelist_head in fast_isolate_freepages().

Link: http://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Fixes: 5a811889de10f1eb ("mm, compaction: use free lists to quickly locate a migration target")
Signed-off-by: Rokudo Yan <[email protected]>
Acked-by: Mel Gorman <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/compaction.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1302,7 +1302,7 @@ fast_isolate_freepages(struct compact_co
{
unsigned int limit = min(1U, freelist_scan_limit(cc) >> 1);
unsigned int nr_scanned = 0;
- unsigned long low_pfn, min_pfn, high_pfn = 0, highest = 0;
+ unsigned long low_pfn, min_pfn, highest = 0;
unsigned long nr_isolated = 0;
unsigned long distance;
struct page *page = NULL;
@@ -1347,6 +1347,7 @@ fast_isolate_freepages(struct compact_co
struct page *freepage;
unsigned long flags;
unsigned int order_scanned = 0;
+ unsigned long high_pfn = 0;

if (!area->nr_free)
continue;


2021-02-08 17:54:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 099/120] mm: hugetlb: fix a race between freeing and dissolving the page

From: Muchun Song <[email protected]>

commit 7ffddd499ba6122b1a07828f023d1d67629aa017 upstream.

There is a race condition between __free_huge_page()
and dissolve_free_huge_page().

CPU0: CPU1:

// page_count(page) == 1
put_page(page)
__free_huge_page(page)
dissolve_free_huge_page(page)
spin_lock(&hugetlb_lock)
// PageHuge(page) && !page_count(page)
update_and_free_page(page)
// page is freed to the buddy
spin_unlock(&hugetlb_lock)
spin_lock(&hugetlb_lock)
clear_page_huge_active(page)
enqueue_huge_page(page)
// It is wrong, the page is already freed
spin_unlock(&hugetlb_lock)

The race window is between put_page() and dissolve_free_huge_page().

We should make sure that the page is already on the free list when it is
dissolved.

As a result __free_huge_page would corrupt page(s) already in the buddy
allocator.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Muchun Song <[email protected]>
Reviewed-by: Mike Kravetz <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Cc: David Hildenbrand <[email protected]>
Cc: Yang Shi <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/hugetlb.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -79,6 +79,21 @@ DEFINE_SPINLOCK(hugetlb_lock);
static int num_fault_mutexes;
struct mutex *hugetlb_fault_mutex_table ____cacheline_aligned_in_smp;

+static inline bool PageHugeFreed(struct page *head)
+{
+ return page_private(head + 4) == -1UL;
+}
+
+static inline void SetPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, -1UL);
+}
+
+static inline void ClearPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, 0);
+}
+
/* Forward declaration */
static int hugetlb_acct_memory(struct hstate *h, long delta);

@@ -1028,6 +1043,7 @@ static void enqueue_huge_page(struct hst
list_move(&page->lru, &h->hugepage_freelists[nid]);
h->free_huge_pages++;
h->free_huge_pages_node[nid]++;
+ SetPageHugeFreed(page);
}

static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
@@ -1044,6 +1060,7 @@ static struct page *dequeue_huge_page_no

list_move(&page->lru, &h->hugepage_activelist);
set_page_refcounted(page);
+ ClearPageHugeFreed(page);
h->free_huge_pages--;
h->free_huge_pages_node[nid]--;
return page;
@@ -1505,6 +1522,7 @@ static void prep_new_huge_page(struct hs
spin_lock(&hugetlb_lock);
h->nr_huge_pages++;
h->nr_huge_pages_node[nid]++;
+ ClearPageHugeFreed(page);
spin_unlock(&hugetlb_lock);
}

@@ -1755,6 +1773,7 @@ int dissolve_free_huge_page(struct page
{
int rc = -EBUSY;

+retry:
/* Not to disrupt normal path by vainly holding hugetlb_lock */
if (!PageHuge(page))
return 0;
@@ -1771,6 +1790,26 @@ int dissolve_free_huge_page(struct page
int nid = page_to_nid(head);
if (h->free_huge_pages - h->resv_huge_pages == 0)
goto out;
+
+ /*
+ * We should make sure that the page is already on the free list
+ * when it is dissolved.
+ */
+ if (unlikely(!PageHugeFreed(head))) {
+ spin_unlock(&hugetlb_lock);
+ cond_resched();
+
+ /*
+ * Theoretically, we should return -EBUSY when we
+ * encounter this race. In fact, we have a chance
+ * to successfully dissolve the page if we do a
+ * retry. Because the race window is quite small.
+ * If we seize this opportunity, it is an optimization
+ * for increasing the success rate of dissolving page.
+ */
+ goto retry;
+ }
+
/*
* Move PageHWPoison flag from head page to the raw error page,
* which makes any subpages rather than the error page reusable.


2021-02-08 17:55:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 104/120] mm: thp: fix MADV_REMOVE deadlock on shmem THP

From: Hugh Dickins <[email protected]>

commit 1c2f67308af4c102b4e1e6cd6f69819ae59408e0 upstream.

Sergey reported deadlock between kswapd correctly doing its usual
lock_page(page) followed by down_read(page->mapping->i_mmap_rwsem), and
madvise(MADV_REMOVE) on an madvise(MADV_HUGEPAGE) area doing
down_write(page->mapping->i_mmap_rwsem) followed by lock_page(page).

This happened when shmem_fallocate(punch hole)'s unmap_mapping_range()
reaches zap_pmd_range()'s call to __split_huge_pmd(). The same deadlock
could occur when partially truncating a mapped huge tmpfs file, or using
fallocate(FALLOC_FL_PUNCH_HOLE) on it.

__split_huge_pmd()'s page lock was added in 5.8, to make sure that any
concurrent use of reuse_swap_page() (holding page lock) could not catch
the anon THP's mapcounts and swapcounts while they were being split.

Fortunately, reuse_swap_page() is never applied to a shmem or file THP
(not even by khugepaged, which checks PageSwapCache before calling), and
anonymous THPs are never created in shmem or file areas: so that
__split_huge_pmd()'s page lock can only be necessary for anonymous THPs,
on which there is no risk of deadlock with i_mmap_rwsem.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: c444eb564fb1 ("mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()")
Signed-off-by: Hugh Dickins <[email protected]>
Reported-by: Sergey Senozhatsky <[email protected]>
Reviewed-by: Andrea Arcangeli <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/huge_memory.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)

--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2188,7 +2188,7 @@ void __split_huge_pmd(struct vm_area_str
{
spinlock_t *ptl;
struct mmu_notifier_range range;
- bool was_locked = false;
+ bool do_unlock_page = false;
pmd_t _pmd;

mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
@@ -2204,7 +2204,6 @@ void __split_huge_pmd(struct vm_area_str
VM_BUG_ON(freeze && !page);
if (page) {
VM_WARN_ON_ONCE(!PageLocked(page));
- was_locked = true;
if (page != pmd_page(*pmd))
goto out;
}
@@ -2213,19 +2212,29 @@ repeat:
if (pmd_trans_huge(*pmd)) {
if (!page) {
page = pmd_page(*pmd);
- if (unlikely(!trylock_page(page))) {
- get_page(page);
- _pmd = *pmd;
- spin_unlock(ptl);
- lock_page(page);
- spin_lock(ptl);
- if (unlikely(!pmd_same(*pmd, _pmd))) {
- unlock_page(page);
+ /*
+ * An anonymous page must be locked, to ensure that a
+ * concurrent reuse_swap_page() sees stable mapcount;
+ * but reuse_swap_page() is not used on shmem or file,
+ * and page lock must not be taken when zap_pmd_range()
+ * calls __split_huge_pmd() while i_mmap_lock is held.
+ */
+ if (PageAnon(page)) {
+ if (unlikely(!trylock_page(page))) {
+ get_page(page);
+ _pmd = *pmd;
+ spin_unlock(ptl);
+ lock_page(page);
+ spin_lock(ptl);
+ if (unlikely(!pmd_same(*pmd, _pmd))) {
+ unlock_page(page);
+ put_page(page);
+ page = NULL;
+ goto repeat;
+ }
put_page(page);
- page = NULL;
- goto repeat;
}
- put_page(page);
+ do_unlock_page = true;
}
}
if (PageMlocked(page))
@@ -2235,7 +2244,7 @@ repeat:
__split_huge_pmd_locked(vma, pmd, range.start, freeze);
out:
spin_unlock(ptl);
- if (!was_locked && page)
+ if (do_unlock_page)
unlock_page(page);
/*
* No need to double call mmu_notifier->invalidate_range() callback.


2021-02-08 17:56:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 118/120] udp: ipv4: manipulate network header of NATed UDP GRO fraglist

From: Dongseok Yi <[email protected]>

commit c3df39ac9b0e3747bf8233ea9ce4ed5ceb3199d3 upstream.

UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
forwarding. Only the header of head_skb from ip_finish_output_gso ->
skb_gso_segment is updated but following frag_skbs are not updated.

A call path skb_mac_gso_segment -> inet_gso_segment ->
udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
does not try to update UDP/IP header of the segment list but copy
only the MAC header.

Update port, addr and check of each skb of the segment list in
__udp_gso_segment_list. It covers both SNAT and DNAT.

Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
Signed-off-by: Dongseok Yi <[email protected]>
Acked-by: Steffen Klassert <[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]>
---
include/net/udp.h | 2 -
net/ipv4/udp_offload.c | 69 +++++++++++++++++++++++++++++++++++++++++++++----
net/ipv6/udp_offload.c | 2 -
3 files changed, 66 insertions(+), 7 deletions(-)

--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -178,7 +178,7 @@ struct sk_buff *udp_gro_receive(struct l
int udp_gro_complete(struct sk_buff *skb, int nhoff, udp_lookup_t lookup);

struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features);
+ netdev_features_t features, bool is_ipv6);

static inline struct udphdr *udp_gro_udphdr(struct sk_buff *skb)
{
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -184,8 +184,67 @@ out_unlock:
}
EXPORT_SYMBOL(skb_udp_tunnel_segment);

+static void __udpv4_gso_segment_csum(struct sk_buff *seg,
+ __be32 *oldip, __be32 *newip,
+ __be16 *oldport, __be16 *newport)
+{
+ struct udphdr *uh;
+ struct iphdr *iph;
+
+ if (*oldip == *newip && *oldport == *newport)
+ return;
+
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if (uh->check) {
+ inet_proto_csum_replace4(&uh->check, seg, *oldip, *newip,
+ true);
+ inet_proto_csum_replace2(&uh->check, seg, *oldport, *newport,
+ false);
+ if (!uh->check)
+ uh->check = CSUM_MANGLED_0;
+ }
+ *oldport = *newport;
+
+ csum_replace4(&iph->check, *oldip, *newip);
+ *oldip = *newip;
+}
+
+static struct sk_buff *__udpv4_gso_segment_list_csum(struct sk_buff *segs)
+{
+ struct sk_buff *seg;
+ struct udphdr *uh, *uh2;
+ struct iphdr *iph, *iph2;
+
+ seg = segs;
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if ((udp_hdr(seg)->dest == udp_hdr(seg->next)->dest) &&
+ (udp_hdr(seg)->source == udp_hdr(seg->next)->source) &&
+ (ip_hdr(seg)->daddr == ip_hdr(seg->next)->daddr) &&
+ (ip_hdr(seg)->saddr == ip_hdr(seg->next)->saddr))
+ return segs;
+
+ while ((seg = seg->next)) {
+ uh2 = udp_hdr(seg);
+ iph2 = ip_hdr(seg);
+
+ __udpv4_gso_segment_csum(seg,
+ &iph2->saddr, &iph->saddr,
+ &uh2->source, &uh->source);
+ __udpv4_gso_segment_csum(seg,
+ &iph2->daddr, &iph->daddr,
+ &uh2->dest, &uh->dest);
+ }
+
+ return segs;
+}
+
static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,
- netdev_features_t features)
+ netdev_features_t features,
+ bool is_ipv6)
{
unsigned int mss = skb_shinfo(skb)->gso_size;

@@ -195,11 +254,11 @@ static struct sk_buff *__udp_gso_segment

udp_hdr(skb)->len = htons(sizeof(struct udphdr) + mss);

- return skb;
+ return is_ipv6 ? skb : __udpv4_gso_segment_list_csum(skb);
}

struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features)
+ netdev_features_t features, bool is_ipv6)
{
struct sock *sk = gso_skb->sk;
unsigned int sum_truesize = 0;
@@ -211,7 +270,7 @@ struct sk_buff *__udp_gso_segment(struct
__be16 newlen;

if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST)
- return __udp_gso_segment_list(gso_skb, features);
+ return __udp_gso_segment_list(gso_skb, features, is_ipv6);

mss = skb_shinfo(gso_skb)->gso_size;
if (gso_skb->len <= sizeof(*uh) + mss)
@@ -325,7 +384,7 @@ static struct sk_buff *udp4_ufo_fragment
goto out;

if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features, false);

mss = skb_shinfo(skb)->gso_size;
if (unlikely(skb->len <= mss))
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -46,7 +46,7 @@ static struct sk_buff *udp6_ufo_fragment
goto out;

if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features, true);

/* Do software UFO. Complete and fill in the UDP checksum as HW cannot
* do checksum of UDP packets sent as multiple IP fragments.


2021-02-08 17:57:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 095/120] ARM: dts; gta04: SPI panel chip select is active low

From: H. Nikolaus Schaller <[email protected]>

commit 181739822cf6f8f4e12b173913af2967a28906c0 upstream.

With the arrival of

commit 2fee9583198eb9 ("spi: dt-bindings: clarify CS behavior for spi-cs-high and gpio descriptors")

it was clarified what the proper state for cs-gpios should be, even if the
flag is ignored. The driver code is doing the right thing since

766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")

The chip-select of the td028ttec1 panel is active-low, so we must omit spi-cs-high;
attribute (already removed by separate patch) and should now use GPIO_ACTIVE_LOW for
the client device description to be fully consistent.

Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
CC: [email protected]
Signed-off-by: H. Nikolaus Schaller <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 003202d12990..7b8c18e6605e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -114,7 +114,7 @@ spi_lcd: spi_lcd {
gpio-sck = <&gpio1 12 GPIO_ACTIVE_HIGH>;
gpio-miso = <&gpio1 18 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio1 20 GPIO_ACTIVE_HIGH>;
- cs-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
num-chipselects = <1>;

/* lcd panel */
--
2.30.0



2021-02-08 17:58:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 100/120] mm: hugetlb: fix a race between isolating and freeing page

From: Muchun Song <[email protected]>

commit 0eb2df2b5629794020f75e94655e1994af63f0d4 upstream.

There is a race between isolate_huge_page() and __free_huge_page().

CPU0: CPU1:

if (PageHuge(page))
put_page(page)
__free_huge_page(page)
spin_lock(&hugetlb_lock)
update_and_free_page(page)
set_compound_page_dtor(page,
NULL_COMPOUND_DTOR)
spin_unlock(&hugetlb_lock)
isolate_huge_page(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHead(page), page)
spin_lock(&hugetlb_lock)
page_huge_active(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHuge(page), page)
spin_unlock(&hugetlb_lock)

When we isolate a HugeTLB page on CPU0. Meanwhile, we free it to the
buddy allocator on CPU1. Then, we can trigger a BUG_ON on CPU0, because
it is already freed to the buddy allocator.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Muchun Song <[email protected]>
Reviewed-by: Mike Kravetz <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
Cc: David Hildenbrand <[email protected]>
Cc: Yang Shi <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/hugetlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5595,9 +5595,9 @@ bool isolate_huge_page(struct page *page
{
bool ret = true;

- VM_BUG_ON_PAGE(!PageHead(page), page);
spin_lock(&hugetlb_lock);
- if (!page_huge_active(page) || !get_page_unless_zero(page)) {
+ if (!PageHeadHuge(page) || !page_huge_active(page) ||
+ !get_page_unless_zero(page)) {
ret = false;
goto unlock;
}


2021-02-08 20:11:02

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon 2021-02-08 15:59:47, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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, 10 Feb 2021 14:57:55 +0000.
> Anything received after that time might be too late.

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) (835.00 B)
signature.asc (201.00 B)
Download all attachments

2021-02-08 21:12:25

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On 2/8/21 7:59 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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, 10 Feb 2021 14:57:55 +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.15-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-02-08 21:30:25

by Davidson Francis

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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.

Compiled and boot tested for x86_64, no dmesg regressions found.

Tested-by: Davidson Francis <[email protected]>

Regards,
Davidson Francis

2021-02-09 02:36:11

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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, 10 Feb 2021 14:57:55 +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.15-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

Due to the patch below, the x86_64 build breaks with gcc 7.3.x
This issue is specific to openembedded kernel builder.

We have also noticed on mainline, Linux next and now on stable-rc 5.10.

collect2: error: ld returned 1 exit status
make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1

ref:
Build failure link,
https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/DISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText

> Rolf Eike Beer <[email protected]>
> scripts: use pkg-config to locate libcrypto

From 7658769759718950f5eda0079e84837738d8fda8 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer <[email protected]>
Date: Thu, 22 Nov 2018 16:40:49 +0100
Subject: scripts: use pkg-config to locate libcrypto

commit 2cea4a7a1885bd0c765089afc14f7ff0eb77864e upstream.

Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.

Signed-off-by: Rolf Eike Beer <[email protected]>
Cc: [email protected] # 5.6.x
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

2021-02-09 06:54:53

by Rolf Eike Beer

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju:
> On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
>
> <[email protected]> wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 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, 10 Feb 2021 14:57:55 +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.15-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
>
> Due to the patch below, the x86_64 build breaks with gcc 7.3.x
> This issue is specific to openembedded kernel builder.
>
> We have also noticed on mainline, Linux next and now on stable-rc 5.10.
>
> collect2: error: ld returned 1 exit status
> make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
>
> ref:
> Build failure link,
> https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D
> ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText

Is this part relevant or does that always happen with your builder.

| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside
/
| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/
libc_nonshared.a inside /
| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux-
x86-64.so.2 inside /

Can you provide a log with V=1 where we can see what actually is going on?

Eike
--
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source


Attachments:
signature.asc (321.00 B)
This is a digitally signed message part.

2021-02-09 07:15:04

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Tue, 9 Feb 2021 at 12:22, Rolf Eike Beer <[email protected]> wrote:
>
> Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju:
> > On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
> >
> > <[email protected]> wrote:
> > > This is the start of the stable review cycle for the 5.10.15 release.
> > > There are 120 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, 10 Feb 2021 14:57:55 +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.15-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
> >
> > Due to the patch below, the x86_64 build breaks with gcc 7.3.x
> > This issue is specific to openembedded kernel builder.
> >
> > We have also noticed on mainline, Linux next and now on stable-rc 5.10.
> >
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
> >
> > ref:
> > Build failure link,
> > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D
> > ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText
>
> Is this part relevant or does that always happen with your builder.
>
> | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside
> /
> | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/
> libc_nonshared.a inside /
> | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux-
> x86-64.so.2 inside /
>
> Can you provide a log with V=1 where we can see what actually is going on?

Daniel Díaz sent a fix patch on the stable mailing list.

[PATCH] scripts: Fix linking extract-cert against libcrypto
https://lore.kernel.org/stable/[email protected]/T/#u

- Naresh

2021-02-09 14:18:08

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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, 10 Feb 2021 14:57:55 +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.15-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 and i386.

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

NOTE:
When compiling under OpenEmbedded, the following error is seen
as of recently:

/srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
/srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a inside /
/srv/oe/build/tmp/hosttools/ld: cannot find /lib/ld-linux-x86-64.so.2 inside /
collect2: error: ld returned 1 exit status
make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1

This is because
2cea4a7a1885 ("scripts: use pkg-config to locate libcrypto"

This patch will fix the reported problem.
scripts: Fix linking extract-cert against libcrypto
https://lore.kernel.org/stable/[email protected]/T/#u

Summary
------------------------------------------------------------------------

kernel: 5.10.15-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.10.y
git commit: 21cc9754fccca82f1b3aae7baa6cddfdf4384802
git describe: v5.10.14-121-g21cc9754fccc
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.14-121-g21cc9754fccc

No regressions (compared to build v5.10.14)

No fixes (compared to build v5.10.14)

Ran 55235 total tests in the following environments and test suites.

Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- nxp-ls2088-64k_page_size
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64

Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kvm-unit-tests
* libhugetlbfs
* ltp-commands-tests
* ltp-containers-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* fwts
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-controllers-tests
* ltp-open-posix-tests
* network-basic-tests
* perf
* v4l2-compliance
* kunit
* rcutorture
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-lib
* kselftest-lkdtm
* 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-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* kselftest-
* kselftest-intel_pstate
* kselftest-kexec
* kselftest-kvm
* kselftest-livepatch
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-vm
* kselftest-x86

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

2021-02-09 20:46:19

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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, 10 Feb 2021 14:57:55 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 427 pass: 427 fail: 0

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

Guenter

2021-02-10 02:23:02

by Ross Schmidt

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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.
>

Compiled and booted with no regressions on x86_64.

Tested-by: Ross Schmidt <[email protected]>


thanks,

Ross

2021-02-10 08:46:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, Feb 08, 2021 at 05:22:07PM -0300, Davidson Francis wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 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.
>
> Compiled and boot tested for x86_64, no dmesg regressions found.
>
> Tested-by: Davidson Francis <[email protected]>

Thanks for testing!

greg k-h

2021-02-10 08:46:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, Feb 08, 2021 at 07:33:53PM +0100, Pavel Machek wrote:
> On Mon 2021-02-08 15:59:47, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 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, 10 Feb 2021 14:57:55 +0000.
> > Anything received after that time might be too late.
>
> 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]>

Thanks for testing some of them and letting me know.

greg k-h

2021-02-10 08:46:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Mon, Feb 08, 2021 at 01:01:09PM -0700, Shuah Khan wrote:
> On 2/8/21 7:59 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 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, 10 Feb 2021 14:57:55 +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.15-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 for testing them all and letting me know.

greg k-h

2021-02-10 08:48:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Tue, Feb 09, 2021 at 07:28:16PM -0600, Ross Schmidt wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 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.
> >
>
> Compiled and booted with no regressions on x86_64.
>
> Tested-by: Ross Schmidt <[email protected]>

Thanks for testing and letting me know.

greg k-h

2021-02-10 08:48:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Tue, Feb 09, 2021 at 10:14:44AM -0800, Guenter Roeck wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 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, 10 Feb 2021 14:57:55 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 154 pass: 154 fail: 0
> Qemu test results:
> total: 427 pass: 427 fail: 0
>
> Tested-by: Guenter Roeck <[email protected]>

Great, thanks for testing.

greg k-h

2021-02-10 08:48:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 000/120] 5.10.15-rc1 review

On Tue, Feb 09, 2021 at 07:42:34PM +0530, Naresh Kamboju wrote:
> On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 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, 10 Feb 2021 14:57:55 +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.15-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 and i386.
>
> Tested-by: Linux Kernel Functional Testing <[email protected]>
>

Thanks for testing them all and letting me know.

greg k-h