2020-02-13 15:31:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 00/96] 5.4.20-stable review

This is the start of the stable review cycle for the 5.4.20 release.
There are 96 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 Sat, 15 Feb 2020 15:16:40 +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.4.20-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Nicolai Stange <[email protected]>
libertas: make lbs_ibss_join_existing() return error code on rates overflow

Nicolai Stange <[email protected]>
libertas: don't exit from lbs_ibss_join_existing() with RCU read lock held

Qing Xu <[email protected]>
mwifiex: Fix possible buffer overflows in mwifiex_cmd_append_vsie_tlv()

Qing Xu <[email protected]>
mwifiex: Fix possible buffer overflows in mwifiex_ret_wmm_get_status()

Chuhong Yuan <[email protected]>
dmaengine: axi-dmac: add a check for devm_regmap_init_mmio

Jerome Brunet <[email protected]>
clk: meson: g12a: fix missing uart2 in regmap table

Bartosz Golaszewski <[email protected]>
mfd: max77650: Select REGMAP_IRQ in Kconfig

Ben Whitten <[email protected]>
regmap: fix writes to non incrementing registers

Geert Uytterhoeven <[email protected]>
pinctrl: sh-pfc: r8a7778: Fix duplicate SDSELF_B and SD1_CLK_B

Geert Uytterhoeven <[email protected]>
pinctrl: sh-pfc: r8a77965: Fix DU_DOTCLKIN3 drive/bias control

Stephen Smalley <[email protected]>
selinux: fix regression introduced by move_mount(2) syscall

Stephen Smalley <[email protected]>
selinux: revert "stop passing MAY_NOT_BLOCK to the AVC upon follow_link"

Coly Li <[email protected]>
bcache: avoid unnecessary btree nodes flushing in btree_flush_write()

Beniamin Bia <[email protected]>
dt-bindings: iio: adc: ad7606: Fix wrong maxItems value

Gustavo A. R. Silva <[email protected]>
media: i2c: adv748x: Fix unsafe macros

Christophe Roullier <[email protected]>
drivers: watchdog: stm32_iwdg: set WDOG_HW_RUNNING at probe

Horia Geantă <[email protected]>
crypto: caam/qi2 - fix typo in algorithm's driver name

Eric Biggers <[email protected]>
crypto: atmel-sha - fix error handling when setting hmac key

Eric Biggers <[email protected]>
crypto: artpec6 - return correct error code for failed setkey()

Eric Biggers <[email protected]>
crypto: testmgr - don't try to decrypt uninitialized buffers

YueHaibing <[email protected]>
mtd: sharpslpart: Fix unsigned comparison to zero

Nathan Chancellor <[email protected]>
mtd: onenand_base: Adjust indentation in onenand_read_ops_nolock

Suzuki K Poulose <[email protected]>
arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly

Alexandru Elisei <[email protected]>
KVM: arm64: Treat emulated TVAL TimerValue as a signed 32-bit integer

Eric Auger <[email protected]>
KVM: arm64: pmu: Fix chained SW_INCR counters

Eric Auger <[email protected]>
KVM: arm64: pmu: Don't increment SW_INCR if PMCR.E is unset

James Morse <[email protected]>
KVM: arm: Make inject_abt32() inject an external abort instead

James Morse <[email protected]>
KVM: arm: Fix DFSR setting for non-LPAE aarch32 guests

Gavin Shan <[email protected]>
KVM: arm/arm64: Fix young bit from mmu notifier

Suzuki K Poulose <[email protected]>
arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations

Suzuki K Poulose <[email protected]>
arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly

Suzuki K Poulose <[email protected]>
arm64: cpufeature: Fix the type of no FP/SIMD capability

Qais Yousef <[email protected]>
sched/uclamp: Fix a bug in propagating uclamp value in new cgroups

Olof Johansson <[email protected]>
ARM: 8949/1: mm: mark free_memmap as __init

Eric Auger <[email protected]>
KVM: arm/arm64: vgic-its: Fix restoration of unmapped collections

Claudiu Beznea <[email protected]>
ARM: at91: pm: use of_device_id array to find the proper shdwc node

Claudiu Beznea <[email protected]>
ARM: at91: pm: use SAM9X60 PMC's compatible

Shameer Kolothum <[email protected]>
iommu/arm-smmu-v3: Populate VMID field for CMDQ_OP_TLBI_NH_VA

Alexey Kardashevskiy <[email protected]>
powerpc/pseries: Allow not having ibm, hypertas-functions::hcall-multi-tce for DDW

Tyrel Datwyler <[email protected]>
powerpc/pseries/vio: Fix iommu_table use-after-free refcount warning

Vaibhav Jain <[email protected]>
powerpc/papr_scm: Fix leaking 'bus_desc.provider_name' in some paths

Christophe Leroy <[email protected]>
powerpc/ptdump: Only enable PPC_CHECK_WX with STRICT_KERNEL_RWX

Christophe Leroy <[email protected]>
powerpc/ptdump: Fix W+X verification call in mark_rodata_ro()

Ram Pai <[email protected]>
Revert "powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests"

Douglas Anderson <[email protected]>
soc: qcom: rpmhpd: Set 'active_only' for active only power domains

Zhengyuan Liu <[email protected]>
tools/power/acpi: fix compilation error

Alexandre Belloni <[email protected]>
ARM: dts: at91: sama5d3: define clock rate range for tcb1

Alexandre Belloni <[email protected]>
ARM: dts: at91: sama5d3: fix maximum peripheral clock rates

Martin Blumenstingl <[email protected]>
ARM: dts: meson8b: use the actual frequency for the GPU's 364MHz OPP

Martin Blumenstingl <[email protected]>
ARM: dts: meson8: use the actual frequency for the GPU's 182.1MHz OPP

Baruch Siach <[email protected]>
arm64: dts: marvell: clearfog-gt-8k: fix switch cpu port node

Kuninori Morimoto <[email protected]>
arm64: dts: renesas: r8a77990: ebisu: Remove clkout-lr-synchronous from sound

Tero Kristo <[email protected]>
ARM: dts: am43xx: add support for clkout1 clock

Ingo van Lil <[email protected]>
ARM: dts: at91: Reenable UART TX pull-ups

Russell King <[email protected]>
arm64: dts: uDPU: fix broken ethernet

Jeffrey Hugo <[email protected]>
arm64: dts: qcom: msm8998: Fix tcsr syscon size

Mika Westerberg <[email protected]>
platform/x86: intel_mid_powerbtn: Take a copy of ddata

Jose Abreu <[email protected]>
ARC: [plat-axs10x]: Add missing multicast filter number to GMAC node

Sai Prakash Ranjan <[email protected]>
watchdog: qcom: Use platform_get_irq_optional() for bark irq

Andy Shevchenko <[email protected]>
rtc: cmos: Stop using shared IRQ

Geert Uytterhoeven <[email protected]>
rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed

Paul Kocialkowski <[email protected]>
rtc: hym8563: Return -EINVAL if the time is known to be invalid

Steven Clarkson <[email protected]>
x86/boot: Handle malformed SRAT tables during early ACPI parsing

Robert Milkowski <[email protected]>
NFSv4.0: nfs4_do_fsinfo() should not do implicit lease renewals

Robert Milkowski <[email protected]>
NFSv4: try lease recovery on NFS4ERR_EXPIRED

Trond Myklebust <[email protected]>
NFSv4: pnfs_roc() must use cred_fscmp() to compare creds

Trond Myklebust <[email protected]>
NFS: Fix fix of show_nfs_errors

Trond Myklebust <[email protected]>
NFS/pnfs: Fix pnfs_generic_prepare_to_resend_writes()

Trond Myklebust <[email protected]>
NFS: Revalidate the file size on a fatal write error

Geert Uytterhoeven <[email protected]>
nfs: NFS_SWAP should depend on SWAP

Lorenz Bauer <[email protected]>
bpf, sockmap: Check update requirements after locking

Martin KaFai Lau <[email protected]>
bpf: Improve bucket_log calculation logic

Jakub Sitnicki <[email protected]>
selftests/bpf: Test freeing sockmap/sockhash with a socket in it

Jakub Sitnicki <[email protected]>
bpf, sockhash: Synchronize_rcu before free'ing map

Jakub Sitnicki <[email protected]>
bpf, sockmap: Don't sleep while holding RCU lock on tear-down

Toke Høiland-Jørgensen <[email protected]>
bpftool: Don't crash on missing xlated program instructions

Avraham Stern <[email protected]>
iwlwifi: mvm: avoid use after free for pmsr request

Dongdong Liu <[email protected]>
PCI/AER: Initialize aer_fifo

Logan Gunthorpe <[email protected]>
PCI: Don't disable bridge BARs when assigning bus resources

Marcel Ziswiler <[email protected]>
PCI: tegra: Fix afi_pex2_ctrl reg offset for Tegra30

Logan Gunthorpe <[email protected]>
PCI/switchtec: Fix vep_vector_number ioread width

Wesley Sheng <[email protected]>
PCI/switchtec: Use dma_set_mask_and_coherent()

Bryan O'Donoghue <[email protected]>
ath10k: pci: Only dump ATH10K_MEM_REGION_TYPE_IOREG when safe

Navid Emamdoost <[email protected]>
PCI/IOV: Fix memory leak in pci_iov_add_virtfn()

Bean Huo <[email protected]>
scsi: ufs: Fix ufshcd_probe_hba() reture value in case ufshcd_scsi_add_wlus() fails

Artemy Kovalyov <[email protected]>
RDMA/umem: Fix ib_umem_find_best_pgsz()

Parav Pandit <[email protected]>
RDMA/cma: Fix unbalanced cm_id reference count during address resolve

Michael Guralnik <[email protected]>
RDMA/uverbs: Verify MR access flags

Jason Gunthorpe <[email protected]>
RDMA/core: Fix locking in ib_uverbs_event_read

Xiyu Yang <[email protected]>
RDMA/i40iw: fix a potential NULL pointer dereference

Håkon Bugge <[email protected]>
RDMA/netlink: Do not always generate an ACK for some netlink operations

Håkon Bugge <[email protected]>
IB/mlx4: Fix leak in id_map_find_del

Sergey Gorenko <[email protected]>
IB/srp: Never use immediate data if it is disabled by a user

Jack Morgenstein <[email protected]>
IB/mlx4: Fix memory leak in add_gid error flow

Sunil Muthuswamy <[email protected]>
hv_sock: Remove the accept port restriction

Ranjani Sridharan <[email protected]>
ASoC: pcm: update FE/BE trigger order based on the command


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

Diffstat:

.../devicetree/bindings/iio/adc/adi,ad7606.yaml | 8 +-
Makefile | 4 +-
arch/arc/boot/dts/axs10x_mb.dtsi | 1 +
arch/arm/boot/dts/am43xx-clocks.dtsi | 54 ++++++++++++
arch/arm/boot/dts/at91sam9260.dtsi | 12 +--
arch/arm/boot/dts/at91sam9261.dtsi | 6 +-
arch/arm/boot/dts/at91sam9263.dtsi | 6 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 8 +-
arch/arm/boot/dts/at91sam9rl.dtsi | 8 +-
arch/arm/boot/dts/meson8.dtsi | 4 +-
arch/arm/boot/dts/meson8b.dtsi | 4 +-
arch/arm/boot/dts/sama5d3.dtsi | 28 +++----
arch/arm/boot/dts/sama5d3_can.dtsi | 4 +-
arch/arm/boot/dts/sama5d3_tcb1.dtsi | 1 +
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 +-
arch/arm/mach-at91/pm.c | 9 +-
arch/arm/mm/init.c | 2 +-
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts | 4 +
.../dts/marvell/armada-8040-clearfog-gt-8k.dts | 2 +
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 1 -
arch/arm64/kernel/cpufeature.c | 39 ++++++++-
arch/arm64/kernel/fpsimd.c | 30 ++++++-
arch/arm64/kernel/ptrace.c | 21 +++++
arch/arm64/kvm/hyp/switch.c | 10 ++-
arch/powerpc/Kconfig.debug | 2 +-
arch/powerpc/mm/pgtable_32.c | 1 +
arch/powerpc/platforms/pseries/iommu.c | 54 ++++++------
arch/powerpc/platforms/pseries/papr_scm.c | 2 +
arch/powerpc/platforms/pseries/vio.c | 2 +
arch/x86/boot/compressed/acpi.c | 6 ++
crypto/testmgr.c | 20 ++++-
drivers/base/regmap/regmap.c | 17 ++--
drivers/clk/meson/g12a.c | 1 +
drivers/crypto/atmel-sha.c | 7 +-
drivers/crypto/axis/artpec6_crypto.c | 2 +-
drivers/crypto/caam/caamalg_qi2.c | 2 +-
drivers/dma/dma-axi-dmac.c | 10 ++-
drivers/infiniband/core/addr.c | 2 +-
drivers/infiniband/core/cma.c | 2 +
drivers/infiniband/core/sa_query.c | 4 +-
drivers/infiniband/core/umem.c | 9 +-
drivers/infiniband/core/uverbs_main.c | 32 ++++----
drivers/infiniband/hw/i40iw/i40iw_main.c | 2 +
drivers/infiniband/hw/mlx4/cm.c | 29 +------
drivers/infiniband/hw/mlx4/main.c | 20 ++++-
drivers/infiniband/ulp/srp/ib_srp.c | 3 +-
drivers/iommu/arm-smmu-v3.c | 1 +
drivers/md/bcache/journal.c | 80 ++++++++++++++++--
drivers/media/i2c/adv748x/adv748x.h | 8 +-
drivers/mfd/Kconfig | 1 +
drivers/mtd/nand/onenand/onenand_base.c | 82 +++++++++----------
drivers/mtd/parsers/sharpslpart.c | 4 +-
drivers/net/wireless/ath/ath10k/pci.c | 19 ++++-
.../net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 5 +-
drivers/net/wireless/marvell/libertas/cfg.c | 2 +
drivers/net/wireless/marvell/mwifiex/scan.c | 7 ++
drivers/net/wireless/marvell/mwifiex/wmm.c | 4 +
drivers/pci/controller/pci-tegra.c | 2 +-
drivers/pci/iov.c | 9 +-
drivers/pci/pcie/aer.c | 1 +
drivers/pci/setup-bus.c | 20 ++++-
drivers/pci/switch/switchtec.c | 4 +-
drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 4 +-
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 6 +-
drivers/platform/x86/intel_mid_powerbtn.c | 5 +-
drivers/rtc/Kconfig | 8 +-
drivers/rtc/rtc-cmos.c | 2 +-
drivers/rtc/rtc-hym8563.c | 2 +-
drivers/scsi/ufs/ufshcd.c | 3 +-
drivers/soc/qcom/rpmhpd.c | 2 +
drivers/watchdog/qcom-wdt.c | 2 +-
drivers/watchdog/stm32_iwdg.c | 18 ++++
fs/nfs/Kconfig | 2 +-
fs/nfs/direct.c | 4 +-
fs/nfs/nfs3xdr.c | 5 +-
fs/nfs/nfs4_fs.h | 4 +-
fs/nfs/nfs4proc.c | 17 +++-
fs/nfs/nfs4renewd.c | 5 +-
fs/nfs/nfs4state.c | 4 +-
fs/nfs/nfs4trace.h | 31 +++----
fs/nfs/nfs4xdr.c | 5 +-
fs/nfs/pnfs.c | 2 +-
fs/nfs/pnfs_nfs.c | 7 +-
fs/nfs/write.c | 12 ++-
include/rdma/ib_verbs.h | 3 +
kernel/sched/core.c | 6 ++
net/core/bpf_sk_storage.c | 5 +-
net/core/sock_map.c | 28 ++++---
net/vmw_vsock/hyperv_transport.c | 68 ++--------------
security/selinux/avc.c | 24 +++++-
security/selinux/hooks.c | 15 +++-
security/selinux/include/avc.h | 5 ++
sound/soc/soc-pcm.c | 95 ++++++++++++++++------
tools/bpf/bpftool/prog.c | 2 +-
tools/power/acpi/Makefile.config | 2 +-
.../selftests/bpf/prog_tests/sockmap_basic.c | 74 +++++++++++++++++
virt/kvm/arm/aarch32.c | 14 +++-
virt/kvm/arm/arch_timer.c | 3 +-
virt/kvm/arm/mmu.c | 3 +-
virt/kvm/arm/pmu.c | 42 +++++++---
virt/kvm/arm/vgic/vgic-its.c | 3 +-
102 files changed, 892 insertions(+), 400 deletions(-)



2020-02-13 15:31:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 80/96] crypto: caam/qi2 - fix typo in algorithms driver name

From: Horia Geantă <[email protected]>

commit 53146d152510584c2034c62778a7cbca25743ce9 upstream.

Fixes: 8d818c105501 ("crypto: caam/qi2 - add DPAA2-CAAM driver")
Signed-off-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/caam/caamalg_qi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/crypto/caam/caamalg_qi2.c
+++ b/drivers/crypto/caam/caamalg_qi2.c
@@ -2481,7 +2481,7 @@ static struct caam_aead_alg driver_aeads
.cra_name = "echainiv(authenc(hmac(sha256),"
"cbc(des)))",
.cra_driver_name = "echainiv-authenc-"
- "hmac-sha256-cbc-desi-"
+ "hmac-sha256-cbc-des-"
"caam-qi2",
.cra_blocksize = DES_BLOCK_SIZE,
},


2020-02-13 15:31:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 83/96] dt-bindings: iio: adc: ad7606: Fix wrong maxItems value

From: Beniamin Bia <[email protected]>

commit a6c4f77cb3b11f81077b53c4a38f21b92d41f21e upstream.

This patch set the correct value for oversampling maxItems. In the
original example, appears 3 items for oversampling while the maxItems
is set to 1, this patch fixes those issues.

Fixes: 416f882c3b40 ("dt-bindings: iio: adc: Migrate AD7606 documentation to yaml")
Signed-off-by: Beniamin Bia <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
@@ -85,7 +85,7 @@ properties:
Must be the device tree identifier of the over-sampling
mode pins. As the line is active high, it should be marked
GPIO_ACTIVE_HIGH.
- maxItems: 1
+ maxItems: 3

adi,sw-mode:
description:
@@ -128,9 +128,9 @@ examples:
adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
- adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH
- &gpio 23 GPIO_ACTIVE_HIGH
- &gpio 26 GPIO_ACTIVE_HIGH>;
+ adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
+ <&gpio 23 GPIO_ACTIVE_HIGH>,
+ <&gpio 26 GPIO_ACTIVE_HIGH>;
standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
adi,sw-mode;
};


2020-02-13 15:31:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 43/96] ARM: dts: at91: Reenable UART TX pull-ups

From: Ingo van Lil <[email protected]>

commit 9d39d86cd4af2b17b970d63307daad71f563d207 upstream.

Pull-ups for SAM9 UART/USART TX lines were disabled in a previous
commit. However, several chips in the SAM9 family require pull-ups to
prevent the TX lines from falling (and causing an endless break
condition) when the transceiver is disabled.

>From the SAM9G20 datasheet, 32.5.1: "To prevent the TXD line from
falling when the USART is disabled, the use of an internal pull up
is mandatory.". This commit reenables the pull-ups for all chips having
that sentence in their datasheets.

Fixes: 5e04822f7db5 ("ARM: dts: at91: fixes uart pinctrl, set pullup on rx, clear pullup on tx")
Signed-off-by: Ingo van Lil <[email protected]>
Cc: Peter Rosin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/at91sam9260.dtsi | 12 ++++++------
arch/arm/boot/dts/at91sam9261.dtsi | 6 +++---
arch/arm/boot/dts/at91sam9263.dtsi | 6 +++---
arch/arm/boot/dts/at91sam9g45.dtsi | 8 ++++----
arch/arm/boot/dts/at91sam9rl.dtsi | 8 ++++----
5 files changed, 20 insertions(+), 20 deletions(-)

--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -187,7 +187,7 @@
usart0 {
pinctrl_usart0: usart0-0 {
atmel,pins =
- <AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 5 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -221,7 +221,7 @@
usart1 {
pinctrl_usart1: usart1-0 {
atmel,pins =
- <AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 7 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -239,7 +239,7 @@
usart2 {
pinctrl_usart2: usart2-0 {
atmel,pins =
- <AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -257,7 +257,7 @@
usart3 {
pinctrl_usart3: usart3-0 {
atmel,pins =
- <AT91_PIOB 10 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -275,7 +275,7 @@
uart0 {
pinctrl_uart0: uart0-0 {
atmel,pins =
- <AT91_PIOA 31 AT91_PERIPH_B AT91_PINCTRL_NONE
+ <AT91_PIOA 31 AT91_PERIPH_B AT91_PINCTRL_PULL_UP
AT91_PIOA 30 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>;
};
};
@@ -283,7 +283,7 @@
uart1 {
pinctrl_uart1: uart1-0 {
atmel,pins =
- <AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};
};
--- a/arch/arm/boot/dts/at91sam9261.dtsi
+++ b/arch/arm/boot/dts/at91sam9261.dtsi
@@ -329,7 +329,7 @@
usart0 {
pinctrl_usart0: usart0-0 {
atmel,pins =
- <AT91_PIOC 8 AT91_PERIPH_A AT91_PINCTRL_NONE>,
+ <AT91_PIOC 8 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
<AT91_PIOC 9 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -347,7 +347,7 @@
usart1 {
pinctrl_usart1: usart1-0 {
atmel,pins =
- <AT91_PIOC 12 AT91_PERIPH_A AT91_PINCTRL_NONE>,
+ <AT91_PIOC 12 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
<AT91_PIOC 13 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -365,7 +365,7 @@
usart2 {
pinctrl_usart2: usart2-0 {
atmel,pins =
- <AT91_PIOC 14 AT91_PERIPH_A AT91_PINCTRL_NONE>,
+ <AT91_PIOC 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
<AT91_PIOC 15 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -183,7 +183,7 @@
usart0 {
pinctrl_usart0: usart0-0 {
atmel,pins =
- <AT91_PIOA 26 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOA 26 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOA 27 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -201,7 +201,7 @@
usart1 {
pinctrl_usart1: usart1-0 {
atmel,pins =
- <AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOD 1 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -219,7 +219,7 @@
usart2 {
pinctrl_usart2: usart2-0 {
atmel,pins =
- <AT91_PIOD 2 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOD 2 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOD 3 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -556,7 +556,7 @@
usart0 {
pinctrl_usart0: usart0-0 {
atmel,pins =
- <AT91_PIOB 19 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 19 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 18 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -574,7 +574,7 @@
usart1 {
pinctrl_usart1: usart1-0 {
atmel,pins =
- <AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 5 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -592,7 +592,7 @@
usart2 {
pinctrl_usart2: usart2-0 {
atmel,pins =
- <AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 7 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -610,7 +610,7 @@
usart3 {
pinctrl_usart3: usart3-0 {
atmel,pins =
- <AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_NONE
+ <AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

--- a/arch/arm/boot/dts/at91sam9rl.dtsi
+++ b/arch/arm/boot/dts/at91sam9rl.dtsi
@@ -682,7 +682,7 @@
usart0 {
pinctrl_usart0: usart0-0 {
atmel,pins =
- <AT91_PIOA 6 AT91_PERIPH_A AT91_PINCTRL_NONE>,
+ <AT91_PIOA 6 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
<AT91_PIOA 7 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -721,7 +721,7 @@
usart1 {
pinctrl_usart1: usart1-0 {
atmel,pins =
- <AT91_PIOA 11 AT91_PERIPH_A AT91_PINCTRL_NONE>,
+ <AT91_PIOA 11 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
<AT91_PIOA 12 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -744,7 +744,7 @@
usart2 {
pinctrl_usart2: usart2-0 {
atmel,pins =
- <AT91_PIOA 13 AT91_PERIPH_A AT91_PINCTRL_NONE>,
+ <AT91_PIOA 13 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
<AT91_PIOA 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};

@@ -767,7 +767,7 @@
usart3 {
pinctrl_usart3: usart3-0 {
atmel,pins =
- <AT91_PIOB 0 AT91_PERIPH_A AT91_PINCTRL_NONE>,
+ <AT91_PIOB 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>,
<AT91_PIOB 1 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;
};



2020-02-13 15:31:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 41/96] arm64: dts: qcom: msm8998: Fix tcsr syscon size

From: Jeffrey Hugo <[email protected]>

commit 05caa5bf9cab9983dd7a50428c46b7e617ba20d6 upstream.

The tcsr syscon region is really 0x40000 in size. We need access to the
full region so that we can access the axi resets when managing the
modem subsystem.

Fixes: c7833949564e ("arm64: dts: qcom: msm8998: Add smem related nodes")
Signed-off-by: Jeffrey Hugo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -985,7 +985,7 @@

tcsr_mutex_regs: syscon@1f40000 {
compatible = "syscon";
- reg = <0x01f40000 0x20000>;
+ reg = <0x01f40000 0x40000>;
};

tlmm: pinctrl@3400000 {


2020-02-13 15:32:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 86/96] selinux: fix regression introduced by move_mount(2) syscall

From: Stephen Smalley <[email protected]>

commit 98aa00345de54b8340dc2ddcd87f446d33387b5e upstream.

commit 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around")
introduced a new move_mount(2) system call and a corresponding new LSM
security_move_mount hook but did not implement this hook for any existing
LSM. This creates a regression for SELinux with respect to consistent
checking of mounts; the existing selinux_mount hook checks mounton
permission to the mount point path. Provide a SELinux hook
implementation for move_mount that applies this same check for
consistency. In the future we may wish to add a new move_mount
filesystem permission and check as well, but this addresses
the immediate regression.

Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around")
Signed-off-by: Stephen Smalley <[email protected]>
Reviewed-by: Ondrej Mosnacek <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
security/selinux/hooks.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2766,6 +2766,14 @@ static int selinux_mount(const char *dev
return path_has_perm(cred, path, FILE__MOUNTON);
}

+static int selinux_move_mount(const struct path *from_path,
+ const struct path *to_path)
+{
+ const struct cred *cred = current_cred();
+
+ return path_has_perm(cred, to_path, FILE__MOUNTON);
+}
+
static int selinux_umount(struct vfsmount *mnt, int flags)
{
const struct cred *cred = current_cred();
@@ -6835,6 +6843,8 @@ static struct security_hook_list selinux
LSM_HOOK_INIT(sb_clone_mnt_opts, selinux_sb_clone_mnt_opts),
LSM_HOOK_INIT(sb_add_mnt_opt, selinux_add_mnt_opt),

+ LSM_HOOK_INIT(move_mount, selinux_move_mount),
+
LSM_HOOK_INIT(dentry_init_security, selinux_dentry_init_security),
LSM_HOOK_INIT(dentry_create_files_as, selinux_dentry_create_files_as),



2020-02-13 15:32:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 59/96] iommu/arm-smmu-v3: Populate VMID field for CMDQ_OP_TLBI_NH_VA

From: Shameer Kolothum <[email protected]>

commit 935d43ba272e0001f8ef446a3eff15d8175cb11b upstream.

CMDQ_OP_TLBI_NH_VA requires VMID and this was missing since
commit 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask
for CMD_TLBI_S2_IPA"). Add it back.

Fixes: 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask for CMD_TLBI_S2_IPA")
Signed-off-by: Shameer Kolothum <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iommu/arm-smmu-v3.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -856,6 +856,7 @@ static int arm_smmu_cmdq_build_cmd(u64 *
cmd[1] |= FIELD_PREP(CMDQ_CFGI_1_RANGE, 31);
break;
case CMDQ_OP_TLBI_NH_VA:
+ cmd[0] |= FIELD_PREP(CMDQ_TLBI_0_VMID, ent->tlbi.vmid);
cmd[0] |= FIELD_PREP(CMDQ_TLBI_0_ASID, ent->tlbi.asid);
cmd[1] |= FIELD_PREP(CMDQ_TLBI_1_LEAF, ent->tlbi.leaf);
cmd[1] |= ent->tlbi.addr & CMDQ_TLBI_1_VA_MASK;


2020-02-13 15:32:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 88/96] pinctrl: sh-pfc: r8a7778: Fix duplicate SDSELF_B and SD1_CLK_B

From: Geert Uytterhoeven <[email protected]>

commit 805f635703b2562b5ddd822c62fc9124087e5dd5 upstream.

The FN_SDSELF_B and FN_SD1_CLK_B enum IDs are used twice, which means
one set of users must be wrong. Replace them by the correct enum IDs.

Fixes: 87f8c988636db0d4 ("sh-pfc: Add r8a7778 pinmux support")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
@@ -2305,7 +2305,7 @@ static const struct pinmux_cfg_reg pinmu
FN_ATAG0_A, 0, FN_REMOCON_B, 0,
/* IP0_11_8 [4] */
FN_SD1_DAT2_A, FN_MMC_D2, 0, FN_BS,
- FN_ATADIR0_A, 0, FN_SDSELF_B, 0,
+ FN_ATADIR0_A, 0, FN_SDSELF_A, 0,
FN_PWM4_B, 0, 0, 0,
0, 0, 0, 0,
/* IP0_7_5 [3] */
@@ -2349,7 +2349,7 @@ static const struct pinmux_cfg_reg pinmu
FN_TS_SDAT0_A, 0, 0, 0,
0, 0, 0, 0,
/* IP1_10_8 [3] */
- FN_SD1_CLK_B, FN_MMC_D6, 0, FN_A24,
+ FN_SD1_CD_A, FN_MMC_D6, 0, FN_A24,
FN_DREQ1_A, 0, FN_HRX0_B, FN_TS_SPSYNC0_A,
/* IP1_7_5 [3] */
FN_A23, FN_HTX0_B, FN_TX2_B, FN_DACK2_A,


2020-02-13 15:32:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 55/96] powerpc/ptdump: Only enable PPC_CHECK_WX with STRICT_KERNEL_RWX

From: Christophe Leroy <[email protected]>

commit f509247b08f2dcf7754d9ed85ad69a7972aa132b upstream.

ptdump_check_wx() is called from mark_rodata_ro() which only exists
when CONFIG_STRICT_KERNEL_RWX is selected.

Fixes: 453d87f6a8ae ("powerpc/mm: Warn if W+X pages found on boot")
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/922d4939c735c6b52b4137838bcc066fffd4fc33.1578989545.git.christophe.leroy@c-s.fr
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -371,7 +371,7 @@ config PPC_PTDUMP

config PPC_DEBUG_WX
bool "Warn on W+X mappings at boot"
- depends on PPC_PTDUMP
+ depends on PPC_PTDUMP && STRICT_KERNEL_RWX
help
Generate a warning if any W+X mappings are found at boot.



2020-02-13 15:32:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 82/96] media: i2c: adv748x: Fix unsafe macros

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

commit 0d962e061abcf1b9105f88fb850158b5887fbca3 upstream.

Enclose multiple macro parameters in parentheses in order to
make such macros safer and fix the Clang warning below:

drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:'
has lower precedence than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]

ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable
? ctrl->val - 1 : 0);

Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Kieran Bingham <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/i2c/adv748x/adv748x.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/media/i2c/adv748x/adv748x.h
+++ b/drivers/media/i2c/adv748x/adv748x.h
@@ -394,10 +394,10 @@ int adv748x_write_block(struct adv748x_s

#define io_read(s, r) adv748x_read(s, ADV748X_PAGE_IO, r)
#define io_write(s, r, v) adv748x_write(s, ADV748X_PAGE_IO, r, v)
-#define io_clrset(s, r, m, v) io_write(s, r, (io_read(s, r) & ~m) | v)
+#define io_clrset(s, r, m, v) io_write(s, r, (io_read(s, r) & ~(m)) | (v))

#define hdmi_read(s, r) adv748x_read(s, ADV748X_PAGE_HDMI, r)
-#define hdmi_read16(s, r, m) (((hdmi_read(s, r) << 8) | hdmi_read(s, r+1)) & m)
+#define hdmi_read16(s, r, m) (((hdmi_read(s, r) << 8) | hdmi_read(s, (r)+1)) & (m))
#define hdmi_write(s, r, v) adv748x_write(s, ADV748X_PAGE_HDMI, r, v)

#define repeater_read(s, r) adv748x_read(s, ADV748X_PAGE_REPEATER, r)
@@ -405,11 +405,11 @@ int adv748x_write_block(struct adv748x_s

#define sdp_read(s, r) adv748x_read(s, ADV748X_PAGE_SDP, r)
#define sdp_write(s, r, v) adv748x_write(s, ADV748X_PAGE_SDP, r, v)
-#define sdp_clrset(s, r, m, v) sdp_write(s, r, (sdp_read(s, r) & ~m) | v)
+#define sdp_clrset(s, r, m, v) sdp_write(s, r, (sdp_read(s, r) & ~(m)) | (v))

#define cp_read(s, r) adv748x_read(s, ADV748X_PAGE_CP, r)
#define cp_write(s, r, v) adv748x_write(s, ADV748X_PAGE_CP, r, v)
-#define cp_clrset(s, r, m, v) cp_write(s, r, (cp_read(s, r) & ~m) | v)
+#define cp_clrset(s, r, m, v) cp_write(s, r, (cp_read(s, r) & ~(m)) | (v))

#define tx_read(t, r) adv748x_read(t->state, t->page, r)
#define tx_write(t, r, v) adv748x_write(t->state, t->page, r, v)


2020-02-13 15:32:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 94/96] mwifiex: Fix possible buffer overflows in mwifiex_cmd_append_vsie_tlv()

From: Qing Xu <[email protected]>

[ Upstream commit b70261a288ea4d2f4ac7cd04be08a9f0f2de4f4d ]

mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking
the destination size may trigger a buffer overflower,
which a local user could use to cause denial of service
or the execution of arbitrary code.
Fix it by putting the length check before calling memcpy().

Signed-off-by: Qing Xu <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 593c594982cb3..59f0651d148bb 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -2886,6 +2886,13 @@ mwifiex_cmd_append_vsie_tlv(struct mwifiex_private *priv,
vs_param_set->header.len =
cpu_to_le16((((u16) priv->vs_ie[id].ie[1])
& 0x00FF) + 2);
+ if (le16_to_cpu(vs_param_set->header.len) >
+ MWIFIEX_MAX_VSIE_LEN) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "Invalid param length!\n");
+ break;
+ }
+
memcpy(vs_param_set->ie, priv->vs_ie[id].ie,
le16_to_cpu(vs_param_set->header.len));
*buffer += le16_to_cpu(vs_param_set->header.len) +
--
2.20.1



2020-02-13 15:36:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 96/96] libertas: make lbs_ibss_join_existing() return error code on rates overflow

From: Nicolai Stange <[email protected]>

[ Upstream commit 1754c4f60aaf1e17d886afefee97e94d7f27b4cb ]

Commit e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss
descriptor") introduced a bounds check on the number of supplied rates to
lbs_ibss_join_existing() and made it to return on overflow.

However, the aforementioned commit doesn't set the return value accordingly
and thus, lbs_ibss_join_existing() would return with zero even though it
failed.

Make lbs_ibss_join_existing return -EINVAL in case the bounds check on the
number of supplied rates fails.

Fixes: e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor")
Signed-off-by: Nicolai Stange <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/wireless/marvell/libertas/cfg.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index 68985d7663491..4e3de684928bf 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -1786,6 +1786,7 @@ static int lbs_ibss_join_existing(struct lbs_private *priv,
if (rates_max > MAX_RATES) {
lbs_deb_join("invalid rates");
rcu_read_unlock();
+ ret = -EINVAL;
goto out;
}
rates = cmd.bss.rates;
--
2.20.1



2020-02-13 15:36:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 58/96] powerpc/pseries: Allow not having ibm, hypertas-functions::hcall-multi-tce for DDW

From: Alexey Kardashevskiy <[email protected]>

commit 7559d3d295f3365ea7ac0c0274c05e633fe4f594 upstream.

By default a pseries guest supports a H_PUT_TCE hypercall which maps
a single IOMMU page in a DMA window. Additionally the hypervisor may
support H_PUT_TCE_INDIRECT/H_STUFF_TCE which update multiple TCEs at once;
this is advertised via the device tree /rtas/ibm,hypertas-functions
property which Linux converts to FW_FEATURE_MULTITCE.

FW_FEATURE_MULTITCE is checked when dma_iommu_ops is used; however
the code managing the huge DMA window (DDW) ignores it and calls
H_PUT_TCE_INDIRECT even if it is explicitly disabled via
the "multitce=off" kernel command line parameter.

This adds FW_FEATURE_MULTITCE checking to the DDW code path.

This changes tce_build_pSeriesLP to take liobn and page size as
the huge window does not have iommu_table descriptor which usually
the place to store these numbers.

Fixes: 4e8b0cf46b25 ("powerpc/pseries: Add support for dynamic dma windows")
Signed-off-by: Alexey Kardashevskiy <[email protected]>
Reviewed-by: Thiago Jung Bauermann <[email protected]>
Tested-by: Thiago Jung Bauermann <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/platforms/pseries/iommu.c | 43 ++++++++++++++++++++++-----------
1 file changed, 29 insertions(+), 14 deletions(-)

--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -132,10 +132,10 @@ static unsigned long tce_get_pseries(str
return be64_to_cpu(*tcep);
}

-static void tce_free_pSeriesLP(struct iommu_table*, long, long);
+static void tce_free_pSeriesLP(unsigned long liobn, long, long);
static void tce_freemulti_pSeriesLP(struct iommu_table*, long, long);

-static int tce_build_pSeriesLP(struct iommu_table *tbl, long tcenum,
+static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,
long npages, unsigned long uaddr,
enum dma_data_direction direction,
unsigned long attrs)
@@ -146,25 +146,25 @@ static int tce_build_pSeriesLP(struct io
int ret = 0;
long tcenum_start = tcenum, npages_start = npages;

- rpn = __pa(uaddr) >> TCE_SHIFT;
+ rpn = __pa(uaddr) >> tceshift;
proto_tce = TCE_PCI_READ;
if (direction != DMA_TO_DEVICE)
proto_tce |= TCE_PCI_WRITE;

while (npages--) {
- tce = proto_tce | (rpn & TCE_RPN_MASK) << TCE_RPN_SHIFT;
- rc = plpar_tce_put((u64)tbl->it_index, (u64)tcenum << 12, tce);
+ tce = proto_tce | (rpn & TCE_RPN_MASK) << tceshift;
+ rc = plpar_tce_put((u64)liobn, (u64)tcenum << tceshift, tce);

if (unlikely(rc == H_NOT_ENOUGH_RESOURCES)) {
ret = (int)rc;
- tce_free_pSeriesLP(tbl, tcenum_start,
+ tce_free_pSeriesLP(liobn, tcenum_start,
(npages_start - (npages + 1)));
break;
}

if (rc && printk_ratelimit()) {
printk("tce_build_pSeriesLP: plpar_tce_put failed. rc=%lld\n", rc);
- printk("\tindex = 0x%llx\n", (u64)tbl->it_index);
+ printk("\tindex = 0x%llx\n", (u64)liobn);
printk("\ttcenum = 0x%llx\n", (u64)tcenum);
printk("\ttce val = 0x%llx\n", tce );
dump_stack();
@@ -193,7 +193,8 @@ static int tce_buildmulti_pSeriesLP(stru
unsigned long flags;

if ((npages == 1) || !firmware_has_feature(FW_FEATURE_MULTITCE)) {
- return tce_build_pSeriesLP(tbl, tcenum, npages, uaddr,
+ return tce_build_pSeriesLP(tbl->it_index, tcenum,
+ tbl->it_page_shift, npages, uaddr,
direction, attrs);
}

@@ -209,8 +210,9 @@ static int tce_buildmulti_pSeriesLP(stru
/* If allocation fails, fall back to the loop implementation */
if (!tcep) {
local_irq_restore(flags);
- return tce_build_pSeriesLP(tbl, tcenum, npages, uaddr,
- direction, attrs);
+ return tce_build_pSeriesLP(tbl->it_index, tcenum,
+ tbl->it_page_shift,
+ npages, uaddr, direction, attrs);
}
__this_cpu_write(tce_page, tcep);
}
@@ -261,16 +263,16 @@ static int tce_buildmulti_pSeriesLP(stru
return ret;
}

-static void tce_free_pSeriesLP(struct iommu_table *tbl, long tcenum, long npages)
+static void tce_free_pSeriesLP(unsigned long liobn, long tcenum, long npages)
{
u64 rc;

while (npages--) {
- rc = plpar_tce_put((u64)tbl->it_index, (u64)tcenum << 12, 0);
+ rc = plpar_tce_put((u64)liobn, (u64)tcenum << 12, 0);

if (rc && printk_ratelimit()) {
printk("tce_free_pSeriesLP: plpar_tce_put failed. rc=%lld\n", rc);
- printk("\tindex = 0x%llx\n", (u64)tbl->it_index);
+ printk("\tindex = 0x%llx\n", (u64)liobn);
printk("\ttcenum = 0x%llx\n", (u64)tcenum);
dump_stack();
}
@@ -285,7 +287,7 @@ static void tce_freemulti_pSeriesLP(stru
u64 rc;

if (!firmware_has_feature(FW_FEATURE_MULTITCE))
- return tce_free_pSeriesLP(tbl, tcenum, npages);
+ return tce_free_pSeriesLP(tbl->it_index, tcenum, npages);

rc = plpar_tce_stuff((u64)tbl->it_index, (u64)tcenum << 12, 0, npages);

@@ -400,6 +402,19 @@ static int tce_setrange_multi_pSeriesLP(
u64 rc = 0;
long l, limit;

+ if (!firmware_has_feature(FW_FEATURE_MULTITCE)) {
+ unsigned long tceshift = be32_to_cpu(maprange->tce_shift);
+ unsigned long dmastart = (start_pfn << PAGE_SHIFT) +
+ be64_to_cpu(maprange->dma_base);
+ unsigned long tcenum = dmastart >> tceshift;
+ unsigned long npages = num_pfn << PAGE_SHIFT >> tceshift;
+ void *uaddr = __va(start_pfn << PAGE_SHIFT);
+
+ return tce_build_pSeriesLP(be32_to_cpu(maprange->liobn),
+ tcenum, tceshift, npages, (unsigned long) uaddr,
+ DMA_BIDIRECTIONAL, 0);
+ }
+
local_irq_disable(); /* to protect tcep and the page behind it */
tcep = __this_cpu_read(tce_page);



2020-02-13 15:36:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 72/96] KVM: arm64: pmu: Fix chained SW_INCR counters

From: Eric Auger <[email protected]>

commit aa76829171e98bd75a0cc00b6248eca269ac7f4f upstream.

At the moment a SW_INCR counter always overflows on 32-bit
boundary, independently on whether the n+1th counter is
programmed as CHAIN.

Check whether the SW_INCR counter is a 64b counter and if so,
implement the 64b logic.

Fixes: 80f393a23be6 ("KVM: arm/arm64: Support chained PMU counters")
Signed-off-by: Eric Auger <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/pmu.c | 43 ++++++++++++++++++++++++++++++-------------
1 file changed, 30 insertions(+), 13 deletions(-)

--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -480,28 +480,45 @@ static void kvm_pmu_perf_overflow(struct
*/
void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
{
+ struct kvm_pmu *pmu = &vcpu->arch.pmu;
int i;
- u64 type, enable, reg;
-
- if (val == 0)
- return;

if (!(__vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E))
return;

- enable = __vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ /* Weed out disabled counters */
+ val &= __vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+
for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
+ u64 type, reg;
+
if (!(val & BIT(i)))
continue;
- type = __vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
- & ARMV8_PMU_EVTYPE_EVENT;
- if ((type == ARMV8_PMUV3_PERFCTR_SW_INCR)
- && (enable & BIT(i))) {
- reg = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+
+ /* PMSWINC only applies to ... SW_INC! */
+ type = __vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i);
+ type &= ARMV8_PMU_EVTYPE_EVENT;
+ if (type != ARMV8_PMUV3_PERFCTR_SW_INCR)
+ continue;
+
+ /* increment this even SW_INC counter */
+ reg = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+ reg = lower_32_bits(reg);
+ __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+
+ if (reg) /* no overflow on the low part */
+ continue;
+
+ if (kvm_pmu_pmc_is_chained(&pmu->pmc[i])) {
+ /* increment the high counter */
+ reg = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i + 1) + 1;
reg = lower_32_bits(reg);
- __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
- if (!reg)
- __vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= BIT(i);
+ __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i + 1) = reg;
+ if (!reg) /* mark overflow on the high counter */
+ __vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= BIT(i + 1);
+ } else {
+ /* mark overflow on low counter */
+ __vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= BIT(i);
}
}
}


2020-02-13 15:36:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 48/96] ARM: dts: meson8b: use the actual frequency for the GPUs 364MHz OPP

From: Martin Blumenstingl <[email protected]>

commit c3dd3315ab58b2cfa1916df55b0d0f9fbd94266f upstream.

The clock setup on Meson8 cannot achieve a Mali frequency of exactly
182.15MHz. The vendor driver uses "FCLK_DIV7 / 1" for this frequency,
which translates to 2550MHz / 7 / 1 = 364285714Hz.
Update the GPU operating point to that specific frequency to not confuse
myself when comparing the frequency from the .dts with the actual clock
rate on the system.

Fixes: c3ea80b6138cae ("ARM: dts: meson8b: add the Mali-450 MP2 GPU")
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/meson8b.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -125,8 +125,8 @@
opp-hz = /bits/ 64 <255000000>;
opp-microvolt = <1100000>;
};
- opp-364300000 {
- opp-hz = /bits/ 64 <364300000>;
+ opp-364285714 {
+ opp-hz = /bits/ 64 <364285714>;
opp-microvolt = <1100000>;
};
opp-425000000 {


2020-02-13 15:36:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 17/96] PCI: tegra: Fix afi_pex2_ctrl reg offset for Tegra30

From: Marcel Ziswiler <[email protected]>

commit 21a92676e1fe292acb077b13106b08c22ed36b14 upstream.

Fix AFI_PEX2_CTRL reg offset for Tegra30 by moving it from the Tegra20
SoC struct where it erroneously got added. This fixes the AFI_PEX2_CTRL
reg offset being uninitialised subsequently failing to bring up the
third PCIe port.

Fixes: adb2653b3d2e ("PCI: tegra: Add AFI_PEX2_CTRL reg offset as part of SoC struct")
Signed-off-by: Marcel Ziswiler <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Andrew Murray <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/controller/pci-tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -2499,7 +2499,6 @@ static const struct tegra_pcie_soc tegra
.num_ports = 2,
.ports = tegra20_pcie_ports,
.msi_base_shift = 0,
- .afi_pex2_ctrl = 0x128,
.pads_pll_ctl = PADS_PLL_CTL_TEGRA20,
.tx_ref_sel = PADS_PLL_CTL_TXCLKREF_DIV10,
.pads_refclk_cfg0 = 0xfa5cfa5c,
@@ -2528,6 +2527,7 @@ static const struct tegra_pcie_soc tegra
.num_ports = 3,
.ports = tegra30_pcie_ports,
.msi_base_shift = 8,
+ .afi_pex2_ctrl = 0x128,
.pads_pll_ctl = PADS_PLL_CTL_TEGRA30,
.tx_ref_sel = PADS_PLL_CTL_TXCLKREF_BUF_EN,
.pads_refclk_cfg0 = 0xfa5cfa5c,


2020-02-13 15:36:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 35/96] rtc: hym8563: Return -EINVAL if the time is known to be invalid

From: Paul Kocialkowski <[email protected]>

commit f236a2a2ebabad0848ad0995af7ad1dc7029e895 upstream.

The current code returns -EPERM when the voltage loss bit is set.
Since the bit indicates that the time value is not valid, return
-EINVAL instead, which is the appropriate error code for this
situation.

Fixes: dcaf03849352 ("rtc: add hym8563 rtc-driver")
Signed-off-by: Paul Kocialkowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/rtc/rtc-hym8563.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/rtc/rtc-hym8563.c
+++ b/drivers/rtc/rtc-hym8563.c
@@ -97,7 +97,7 @@ static int hym8563_rtc_read_time(struct

if (!hym8563->valid) {
dev_warn(&client->dev, "no valid clock/calendar values available\n");
- return -EPERM;
+ return -EINVAL;
}

ret = i2c_smbus_read_i2c_block_data(client, HYM8563_SEC, 7, buf);


2020-02-13 15:36:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 32/96] NFSv4: try lease recovery on NFS4ERR_EXPIRED

From: Robert Milkowski <[email protected]>

commit 924491f2e476f7234d722b24171a4daff61bbe13 upstream.

Currently, if an nfs server returns NFS4ERR_EXPIRED to open(),
we return EIO to applications without even trying to recover.

Fixes: 272289a3df72 ("NFSv4: nfs4_do_handle_exception() handle revoke/expiry of a single stateid")
Signed-off-by: Robert Milkowski <[email protected]>
Reviewed-by: Trond Myklebust <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/nfs4proc.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3187,6 +3187,11 @@ static struct nfs4_state *nfs4_do_open(s
exception.retry = 1;
continue;
}
+ if (status == -NFS4ERR_EXPIRED) {
+ nfs4_schedule_lease_recovery(server->nfs_client);
+ exception.retry = 1;
+ continue;
+ }
if (status == -EAGAIN) {
/* We must have found a delegation */
exception.retry = 1;


2020-02-13 15:37:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 18/96] PCI: Dont disable bridge BARs when assigning bus resources

From: Logan Gunthorpe <[email protected]>

commit 9db8dc6d0785225c42a37be7b44d1b07b31b8957 upstream.

Some PCI bridges implement BARs in addition to bridge windows. For
example, here's a PLX switch:

04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI
Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0
Memory at 90a00000 (32-bit, non-prefetchable) [size=256K]
Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0
I/O behind bridge: 00002000-00003fff
Memory behind bridge: 90000000-909fffff
Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff

Previously, when the kernel assigned resource addresses (with the
pci=realloc command line parameter, for example) it could clear the struct
resource corresponding to the BAR. When this happened, lspci would report
this BAR as "ignored":

Region 0: Memory at <ignored> (32-bit, non-prefetchable) [size=256K]

This is because the kernel reports a zero start address and zero flags
in the corresponding sysfs resource file and in /proc/bus/pci/devices.
Investigation with 'lspci -x', however, shows the BIOS-assigned address
will still be programmed in the device's BAR registers.

It's clearly a bug that the kernel lost track of the BAR value, but in most
cases, this still won't result in a visible issue because nothing uses the
memory, so nothing is affected. However, when an IOMMU is in use, it will
not reserve this space in the IOVA because the kernel no longer thinks the
range is valid. (See dmar_init_reserved_ranges() for the Intel
implementation of this.)

Without the proper reserved range, a DMA mapping may allocate an IOVA that
matches a bridge BAR, which results in DMA accesses going to the BAR
instead of the intended RAM.

The problem was in pci_assign_unassigned_root_bus_resources(). When any
resource from a bridge device fails to get assigned, the code set the
resource's flags to zero. This makes sense for bridge windows, as they
will be re-enabled later, but for regular BARs, it makes the kernel
permanently lose track of the fact that they decode address space.

Change pci_assign_unassigned_root_bus_resources() and
pci_assign_unassigned_bridge_resources() so they only clear "res->flags"
for bridge *windows*, not bridge BARs.

Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)")
Link: https://lore.kernel.org/r/[email protected]
[bhelgaas: commit log, check for pci_is_bridge()]
Reported-by: Kit Chow <[email protected]>
Signed-off-by: Logan Gunthorpe <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/setup-bus.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1785,12 +1785,18 @@ again:
/* Restore size and flags */
list_for_each_entry(fail_res, &fail_head, list) {
struct resource *res = fail_res->res;
+ int idx;

res->start = fail_res->start;
res->end = fail_res->end;
res->flags = fail_res->flags;
- if (fail_res->dev->subordinate)
- res->flags = 0;
+
+ if (pci_is_bridge(fail_res->dev)) {
+ idx = res - &fail_res->dev->resource[0];
+ if (idx >= PCI_BRIDGE_RESOURCES &&
+ idx <= PCI_BRIDGE_RESOURCE_END)
+ res->flags = 0;
+ }
}
free_list(&fail_head);

@@ -2037,12 +2043,18 @@ again:
/* Restore size and flags */
list_for_each_entry(fail_res, &fail_head, list) {
struct resource *res = fail_res->res;
+ int idx;

res->start = fail_res->start;
res->end = fail_res->end;
res->flags = fail_res->flags;
- if (fail_res->dev->subordinate)
- res->flags = 0;
+
+ if (pci_is_bridge(fail_res->dev)) {
+ idx = res - &fail_res->dev->resource[0];
+ if (idx >= PCI_BRIDGE_RESOURCES &&
+ idx <= PCI_BRIDGE_RESOURCE_END)
+ res->flags = 0;
+ }
}
free_list(&fail_head);



2020-02-13 15:37:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 78/96] crypto: artpec6 - return correct error code for failed setkey()

From: Eric Biggers <[email protected]>

commit b828f905904cd76424230c69741a4cabb0174168 upstream.

->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1.

Fixes: a21eb94fc4d3 ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver")
Cc: Jesper Nilsson <[email protected]>
Cc: Lars Persson <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Acked-by: Lars Persson <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/axis/artpec6_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/crypto/axis/artpec6_crypto.c
+++ b/drivers/crypto/axis/artpec6_crypto.c
@@ -1251,7 +1251,7 @@ static int artpec6_crypto_aead_set_key(s

if (len != 16 && len != 24 && len != 32) {
crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
- return -1;
+ return -EINVAL;
}

ctx->key_length = len;


2020-02-13 15:37:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 64/96] sched/uclamp: Fix a bug in propagating uclamp value in new cgroups

From: Qais Yousef <[email protected]>

commit 7226017ad37a888915628e59a84a2d1e57b40707 upstream.

When a new cgroup is created, the effective uclamp value wasn't updated
with a call to cpu_util_update_eff() that looks at the hierarchy and
update to the most restrictive values.

Fix it by ensuring to call cpu_util_update_eff() when a new cgroup
becomes online.

Without this change, the newly created cgroup uses the default
root_task_group uclamp values, which is 1024 for both uclamp_{min, max},
which will cause the rq to to be clamped to max, hence cause the
system to run at max frequency.

The problem was observed on Ubuntu server and was reproduced on Debian
and Buildroot rootfs.

By default, Ubuntu and Debian create a cpu controller cgroup hierarchy
and add all tasks to it - which creates enough noise to keep the rq
uclamp value at max most of the time. Imitating this behavior makes the
problem visible in Buildroot too which otherwise looks fine since it's a
minimal userspace.

Fixes: 0b60ba2dd342 ("sched/uclamp: Propagate parent clamps")
Reported-by: Doug Smythies <[email protected]>
Signed-off-by: Qais Yousef <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Tested-by: Doug Smythies <[email protected]>
Link: https://lore.kernel.org/lkml/000701d5b965$361b6c60$a2524520$@net/
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/sched/core.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7090,6 +7090,12 @@ static int cpu_cgroup_css_online(struct

if (parent)
sched_online_group(tg, parent);
+
+#ifdef CONFIG_UCLAMP_TASK_GROUP
+ /* Propagate the effective uclamp value for the new group */
+ cpu_util_update_eff(css);
+#endif
+
return 0;
}



2020-02-13 15:37:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 73/96] KVM: arm64: Treat emulated TVAL TimerValue as a signed 32-bit integer

From: Alexandru Elisei <[email protected]>

commit 4a267aa707953a9a73d1f5dc7f894dd9024a92be upstream.

According to the ARM ARM, registers CNT{P,V}_TVAL_EL0 have bits [63:32]
RES0 [1]. When reading the register, the value is truncated to the least
significant 32 bits [2], and on writes, TimerValue is treated as a signed
32-bit integer [1, 2].

When the guest behaves correctly and writes 32-bit values, treating TVAL
as an unsigned 64 bit register works as expected. However, things start
to break down when the guest writes larger values, because
(u64)0x1_ffff_ffff = 8589934591. but (s32)0x1_ffff_ffff = -1, and the
former will cause the timer interrupt to be asserted in the future, but
the latter will cause it to be asserted now. Let's treat TVAL as a
signed 32-bit register on writes, to match the behaviour described in
the architecture, and the behaviour experimentally exhibited by the
virtual timer on a non-vhe host.

[1] Arm DDI 0487E.a, section D13.8.18
[2] Arm DDI 0487E.a, section D11.2.4

Signed-off-by: Alexandru Elisei <[email protected]>
[maz: replaced the read-side mask with lower_32_bits]
Signed-off-by: Marc Zyngier <[email protected]>
Fixes: 8fa761624871 ("KVM: arm/arm64: arch_timer: Fix CNTP_TVAL calculation")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/arch_timer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -805,6 +805,7 @@ static u64 kvm_arm_timer_read(struct kvm
switch (treg) {
case TIMER_REG_TVAL:
val = timer->cnt_cval - kvm_phys_timer_read() + timer->cntvoff;
+ val &= lower_32_bits(val);
break;

case TIMER_REG_CTL:
@@ -850,7 +851,7 @@ static void kvm_arm_timer_write(struct k
{
switch (treg) {
case TIMER_REG_TVAL:
- timer->cnt_cval = kvm_phys_timer_read() - timer->cntvoff + val;
+ timer->cnt_cval = kvm_phys_timer_read() - timer->cntvoff + (s32)val;
break;

case TIMER_REG_CTL:


2020-02-13 15:37:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 02/96] hv_sock: Remove the accept port restriction

From: Sunil Muthuswamy <[email protected]>

[ Upstream commit c742c59e1fbd022b64d91aa9a0092b3a699d653c ]

Currently, hv_sock restricts the port the guest socket can accept
connections on. hv_sock divides the socket port namespace into two parts
for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF
(there are no restrictions on client port namespace). The first part
(0-0x7FFFFFFF) is reserved for sockets where connections can be accepted.
The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports
for the peer (host) socket, once a connection is accepted.
This reservation of the port namespace is specific to hv_sock and not
known by the generic vsock library (ex: af_vsock). This is problematic
because auto-binds/ephemeral ports are handled by the generic vsock
library and it has no knowledge of this port reservation and could
allocate a port that is not compatible with hv_sock (and legitimately so).
The issue hasn't surfaced so far because the auto-bind code of vsock
(__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for
VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and
start assigning ports. That will take a large number of iterations to hit
0x7FFFFFFF. But, after the above change to randomize port selection, the
issue has started coming up more frequently.
There has really been no good reason to have this port reservation logic
in hv_sock from the get go. Reserving a local port for peer ports is not
how things are handled generally. Peer ports should reflect the peer port.
This fixes the issue by lifting the port reservation, and also returns the
right peer port. Since the code converts the GUID to the peer port (by
using the first 4 bytes), there is a possibility of conflicts, but that
seems like a reasonable risk to take, given this is limited to vsock and
that only applies to all local sockets.

Signed-off-by: Sunil Muthuswamy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/vmw_vsock/hyperv_transport.c | 68 +++++---------------------------
1 file changed, 9 insertions(+), 59 deletions(-)

diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index c443db7af8d4a..463cefc1e5ae2 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -136,28 +136,15 @@ struct hvsock {
****************************************************************************
* The only valid Service GUIDs, from the perspectives of both the host and *
* Linux VM, that can be connected by the other end, must conform to this *
- * format: <port>-facb-11e6-bd58-64006a7986d3, and the "port" must be in *
- * this range [0, 0x7FFFFFFF]. *
+ * format: <port>-facb-11e6-bd58-64006a7986d3. *
****************************************************************************
*
* When we write apps on the host to connect(), the GUID ServiceID is used.
* When we write apps in Linux VM to connect(), we only need to specify the
* port and the driver will form the GUID and use that to request the host.
*
- * From the perspective of Linux VM:
- * 1. the local ephemeral port (i.e. the local auto-bound port when we call
- * connect() without explicit bind()) is generated by __vsock_bind_stream(),
- * and the range is [1024, 0xFFFFFFFF).
- * 2. the remote ephemeral port (i.e. the auto-generated remote port for
- * a connect request initiated by the host's connect()) is generated by
- * hvs_remote_addr_init() and the range is [0x80000000, 0xFFFFFFFF).
*/

-#define MAX_LISTEN_PORT ((u32)0x7FFFFFFF)
-#define MAX_VM_LISTEN_PORT MAX_LISTEN_PORT
-#define MAX_HOST_LISTEN_PORT MAX_LISTEN_PORT
-#define MIN_HOST_EPHEMERAL_PORT (MAX_HOST_LISTEN_PORT + 1)
-
/* 00000000-facb-11e6-bd58-64006a7986d3 */
static const guid_t srv_id_template =
GUID_INIT(0x00000000, 0xfacb, 0x11e6, 0xbd, 0x58,
@@ -180,33 +167,6 @@ static void hvs_addr_init(struct sockaddr_vm *addr, const guid_t *svr_id)
vsock_addr_init(addr, VMADDR_CID_ANY, port);
}

-static void hvs_remote_addr_init(struct sockaddr_vm *remote,
- struct sockaddr_vm *local)
-{
- static u32 host_ephemeral_port = MIN_HOST_EPHEMERAL_PORT;
- struct sock *sk;
-
- vsock_addr_init(remote, VMADDR_CID_ANY, VMADDR_PORT_ANY);
-
- while (1) {
- /* Wrap around ? */
- if (host_ephemeral_port < MIN_HOST_EPHEMERAL_PORT ||
- host_ephemeral_port == VMADDR_PORT_ANY)
- host_ephemeral_port = MIN_HOST_EPHEMERAL_PORT;
-
- remote->svm_port = host_ephemeral_port++;
-
- sk = vsock_find_connected_socket(remote, local);
- if (!sk) {
- /* Found an available ephemeral port */
- return;
- }
-
- /* Release refcnt got in vsock_find_connected_socket */
- sock_put(sk);
- }
-}
-
static void hvs_set_channel_pending_send_size(struct vmbus_channel *chan)
{
set_channel_pending_send_size(chan,
@@ -336,12 +296,7 @@ static void hvs_open_connection(struct vmbus_channel *chan)
if_type = &chan->offermsg.offer.if_type;
if_instance = &chan->offermsg.offer.if_instance;
conn_from_host = chan->offermsg.offer.u.pipe.user_def[0];
-
- /* The host or the VM should only listen on a port in
- * [0, MAX_LISTEN_PORT]
- */
- if (!is_valid_srv_id(if_type) ||
- get_port_by_srv_id(if_type) > MAX_LISTEN_PORT)
+ if (!is_valid_srv_id(if_type))
return;

hvs_addr_init(&addr, conn_from_host ? if_type : if_instance);
@@ -365,6 +320,13 @@ static void hvs_open_connection(struct vmbus_channel *chan)

new->sk_state = TCP_SYN_SENT;
vnew = vsock_sk(new);
+
+ hvs_addr_init(&vnew->local_addr, if_type);
+
+ /* Remote peer is always the host */
+ vsock_addr_init(&vnew->remote_addr,
+ VMADDR_CID_HOST, VMADDR_PORT_ANY);
+ vnew->remote_addr.svm_port = get_port_by_srv_id(if_instance);
hvs_new = vnew->trans;
hvs_new->chan = chan;
} else {
@@ -429,8 +391,6 @@ static void hvs_open_connection(struct vmbus_channel *chan)
sk->sk_ack_backlog++;

hvs_addr_init(&vnew->local_addr, if_type);
- hvs_remote_addr_init(&vnew->remote_addr, &vnew->local_addr);
-
hvs_new->vm_srv_id = *if_type;
hvs_new->host_srv_id = *if_instance;

@@ -753,16 +713,6 @@ static bool hvs_stream_is_active(struct vsock_sock *vsk)

static bool hvs_stream_allow(u32 cid, u32 port)
{
- /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
- * reserved as ephemeral ports, which are used as the host's ports
- * when the host initiates connections.
- *
- * Perform this check in the guest so an immediate error is produced
- * instead of a timeout.
- */
- if (port > MAX_HOST_LISTEN_PORT)
- return false;
-
if (cid == VMADDR_CID_HOST)
return true;

--
2.20.1



2020-02-13 15:37:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 15/96] PCI/switchtec: Use dma_set_mask_and_coherent()

From: Wesley Sheng <[email protected]>

commit aa82130a22f77c1aa5794703730304d035a0c1f4 upstream.

Use dma_set_mask_and_coherent() instead of dma_set_coherent_mask() as the
Switchtec hardware fully supports 64bit addressing and we should set both
the streaming and coherent masks the same.

[[email protected]: reworked commit message]
Fixes: aff614c6339c ("switchtec: Set DMA coherent mask")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Wesley Sheng <[email protected]>
Signed-off-by: Logan Gunthorpe <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/switch/switchtec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1349,7 +1349,7 @@ static int switchtec_init_pci(struct swi
if (rc)
return rc;

- rc = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
+ rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (rc)
return rc;



2020-02-13 15:37:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 53/96] Revert "powerpc/pseries/iommu: Dont use dma_iommu_ops on secure guests"

From: Ram Pai <[email protected]>

commit d862b44133b7a1d7de25288e09eabf4df415e971 upstream.

This reverts commit edea902c1c1efb855f77e041f9daf1abe7a9768a.

At the time the change allowed direct DMA ops for secure VMs; however
since then we switched on using SWIOTLB backed with IOMMU (direct mapping)
and to make this work, we need dma_iommu_ops which handles all cases
including TCE mapping I/O pages in the presence of an IOMMU.

Fixes: edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests")
Signed-off-by: Ram Pai <[email protected]>
[aik: added "revert" and "fixes:"]
Signed-off-by: Alexey Kardashevskiy <[email protected]>
Reviewed-by: Thiago Jung Bauermann <[email protected]>
Tested-by: Thiago Jung Bauermann <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/platforms/pseries/iommu.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)

--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -36,7 +36,6 @@
#include <asm/udbg.h>
#include <asm/mmzone.h>
#include <asm/plpar_wrappers.h>
-#include <asm/svm.h>

#include "pseries.h"

@@ -1320,15 +1319,7 @@ void iommu_init_early_pSeries(void)
of_reconfig_notifier_register(&iommu_reconfig_nb);
register_memory_notifier(&iommu_mem_nb);

- /*
- * Secure guest memory is inacessible to devices so regular DMA isn't
- * possible.
- *
- * In that case keep devices' dma_map_ops as NULL so that the generic
- * DMA code path will use SWIOTLB to bounce buffers for DMA.
- */
- if (!is_secure_guest())
- set_pci_dma_ops(&dma_iommu_ops);
+ set_pci_dma_ops(&dma_iommu_ops);
}

static int __init disable_multitce(char *str)


2020-02-13 15:37:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 24/96] selftests/bpf: Test freeing sockmap/sockhash with a socket in it

From: Jakub Sitnicki <[email protected]>

commit 5d3919a953c3c96c02fc7a337f8376cde43ae31f upstream.

Commit 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear
down") introduced sleeping issues inside RCU critical sections and while
holding a spinlock on sockmap/sockhash tear-down. There has to be at least
one socket in the map for the problem to surface.

This adds a test that triggers the warnings for broken locking rules. Not a
fix per se, but rather tooling to verify the accompanying fixes. Run on a
VM with 1 vCPU to reproduce the warnings.

Fixes: 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down")
Signed-off-by: Jakub Sitnicki <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: John Fastabend <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 74 +++++++++++++++++
1 file changed, 74 insertions(+)

--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 Cloudflare
+
+#include "test_progs.h"
+
+static int connected_socket_v4(void)
+{
+ struct sockaddr_in addr = {
+ .sin_family = AF_INET,
+ .sin_port = htons(80),
+ .sin_addr = { inet_addr("127.0.0.1") },
+ };
+ socklen_t len = sizeof(addr);
+ int s, repair, err;
+
+ s = socket(AF_INET, SOCK_STREAM, 0);
+ if (CHECK_FAIL(s == -1))
+ goto error;
+
+ repair = TCP_REPAIR_ON;
+ err = setsockopt(s, SOL_TCP, TCP_REPAIR, &repair, sizeof(repair));
+ if (CHECK_FAIL(err))
+ goto error;
+
+ err = connect(s, (struct sockaddr *)&addr, len);
+ if (CHECK_FAIL(err))
+ goto error;
+
+ repair = TCP_REPAIR_OFF_NO_WP;
+ err = setsockopt(s, SOL_TCP, TCP_REPAIR, &repair, sizeof(repair));
+ if (CHECK_FAIL(err))
+ goto error;
+
+ return s;
+error:
+ perror(__func__);
+ close(s);
+ return -1;
+}
+
+/* Create a map, populate it with one socket, and free the map. */
+static void test_sockmap_create_update_free(enum bpf_map_type map_type)
+{
+ const int zero = 0;
+ int s, map, err;
+
+ s = connected_socket_v4();
+ if (CHECK_FAIL(s == -1))
+ return;
+
+ map = bpf_create_map(map_type, sizeof(int), sizeof(int), 1, 0);
+ if (CHECK_FAIL(map == -1)) {
+ perror("bpf_create_map");
+ goto out;
+ }
+
+ err = bpf_map_update_elem(map, &zero, &s, BPF_NOEXIST);
+ if (CHECK_FAIL(err)) {
+ perror("bpf_map_update");
+ goto out;
+ }
+
+out:
+ close(map);
+ close(s);
+}
+
+void test_sockmap_basic(void)
+{
+ if (test__start_subtest("sockmap create_update_free"))
+ test_sockmap_create_update_free(BPF_MAP_TYPE_SOCKMAP);
+ if (test__start_subtest("sockhash create_update_free"))
+ test_sockmap_create_update_free(BPF_MAP_TYPE_SOCKHASH);
+}


2020-02-13 15:37:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 70/96] KVM: arm: Make inject_abt32() inject an external abort instead

From: James Morse <[email protected]>

commit 21aecdbd7f3ab02c9b82597dc733ee759fb8b274 upstream.

KVM's inject_abt64() injects an external-abort into an aarch64 guest.
The KVM_CAP_ARM_INJECT_EXT_DABT is intended to do exactly this, but
for an aarch32 guest inject_abt32() injects an implementation-defined
exception, 'Lockdown fault'.

Change this to external abort. For non-LPAE we now get the documented:
| Unhandled fault: external abort on non-linefetch (0x008) at 0x9c800f00
and for LPAE:
| Unhandled fault: synchronous external abort (0x210) at 0x9c800f00

Fixes: 74a64a981662a ("KVM: arm/arm64: Unify 32bit fault injection")
Reported-by: Beata Michalska <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/aarch32.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

--- a/virt/kvm/arm/aarch32.c
+++ b/virt/kvm/arm/aarch32.c
@@ -15,6 +15,10 @@
#include <asm/kvm_emulate.h>
#include <asm/kvm_hyp.h>

+#define DFSR_FSC_EXTABT_LPAE 0x10
+#define DFSR_FSC_EXTABT_nLPAE 0x08
+#define DFSR_LPAE BIT(9)
+
/*
* Table taken from ARMv8 ARM DDI0487B-B, table G1-10.
*/
@@ -182,10 +186,10 @@ static void inject_abt32(struct kvm_vcpu
/* Give the guest an IMPLEMENTATION DEFINED exception */
is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
if (is_lpae) {
- *fsr = 1 << 9 | 0x34;
+ *fsr = DFSR_LPAE | DFSR_FSC_EXTABT_LPAE;
} else {
- /* Surprise! DFSR's FS[4] lives in bit 10 */
- *fsr = BIT(10) | 0x4; /* 0x14 */
+ /* no need to shuffle FS[4] into DFSR[10] as its 0 */
+ *fsr = DFSR_FSC_EXTABT_nLPAE;
}
}



2020-02-13 15:38:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 08/96] RDMA/core: Fix locking in ib_uverbs_event_read

From: Jason Gunthorpe <[email protected]>

commit 14e23bd6d22123f6f3b2747701fa6cd4c6d05873 upstream.

This should not be using ib_dev to test for disassociation, during
disassociation is_closed is set under lock and the waitq is triggered.

Instead check is_closed and be sure to re-obtain the lock to test the
value after the wait_event returns.

Fixes: 036b10635739 ("IB/uverbs: Enable device removal when there are active user space applications")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Yishai Hadas <[email protected]>
Reviewed-by: Håkon Bugge <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/uverbs_main.c | 32 ++++++++++++++------------------
1 file changed, 14 insertions(+), 18 deletions(-)

--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -220,7 +220,6 @@ void ib_uverbs_release_file(struct kref
}

static ssize_t ib_uverbs_event_read(struct ib_uverbs_event_queue *ev_queue,
- struct ib_uverbs_file *uverbs_file,
struct file *filp, char __user *buf,
size_t count, loff_t *pos,
size_t eventsz)
@@ -238,19 +237,16 @@ static ssize_t ib_uverbs_event_read(stru

if (wait_event_interruptible(ev_queue->poll_wait,
(!list_empty(&ev_queue->event_list) ||
- /* The barriers built into wait_event_interruptible()
- * and wake_up() guarentee this will see the null set
- * without using RCU
- */
- !uverbs_file->device->ib_dev)))
+ ev_queue->is_closed)))
return -ERESTARTSYS;

+ spin_lock_irq(&ev_queue->lock);
+
/* If device was disassociated and no event exists set an error */
- if (list_empty(&ev_queue->event_list) &&
- !uverbs_file->device->ib_dev)
+ if (list_empty(&ev_queue->event_list) && ev_queue->is_closed) {
+ spin_unlock_irq(&ev_queue->lock);
return -EIO;
-
- spin_lock_irq(&ev_queue->lock);
+ }
}

event = list_entry(ev_queue->event_list.next, struct ib_uverbs_event, list);
@@ -285,8 +281,7 @@ static ssize_t ib_uverbs_async_event_rea
{
struct ib_uverbs_async_event_file *file = filp->private_data;

- return ib_uverbs_event_read(&file->ev_queue, file->uverbs_file, filp,
- buf, count, pos,
+ return ib_uverbs_event_read(&file->ev_queue, filp, buf, count, pos,
sizeof(struct ib_uverbs_async_event_desc));
}

@@ -296,9 +291,8 @@ static ssize_t ib_uverbs_comp_event_read
struct ib_uverbs_completion_event_file *comp_ev_file =
filp->private_data;

- return ib_uverbs_event_read(&comp_ev_file->ev_queue,
- comp_ev_file->uobj.ufile, filp,
- buf, count, pos,
+ return ib_uverbs_event_read(&comp_ev_file->ev_queue, filp, buf, count,
+ pos,
sizeof(struct ib_uverbs_comp_event_desc));
}

@@ -321,7 +315,9 @@ static __poll_t ib_uverbs_event_poll(str
static __poll_t ib_uverbs_async_event_poll(struct file *filp,
struct poll_table_struct *wait)
{
- return ib_uverbs_event_poll(filp->private_data, filp, wait);
+ struct ib_uverbs_async_event_file *file = filp->private_data;
+
+ return ib_uverbs_event_poll(&file->ev_queue, filp, wait);
}

static __poll_t ib_uverbs_comp_event_poll(struct file *filp,
@@ -335,9 +331,9 @@ static __poll_t ib_uverbs_comp_event_pol

static int ib_uverbs_async_event_fasync(int fd, struct file *filp, int on)
{
- struct ib_uverbs_event_queue *ev_queue = filp->private_data;
+ struct ib_uverbs_async_event_file *file = filp->private_data;

- return fasync_helper(fd, filp, on, &ev_queue->async_queue);
+ return fasync_helper(fd, filp, on, &file->ev_queue.async_queue);
}

static int ib_uverbs_comp_event_fasync(int fd, struct file *filp, int on)


2020-02-13 15:43:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 95/96] libertas: dont exit from lbs_ibss_join_existing() with RCU read lock held

From: Nicolai Stange <[email protected]>

[ Upstream commit c7bf1fb7ddca331780b9a733ae308737b39f1ad4 ]

Commit e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss
descriptor") introduced a bounds check on the number of supplied rates to
lbs_ibss_join_existing().

Unfortunately, it introduced a return path from within a RCU read side
critical section without a corresponding rcu_read_unlock(). Fix this.

Fixes: e5e884b42639 ("libertas: Fix two buffer overflows at parsing bss descriptor")
Signed-off-by: Nicolai Stange <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/wireless/marvell/libertas/cfg.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index c9401c121a14e..68985d7663491 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -1785,6 +1785,7 @@ static int lbs_ibss_join_existing(struct lbs_private *priv,
rates_max = rates_eid[1];
if (rates_max > MAX_RATES) {
lbs_deb_join("invalid rates");
+ rcu_read_unlock();
goto out;
}
rates = cmd.bss.rates;
--
2.20.1



2020-02-13 15:43:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 74/96] arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly

From: Suzuki K Poulose <[email protected]>

commit 52f73c383b2418f2d31b798e765ae7d596c35021 upstream.

We detect the absence of FP/SIMD after an incapable CPU is brought up,
and by then we have kernel threads running already with TIF_FOREIGN_FPSTATE set
which could be set for early userspace applications (e.g, modprobe triggered
from initramfs) and init. This could cause the applications to loop forever in
do_nofity_resume() as we never clear the TIF flag, once we now know that
we don't support FP.

Fix this by making sure that we clear the TIF_FOREIGN_FPSTATE flag
for tasks which may have them set, as we would have done in the normal
case, but avoiding touching the hardware state (since we don't support any).

Also to make sure we handle the cases seemlessly we categorise the
helper functions to two :
1) Helpers for common core code, which calls into take appropriate
actions without knowing the current FPSIMD state of the CPU/task.

e.g fpsimd_restore_current_state(), fpsimd_flush_task_state(),
fpsimd_save_and_flush_cpu_state().

We bail out early for these functions, taking any appropriate actions
(e.g, clearing the TIF flag) where necessary to hide the handling
from core code.

2) Helpers used when the presence of FP/SIMD is apparent.
i.e, save/restore the FP/SIMD register state, modify the CPU/task
FP/SIMD state.
e.g,

fpsimd_save(), task_fpsimd_load() - save/restore task FP/SIMD registers

fpsimd_bind_task_to_cpu() \
- Update the "state" metadata for CPU/task.
fpsimd_bind_state_to_cpu() /

fpsimd_update_current_state() - Update the fp/simd state for the current
task from memory.

These must not be called in the absence of FP/SIMD. Put in a WARNING
to make sure they are not invoked in the absence of FP/SIMD.

KVM also uses the TIF_FOREIGN_FPSTATE flag to manage the FP/SIMD state
on the CPU. However, without FP/SIMD support we trap all accesses and
inject undefined instruction. Thus we should never "load" guest state.
Add a sanity check to make sure this is valid.

Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Catalin Marinas <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Signed-off-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/kernel/fpsimd.c | 30 +++++++++++++++++++++++++++---
arch/arm64/kvm/hyp/switch.c | 10 +++++++++-
2 files changed, 36 insertions(+), 4 deletions(-)

--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -269,6 +269,7 @@ static void sve_free(struct task_struct
*/
static void task_fpsimd_load(void)
{
+ WARN_ON(!system_supports_fpsimd());
WARN_ON(!have_cpu_fpsimd_context());

if (system_supports_sve() && test_thread_flag(TIF_SVE))
@@ -289,6 +290,7 @@ static void fpsimd_save(void)
this_cpu_ptr(&fpsimd_last_state);
/* set by fpsimd_bind_task_to_cpu() or fpsimd_bind_state_to_cpu() */

+ WARN_ON(!system_supports_fpsimd());
WARN_ON(!have_cpu_fpsimd_context());

if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
@@ -1092,6 +1094,7 @@ void fpsimd_bind_task_to_cpu(void)
struct fpsimd_last_state_struct *last =
this_cpu_ptr(&fpsimd_last_state);

+ WARN_ON(!system_supports_fpsimd());
last->st = &current->thread.uw.fpsimd_state;
last->sve_state = current->thread.sve_state;
last->sve_vl = current->thread.sve_vl;
@@ -1114,6 +1117,7 @@ void fpsimd_bind_state_to_cpu(struct use
struct fpsimd_last_state_struct *last =
this_cpu_ptr(&fpsimd_last_state);

+ WARN_ON(!system_supports_fpsimd());
WARN_ON(!in_softirq() && !irqs_disabled());

last->st = st;
@@ -1128,8 +1132,19 @@ void fpsimd_bind_state_to_cpu(struct use
*/
void fpsimd_restore_current_state(void)
{
- if (!system_supports_fpsimd())
+ /*
+ * For the tasks that were created before we detected the absence of
+ * FP/SIMD, the TIF_FOREIGN_FPSTATE could be set via fpsimd_thread_switch(),
+ * e.g, init. This could be then inherited by the children processes.
+ * If we later detect that the system doesn't support FP/SIMD,
+ * we must clear the flag for all the tasks to indicate that the
+ * FPSTATE is clean (as we can't have one) to avoid looping for ever in
+ * do_notify_resume().
+ */
+ if (!system_supports_fpsimd()) {
+ clear_thread_flag(TIF_FOREIGN_FPSTATE);
return;
+ }

get_cpu_fpsimd_context();

@@ -1148,7 +1163,7 @@ void fpsimd_restore_current_state(void)
*/
void fpsimd_update_current_state(struct user_fpsimd_state const *state)
{
- if (!system_supports_fpsimd())
+ if (WARN_ON(!system_supports_fpsimd()))
return;

get_cpu_fpsimd_context();
@@ -1179,7 +1194,13 @@ void fpsimd_update_current_state(struct
void fpsimd_flush_task_state(struct task_struct *t)
{
t->thread.fpsimd_cpu = NR_CPUS;
-
+ /*
+ * If we don't support fpsimd, bail out after we have
+ * reset the fpsimd_cpu for this task and clear the
+ * FPSTATE.
+ */
+ if (!system_supports_fpsimd())
+ return;
barrier();
set_tsk_thread_flag(t, TIF_FOREIGN_FPSTATE);

@@ -1193,6 +1214,7 @@ void fpsimd_flush_task_state(struct task
*/
static void fpsimd_flush_cpu_state(void)
{
+ WARN_ON(!system_supports_fpsimd());
__this_cpu_write(fpsimd_last_state.st, NULL);
set_thread_flag(TIF_FOREIGN_FPSTATE);
}
@@ -1203,6 +1225,8 @@ static void fpsimd_flush_cpu_state(void)
*/
void fpsimd_save_and_flush_cpu_state(void)
{
+ if (!system_supports_fpsimd())
+ return;
WARN_ON(preemptible());
__get_cpu_fpsimd_context();
fpsimd_save();
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -28,7 +28,15 @@
/* Check whether the FP regs were dirtied while in the host-side run loop: */
static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu)
{
- if (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE)
+ /*
+ * When the system doesn't support FP/SIMD, we cannot rely on
+ * the _TIF_FOREIGN_FPSTATE flag. However, we always inject an
+ * abort on the very first access to FP and thus we should never
+ * see KVM_ARM64_FP_ENABLED. For added safety, make sure we always
+ * trap the accesses.
+ */
+ if (!system_supports_fpsimd() ||
+ vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE)
vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED |
KVM_ARM64_FP_HOST);



2020-02-13 15:43:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 79/96] crypto: atmel-sha - fix error handling when setting hmac key

From: Eric Biggers <[email protected]>

commit b529f1983b2dcc46354f311feda92e07b6e9e2da upstream.

HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only
fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated
any error as a "bad key length" error. Fix it to correctly propagate
the -ENOMEM error code and not set any tfm result flags.

Fixes: 81d8750b2b59 ("crypto: atmel-sha - add support to hmac(shaX)")
Cc: Nicolas Ferre <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Cc: Ludovic Desroches <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Reviewed-by: Tudor Ambarus <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/atmel-sha.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -1918,12 +1918,7 @@ static int atmel_sha_hmac_setkey(struct
{
struct atmel_sha_hmac_ctx *hmac = crypto_ahash_ctx(tfm);

- if (atmel_sha_hmac_key_set(&hmac->hkey, key, keylen)) {
- crypto_ahash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
- return -EINVAL;
- }
-
- return 0;
+ return atmel_sha_hmac_key_set(&hmac->hkey, key, keylen);
}

static int atmel_sha_hmac_init(struct ahash_request *req)


2020-02-13 15:44:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 89/96] regmap: fix writes to non incrementing registers

From: Ben Whitten <[email protected]>

commit 2e31aab08bad0d4ee3d3d890a7b74cb6293e0a41 upstream.

When checking if a register block is writable we must ensure that the
block does not start with or contain a non incrementing register.

Fixes: 8b9f9d4dc511 ("regmap: verify if register is writeable before writing operations")
Signed-off-by: Ben Whitten <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/base/regmap/regmap.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)

--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1488,11 +1488,18 @@ static int _regmap_raw_write_impl(struct

WARN_ON(!map->bus);

- /* Check for unwritable registers before we start */
- for (i = 0; i < val_len / map->format.val_bytes; i++)
- if (!regmap_writeable(map,
- reg + regmap_get_offset(map, i)))
- return -EINVAL;
+ /* Check for unwritable or noinc registers in range
+ * before we start
+ */
+ if (!regmap_writeable_noinc(map, reg)) {
+ for (i = 0; i < val_len / map->format.val_bytes; i++) {
+ unsigned int element =
+ reg + regmap_get_offset(map, i);
+ if (!regmap_writeable(map, element) ||
+ regmap_writeable_noinc(map, element))
+ return -EINVAL;
+ }
+ }

if (!map->cache_bypass && map->format.parse_val) {
unsigned int ival;


2020-02-13 15:44:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 87/96] pinctrl: sh-pfc: r8a77965: Fix DU_DOTCLKIN3 drive/bias control

From: Geert Uytterhoeven <[email protected]>

commit a34cd9dfd03fa9ec380405969f1d638bc63b8d63 upstream.

R-Car Gen3 Hardware Manual Errata for Rev. 2.00 of October 24, 2019
changed the configuration bits for drive and bias control for the
DU_DOTCLKIN3 pin on R-Car M3-N, to match the same pin on R-Car H3.
Update the driver to reflect this.

After this, the handling of drive and bias control for the various
DU_DOTCLKINx pins is consistent across all of the R-Car H3, M3-W,
M3-W+, and M3-N SoCs.

Fixes: 86c045c2e4201e94 ("pinctrl: sh-pfc: r8a77965: Replace DU_DOTCLKIN2 by DU_DOTCLKIN3")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -5984,7 +5984,7 @@ static const struct pinmux_drive_reg pin
{ PIN_DU_DOTCLKIN1, 0, 2 }, /* DU_DOTCLKIN1 */
} },
{ PINMUX_DRIVE_REG("DRVCTRL12", 0xe6060330) {
- { PIN_DU_DOTCLKIN3, 28, 2 }, /* DU_DOTCLKIN3 */
+ { PIN_DU_DOTCLKIN3, 24, 2 }, /* DU_DOTCLKIN3 */
{ PIN_FSCLKST, 20, 2 }, /* FSCLKST */
{ PIN_TMS, 4, 2 }, /* TMS */
} },
@@ -6240,8 +6240,8 @@ static const struct pinmux_bias_reg pinm
[31] = PIN_DU_DOTCLKIN1, /* DU_DOTCLKIN1 */
} },
{ PINMUX_BIAS_REG("PUEN3", 0xe606040c, "PUD3", 0xe606044c) {
- [ 0] = PIN_DU_DOTCLKIN3, /* DU_DOTCLKIN3 */
- [ 1] = SH_PFC_PIN_NONE,
+ [ 0] = SH_PFC_PIN_NONE,
+ [ 1] = PIN_DU_DOTCLKIN3, /* DU_DOTCLKIN3 */
[ 2] = PIN_FSCLKST, /* FSCLKST */
[ 3] = PIN_EXTALR, /* EXTALR*/
[ 4] = PIN_TRST_N, /* TRST# */


2020-02-13 15:44:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 84/96] bcache: avoid unnecessary btree nodes flushing in btree_flush_write()

From: Coly Li <[email protected]>

commit 2aa8c529387c25606fdc1484154b92f8bfbc5746 upstream.

the commit 91be66e1318f ("bcache: performance improvement for
btree_flush_write()") was an effort to flushing btree node with oldest
btree node faster in following methods,
- Only iterate dirty btree nodes in c->btree_cache, avoid scanning a lot
of clean btree nodes.
- Take c->btree_cache as a LRU-like list, aggressively flushing all
dirty nodes from tail of c->btree_cache util the btree node with
oldest journal entry is flushed. This is to reduce the time of holding
c->bucket_lock.

Guoju Fang and Shuang Li reported that they observe unexptected extra
write I/Os on cache device after applying the above patch. Guoju Fang
provideed more detailed diagnose information that the aggressive
btree nodes flushing may cause 10x more btree nodes to flush in his
workload. He points out when system memory is large enough to hold all
btree nodes in memory, c->btree_cache is not a LRU-like list any more.
Then the btree node with oldest journal entry is very probably not-
close to the tail of c->btree_cache list. In such situation much more
dirty btree nodes will be aggressively flushed before the target node
is flushed. When slow SATA SSD is used as cache device, such over-
aggressive flushing behavior will cause performance regression.

After spending a lot of time on debug and diagnose, I find the real
condition is more complicated, aggressive flushing dirty btree nodes
from tail of c->btree_cache list is not a good solution.
- When all btree nodes are cached in memory, c->btree_cache is not
a LRU-like list, the btree nodes with oldest journal entry won't
be close to the tail of the list.
- There can be hundreds dirty btree nodes reference the oldest journal
entry, before flushing all the nodes the oldest journal entry cannot
be reclaimed.
When the above two conditions mixed together, a simply flushing from
tail of c->btree_cache list is really NOT a good idea.

Fortunately there is still chance to make btree_flush_write() work
better. Here is how this patch avoids unnecessary btree nodes flushing,
- Only acquire c->journal.lock when getting oldest journal entry of
fifo c->journal.pin. In rested locations check the journal entries
locklessly, so their values can be changed on other cores
in parallel.
- In loop list_for_each_entry_safe_reverse(), checking latest front
point of fifo c->journal.pin. If it is different from the original
point which we get with locking c->journal.lock, it means the oldest
journal entry is reclaim on other cores. At this moment, all selected
dirty nodes recorded in array btree_nodes[] are all flushed and clean
on other CPU cores, it is unncessary to iterate c->btree_cache any
longer. Just quit the list_for_each_entry_safe_reverse() loop and
the following for-loop will skip all the selected clean nodes.
- Find a proper time to quit the list_for_each_entry_safe_reverse()
loop. Check the refcount value of orignial fifo front point, if the
value is larger than selected node number of btree_nodes[], it means
more matching btree nodes should be scanned. Otherwise it means no
more matching btee nodes in rest of c->btree_cache list, the loop
can be quit. If the original oldest journal entry is reclaimed and
fifo front point is updated, the refcount of original fifo front point
will be 0, then the loop will be quit too.
- Not hold c->bucket_lock too long time. c->bucket_lock is also required
for space allocation for cached data, hold it for too long time will
block regular I/O requests. When iterating list c->btree_cache, even
there are a lot of maching btree nodes, in order to not holding
c->bucket_lock for too long time, only BTREE_FLUSH_NR nodes are
selected and to flush in following for-loop.
With this patch, only btree nodes referencing oldest journal entry
are flushed to cache device, no aggressive flushing for unnecessary
btree node any more. And in order to avoid blocking regluar I/O
requests, each time when btree_flush_write() called, at most only
BTREE_FLUSH_NR btree nodes are selected to flush, even there are more
maching btree nodes in list c->btree_cache.

At last, one more thing to explain: Why it is safe to read front point
of c->journal.pin without holding c->journal.lock inside the
list_for_each_entry_safe_reverse() loop ?

Here is my answer: When reading the front point of fifo c->journal.pin,
we don't need to know the exact value of front point, we just want to
check whether the value is different from the original front point
(which is accurate value because we get it while c->jouranl.lock is
held). For such purpose, it works as expected without holding
c->journal.lock. Even the front point is changed on other CPU core and
not updated to local core, and current iterating btree node has
identical journal entry local as original fetched fifo front point, it
is still safe. Because after holding mutex b->write_lock (with memory
barrier) this btree node can be found as clean and skipped, the loop
will quite latter when iterate on next node of list c->btree_cache.

Fixes: 91be66e1318f ("bcache: performance improvement for btree_flush_write()")
Reported-by: Guoju Fang <[email protected]>
Reported-by: Shuang Li <[email protected]>
Signed-off-by: Coly Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/bcache/journal.c | 80 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 75 insertions(+), 5 deletions(-)

--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -417,10 +417,14 @@ err:

/* Journalling */

+#define nr_to_fifo_front(p, front_p, mask) (((p) - (front_p)) & (mask))
+
static void btree_flush_write(struct cache_set *c)
{
struct btree *b, *t, *btree_nodes[BTREE_FLUSH_NR];
- unsigned int i, n;
+ unsigned int i, nr, ref_nr;
+ atomic_t *fifo_front_p, *now_fifo_front_p;
+ size_t mask;

if (c->journal.btree_flushing)
return;
@@ -433,12 +437,50 @@ static void btree_flush_write(struct cac
c->journal.btree_flushing = true;
spin_unlock(&c->journal.flush_write_lock);

+ /* get the oldest journal entry and check its refcount */
+ spin_lock(&c->journal.lock);
+ fifo_front_p = &fifo_front(&c->journal.pin);
+ ref_nr = atomic_read(fifo_front_p);
+ if (ref_nr <= 0) {
+ /*
+ * do nothing if no btree node references
+ * the oldest journal entry
+ */
+ spin_unlock(&c->journal.lock);
+ goto out;
+ }
+ spin_unlock(&c->journal.lock);
+
+ mask = c->journal.pin.mask;
+ nr = 0;
atomic_long_inc(&c->flush_write);
memset(btree_nodes, 0, sizeof(btree_nodes));
- n = 0;

mutex_lock(&c->bucket_lock);
list_for_each_entry_safe_reverse(b, t, &c->btree_cache, list) {
+ /*
+ * It is safe to get now_fifo_front_p without holding
+ * c->journal.lock here, because we don't need to know
+ * the exactly accurate value, just check whether the
+ * front pointer of c->journal.pin is changed.
+ */
+ now_fifo_front_p = &fifo_front(&c->journal.pin);
+ /*
+ * If the oldest journal entry is reclaimed and front
+ * pointer of c->journal.pin changes, it is unnecessary
+ * to scan c->btree_cache anymore, just quit the loop and
+ * flush out what we have already.
+ */
+ if (now_fifo_front_p != fifo_front_p)
+ break;
+ /*
+ * quit this loop if all matching btree nodes are
+ * scanned and record in btree_nodes[] already.
+ */
+ ref_nr = atomic_read(fifo_front_p);
+ if (nr >= ref_nr)
+ break;
+
if (btree_node_journal_flush(b))
pr_err("BUG: flush_write bit should not be set here!");

@@ -454,17 +496,44 @@ static void btree_flush_write(struct cac
continue;
}

+ /*
+ * Only select the btree node which exactly references
+ * the oldest journal entry.
+ *
+ * If the journal entry pointed by fifo_front_p is
+ * reclaimed in parallel, don't worry:
+ * - the list_for_each_xxx loop will quit when checking
+ * next now_fifo_front_p.
+ * - If there are matched nodes recorded in btree_nodes[],
+ * they are clean now (this is why and how the oldest
+ * journal entry can be reclaimed). These selected nodes
+ * will be ignored and skipped in the folowing for-loop.
+ */
+ if (nr_to_fifo_front(btree_current_write(b)->journal,
+ fifo_front_p,
+ mask) != 0) {
+ mutex_unlock(&b->write_lock);
+ continue;
+ }
+
set_btree_node_journal_flush(b);

mutex_unlock(&b->write_lock);

- btree_nodes[n++] = b;
- if (n == BTREE_FLUSH_NR)
+ btree_nodes[nr++] = b;
+ /*
+ * To avoid holding c->bucket_lock too long time,
+ * only scan for BTREE_FLUSH_NR matched btree nodes
+ * at most. If there are more btree nodes reference
+ * the oldest journal entry, try to flush them next
+ * time when btree_flush_write() is called.
+ */
+ if (nr == BTREE_FLUSH_NR)
break;
}
mutex_unlock(&c->bucket_lock);

- for (i = 0; i < n; i++) {
+ for (i = 0; i < nr; i++) {
b = btree_nodes[i];
if (!b) {
pr_err("BUG: btree_nodes[%d] is NULL", i);
@@ -497,6 +566,7 @@ static void btree_flush_write(struct cac
mutex_unlock(&b->write_lock);
}

+out:
spin_lock(&c->journal.flush_write_lock);
c->journal.btree_flushing = false;
spin_unlock(&c->journal.flush_write_lock);


2020-02-13 15:44:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 85/96] selinux: revert "stop passing MAY_NOT_BLOCK to the AVC upon follow_link"

From: Stephen Smalley <[email protected]>

commit 1a37079c236d55fb31ebbf4b59945dab8ec8764c upstream.

This reverts commit e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK
to the AVC upon follow_link"). The correct fix is to instead fall
back to ref-walk if audit is required irrespective of the specific
audit data type. This is done in the next commit.

Fixes: e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link")
Reported-by: Will Deacon <[email protected]>
Signed-off-by: Stephen Smalley <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
security/selinux/avc.c | 24 ++++++++++++++++++++++--
security/selinux/hooks.c | 5 +++--
security/selinux/include/avc.h | 5 +++++
3 files changed, 30 insertions(+), 4 deletions(-)

--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -862,8 +862,9 @@ static int avc_update_node(struct selinu
* permissive mode that only appear when in enforcing mode.
*
* See the corresponding handling in slow_avc_audit(), and the
- * logic in selinux_inode_permission for the MAY_NOT_BLOCK flag,
- * which is transliterated into AVC_NONBLOCKING.
+ * logic in selinux_inode_follow_link and selinux_inode_permission
+ * for the VFS MAY_NOT_BLOCK flag, which is transliterated into
+ * AVC_NONBLOCKING for avc_has_perm_noaudit().
*/
if (flags & AVC_NONBLOCKING)
return 0;
@@ -1203,6 +1204,25 @@ int avc_has_perm(struct selinux_state *s
if (rc2)
return rc2;
return rc;
+}
+
+int avc_has_perm_flags(struct selinux_state *state,
+ u32 ssid, u32 tsid, u16 tclass, u32 requested,
+ struct common_audit_data *auditdata,
+ int flags)
+{
+ struct av_decision avd;
+ int rc, rc2;
+
+ rc = avc_has_perm_noaudit(state, ssid, tsid, tclass, requested,
+ (flags & MAY_NOT_BLOCK) ? AVC_NONBLOCKING : 0,
+ &avd);
+
+ rc2 = avc_audit(state, ssid, tsid, tclass, requested, &avd, rc,
+ auditdata, flags);
+ if (rc2)
+ return rc2;
+ return rc;
}

u32 avc_policy_seqno(struct selinux_state *state)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3008,8 +3008,9 @@ static int selinux_inode_follow_link(str
if (IS_ERR(isec))
return PTR_ERR(isec);

- return avc_has_perm(&selinux_state,
- sid, isec->sid, isec->sclass, FILE__READ, &ad);
+ return avc_has_perm_flags(&selinux_state,
+ sid, isec->sid, isec->sclass, FILE__READ, &ad,
+ rcu ? MAY_NOT_BLOCK : 0);
}

static noinline int audit_inode_permission(struct inode *inode,
--- a/security/selinux/include/avc.h
+++ b/security/selinux/include/avc.h
@@ -153,6 +153,11 @@ int avc_has_perm(struct selinux_state *s
u32 ssid, u32 tsid,
u16 tclass, u32 requested,
struct common_audit_data *auditdata);
+int avc_has_perm_flags(struct selinux_state *state,
+ u32 ssid, u32 tsid,
+ u16 tclass, u32 requested,
+ struct common_audit_data *auditdata,
+ int flags);

int avc_has_extended_perms(struct selinux_state *state,
u32 ssid, u32 tsid, u16 tclass, u32 requested,


2020-02-13 15:44:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 75/96] mtd: onenand_base: Adjust indentation in onenand_read_ops_nolock

From: Nathan Chancellor <[email protected]>

commit 0e7ca83e82d021c928dadf4c13c137d57337540d upstream.

Clang warns:

../drivers/mtd/nand/onenand/onenand_base.c:1269:3: warning: misleading
indentation; statement is not part of the previous 'if'
[-Wmisleading-indentation]
while (!ret) {
^
../drivers/mtd/nand/onenand/onenand_base.c:1266:2: note: previous
statement is here
if (column + thislen > writesize)
^
1 warning generated.

This warning occurs because there is a space before the tab of the while
loop. There are spaces at the beginning of a lot of the lines in this
block, remove them so that the indentation is consistent with the Linux
kernel coding style and clang no longer warns.

Fixes: a8de85d55700 ("[MTD] OneNAND: Implement read-while-load")
Link: https://github.com/ClangBuiltLinux/linux/issues/794
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mtd/nand/onenand/onenand_base.c | 82 ++++++++++++++++----------------
1 file changed, 41 insertions(+), 41 deletions(-)

--- a/drivers/mtd/nand/onenand/onenand_base.c
+++ b/drivers/mtd/nand/onenand/onenand_base.c
@@ -1248,44 +1248,44 @@ static int onenand_read_ops_nolock(struc

stats = mtd->ecc_stats;

- /* Read-while-load method */
+ /* Read-while-load method */

- /* Do first load to bufferRAM */
- if (read < len) {
- if (!onenand_check_bufferram(mtd, from)) {
+ /* Do first load to bufferRAM */
+ if (read < len) {
+ if (!onenand_check_bufferram(mtd, from)) {
this->command(mtd, ONENAND_CMD_READ, from, writesize);
- ret = this->wait(mtd, FL_READING);
- onenand_update_bufferram(mtd, from, !ret);
+ ret = this->wait(mtd, FL_READING);
+ onenand_update_bufferram(mtd, from, !ret);
if (mtd_is_eccerr(ret))
ret = 0;
- }
- }
+ }
+ }

thislen = min_t(int, writesize, len - read);
column = from & (writesize - 1);
if (column + thislen > writesize)
thislen = writesize - column;

- while (!ret) {
- /* If there is more to load then start next load */
- from += thislen;
- if (read + thislen < len) {
+ while (!ret) {
+ /* If there is more to load then start next load */
+ from += thislen;
+ if (read + thislen < len) {
this->command(mtd, ONENAND_CMD_READ, from, writesize);
- /*
- * Chip boundary handling in DDP
- * Now we issued chip 1 read and pointed chip 1
+ /*
+ * Chip boundary handling in DDP
+ * Now we issued chip 1 read and pointed chip 1
* bufferram so we have to point chip 0 bufferram.
- */
- if (ONENAND_IS_DDP(this) &&
- unlikely(from == (this->chipsize >> 1))) {
- this->write_word(ONENAND_DDP_CHIP0, this->base + ONENAND_REG_START_ADDRESS2);
- boundary = 1;
- } else
- boundary = 0;
- ONENAND_SET_PREV_BUFFERRAM(this);
- }
- /* While load is going, read from last bufferRAM */
- this->read_bufferram(mtd, ONENAND_DATARAM, buf, column, thislen);
+ */
+ if (ONENAND_IS_DDP(this) &&
+ unlikely(from == (this->chipsize >> 1))) {
+ this->write_word(ONENAND_DDP_CHIP0, this->base + ONENAND_REG_START_ADDRESS2);
+ boundary = 1;
+ } else
+ boundary = 0;
+ ONENAND_SET_PREV_BUFFERRAM(this);
+ }
+ /* While load is going, read from last bufferRAM */
+ this->read_bufferram(mtd, ONENAND_DATARAM, buf, column, thislen);

/* Read oob area if needed */
if (oobbuf) {
@@ -1301,24 +1301,24 @@ static int onenand_read_ops_nolock(struc
oobcolumn = 0;
}

- /* See if we are done */
- read += thislen;
- if (read == len)
- break;
- /* Set up for next read from bufferRAM */
- if (unlikely(boundary))
- this->write_word(ONENAND_DDP_CHIP1, this->base + ONENAND_REG_START_ADDRESS2);
- ONENAND_SET_NEXT_BUFFERRAM(this);
- buf += thislen;
+ /* See if we are done */
+ read += thislen;
+ if (read == len)
+ break;
+ /* Set up for next read from bufferRAM */
+ if (unlikely(boundary))
+ this->write_word(ONENAND_DDP_CHIP1, this->base + ONENAND_REG_START_ADDRESS2);
+ ONENAND_SET_NEXT_BUFFERRAM(this);
+ buf += thislen;
thislen = min_t(int, writesize, len - read);
- column = 0;
- cond_resched();
- /* Now wait for load */
- ret = this->wait(mtd, FL_READING);
- onenand_update_bufferram(mtd, from, !ret);
+ column = 0;
+ cond_resched();
+ /* Now wait for load */
+ ret = this->wait(mtd, FL_READING);
+ onenand_update_bufferram(mtd, from, !ret);
if (mtd_is_eccerr(ret))
ret = 0;
- }
+ }

/*
* Return success, if no ECC failures, else -EBADMSG


2020-02-13 15:44:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 63/96] ARM: 8949/1: mm: mark free_memmap as __init

From: Olof Johansson <[email protected]>

commit 31f3010e60522ede237fb145a63b4af5a41718c2 upstream.

As of commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
forcibly"), free_memmap() might not always be inlined, and thus is
triggering a section warning:

WARNING: vmlinux.o(.text.unlikely+0x904): Section mismatch in reference from the function free_memmap() to the function .meminit.text:memblock_free()

Mark it as __init, since the faller (free_unused_memmap) already is.

Fixes: ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly")
Signed-off-by: Olof Johansson <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -323,7 +323,7 @@ static inline void poison_init_mem(void
*p++ = 0xe7fddef0;
}

-static inline void
+static inline void __init
free_memmap(unsigned long start_pfn, unsigned long end_pfn)
{
struct page *start_pg, *end_pg;


2020-02-13 15:44:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 81/96] drivers: watchdog: stm32_iwdg: set WDOG_HW_RUNNING at probe

From: Christophe Roullier <[email protected]>

commit 85fdc63fe256b595f923a69848cd99972ff446d8 upstream.

If the watchdog hardware is already enabled during the boot process,
when the Linux watchdog driver loads, it should start/reset the watchdog
and tell the watchdog framework. As a result, ping can be generated from
the watchdog framework (if CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set),
until the userspace watchdog daemon takes over control

Fixes:4332d113c66a ("watchdog: Add STM32 IWDG driver")

Signed-off-by: Christophe Roullier <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/watchdog/stm32_iwdg.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -262,6 +262,24 @@ static int stm32_iwdg_probe(struct platf
watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT);
watchdog_init_timeout(wdd, 0, dev);

+ /*
+ * In case of CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set
+ * (Means U-Boot/bootloaders leaves the watchdog running)
+ * When we get here we should make a decision to prevent
+ * any side effects before user space daemon will take care of it.
+ * The best option, taking into consideration that there is no
+ * way to read values back from hardware, is to enforce watchdog
+ * being run with deterministic values.
+ */
+ if (IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED)) {
+ ret = stm32_iwdg_start(wdd);
+ if (ret)
+ return ret;
+
+ /* Make sure the watchdog is serviced */
+ set_bit(WDOG_HW_RUNNING, &wdd->status);
+ }
+
ret = devm_watchdog_register_device(dev, wdd);
if (ret)
return ret;


2020-02-13 15:44:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 60/96] ARM: at91: pm: use SAM9X60 PMCs compatible

From: Claudiu Beznea <[email protected]>

commit 6b9dfd986a81a999a27b6ed9dbe91203089c62dd upstream.

SAM9X60 PMC's has a different PMC. It was not integrated at the moment
commit 01c7031cfa73 ("ARM: at91: pm: initial PM support for SAM9X60")
was published.

Fixes: 01c7031cfa73 ("ARM: at91: pm: initial PM support for SAM9X60")
Signed-off-by: Claudiu Beznea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/mach-at91/pm.c | 1 +
1 file changed, 1 insertion(+)

--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -751,6 +751,7 @@ static const struct of_device_id atmel_p
{ .compatible = "atmel,sama5d3-pmc", .data = &pmc_infos[1] },
{ .compatible = "atmel,sama5d4-pmc", .data = &pmc_infos[1] },
{ .compatible = "atmel,sama5d2-pmc", .data = &pmc_infos[1] },
+ { .compatible = "microchip,sam9x60-pmc", .data = &pmc_infos[1] },
{ /* sentinel */ },
};



2020-02-13 15:44:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 77/96] crypto: testmgr - dont try to decrypt uninitialized buffers

From: Eric Biggers <[email protected]>

commit eb455dbd02cb1074b37872ffca30a81cb2a18eaa upstream.

Currently if the comparison fuzz tests encounter an encryption error
when generating an skcipher or AEAD test vector, they will still test
the decryption side (passing it the uninitialized ciphertext buffer)
and expect it to fail with the same error.

This is sort of broken because it's not well-defined usage of the API to
pass an uninitialized buffer, and furthermore in the AEAD case it's
acceptable for the decryption error to be EBADMSG (meaning "inauthentic
input") even if the encryption error was something else like EINVAL.

Fix this for skcipher by explicitly initializing the ciphertext buffer
on error, and for AEAD by skipping the decryption test on error.

Reported-by: Pascal Van Leeuwen <[email protected]>
Fixes: d435e10e67be ("crypto: testmgr - fuzz skciphers against their generic implementation")
Fixes: 40153b10d91c ("crypto: testmgr - fuzz AEADs against their generic implementation")
Signed-off-by: Eric Biggers <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/testmgr.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2102,6 +2102,7 @@ static void generate_random_aead_testvec
* If the key or authentication tag size couldn't be set, no need to
* continue to encrypt.
*/
+ vec->crypt_error = 0;
if (vec->setkey_error || vec->setauthsize_error)
goto done;

@@ -2245,10 +2246,12 @@ static int test_aead_vs_generic_impl(con
req, tsgls);
if (err)
goto out;
- err = test_aead_vec_cfg(driver, DECRYPT, &vec, vec_name, cfg,
- req, tsgls);
- if (err)
- goto out;
+ if (vec.crypt_error == 0) {
+ err = test_aead_vec_cfg(driver, DECRYPT, &vec, vec_name,
+ cfg, req, tsgls);
+ if (err)
+ goto out;
+ }
cond_resched();
}
err = 0;
@@ -2678,6 +2681,15 @@ static void generate_random_cipher_testv
skcipher_request_set_callback(req, 0, crypto_req_done, &wait);
skcipher_request_set_crypt(req, &src, &dst, vec->len, iv);
vec->crypt_error = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
+ if (vec->crypt_error != 0) {
+ /*
+ * The only acceptable error here is for an invalid length, so
+ * skcipher decryption should fail with the same error too.
+ * We'll test for this. But to keep the API usage well-defined,
+ * explicitly initialize the ciphertext buffer too.
+ */
+ memset((u8 *)vec->ctext, 0, vec->len);
+ }
done:
snprintf(name, max_namelen, "\"random: len=%u klen=%u\"",
vec->len, vec->klen);


2020-02-13 15:44:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 93/96] mwifiex: Fix possible buffer overflows in mwifiex_ret_wmm_get_status()

From: Qing Xu <[email protected]>

[ Upstream commit 3a9b153c5591548612c3955c9600a98150c81875 ]

mwifiex_ret_wmm_get_status() calls memcpy() without checking the
destination size.Since the source is given from remote AP which
contains illegal wmm elements , this may trigger a heap buffer
overflow.
Fix it by putting the length check before calling memcpy().

Signed-off-by: Qing Xu <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/wireless/marvell/mwifiex/wmm.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 41f0231376c01..132f9e8ed68c1 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -970,6 +970,10 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,
"WMM Parameter Set Count: %d\n",
wmm_param_ie->qos_info_bitmap & mask);

+ if (wmm_param_ie->vend_hdr.len + 2 >
+ sizeof(struct ieee_types_wmm_parameter))
+ break;
+
memcpy((u8 *) &priv->curr_bss_params.bss_descriptor.
wmm_ie, wmm_param_ie,
wmm_param_ie->vend_hdr.len + 2);
--
2.20.1



2020-02-13 15:45:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 57/96] powerpc/pseries/vio: Fix iommu_table use-after-free refcount warning

From: Tyrel Datwyler <[email protected]>

commit aff8c8242bc638ba57247ae1ec5f272ac3ed3b92 upstream.

Commit e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to
iommu_table") missed an iommu_table allocation in the pseries vio code.
The iommu_table is allocated with kzalloc and as a result the associated
kref gets a value of zero. This has the side effect that during a DLPAR
remove of the associated virtual IOA the iommu_tce_table_put() triggers
a use-after-free underflow warning.

Call Trace:
[c0000002879e39f0] [c00000000071ecb4] refcount_warn_saturate+0x184/0x190
(unreliable)
[c0000002879e3a50] [c0000000000500ac] iommu_tce_table_put+0x9c/0xb0
[c0000002879e3a70] [c0000000000f54e4] vio_dev_release+0x34/0x70
[c0000002879e3aa0] [c00000000087cfa4] device_release+0x54/0xf0
[c0000002879e3b10] [c000000000d64c84] kobject_cleanup+0xa4/0x240
[c0000002879e3b90] [c00000000087d358] put_device+0x28/0x40
[c0000002879e3bb0] [c0000000007a328c] dlpar_remove_slot+0x15c/0x250
[c0000002879e3c50] [c0000000007a348c] remove_slot_store+0xac/0xf0
[c0000002879e3cd0] [c000000000d64220] kobj_attr_store+0x30/0x60
[c0000002879e3cf0] [c0000000004ff13c] sysfs_kf_write+0x6c/0xa0
[c0000002879e3d10] [c0000000004fde4c] kernfs_fop_write+0x18c/0x260
[c0000002879e3d60] [c000000000410f3c] __vfs_write+0x3c/0x70
[c0000002879e3d80] [c000000000415408] vfs_write+0xc8/0x250
[c0000002879e3dd0] [c0000000004157dc] ksys_write+0x7c/0x120
[c0000002879e3e20] [c00000000000b278] system_call+0x5c/0x68

Further, since the refcount was always zero the iommu_tce_table_put()
fails to call the iommu_table release function resulting in a leak.

Fix this issue be initilizing the iommu_table kref immediately after
allocation.

Fixes: e5afdf9dd515 ("powerpc/vfio_spapr_tce: Add reference counting to iommu_table")
Signed-off-by: Tyrel Datwyler <[email protected]>
Reviewed-by: Alexey Kardashevskiy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/platforms/pseries/vio.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1176,6 +1176,8 @@ static struct iommu_table *vio_build_iom
if (tbl == NULL)
return NULL;

+ kref_init(&tbl->it_kref);
+
of_parse_dma_window(dev->dev.of_node, dma_window,
&tbl->it_index, &offset, &size);



2020-02-13 15:45:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 71/96] KVM: arm64: pmu: Dont increment SW_INCR if PMCR.E is unset

From: Eric Auger <[email protected]>

commit 3837407c1aa1101ed5e214c7d6041e7a23335c6e upstream.

The specification says PMSWINC increments PMEVCNTR<n>_EL1 by 1
if PMEVCNTR<n>_EL0 is enabled and configured to count SW_INCR.

For PMEVCNTR<n>_EL0 to be enabled, we need both PMCNTENSET to
be set for the corresponding event counter but we also need
the PMCR.E bit to be set.

Fixes: 7a0adc7064b8 ("arm64: KVM: Add access handler for PMSWINC register")
Signed-off-by: Eric Auger <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Andrew Murray <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/pmu.c | 3 +++
1 file changed, 3 insertions(+)

--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -486,6 +486,9 @@ void kvm_pmu_software_increment(struct k
if (val == 0)
return;

+ if (!(__vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E))
+ return;
+
enable = __vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
if (!(val & BIT(i)))


2020-02-13 15:45:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 68/96] KVM: arm/arm64: Fix young bit from mmu notifier

From: Gavin Shan <[email protected]>

commit cf2d23e0bac9f6b5cd1cba8898f5f05ead40e530 upstream.

kvm_test_age_hva() is called upon mmu_notifier_test_young(), but wrong
address range has been passed to handle_hva_to_gpa(). With the wrong
address range, no young bits will be checked in handle_hva_to_gpa().
It means zero is always returned from mmu_notifier_test_young().

This fixes the issue by passing correct address range to the underly
function handle_hva_to_gpa(), so that the hardware young (access) bit
will be visited.

Fixes: 35307b9a5f7e ("arm/arm64: KVM: Implement Stage-2 page aging")
Signed-off-by: Gavin Shan <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/mmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -2147,7 +2147,8 @@ int kvm_test_age_hva(struct kvm *kvm, un
if (!kvm->arch.pgd)
return 0;
trace_kvm_test_age_hva(hva);
- return handle_hva_to_gpa(kvm, hva, hva, kvm_test_age_hva_handler, NULL);
+ return handle_hva_to_gpa(kvm, hva, hva + PAGE_SIZE,
+ kvm_test_age_hva_handler, NULL);
}

void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu)


2020-02-13 15:45:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 92/96] dmaengine: axi-dmac: add a check for devm_regmap_init_mmio

From: Chuhong Yuan <[email protected]>

commit a5b982af953bcc838cd198b0434834cc1dff14ec upstream.

The driver misses checking the result of devm_regmap_init_mmio().
Add a check to fix it.

Fixes: fc15be39a827 ("dmaengine: axi-dmac: add regmap support")
Signed-off-by: Chuhong Yuan <[email protected]>
Reviewed-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma/dma-axi-dmac.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/dma/dma-axi-dmac.c
+++ b/drivers/dma/dma-axi-dmac.c
@@ -830,6 +830,7 @@ static int axi_dmac_probe(struct platfor
struct dma_device *dma_dev;
struct axi_dmac *dmac;
struct resource *res;
+ struct regmap *regmap;
int ret;

dmac = devm_kzalloc(&pdev->dev, sizeof(*dmac), GFP_KERNEL);
@@ -921,10 +922,17 @@ static int axi_dmac_probe(struct platfor

platform_set_drvdata(pdev, dmac);

- devm_regmap_init_mmio(&pdev->dev, dmac->base, &axi_dmac_regmap_config);
+ regmap = devm_regmap_init_mmio(&pdev->dev, dmac->base,
+ &axi_dmac_regmap_config);
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ goto err_free_irq;
+ }

return 0;

+err_free_irq:
+ free_irq(dmac->irq, dmac);
err_unregister_of:
of_dma_controller_free(pdev->dev.of_node);
err_unregister_device:


2020-02-13 15:45:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 62/96] KVM: arm/arm64: vgic-its: Fix restoration of unmapped collections

From: Eric Auger <[email protected]>

commit 8c58be34494b7f1b2adb446e2d8beeb90e5de65b upstream.

Saving/restoring an unmapped collection is a valid scenario. For
example this happens if a MAPTI command was sent, featuring an
unmapped collection. At the moment the CTE fails to be restored.
Only compare against the number of online vcpus if the rdist
base is set.

Fixes: ea1ad53e1e31a ("KVM: arm64: vgic-its: Collection table save/restore")
Signed-off-by: Eric Auger <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Zenghui Yu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/vgic/vgic-its.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -2472,7 +2472,8 @@ static int vgic_its_restore_cte(struct v
target_addr = (u32)(val >> KVM_ITS_CTE_RDBASE_SHIFT);
coll_id = val & KVM_ITS_CTE_ICID_MASK;

- if (target_addr >= atomic_read(&kvm->online_vcpus))
+ if (target_addr != COLLECTION_NOT_MAPPED &&
+ target_addr >= atomic_read(&kvm->online_vcpus))
return -EINVAL;

collection = find_collection(its, coll_id);


2020-02-13 15:45:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 67/96] arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations

From: Suzuki K Poulose <[email protected]>

commit c9d66999f064947e6b577ceacc1eb2fbca6a8d3c upstream.

When fp/simd is not supported on the system, fail the operations
of FP/SIMD regsets.

Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Catalin Marinas <[email protected]>
Signed-off-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/kernel/ptrace.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)

--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -615,6 +615,13 @@ static int gpr_set(struct task_struct *t
return 0;
}

+static int fpr_active(struct task_struct *target, const struct user_regset *regset)
+{
+ if (!system_supports_fpsimd())
+ return -ENODEV;
+ return regset->n;
+}
+
/*
* TODO: update fp accessors for lazy context switching (sync/flush hwstate)
*/
@@ -637,6 +644,9 @@ static int fpr_get(struct task_struct *t
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
+ if (!system_supports_fpsimd())
+ return -EINVAL;
+
if (target == current)
fpsimd_preserve_current_state();

@@ -676,6 +686,9 @@ static int fpr_set(struct task_struct *t
{
int ret;

+ if (!system_supports_fpsimd())
+ return -EINVAL;
+
ret = __fpr_set(target, regset, pos, count, kbuf, ubuf, 0);
if (ret)
return ret;
@@ -1134,6 +1147,7 @@ static const struct user_regset aarch64_
*/
.size = sizeof(u32),
.align = sizeof(u32),
+ .active = fpr_active,
.get = fpr_get,
.set = fpr_set
},
@@ -1348,6 +1362,9 @@ static int compat_vfp_get(struct task_st
compat_ulong_t fpscr;
int ret, vregs_end_pos;

+ if (!system_supports_fpsimd())
+ return -EINVAL;
+
uregs = &target->thread.uw.fpsimd_state;

if (target == current)
@@ -1381,6 +1398,9 @@ static int compat_vfp_set(struct task_st
compat_ulong_t fpscr;
int ret, vregs_end_pos;

+ if (!system_supports_fpsimd())
+ return -EINVAL;
+
uregs = &target->thread.uw.fpsimd_state;

vregs_end_pos = VFP_STATE_SIZE - sizeof(compat_ulong_t);
@@ -1438,6 +1458,7 @@ static const struct user_regset aarch32_
.n = VFP_STATE_SIZE / sizeof(compat_ulong_t),
.size = sizeof(compat_ulong_t),
.align = sizeof(compat_ulong_t),
+ .active = fpr_active,
.get = compat_vfp_get,
.set = compat_vfp_set
},


2020-02-13 15:45:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 65/96] arm64: cpufeature: Fix the type of no FP/SIMD capability

From: Suzuki K Poulose <[email protected]>

commit 449443c03d8cfdacf7313e17779a2594ebf87e6d upstream.

The NO_FPSIMD capability is defined with scope SYSTEM, which implies
that the "absence" of FP/SIMD on at least one CPU is detected only
after all the SMP CPUs are brought up. However, we use the status
of this capability for every context switch. So, let us change
the scope to LOCAL_CPU to allow the detection of this capability
as and when the first CPU without FP is brought up.

Also, the current type allows hotplugged CPU to be brought up without
FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace
up. Fix both of these issues by changing the capability to
BOOT_RESTRICTED_LOCAL_CPU_FEATURE.

Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Catalin Marinas <[email protected]>
Signed-off-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/kernel/cpufeature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1367,7 +1367,7 @@ static const struct arm64_cpu_capabiliti
{
/* FP/SIMD is not implemented */
.capability = ARM64_HAS_NO_FPSIMD,
- .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .type = ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE,
.min_field_value = 0,
.matches = has_no_fpsimd,
},


2020-02-13 15:45:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 56/96] powerpc/papr_scm: Fix leaking bus_desc.provider_name in some paths

From: Vaibhav Jain <[email protected]>

commit 5649607a8d0b0e019a4db14aab3de1e16c3a2b4f upstream.

String 'bus_desc.provider_name' allocated inside
papr_scm_nvdimm_init() will leaks in case call to
nvdimm_bus_register() fails or when papr_scm_remove() is called.

This minor patch ensures that 'bus_desc.provider_name' is freed in
error path for nvdimm_bus_register() as well as in papr_scm_remove().

Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
Signed-off-by: Vaibhav Jain <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/platforms/pseries/papr_scm.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -342,6 +342,7 @@ static int papr_scm_nvdimm_init(struct p
p->bus = nvdimm_bus_register(NULL, &p->bus_desc);
if (!p->bus) {
dev_err(dev, "Error creating nvdimm bus %pOF\n", p->dn);
+ kfree(p->bus_desc.provider_name);
return -ENXIO;
}

@@ -498,6 +499,7 @@ static int papr_scm_remove(struct platfo

nvdimm_bus_unregister(p->bus);
drc_pmem_unbind(p);
+ kfree(p->bus_desc.provider_name);
kfree(p);

return 0;


2020-02-13 15:45:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 61/96] ARM: at91: pm: use of_device_id array to find the proper shdwc node

From: Claudiu Beznea <[email protected]>

commit ec6e618c8c018c1361d77789a100a5f6f6317178 upstream.

Use of_device_id array to find the proper shdwc compatibile node.
SAM9X60's shdwc changes were not integrated when
commit eaedc0d379da ("ARM: at91: pm: add ULP1 support for SAM9X60")
was integrated.

Fixes: eaedc0d379da ("ARM: at91: pm: add ULP1 support for SAM9X60")
Signed-off-by: Claudiu Beznea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/mach-at91/pm.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -691,6 +691,12 @@ static void __init at91_pm_use_default_m
soc_pm.data.suspend_mode = AT91_PM_ULP0;
}

+static const struct of_device_id atmel_shdwc_ids[] = {
+ { .compatible = "atmel,sama5d2-shdwc" },
+ { .compatible = "microchip,sam9x60-shdwc" },
+ { /* sentinel. */ }
+};
+
static void __init at91_pm_modes_init(void)
{
struct device_node *np;
@@ -700,7 +706,7 @@ static void __init at91_pm_modes_init(vo
!at91_is_pm_mode_active(AT91_PM_ULP1))
return;

- np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-shdwc");
+ np = of_find_matching_node(NULL, atmel_shdwc_ids);
if (!np) {
pr_warn("%s: failed to find shdwc!\n", __func__);
goto ulp1_default;


2020-02-13 15:45:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 44/96] ARM: dts: am43xx: add support for clkout1 clock

From: Tero Kristo <[email protected]>

commit 01053dadb79d63b65f7b353e68b4b6ccf4effedb upstream.

clkout1 clock node and its generation tree was missing. Add this based
on the data on TRM and PRCM functional spec.

commit 664ae1ab2536 ("ARM: dts: am43xx: add clkctrl nodes") effectively
reverted this commit 8010f13a40d3 ("ARM: dts: am43xx: add support for
clkout1 clock") which is needed for the ov2659 camera sensor clock
definition hence it is being re-applied here.

Note that because of the current dts node name dependency for mapping to
clock domain, we must still use "clkout1-*ck" naming instead of generic
"clock@" naming for the node. And because of this, it's probably best to
apply the dts node addition together along with the other clock changes.

Fixes: 664ae1ab2536 ("ARM: dts: am43xx: add clkctrl nodes")
Signed-off-by: Tero Kristo <[email protected]>
Tested-by: Benoit Parrot <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Benoit Parrot <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/am43xx-clocks.dtsi | 54 +++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)

--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -704,6 +704,60 @@
ti,bit-shift = <8>;
reg = <0x2a48>;
};
+
+ clkout1_osc_div_ck: clkout1-osc-div-ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&sys_clkin_ck>;
+ ti,bit-shift = <20>;
+ ti,max-div = <4>;
+ reg = <0x4100>;
+ };
+
+ clkout1_src2_mux_ck: clkout1-src2-mux-ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&clk_rc32k_ck>, <&sysclk_div>, <&dpll_ddr_m2_ck>,
+ <&dpll_per_m2_ck>, <&dpll_disp_m2_ck>,
+ <&dpll_mpu_m2_ck>;
+ reg = <0x4100>;
+ };
+
+ clkout1_src2_pre_div_ck: clkout1-src2-pre-div-ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&clkout1_src2_mux_ck>;
+ ti,bit-shift = <4>;
+ ti,max-div = <8>;
+ reg = <0x4100>;
+ };
+
+ clkout1_src2_post_div_ck: clkout1-src2-post-div-ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&clkout1_src2_pre_div_ck>;
+ ti,bit-shift = <8>;
+ ti,max-div = <32>;
+ ti,index-power-of-two;
+ reg = <0x4100>;
+ };
+
+ clkout1_mux_ck: clkout1-mux-ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&clkout1_osc_div_ck>, <&clk_rc32k_ck>,
+ <&clkout1_src2_post_div_ck>, <&dpll_extdev_m2_ck>;
+ ti,bit-shift = <16>;
+ reg = <0x4100>;
+ };
+
+ clkout1_ck: clkout1-ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&clkout1_mux_ck>;
+ ti,bit-shift = <23>;
+ reg = <0x4100>;
+ };
};

&prcm {


2020-02-13 15:45:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 40/96] platform/x86: intel_mid_powerbtn: Take a copy of ddata

From: Mika Westerberg <[email protected]>

commit 5e0c94d3aeeecc68c573033f08d9678fecf253bd upstream.

The driver gets driver_data from memory that is marked as const (which
is probably put to read-only memory) and it then modifies it. This
likely causes some sort of fault to happen.

Fix this by taking a copy of the structure.

Fixes: c94a8ff14de3 ("platform/x86: intel_mid_powerbtn: make mid_pb_ddata const")
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/platform/x86/intel_mid_powerbtn.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/platform/x86/intel_mid_powerbtn.c
+++ b/drivers/platform/x86/intel_mid_powerbtn.c
@@ -146,9 +146,10 @@ static int mid_pb_probe(struct platform_

input_set_capability(input, EV_KEY, KEY_POWER);

- ddata = (struct mid_pb_ddata *)id->driver_data;
+ ddata = devm_kmemdup(&pdev->dev, (void *)id->driver_data,
+ sizeof(*ddata), GFP_KERNEL);
if (!ddata)
- return -ENODATA;
+ return -ENOMEM;

ddata->dev = &pdev->dev;
ddata->irq = irq;


2020-02-13 15:45:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 39/96] ARC: [plat-axs10x]: Add missing multicast filter number to GMAC node

From: Jose Abreu <[email protected]>

commit 7980dff398f86a618f502378fa27cf7e77449afa upstream.

Add a missing property to GMAC node so that multicast filtering works
correctly.

Fixes: 556cc1c5f528 ("ARC: [axs101] Add support for AXS101 SDP (software development platform)")
Acked-by: Alexey Brodkin <[email protected]>
Signed-off-by: Jose Abreu <[email protected]>
Signed-off-by: Vineet Gupta <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arc/boot/dts/axs10x_mb.dtsi | 1 +
1 file changed, 1 insertion(+)

--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -77,6 +77,7 @@
interrupt-names = "macirq";
phy-mode = "rgmii";
snps,pbl = < 32 >;
+ snps,multicast-filter-bins = <256>;
clocks = <&apbclk>;
clock-names = "stmmaceth";
max-speed = <100>;


2020-02-13 15:46:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 52/96] soc: qcom: rpmhpd: Set active_only for active only power domains

From: Douglas Anderson <[email protected]>

commit 5d0d4d42bed0090d3139e7c5ca1587d76d48add6 upstream.

The 'active_only' attribute was accidentally never set to true for any
power domains meaning that all the code handling this attribute was
dead.

NOTE that the RPM power domain code (as opposed to the RPMh one) gets
this right.

Acked-by: Rajendra Nayak <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver")
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/soc/qcom/rpmhpd.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -93,6 +93,7 @@ static struct rpmhpd sdm845_mx = {

static struct rpmhpd sdm845_mx_ao = {
.pd = { .name = "mx_ao", },
+ .active_only = true,
.peer = &sdm845_mx,
.res_name = "mx.lvl",
};
@@ -107,6 +108,7 @@ static struct rpmhpd sdm845_cx = {

static struct rpmhpd sdm845_cx_ao = {
.pd = { .name = "cx_ao", },
+ .active_only = true,
.peer = &sdm845_cx,
.parent = &sdm845_mx_ao.pd,
.res_name = "cx.lvl",


2020-02-13 15:46:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 38/96] watchdog: qcom: Use platform_get_irq_optional() for bark irq

From: Sai Prakash Ranjan <[email protected]>

commit e0b4f4e0cf7fa9d62628d4249c765ec18dffd143 upstream.

platform_get_irq() prints an error message when the interrupt
is not available. So on platforms where bark interrupt is
not specified, following error message is observed on SDM845.

[ 2.975888] qcom_wdt 17980000.watchdog: IRQ index 0 not found

This is also seen on SC7180, SM8150 SoCs as well.
Fix this by using platform_get_irq_optional() instead.

Fixes: 36375491a4395654 ("watchdog: qcom: support pre-timeout when the bark irq is available")
Signed-off-by: Sai Prakash Ranjan <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Wim Van Sebroeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/watchdog/qcom-wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/watchdog/qcom-wdt.c
+++ b/drivers/watchdog/qcom-wdt.c
@@ -246,7 +246,7 @@ static int qcom_wdt_probe(struct platfor
}

/* check if there is pretimeout support */
- irq = platform_get_irq(pdev, 0);
+ irq = platform_get_irq_optional(pdev, 0);
if (irq > 0) {
ret = devm_request_irq(dev, irq, qcom_wdt_isr,
IRQF_TRIGGER_RISING,


2020-02-13 15:46:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 69/96] KVM: arm: Fix DFSR setting for non-LPAE aarch32 guests

From: James Morse <[email protected]>

commit 018f22f95e8a6c3e27188b7317ef2c70a34cb2cd upstream.

Beata reports that KVM_SET_VCPU_EVENTS doesn't inject the expected
exception to a non-LPAE aarch32 guest.

The host intends to inject DFSR.FS=0x14 "IMPLEMENTATION DEFINED fault
(Lockdown fault)", but the guest receives DFSR.FS=0x04 "Fault on
instruction cache maintenance". This fault is hooked by
do_translation_fault() since ARMv6, which goes on to silently 'handle'
the exception, and restart the faulting instruction.

It turns out, when TTBCR.EAE is clear DFSR is split, and FS[4] has
to shuffle up to DFSR[10].

As KVM only does this in one place, fix up the static values. We
now get the expected:
| Unhandled fault: lock abort (0x404) at 0x9c800f00

Fixes: 74a64a981662a ("KVM: arm/arm64: Unify 32bit fault injection")
Reported-by: Beata Michalska <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/aarch32.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/virt/kvm/arm/aarch32.c
+++ b/virt/kvm/arm/aarch32.c
@@ -181,10 +181,12 @@ static void inject_abt32(struct kvm_vcpu

/* Give the guest an IMPLEMENTATION DEFINED exception */
is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
- if (is_lpae)
+ if (is_lpae) {
*fsr = 1 << 9 | 0x34;
- else
- *fsr = 0x14;
+ } else {
+ /* Surprise! DFSR's FS[4] lives in bit 10 */
+ *fsr = BIT(10) | 0x4; /* 0x14 */
+ }
}

void kvm_inject_dabt32(struct kvm_vcpu *vcpu, unsigned long addr)


2020-02-13 15:46:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 49/96] ARM: dts: at91: sama5d3: fix maximum peripheral clock rates

From: Alexandre Belloni <[email protected]>

commit ee0aa926ddb0bd8ba59e33e3803b3b5804e3f5da upstream.

Currently the maximum rate for peripheral clock is calculated based on a
typical 133MHz MCK. The maximum frequency is defined in the datasheet as a
ratio to MCK. Some sama5d3 platforms are using a 166MHz MCK. Update the
device trees to match the maximum rate based on 166MHz.

Reported-by: Karl Rudbæk Olsen <[email protected]>
Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/sama5d3.dtsi | 28 ++++++++++++++--------------
arch/arm/boot/dts/sama5d3_can.dtsi | 4 ++--
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
3 files changed, 18 insertions(+), 18 deletions(-)

--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1188,49 +1188,49 @@
usart0_clk: usart0_clk {
#clock-cells = <0>;
reg = <12>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

usart1_clk: usart1_clk {
#clock-cells = <0>;
reg = <13>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

usart2_clk: usart2_clk {
#clock-cells = <0>;
reg = <14>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

usart3_clk: usart3_clk {
#clock-cells = <0>;
reg = <15>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

uart0_clk: uart0_clk {
#clock-cells = <0>;
reg = <16>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

twi0_clk: twi0_clk {
reg = <18>;
#clock-cells = <0>;
- atmel,clk-output-range = <0 16625000>;
+ atmel,clk-output-range = <0 41500000>;
};

twi1_clk: twi1_clk {
#clock-cells = <0>;
reg = <19>;
- atmel,clk-output-range = <0 16625000>;
+ atmel,clk-output-range = <0 41500000>;
};

twi2_clk: twi2_clk {
#clock-cells = <0>;
reg = <20>;
- atmel,clk-output-range = <0 16625000>;
+ atmel,clk-output-range = <0 41500000>;
};

mci0_clk: mci0_clk {
@@ -1246,19 +1246,19 @@
spi0_clk: spi0_clk {
#clock-cells = <0>;
reg = <24>;
- atmel,clk-output-range = <0 133000000>;
+ atmel,clk-output-range = <0 166000000>;
};

spi1_clk: spi1_clk {
#clock-cells = <0>;
reg = <25>;
- atmel,clk-output-range = <0 133000000>;
+ atmel,clk-output-range = <0 166000000>;
};

tcb0_clk: tcb0_clk {
#clock-cells = <0>;
reg = <26>;
- atmel,clk-output-range = <0 133000000>;
+ atmel,clk-output-range = <0 166000000>;
};

pwm_clk: pwm_clk {
@@ -1269,7 +1269,7 @@
adc_clk: adc_clk {
#clock-cells = <0>;
reg = <29>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

dma0_clk: dma0_clk {
@@ -1300,13 +1300,13 @@
ssc0_clk: ssc0_clk {
#clock-cells = <0>;
reg = <38>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

ssc1_clk: ssc1_clk {
#clock-cells = <0>;
reg = <39>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

sha_clk: sha_clk {
--- a/arch/arm/boot/dts/sama5d3_can.dtsi
+++ b/arch/arm/boot/dts/sama5d3_can.dtsi
@@ -36,13 +36,13 @@
can0_clk: can0_clk {
#clock-cells = <0>;
reg = <40>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

can1_clk: can1_clk {
#clock-cells = <0>;
reg = <41>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
};
};
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -41,13 +41,13 @@
uart0_clk: uart0_clk {
#clock-cells = <0>;
reg = <16>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};

uart1_clk: uart1_clk {
#clock-cells = <0>;
reg = <17>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
};
};


2020-02-13 15:46:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 50/96] ARM: dts: at91: sama5d3: define clock rate range for tcb1

From: Alexandre Belloni <[email protected]>

commit a7e0f3fc01df4b1b7077df777c37feae8c9e8b6d upstream.

The clock rate range for the TCB1 clock is missing. define it in the device
tree.

Reported-by: Karl Rudbæk Olsen <[email protected]>
Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/sama5d3_tcb1.dtsi | 1 +
1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/sama5d3_tcb1.dtsi
+++ b/arch/arm/boot/dts/sama5d3_tcb1.dtsi
@@ -22,6 +22,7 @@
tcb1_clk: tcb1_clk {
#clock-cells = <0>;
reg = <27>;
+ atmel,clk-output-range = <0 166000000>;
};
};
};


2020-02-13 15:46:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 47/96] ARM: dts: meson8: use the actual frequency for the GPUs 182.1MHz OPP

From: Martin Blumenstingl <[email protected]>

commit fe634a7a9a57fb736e39fb71aa9adc6448a90f94 upstream.

The clock setup on Meson8 cannot achieve a Mali frequency of exactly
182.15MHz. The vendor driver uses "FCLK_DIV7 / 2" for this frequency,
which translates to 2550MHz / 7 / 2 = 182142857Hz.
Update the GPU operating point to that specific frequency to not confuse
myself when comparing the frequency from the .dts with the actual clock
rate on the system.

Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/meson8.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -129,8 +129,8 @@
gpu_opp_table: gpu-opp-table {
compatible = "operating-points-v2";

- opp-182150000 {
- opp-hz = /bits/ 64 <182150000>;
+ opp-182142857 {
+ opp-hz = /bits/ 64 <182142857>;
opp-microvolt = <1150000>;
};
opp-318750000 {


2020-02-13 15:46:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 51/96] tools/power/acpi: fix compilation error

From: Zhengyuan Liu <[email protected]>

commit 1985f8c7f9a42a651a9750d6fcadc74336d182df upstream.

If we compile tools/acpi target in the top source directory, we'd get a
compilation error showing as bellow:

# make tools/acpi
DESCEND power/acpi
DESCEND tools/acpidbg
CC tools/acpidbg/acpidbg.o
Assembler messages:
Fatal error: can't create /home/lzy/kernel-upstream/power/acpi/\
tools/acpidbg/acpidbg.o: No such file or directory
../../Makefile.rules:26: recipe for target '/home/lzy/kernel-upstream/\
power/acpi/tools/acpidbg/acpidbg.o' failed
make[3]: *** [/home/lzy/kernel-upstream//power/acpi/tools/acpidbg/\
acpidbg.o] Error 1
Makefile:19: recipe for target 'acpidbg' failed
make[2]: *** [acpidbg] Error 2
Makefile:54: recipe for target 'acpi' failed
make[1]: *** [acpi] Error 2
Makefile:1607: recipe for target 'tools/acpi' failed
make: *** [tools/acpi] Error 2

Fixes: d5a4b1a540b8 ("tools/power/acpi: Remove direct kernel source include reference")
Signed-off-by: Zhengyuan Liu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/power/acpi/Makefile.config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/power/acpi/Makefile.config
+++ b/tools/power/acpi/Makefile.config
@@ -15,7 +15,7 @@ include $(srctree)/../../scripts/Makefil

OUTPUT=$(srctree)/
ifeq ("$(origin O)", "command line")
- OUTPUT := $(O)/power/acpi/
+ OUTPUT := $(O)/tools/power/acpi/
endif
#$(info Determined 'OUTPUT' to be $(OUTPUT))



2020-02-13 15:46:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 23/96] bpf, sockhash: Synchronize_rcu before freeing map

From: Jakub Sitnicki <[email protected]>

commit 0b2dc83906cf1e694e48003eae5df8fa63f76fd9 upstream.

We need to have a synchronize_rcu before free'ing the sockhash because any
outstanding psock references will have a pointer to the map and when they
use it, this could trigger a use after free.

This is a sister fix for sockhash, following commit 2bb90e5cc90e ("bpf:
sockmap, synchronize_rcu before free'ing map") which addressed sockmap,
which comes from a manual audit.

Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Jakub Sitnicki <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: John Fastabend <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/core/sock_map.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -250,6 +250,7 @@ static void sock_map_free(struct bpf_map
}
raw_spin_unlock_bh(&stab->lock);

+ /* wait for psock readers accessing its map link */
synchronize_rcu();

bpf_map_area_free(stab->sks);
@@ -873,6 +874,9 @@ static void sock_hash_free(struct bpf_ma
raw_spin_unlock_bh(&bucket->lock);
}

+ /* wait for psock readers accessing its map link */
+ synchronize_rcu();
+
bpf_map_area_free(htab->buckets);
kfree(htab);
}


2020-02-13 15:46:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 19/96] PCI/AER: Initialize aer_fifo

From: Dongdong Liu <[email protected]>

commit d95f20c4f07020ebc605f3b46af4b6db9eb5fc99 upstream.

Previously we did not call INIT_KFIFO() for aer_fifo. This leads to
kfifo_put() sometimes returning 0 (queue full) when in fact it is not.

It is easy to reproduce the problem by using aer-inject:

$ aer-inject -s :82:00.0 multiple-corr-nonfatal

The content of the multiple-corr-nonfatal file is as below:

AER
COR RCVR
HL 0 1 2 3
AER
UNCOR POISON_TLP
HL 4 5 6 7

Fixes: 27c1ce8bbed7 ("PCI/AER: Use kfifo for tracking events instead of reimplementing it")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dongdong Liu <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/pcie/aer.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1387,6 +1387,7 @@ static int aer_probe(struct pcie_device
return -ENOMEM;

rpc->rpd = port;
+ INIT_KFIFO(rpc->aer_fifo);
set_service_data(dev, rpc);

status = devm_request_threaded_irq(device, dev->irq, aer_irq, aer_isr,


2020-02-13 15:47:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 31/96] NFSv4: pnfs_roc() must use cred_fscmp() to compare creds

From: Trond Myklebust <[email protected]>

commit 387122478775be5d9816c34aa29de53d0b926835 upstream.

When comparing two 'struct cred' for equality w.r.t. behaviour under
filesystem access, we need to use cred_fscmp().

Fixes: a52458b48af1 ("NFS/NFSD/SUNRPC: replace generic creds with 'struct cred'.")
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/pnfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1425,7 +1425,7 @@ retry:
/* lo ref dropped in pnfs_roc_release() */
layoutreturn = pnfs_prepare_layoutreturn(lo, &stateid, &iomode);
/* If the creds don't match, we can't compound the layoutreturn */
- if (!layoutreturn || cred != lo->plh_lc_cred)
+ if (!layoutreturn || cred_fscmp(cred, lo->plh_lc_cred) != 0)
goto out_noroc;

roc = layoutreturn;


2020-02-13 15:47:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 34/96] x86/boot: Handle malformed SRAT tables during early ACPI parsing

From: Steven Clarkson <[email protected]>

[ Upstream commit 2b73ea3796242608b4ccf019ff217156c92e92fe ]

Break an infinite loop when early parsing of the SRAT table is caused
by a subtable with zero length. Known to affect the ASUS WS X299 SAGE
motherboard with firmware version 1201 which has a large block of
zeros in its SRAT table. The kernel could boot successfully on this
board/firmware prior to the introduction of early parsing this table or
after a BIOS update.

[ bp: Fixup whitespace damage and commit message. Make it return 0 to
denote that there are no immovable regions because who knows what
else is broken in this BIOS. ]

Fixes: 02a3e3cdb7f1 ("x86/boot: Parse SRAT table and count immovable memory regions")
Signed-off-by: Steven Clarkson <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: [email protected]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206343
Link: https://lkml.kernel.org/r/CAHKq8taGzj0u1E_i=poHUam60Bko5BpiJ9jn0fAupFUYexvdUQ@mail.gmail.com
Signed-off-by: Sasha Levin <[email protected]>
---
arch/x86/boot/compressed/acpi.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
index 25019d42ae937..ef2ad7253cd5e 100644
--- a/arch/x86/boot/compressed/acpi.c
+++ b/arch/x86/boot/compressed/acpi.c
@@ -393,7 +393,13 @@ int count_immovable_mem_regions(void)
table = table_addr + sizeof(struct acpi_table_srat);

while (table + sizeof(struct acpi_subtable_header) < table_end) {
+
sub_table = (struct acpi_subtable_header *)table;
+ if (!sub_table->length) {
+ debug_putstr("Invalid zero length SRAT subtable.\n");
+ return 0;
+ }
+
if (sub_table->type == ACPI_SRAT_TYPE_MEMORY_AFFINITY) {
struct acpi_srat_mem_affinity *ma;

--
2.20.1



2020-02-13 15:47:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 37/96] rtc: cmos: Stop using shared IRQ

From: Andy Shevchenko <[email protected]>

commit b6da197a2e9670df6f07e6698629e9ce95ab614e upstream.

As reported by Guilherme G. Piccoli:

---8<---8<---8<---

The rtc-cmos interrupt setting was changed in the commit 079062b28fb4
("rtc: cmos: prevent kernel warning on IRQ flags mismatch") in order
to allow shared interrupts; according to that commit's description,
some machine got kernel warnings due to the interrupt line being shared
between rtc-cmos and other hardware, and rtc-cmos didn't allow IRQ sharing
that time.

After the aforementioned commit though it was observed a huge increase
in lost HPET interrupts in some systems, observed through the following
kernel message:

[...] hpet1: lost 35 rtc interrupts

After investigation, it was narrowed down to the shared interrupts
usage when having the kernel option "irqpoll" enabled. In this case,
all IRQ handlers are called for non-timer interrupts, if such handlers
are setup in shared IRQ lines. The rtc-cmos IRQ handler could be set to
hpet_rtc_interrupt(), which will produce the kernel "lost interrupts"
message after doing work - lots of readl/writel to HPET registers, which
are known to be slow.

Although "irqpoll" is not a default kernel option, it's used in some contexts,
one being the kdump kernel (which is an already "impaired" kernel usually
running with 1 CPU available), so the performance burden could be considerable.
Also, the same issue would happen (in a shorter extent though) when using
"irqfixup" kernel option.

In a quick experiment, a virtual machine with uptime of 2 minutes produced
>300 calls to hpet_rtc_interrupt() when "irqpoll" was set, whereas without
sharing interrupts this number reduced to 1 interrupt. Machines with more
hardware than a VM should generate even more unnecessary HPET interrupts
in this scenario.

---8<---8<---8<---

After looking into the rtc-cmos driver history and DSDT table from
the Microsoft Surface 3, we may notice that Hans de Goede submitted
a correct fix (see dependency below). Thus, we simply revert
the culprit commit.

Fixes: 079062b28fb4 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch")
Depends-on: a1e23a42f1bd ("rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs")
Reported-by: Guilherme G. Piccoli <[email protected]>
Cc: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Tested-by: Guilherme G. Piccoli <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/rtc/rtc-cmos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -850,7 +850,7 @@ cmos_do_probe(struct device *dev, struct
rtc_cmos_int_handler = cmos_interrupt;

retval = request_irq(rtc_irq, rtc_cmos_int_handler,
- IRQF_SHARED, dev_name(&cmos_rtc.rtc->dev),
+ 0, dev_name(&cmos_rtc.rtc->dev),
cmos_rtc.rtc);
if (retval < 0) {
dev_dbg(dev, "IRQ %d is already in use\n", rtc_irq);


2020-02-13 15:47:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 28/96] NFS: Revalidate the file size on a fatal write error

From: Trond Myklebust <[email protected]>

commit 0df68ced55443243951d02cc497be31fadf28173 upstream.

If we suffer a fatal error upon writing a file, which causes us to
need to revalidate the entire mapping, then we should also revalidate
the file size.

Fixes: d2ceb7e57086 ("NFS: Don't use page_file_mapping after removing the page")
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/write.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -243,7 +243,15 @@ out:
/* A writeback failed: mark the page as bad, and invalidate the page cache */
static void nfs_set_pageerror(struct address_space *mapping)
{
+ struct inode *inode = mapping->host;
+
nfs_zap_mapping(mapping->host, mapping);
+ /* Force file size revalidation */
+ spin_lock(&inode->i_lock);
+ NFS_I(inode)->cache_validity |= NFS_INO_REVAL_FORCED |
+ NFS_INO_REVAL_PAGECACHE |
+ NFS_INO_INVALID_SIZE;
+ spin_unlock(&inode->i_lock);
}

static void nfs_mapping_set_error(struct page *page, int error)


2020-02-13 15:47:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 46/96] arm64: dts: marvell: clearfog-gt-8k: fix switch cpu port node

From: Baruch Siach <[email protected]>

commit 62bba54d99407aedfe9b0a02e72e23c06e2b0116 upstream.

Explicitly set the switch cpu (upstream) port phy-mode and managed
properties. This fixes the Marvell 88E6141 switch serdes configuration
with the recently enabled phylink layer.

Fixes: a6120833272c ("arm64: dts: add support for SolidRun Clearfog GT 8K")
Reported-by: Denis Odintsov <[email protected]>
Signed-off-by: Baruch Siach <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-clearfog-gt-8k.dts
@@ -408,6 +408,8 @@
reg = <5>;
label = "cpu";
ethernet = <&cp1_eth2>;
+ phy-mode = "2500base-x";
+ managed = "in-band-status";
};
};



2020-02-13 15:47:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 06/96] RDMA/netlink: Do not always generate an ACK for some netlink operations

From: Håkon Bugge <[email protected]>

commit a242c36951ecd24bc16086940dbe6b522205c461 upstream.

In rdma_nl_rcv_skb(), the local variable err is assigned the return value
of the supplied callback function, which could be one of
ib_nl_handle_resolve_resp(), ib_nl_handle_set_timeout(), or
ib_nl_handle_ip_res_resp(). These three functions all return skb->len on
success.

rdma_nl_rcv_skb() is merely a copy of netlink_rcv_skb(). The callback
functions used by the latter have the convention: "Returns 0 on success or
a negative error code".

In particular, the statement (equal for both functions):

if (nlh->nlmsg_flags & NLM_F_ACK || err)

implies that rdma_nl_rcv_skb() always will ack a message, independent of
the NLM_F_ACK being set in nlmsg_flags or not.

The fix could be to change the above statement, but it is better to keep
the two *_rcv_skb() functions equal in this respect and instead change the
three callback functions in the rdma subsystem to the correct convention.

Fixes: 2ca546b92a02 ("IB/sa: Route SA pathrecord query through netlink")
Fixes: ae43f8286730 ("IB/core: Add IP to GID netlink offload")
Link: https://lore.kernel.org/r/[email protected]
Suggested-by: Mark Haywood <[email protected]>
Signed-off-by: Håkon Bugge <[email protected]>
Tested-by: Mark Haywood <[email protected]>
Reviewed-by: Leon Romanovsky <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/addr.c | 2 +-
drivers/infiniband/core/sa_query.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -139,7 +139,7 @@ int ib_nl_handle_ip_res_resp(struct sk_b
if (ib_nl_is_good_ip_resp(nlh))
ib_nl_process_good_ip_rsep(nlh);

- return skb->len;
+ return 0;
}

static int ib_nl_ip_send_msg(struct rdma_dev_addr *dev_addr,
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -1068,7 +1068,7 @@ int ib_nl_handle_set_timeout(struct sk_b
}

settimeout_out:
- return skb->len;
+ return 0;
}

static inline int ib_nl_is_good_resolve_resp(const struct nlmsghdr *nlh)
@@ -1139,7 +1139,7 @@ int ib_nl_handle_resolve_resp(struct sk_
}

resp_out:
- return skb->len;
+ return 0;
}

static void free_sm_ah(struct kref *kref)


2020-02-13 15:47:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 21/96] bpftool: Dont crash on missing xlated program instructions

From: Toke Høiland-Jørgensen <[email protected]>

commit d95f1e8b462c4372ac409886070bb8719d8a4d3a upstream.

Turns out the xlated program instructions can also be missing if
kptr_restrict sysctl is set. This means that the previous fix to check the
jited_prog_insns pointer was insufficient; add another check of the
xlated_prog_insns pointer as well.

Fixes: 5b79bcdf0362 ("bpftool: Don't crash on missing jited insns or ksyms")
Fixes: cae73f233923 ("bpftool: use bpf_program__get_prog_info_linear() in prog.c:do_dump()")
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Reviewed-by: Quentin Monnet <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/bpf/bpftool/prog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -500,7 +500,7 @@ static int do_dump(int argc, char **argv
buf = (unsigned char *)(info->jited_prog_insns);
member_len = info->jited_prog_len;
} else { /* DUMP_XLATED */
- if (info->xlated_prog_len == 0) {
+ if (info->xlated_prog_len == 0 || !info->xlated_prog_insns) {
p_err("error retrieving insn dump: kernel.kptr_restrict set?");
goto err_free;
}


2020-02-13 15:47:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 04/96] IB/srp: Never use immediate data if it is disabled by a user

From: Sergey Gorenko <[email protected]>

commit 0fbb37dd82998b5c83355997b3bdba2806968ac7 upstream.

Some SRP targets that do not support specification SRP-2, put the garbage
to the reserved bits of the SRP login response. The problem was not
detected for a long time because the SRP initiator ignored those bits. But
now one of them is used as SRP_LOGIN_RSP_IMMED_SUPP. And it causes a
critical error on the target when the initiator sends immediate data.

The ib_srp module has a use_imm_date parameter to enable or disable
immediate data manually. But it does not help in the above case, because
use_imm_date is ignored at handling the SRP login response. The problem is
definitely caused by a bug on the target side, but the initiator's
behavior also does not look correct. The initiator should not use
immediate data if use_imm_date is disabled by a user.

This commit adds an additional checking of use_imm_date at the handling of
SRP login response to avoid unexpected use of immediate data.

Fixes: 882981f4a411 ("RDMA/srp: Add support for immediate data")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sergey Gorenko <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/ulp/srp/ib_srp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2536,7 +2536,8 @@ static void srp_cm_rep_handler(struct ib
if (lrsp->opcode == SRP_LOGIN_RSP) {
ch->max_ti_iu_len = be32_to_cpu(lrsp->max_ti_iu_len);
ch->req_lim = be32_to_cpu(lrsp->req_lim_delta);
- ch->use_imm_data = lrsp->rsp_flags & SRP_LOGIN_RSP_IMMED_SUPP;
+ ch->use_imm_data = srp_use_imm_data &&
+ (lrsp->rsp_flags & SRP_LOGIN_RSP_IMMED_SUPP);
ch->max_it_iu_len = srp_max_it_iu_len(target->cmd_sg_cnt,
ch->use_imm_data);
WARN_ON_ONCE(ch->max_it_iu_len >


2020-02-13 15:48:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 33/96] NFSv4.0: nfs4_do_fsinfo() should not do implicit lease renewals

From: Robert Milkowski <[email protected]>

commit 7dc2993a9e51dd2eee955944efec65bef90265b7 upstream.

Currently, each time nfs4_do_fsinfo() is called it will do an implicit
NFS4 lease renewal, which is not compliant with the NFS4 specification.
This can result in a lease being expired by an NFS server.

Commit 83ca7f5ab31f ("NFS: Avoid PUTROOTFH when managing leases")
introduced implicit client lease renewal in nfs4_do_fsinfo(),
which can result in the NFSv4.0 lease to expire on a server side,
and servers returning NFS4ERR_EXPIRED or NFS4ERR_STALE_CLIENTID.

This can easily be reproduced by frequently unmounting a sub-mount,
then stat'ing it to get it mounted again, which will delay or even
completely prevent client from sending RENEW operations if no other
NFS operations are issued. Eventually nfs server will expire client's
lease and return an error on file access or next RENEW.

This can also happen when a sub-mount is automatically unmounted
due to inactivity (after nfs_mountpoint_expiry_timeout), then it is
mounted again via stat(). This can result in a short window during
which client's lease will expire on a server but not on a client.
This specific case was observed on production systems.

This patch removes the implicit lease renewal from nfs4_do_fsinfo().

Fixes: 83ca7f5ab31f ("NFS: Avoid PUTROOTFH when managing leases")
Signed-off-by: Robert Milkowski <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/nfs4_fs.h | 4 +---
fs/nfs/nfs4proc.c | 12 ++++++++----
fs/nfs/nfs4renewd.c | 5 +----
fs/nfs/nfs4state.c | 4 +---
4 files changed, 11 insertions(+), 14 deletions(-)

--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -439,9 +439,7 @@ extern void nfs4_schedule_state_renewal(
extern void nfs4_renewd_prepare_shutdown(struct nfs_server *);
extern void nfs4_kill_renewd(struct nfs_client *);
extern void nfs4_renew_state(struct work_struct *);
-extern void nfs4_set_lease_period(struct nfs_client *clp,
- unsigned long lease,
- unsigned long lastrenewed);
+extern void nfs4_set_lease_period(struct nfs_client *clp, unsigned long lease);


/* nfs4state.c */
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5024,16 +5024,13 @@ static int nfs4_do_fsinfo(struct nfs_ser
struct nfs4_exception exception = {
.interruptible = true,
};
- unsigned long now = jiffies;
int err;

do {
err = _nfs4_do_fsinfo(server, fhandle, fsinfo);
trace_nfs4_fsinfo(server, fhandle, fsinfo->fattr, err);
if (err == 0) {
- nfs4_set_lease_period(server->nfs_client,
- fsinfo->lease_time * HZ,
- now);
+ nfs4_set_lease_period(server->nfs_client, fsinfo->lease_time * HZ);
break;
}
err = nfs4_handle_exception(server, err, &exception);
@@ -6089,6 +6086,7 @@ int nfs4_proc_setclientid(struct nfs_cli
.callback_data = &setclientid,
.flags = RPC_TASK_TIMEOUT | RPC_TASK_NO_ROUND_ROBIN,
};
+ unsigned long now = jiffies;
int status;

/* nfs_client_id4 */
@@ -6121,6 +6119,9 @@ int nfs4_proc_setclientid(struct nfs_cli
clp->cl_acceptor = rpcauth_stringify_acceptor(setclientid.sc_cred);
put_rpccred(setclientid.sc_cred);
}
+
+ if (status == 0)
+ do_renew_lease(clp, now);
out:
trace_nfs4_setclientid(clp, status);
dprintk("NFS reply setclientid: %d\n", status);
@@ -8204,6 +8205,7 @@ static int _nfs4_proc_exchange_id(struct
struct rpc_task *task;
struct nfs41_exchange_id_args *argp;
struct nfs41_exchange_id_res *resp;
+ unsigned long now = jiffies;
int status;

task = nfs4_run_exchange_id(clp, cred, sp4_how, NULL);
@@ -8224,6 +8226,8 @@ static int _nfs4_proc_exchange_id(struct
if (status != 0)
goto out;

+ do_renew_lease(clp, now);
+
clp->cl_clientid = resp->clientid;
clp->cl_exchange_flags = resp->flags;
clp->cl_seqid = resp->seqid;
--- a/fs/nfs/nfs4renewd.c
+++ b/fs/nfs/nfs4renewd.c
@@ -138,15 +138,12 @@ nfs4_kill_renewd(struct nfs_client *clp)
*
* @clp: pointer to nfs_client
* @lease: new value for lease period
- * @lastrenewed: time at which lease was last renewed
*/
void nfs4_set_lease_period(struct nfs_client *clp,
- unsigned long lease,
- unsigned long lastrenewed)
+ unsigned long lease)
{
spin_lock(&clp->cl_lock);
clp->cl_lease_time = lease;
- clp->cl_last_renewal = lastrenewed;
spin_unlock(&clp->cl_lock);

/* Cap maximum reconnect timeout at 1/2 lease period */
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -91,17 +91,15 @@ static int nfs4_setup_state_renewal(stru
{
int status;
struct nfs_fsinfo fsinfo;
- unsigned long now;

if (!test_bit(NFS_CS_CHECK_LEASE_TIME, &clp->cl_res_state)) {
nfs4_schedule_state_renewal(clp);
return 0;
}

- now = jiffies;
status = nfs4_proc_get_lease_time(clp, &fsinfo);
if (status == 0) {
- nfs4_set_lease_period(clp, fsinfo.lease_time * HZ, now);
+ nfs4_set_lease_period(clp, fsinfo.lease_time * HZ);
nfs4_schedule_state_renewal(clp);
}



2020-02-13 15:48:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 12/96] scsi: ufs: Fix ufshcd_probe_hba() reture value in case ufshcd_scsi_add_wlus() fails

From: Bean Huo <[email protected]>

commit b9fc5320212efdfb4e08b825aaa007815fd11d16 upstream.

A non-zero error value likely being returned by ufshcd_scsi_add_wlus() in
case of failure of adding the WLs, but ufshcd_probe_hba() doesn't use this
value, and doesn't report this failure to upper caller. This patch is to
fix this issue.

Fixes: 2a8fa600445c ("ufs: manually add well known logical units")
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Asutosh Das <[email protected]>
Reviewed-by: Alim Akhtar <[email protected]>
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Bean Huo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/ufs/ufshcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6953,7 +6953,8 @@ static int ufshcd_probe_hba(struct ufs_h
ufshcd_init_icc_levels(hba);

/* Add required well known logical units to scsi mid layer */
- if (ufshcd_scsi_add_wlus(hba))
+ ret = ufshcd_scsi_add_wlus(hba);
+ if (ret)
goto out;

/* Initialize devfreq after UFS device is detected */


2020-02-13 15:48:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 11/96] RDMA/umem: Fix ib_umem_find_best_pgsz()

From: Artemy Kovalyov <[email protected]>

commit 36798d5ae1af62e830c5e045b2e41ce038690c61 upstream.

Except for the last entry, the ending iova alignment sets the maximum
possible page size as the low bits of the iova must be zero when starting
the next chunk.

Fixes: 4a35339958f1 ("RDMA/umem: Add API to find best driver supported page size in an MR")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Artemy Kovalyov <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Tested-by: Gal Pressman <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/umem.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -166,10 +166,13 @@ unsigned long ib_umem_find_best_pgsz(str
* for any address.
*/
mask |= (sg_dma_address(sg) + pgoff) ^ va;
- if (i && i != (umem->nmap - 1))
- /* restrict by length as well for interior SGEs */
- mask |= sg_dma_len(sg);
va += sg_dma_len(sg) - pgoff;
+ /* Except for the last entry, the ending iova alignment sets
+ * the maximum possible page size as the low bits of the iova
+ * must be zero when starting the next chunk.
+ */
+ if (i != (umem->nmap - 1))
+ mask |= va;
pgoff = 0;
}
best_pg_bit = rdma_find_pg_bit(mask, pgsz_bitmap);


2020-02-13 15:48:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 03/96] IB/mlx4: Fix memory leak in add_gid error flow

From: Jack Morgenstein <[email protected]>

commit eaad647e5cc27f7b46a27f3b85b14c4c8a64bffa upstream.

In procedure mlx4_ib_add_gid(), if the driver is unable to update the FW
gid table, there is a memory leak in the driver's copy of the gid table:
the gid entry's context buffer is not freed.

If such an error occurs, free the entry's context buffer, and mark the
entry as available (by setting its context pointer to NULL).

Fixes: e26be1bfef81 ("IB/mlx4: Implement ib_device callbacks")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jack Morgenstein <[email protected]>
Reviewed-by: Parav Pandit <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/hw/mlx4/main.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -246,6 +246,13 @@ static int mlx4_ib_update_gids(struct gi
return mlx4_ib_update_gids_v1(gids, ibdev, port_num);
}

+static void free_gid_entry(struct gid_entry *entry)
+{
+ memset(&entry->gid, 0, sizeof(entry->gid));
+ kfree(entry->ctx);
+ entry->ctx = NULL;
+}
+
static int mlx4_ib_add_gid(const struct ib_gid_attr *attr, void **context)
{
struct mlx4_ib_dev *ibdev = to_mdev(attr->device);
@@ -306,6 +313,8 @@ static int mlx4_ib_add_gid(const struct
GFP_ATOMIC);
if (!gids) {
ret = -ENOMEM;
+ *context = NULL;
+ free_gid_entry(&port_gid_table->gids[free]);
} else {
for (i = 0; i < MLX4_MAX_PORT_GIDS; i++) {
memcpy(&gids[i].gid, &port_gid_table->gids[i].gid, sizeof(union ib_gid));
@@ -317,6 +326,12 @@ static int mlx4_ib_add_gid(const struct

if (!ret && hw_update) {
ret = mlx4_ib_update_gids(gids, ibdev, attr->port_num);
+ if (ret) {
+ spin_lock_bh(&iboe->lock);
+ *context = NULL;
+ free_gid_entry(&port_gid_table->gids[free]);
+ spin_unlock_bh(&iboe->lock);
+ }
kfree(gids);
}

@@ -346,10 +361,7 @@ static int mlx4_ib_del_gid(const struct
if (!ctx->refcount) {
unsigned int real_index = ctx->real_index;

- memset(&port_gid_table->gids[real_index].gid, 0,
- sizeof(port_gid_table->gids[real_index].gid));
- kfree(port_gid_table->gids[real_index].ctx);
- port_gid_table->gids[real_index].ctx = NULL;
+ free_gid_entry(&port_gid_table->gids[real_index]);
hw_update = 1;
}
}


2020-02-13 15:48:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 10/96] RDMA/cma: Fix unbalanced cm_id reference count during address resolve

From: Parav Pandit <[email protected]>

commit b4fb4cc5ba83b20dae13cef116c33648e81d2f44 upstream.

Below commit missed the AF_IB and loopback code flow in
rdma_resolve_addr(). This leads to an unbalanced cm_id refcount in
cma_work_handler() which puts the refcount which was not incremented prior
to queuing the work.

A call trace is observed with such code flow:

BUG: unable to handle kernel NULL pointer dereference at (null)
[<ffffffff96b67e16>] __mutex_lock_slowpath+0x166/0x1d0
[<ffffffff96b6715f>] mutex_lock+0x1f/0x2f
[<ffffffffc0beabb5>] cma_work_handler+0x25/0xa0
[<ffffffff964b9ebf>] process_one_work+0x17f/0x440
[<ffffffff964baf56>] worker_thread+0x126/0x3c0

Hence, hold the cm_id reference when scheduling the resolve work item.

Fixes: 722c7b2bfead ("RDMA/{cma, core}: Avoid callback on rdma_addr_cancel()")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Parav Pandit <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/cma.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -3091,6 +3091,7 @@ static int cma_resolve_loopback(struct r
rdma_addr_get_sgid(&id_priv->id.route.addr.dev_addr, &gid);
rdma_addr_set_dgid(&id_priv->id.route.addr.dev_addr, &gid);

+ atomic_inc(&id_priv->refcount);
cma_init_resolve_addr_work(work, id_priv);
queue_work(cma_wq, &work->work);
return 0;
@@ -3117,6 +3118,7 @@ static int cma_resolve_ib_addr(struct rd
rdma_addr_set_dgid(&id_priv->id.route.addr.dev_addr, (union ib_gid *)
&(((struct sockaddr_ib *) &id_priv->id.route.addr.dst_addr)->sib_addr));

+ atomic_inc(&id_priv->refcount);
cma_init_resolve_addr_work(work, id_priv);
queue_work(cma_wq, &work->work);
return 0;


2020-02-13 15:48:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 27/96] nfs: NFS_SWAP should depend on SWAP

From: Geert Uytterhoeven <[email protected]>

commit 474c4f306eefbb21b67ebd1de802d005c7d7ecdc upstream.

If CONFIG_SWAP=n, it does not make much sense to offer the user the
option to enable support for swapping over NFS, as that will still fail
at run time:

# swapon /swap
swapon: /swap: swapon failed: Function not implemented

Fix this by adding a dependency on CONFIG_SWAP.

Fixes: a564b8f0398636ba ("nfs: enable swap on NFS")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/Kconfig
+++ b/fs/nfs/Kconfig
@@ -90,7 +90,7 @@ config NFS_V4
config NFS_SWAP
bool "Provide swap over NFS support"
default n
- depends on NFS_FS
+ depends on NFS_FS && SWAP
select SUNRPC_SWAP
help
This option enables swapon to work on files located on NFS mounts.


2020-02-13 15:49:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 14/96] ath10k: pci: Only dump ATH10K_MEM_REGION_TYPE_IOREG when safe

From: Bryan O'Donoghue <[email protected]>

commit d239380196c4e27a26fa4bea73d2bf994c14ec2d upstream.

ath10k_pci_dump_memory_reg() will try to access memory of type
ATH10K_MEM_REGION_TYPE_IOREG however, if a hardware restart is in progress
this can crash a system.

Individual ioread32() time has been observed to jump from 15-20 ticks to >
80k ticks followed by a secure-watchdog bite and a system reset.

Work around this corner case by only issuing the read transaction when the
driver state is ATH10K_STATE_ON.

Tested-on: QCA9988 PCI 10.4-3.9.0.2-00044

Fixes: 219cc084c6706 ("ath10k: add memory dump support QCA9984")
Signed-off-by: Bryan O'Donoghue <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath10k/pci.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1604,11 +1604,22 @@ static int ath10k_pci_dump_memory_reg(st
{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
u32 i;
+ int ret;
+
+ mutex_lock(&ar->conf_mutex);
+ if (ar->state != ATH10K_STATE_ON) {
+ ath10k_warn(ar, "Skipping pci_dump_memory_reg invalid state\n");
+ ret = -EIO;
+ goto done;
+ }

for (i = 0; i < region->len; i += 4)
*(u32 *)(buf + i) = ioread32(ar_pci->mem + region->start + i);

- return region->len;
+ ret = region->len;
+done:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
}

/* if an error happened returns < 0, otherwise the length */
@@ -1704,7 +1715,11 @@ static void ath10k_pci_dump_memory(struc
count = ath10k_pci_dump_memory_sram(ar, current_region, buf);
break;
case ATH10K_MEM_REGION_TYPE_IOREG:
- count = ath10k_pci_dump_memory_reg(ar, current_region, buf);
+ ret = ath10k_pci_dump_memory_reg(ar, current_region, buf);
+ if (ret < 0)
+ break;
+
+ count = ret;
break;
default:
ret = ath10k_pci_dump_memory_generic(ar, current_region, buf);


2020-02-13 15:49:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 01/96] ASoC: pcm: update FE/BE trigger order based on the command

From: Ranjani Sridharan <[email protected]>

[ Upstream commit acbf27746ecfa96b290b54cc7f05273482ea128a ]

Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.

In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.

The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.

Signed-off-by: Ranjani Sridharan <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
sound/soc/soc-pcm.c | 95 ++++++++++++++++++++++++++++++++-------------
1 file changed, 68 insertions(+), 27 deletions(-)

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index d07026a846b9c..8712a91e0e3ea 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2297,42 +2297,81 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream,
}
EXPORT_SYMBOL_GPL(dpcm_be_dai_trigger);

+static int dpcm_dai_trigger_fe_be(struct snd_pcm_substream *substream,
+ int cmd, bool fe_first)
+{
+ struct snd_soc_pcm_runtime *fe = substream->private_data;
+ int ret;
+
+ /* call trigger on the frontend before the backend. */
+ if (fe_first) {
+ dev_dbg(fe->dev, "ASoC: pre trigger FE %s cmd %d\n",
+ fe->dai_link->name, cmd);
+
+ ret = soc_pcm_trigger(substream, cmd);
+ if (ret < 0)
+ return ret;
+
+ ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
+ return ret;
+ }
+
+ /* call trigger on the frontend after the backend. */
+ ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
+ if (ret < 0)
+ return ret;
+
+ dev_dbg(fe->dev, "ASoC: post trigger FE %s cmd %d\n",
+ fe->dai_link->name, cmd);
+
+ ret = soc_pcm_trigger(substream, cmd);
+
+ return ret;
+}
+
static int dpcm_fe_dai_do_trigger(struct snd_pcm_substream *substream, int cmd)
{
struct snd_soc_pcm_runtime *fe = substream->private_data;
- int stream = substream->stream, ret;
+ int stream = substream->stream;
+ int ret = 0;
enum snd_soc_dpcm_trigger trigger = fe->dai_link->trigger[stream];

fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;

switch (trigger) {
case SND_SOC_DPCM_TRIGGER_PRE:
- /* call trigger on the frontend before the backend. */
-
- dev_dbg(fe->dev, "ASoC: pre trigger FE %s cmd %d\n",
- fe->dai_link->name, cmd);
-
- ret = soc_pcm_trigger(substream, cmd);
- if (ret < 0) {
- dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
- goto out;
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ ret = dpcm_dai_trigger_fe_be(substream, cmd, true);
+ break;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ ret = dpcm_dai_trigger_fe_be(substream, cmd, false);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
}
-
- ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
break;
case SND_SOC_DPCM_TRIGGER_POST:
- /* call trigger on the frontend after the backend. */
-
- ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
- if (ret < 0) {
- dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
- goto out;
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ ret = dpcm_dai_trigger_fe_be(substream, cmd, false);
+ break;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ ret = dpcm_dai_trigger_fe_be(substream, cmd, true);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
}
-
- dev_dbg(fe->dev, "ASoC: post trigger FE %s cmd %d\n",
- fe->dai_link->name, cmd);
-
- ret = soc_pcm_trigger(substream, cmd);
break;
case SND_SOC_DPCM_TRIGGER_BESPOKE:
/* bespoke trigger() - handles both FE and BEs */
@@ -2341,10 +2380,6 @@ static int dpcm_fe_dai_do_trigger(struct snd_pcm_substream *substream, int cmd)
fe->dai_link->name, cmd);

ret = soc_pcm_bespoke_trigger(substream, cmd);
- if (ret < 0) {
- dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
- goto out;
- }
break;
default:
dev_err(fe->dev, "ASoC: invalid trigger cmd %d for %s\n", cmd,
@@ -2353,6 +2388,12 @@ static int dpcm_fe_dai_do_trigger(struct snd_pcm_substream *substream, int cmd)
goto out;
}

+ if (ret < 0) {
+ dev_err(fe->dev, "ASoC: trigger FE cmd: %d failed: %d\n",
+ cmd, ret);
+ goto out;
+ }
+
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
--
2.20.1



2020-02-13 16:01:03

by Stephen Smalley

[permalink] [raw]
Subject: Re: [PATCH 5.4 85/96] selinux: revert "stop passing MAY_NOT_BLOCK to the AVC upon follow_link"

On 2/13/20 10:21 AM, Greg Kroah-Hartman wrote:
> From: Stephen Smalley <[email protected]>
>
> commit 1a37079c236d55fb31ebbf4b59945dab8ec8764c upstream.
>
> This reverts commit e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK
> to the AVC upon follow_link"). The correct fix is to instead fall
> back to ref-walk if audit is required irrespective of the specific
> audit data type. This is done in the next commit.
>
> Fixes: e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link")
> Reported-by: Will Deacon <[email protected]>
> Signed-off-by: Stephen Smalley <[email protected]>
> Signed-off-by: Paul Moore <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>

This patch should be accompanied by commit
0188d5c025ca8fe756ba3193bd7d150139af5a88 ("selinux: fall back to
ref-walk if audit is required"). The former is reverting an incorrect
fix for bda0be7ad994 ("security: make inode_follow_link RCU-walk
aware"), the latter is providing the correct fix for it.

>
> ---
> security/selinux/avc.c | 24 ++++++++++++++++++++++--
> security/selinux/hooks.c | 5 +++--
> security/selinux/include/avc.h | 5 +++++
> 3 files changed, 30 insertions(+), 4 deletions(-)

[...]

2020-02-13 16:28:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.4 85/96] selinux: revert "stop passing MAY_NOT_BLOCK to the AVC upon follow_link"

On Thu, Feb 13, 2020 at 11:01:41AM -0500, Stephen Smalley wrote:
> On 2/13/20 10:21 AM, Greg Kroah-Hartman wrote:
> > From: Stephen Smalley <[email protected]>
> >
> > commit 1a37079c236d55fb31ebbf4b59945dab8ec8764c upstream.
> >
> > This reverts commit e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK
> > to the AVC upon follow_link"). The correct fix is to instead fall
> > back to ref-walk if audit is required irrespective of the specific
> > audit data type. This is done in the next commit.
> >
> > Fixes: e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link")
> > Reported-by: Will Deacon <[email protected]>
> > Signed-off-by: Stephen Smalley <[email protected]>
> > Signed-off-by: Paul Moore <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This patch should be accompanied by commit
> 0188d5c025ca8fe756ba3193bd7d150139af5a88 ("selinux: fall back to ref-walk if
> audit is required"). The former is reverting an incorrect fix for
> bda0be7ad994 ("security: make inode_follow_link RCU-walk aware"), the latter
> is providing the correct fix for it.

Thanks for letting me know, now queued up for both trees.

greg k-h

2020-02-13 22:28:54

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

On Thu, Feb 13, 2020 at 07:20:07AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.20 release.
> There are 96 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 Sat, 15 Feb 2020 15:16:40 +0000.
> Anything received after that time might be too late.
>

Build reference: v5.4.19-98-gdfae536f94c2
gcc version: powerpc64-linux-gcc (GCC) 9.2.0

Building powerpc:defconfig ... failed
--------------
Error log:
drivers/rtc/rtc-ds1307.c:1570:21: error: variable 'regmap_config' has initializer but incomplete type
1570 | static const struct regmap_config regmap_config = {

Bisect log below. Looks like the the definition of "not needed"
needs an update.

v5.5.y has the same problem.

Guenter

---
# bad: [dfae536f94c22d5fd109d5db73cd5ed7245a764c] Linux 5.4.20-rc1
# good: [d6591ea2dd1a44b1c72c5a3e3b6555d7585acdae] Linux 5.4.19
git bisect start 'HEAD' 'v5.4.19'
# bad: [f52a8d450b1431b775d993cd8586f0cfd5fe25e1] ARM: dts: at91: sama5d3: fix maximum peripheral clock rates
git bisect bad f52a8d450b1431b775d993cd8586f0cfd5fe25e1
# good: [99323d91be3464a8ff87c7b16c72e7134b7b5075] selftests/bpf: Test freeing sockmap/sockhash with a socket in it
git bisect good 99323d91be3464a8ff87c7b16c72e7134b7b5075
# bad: [4ece240000532dbe0628f28f3f5466ed4091613b] rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed
git bisect bad 4ece240000532dbe0628f28f3f5466ed4091613b
# good: [3a0805bedf5a29ff659d82b34ccf8f393820a5f1] NFS: Fix fix of show_nfs_errors
git bisect good 3a0805bedf5a29ff659d82b34ccf8f393820a5f1
# good: [bd35cae202fa94fe8349ea63ea082f190b31692c] NFSv4.0: nfs4_do_fsinfo() should not do implicit lease renewals
git bisect good bd35cae202fa94fe8349ea63ea082f190b31692c
# good: [d052da5a3c584de39b4b74176b37925d58ab4239] rtc: hym8563: Return -EINVAL if the time is known to be invalid
git bisect good d052da5a3c584de39b4b74176b37925d58ab4239
# first bad commit: [4ece240000532dbe0628f28f3f5466ed4091613b] rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed

2020-02-13 23:06:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

On Thu, Feb 13, 2020 at 02:27:32PM -0800, Guenter Roeck wrote:
> On Thu, Feb 13, 2020 at 07:20:07AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.20 release.
> > There are 96 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 Sat, 15 Feb 2020 15:16:40 +0000.
> > Anything received after that time might be too late.
> >
>
> Build reference: v5.4.19-98-gdfae536f94c2
> gcc version: powerpc64-linux-gcc (GCC) 9.2.0
>
> Building powerpc:defconfig ... failed
> --------------
> Error log:
> drivers/rtc/rtc-ds1307.c:1570:21: error: variable 'regmap_config' has initializer but incomplete type
> 1570 | static const struct regmap_config regmap_config = {
>
> Bisect log below. Looks like the the definition of "not needed"
> needs an update.

Nice catch, sorry about that. I've dropped the offending commit and
will push out -rc2 releases for both 5.5.y and 5.4.y.

thanks,

greg k-h

2020-02-14 00:42:33

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

On 2/13/20 8:20 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.20 release.
> There are 96 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 Sat, 15 Feb 2020 15:16:40 +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.4.20-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

thanks,
-- Shuah

2020-02-14 07:56:21

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

Hi Günter,

On Thu, Feb 13, 2020 at 11:28 PM Guenter Roeck <[email protected]> wrote:
> On Thu, Feb 13, 2020 at 07:20:07AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.4.20 release.
> > There are 96 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 Sat, 15 Feb 2020 15:16:40 +0000.
> > Anything received after that time might be too late.
> >
>
> Build reference: v5.4.19-98-gdfae536f94c2
> gcc version: powerpc64-linux-gcc (GCC) 9.2.0
>
> Building powerpc:defconfig ... failed
> --------------
> Error log:
> drivers/rtc/rtc-ds1307.c:1570:21: error: variable 'regmap_config' has initializer but incomplete type
> 1570 | static const struct regmap_config regmap_config = {
>
> Bisect log below. Looks like the the definition of "not needed"
> needs an update.

"not needed" goes together with (or after) "when necessary":
578c2b661e2b1b47 ("rtc: Kconfig: select REGMAP_I2C when necessary")

> v5.5.y has the same problem.
>
> Guenter
>
> ---
> # bad: [dfae536f94c22d5fd109d5db73cd5ed7245a764c] Linux 5.4.20-rc1
> # good: [d6591ea2dd1a44b1c72c5a3e3b6555d7585acdae] Linux 5.4.19
> git bisect start 'HEAD' 'v5.4.19'
> # bad: [f52a8d450b1431b775d993cd8586f0cfd5fe25e1] ARM: dts: at91: sama5d3: fix maximum peripheral clock rates
> git bisect bad f52a8d450b1431b775d993cd8586f0cfd5fe25e1
> # good: [99323d91be3464a8ff87c7b16c72e7134b7b5075] selftests/bpf: Test freeing sockmap/sockhash with a socket in it
> git bisect good 99323d91be3464a8ff87c7b16c72e7134b7b5075
> # bad: [4ece240000532dbe0628f28f3f5466ed4091613b] rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed
> git bisect bad 4ece240000532dbe0628f28f3f5466ed4091613b
> # good: [3a0805bedf5a29ff659d82b34ccf8f393820a5f1] NFS: Fix fix of show_nfs_errors
> git bisect good 3a0805bedf5a29ff659d82b34ccf8f393820a5f1
> # good: [bd35cae202fa94fe8349ea63ea082f190b31692c] NFSv4.0: nfs4_do_fsinfo() should not do implicit lease renewals
> git bisect good bd35cae202fa94fe8349ea63ea082f190b31692c
> # good: [d052da5a3c584de39b4b74176b37925d58ab4239] rtc: hym8563: Return -EINVAL if the time is known to be invalid
> git bisect good d052da5a3c584de39b4b74176b37925d58ab4239
> # first bad commit: [4ece240000532dbe0628f28f3f5466ed4091613b] rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2020-02-14 10:23:06

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

On Thu, 13 Feb 2020 at 20:57, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.20 release.
> There are 96 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 Sat, 15 Feb 2020 15:16:40 +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.4.20-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

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

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

kernel: 5.4.20-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: b06b66d0f2c4879cebdf5de3d93f4245d1470a70
git describe: v5.4.19-97-gb06b66d0f2c4
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.19-97-gb06b66d0f2c4

No regressions (compared to build v5.4.19)

No fixes (compared to build v5.4.19)

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

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* libgpiod
* ltp-fs-tests
* ltp-ipc-tests
* ltp-syscalls-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite

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

2020-02-14 10:28:05

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review


On 13/02/2020 15:20, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.20 release.
> There are 96 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 Sat, 15 Feb 2020 15:16:40 +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.4.20-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.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v5.4:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
40 tests: 40 pass, 0 fail

Linux version: 5.4.20-rc2-gb06b66d0f2c4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-02-14 16:14:12

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

On Thu, Feb 13, 2020 at 07:20:07AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.20 release.
> There are 96 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 Sat, 15 Feb 2020 15:16:40 +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.4.20-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.4.y
> and the diffstat can be found below.

hello,

compiled and booted 5.4.20-rc1+ . No new error according to "dmesg -l err"

--
software engineer
rajagiri school of engineering and technology

2020-02-14 16:29:35

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

On Thu, Feb 13, 2020 at 07:20:07AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.20 release.
> There are 96 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 Sat, 15 Feb 2020 15:16:40 +0000.
> Anything received after that time might be too late.
>

For v5.4.19-97-gb06b66d0f2c4:

Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 399 pass: 399 fail: 0

Guenter

2020-02-14 20:02:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/96] 5.4.20-stable review

On Fri, Feb 14, 2020 at 08:55:48AM +0100, Geert Uytterhoeven wrote:
> Hi G?nter,
>
> On Thu, Feb 13, 2020 at 11:28 PM Guenter Roeck <[email protected]> wrote:
> > On Thu, Feb 13, 2020 at 07:20:07AM -0800, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.4.20 release.
> > > There are 96 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 Sat, 15 Feb 2020 15:16:40 +0000.
> > > Anything received after that time might be too late.
> > >
> >
> > Build reference: v5.4.19-98-gdfae536f94c2
> > gcc version: powerpc64-linux-gcc (GCC) 9.2.0
> >
> > Building powerpc:defconfig ... failed
> > --------------
> > Error log:
> > drivers/rtc/rtc-ds1307.c:1570:21: error: variable 'regmap_config' has initializer but incomplete type
> > 1570 | static const struct regmap_config regmap_config = {
> >
> > Bisect log below. Looks like the the definition of "not needed"
> > needs an update.
>
> "not needed" goes together with (or after) "when necessary":
> 578c2b661e2b1b47 ("rtc: Kconfig: select REGMAP_I2C when necessary")

Thanks for that, I'll consider it for the next round of releases.

greg k-h