2019-12-11 15:13:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 000/105] 5.3.16-stable review

This is the start of the stable review cycle for the 5.3.16 release.
There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Jann Horn <[email protected]>
binder: Handle start==NULL in binder_update_page_range()

Jann Horn <[email protected]>
binder: Prevent repeated use of ->mmap() via NULL mapping

Jann Horn <[email protected]>
binder: Fix race between mmap() and binder_alloc_print_pages()

Nicolas Pitre <[email protected]>
vcs: prevent write access to vcsu devices

Wei Wang <[email protected]>
thermal: Fix deadlock in thermal thermal_zone_device_check

Jan Kara <[email protected]>
iomap: Fix pipe page leakage during splicing

Viresh Kumar <[email protected]>
RDMA/qib: Validate ->show()/store() callbacks before calling them

Johan Hovold <[email protected]>
can: ucan: fix non-atomic allocation in completion handler

Gregory CLEMENT <[email protected]>
spi: Fix NULL pointer when setting SPI_CS_HIGH for GPIO CS

Gregory CLEMENT <[email protected]>
spi: Fix SPI_CS_HIGH setting when using native and GPIO CS

Gregory CLEMENT <[email protected]>
spi: atmel: Fix CS high support

Patrice Chotard <[email protected]>
spi: stm32-qspi: Fix kernel oops when unbinding driver

Frieder Schrempf <[email protected]>
spi: spi-fsl-qspi: Clear TDH bits in FLSHCR register

Navid Emamdoost <[email protected]>
crypto: user - fix memory leak in crypto_reportstat

Navid Emamdoost <[email protected]>
crypto: user - fix memory leak in crypto_report

Ard Biesheuvel <[email protected]>
crypto: ecdh - fix big endian bug in ECC library

Mark Salter <[email protected]>
crypto: ccp - fix uninitialized list head

Ard Biesheuvel <[email protected]>
crypto: geode-aes - switch to skcipher for cbc(aes) fallback

Ayush Sawal <[email protected]>
crypto: af_alg - cast ki_complete ternary op to int

Tudor Ambarus <[email protected]>
crypto: atmel-aes - Fix IV handling when req->nbytes < ivsize

Christian Lamparter <[email protected]>
crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr

Sean Christopherson <[email protected]>
KVM: x86: Grab KVM's srcu lock when setting nested state

Sean Christopherson <[email protected]>
KVM: x86: Remove a spurious export of a static function

Paolo Bonzini <[email protected]>
KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES

Paolo Bonzini <[email protected]>
KVM: x86: do not modify masked bits of shared MSRs

Zenghui Yu <[email protected]>
KVM: arm/arm64: vgic: Don't rely on the wrong pending table

Sean Christopherson <[email protected]>
KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter

Greg Kurz <[email protected]>
KVM: PPC: Book3S HV: XIVE: Set kvm->arch.xive when VPs are allocated

Greg Kurz <[email protected]>
KVM: PPC: Book3S HV: XIVE: Fix potential page leak on error path

Greg Kurz <[email protected]>
KVM: PPC: Book3S HV: XIVE: Free previous EQ page when setting up a new one

Marek Szyprowski <[email protected]>
arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node"

Dan Carpenter <[email protected]>
drm/i810: Prevent underflow in ioctl

Sean Paul <[email protected]>
drm: damage_helper: Fix race checking plane->state->fb

Johan Hovold <[email protected]>
drm/msm: fix memleak on release

Jan Kara <[email protected]>
jbd2: Fix possible overflow in jbd2_log_space_left()

Tejun Heo <[email protected]>
kernfs: fix ino wrap-around detection

J. Bruce Fields <[email protected]>
nfsd: restore NFSv3 ACL support

Trond Myklebust <[email protected]>
nfsd: Ensure CLONE persists data and metadata changes to the target file

Jouni Hogander <[email protected]>
can: slcan: Fix use-after-free Read in slcan_open

Dmitry Torokhov <[email protected]>
tty: vt: keyboard: reject invalid keycodes

Pavel Shilovsky <[email protected]>
CIFS: Fix SMB2 oplock break processing

Pavel Shilovsky <[email protected]>
CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks

Kai-Heng Feng <[email protected]>
x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect

Joerg Roedel <[email protected]>
x86/mm/32: Sync only to VMALLOC_END in vmalloc_sync_all()

Sean Young <[email protected]>
media: rc: mark input device as pointing stick

Navid Emamdoost <[email protected]>
Input: Fix memory leak in psxpad_spi_probe

Mike Leach <[email protected]>
coresight: etm4x: Fix input validation for sysfs.

Hans de Goede <[email protected]>
Input: goodix - add upside-down quirk for Teclast X89 tablet

Hans Verkuil <[email protected]>
Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers

Lucas Stach <[email protected]>
Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash

Hans Verkuil <[email protected]>
Input: synaptics - switch another X1 Carbon 6 to RMI/SMbus

Takashi Iwai <[email protected]>
ALSA: hda: Modify stream stripe mask only when needed

Kai-Heng Feng <[email protected]>
ALSA: hda - Add mute led support for HP ProBook 645 G4

Takashi Iwai <[email protected]>
ALSA: pcm: oss: Avoid potential buffer overflows

Kailang Yang <[email protected]>
ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236

Hui Wang <[email protected]>
ALSA: hda/realtek - Enable the headset-mic on a Xiaomi's laptop

Jian-Hong Pan <[email protected]>
ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC

Trond Myklebust <[email protected]>
SUNRPC: Avoid RPC delays when exiting suspend

Jens Axboe <[email protected]>
io_uring: ensure req->submit is copied when req is deferred

Miklos Szeredi <[email protected]>
fuse: verify attributes

Miklos Szeredi <[email protected]>
fuse: verify nlink

Jens Axboe <[email protected]>
io_uring: transform send/recvmsg() -ERESTARTSYS to -EINTR

Wen Yang <[email protected]>
i2c: core: fix use after free in of_i2c_notify

Chuhong Yuan <[email protected]>
net: ep93xx_eth: fix mismatch of request_mem_region in remove

David Howells <[email protected]>
afs: Fix race in commit bulk status fetch

Yonglong Liu <[email protected]>
net: hns3: fix ETS bandwidth validation bug

Yunsheng Lin <[email protected]>
net: hns3: reallocate SSU' buffer size when pfc_en changes

Ulrich Hecht <[email protected]>
ravb: implement MTU change while device is up

Chuhong Yuan <[email protected]>
rsxx: add missed destroy_workqueue calls in remove

Ilya Dryomov <[email protected]>
rbd: silence bogus uninitialized warning in rbd_object_map_update_finish()

Vitaly Kuznetsov <[email protected]>
selftests: kvm: fix build with glibc >= 2.30

Yunhao Tian <[email protected]>
drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.

Xiaochen Shen <[email protected]>
x86/resctrl: Fix potential lockdep warning

paulhsia <[email protected]>
ALSA: pcm: Fix stream lock usage in snd_pcm_period_elapsed()

Alexander Shishkin <[email protected]>
perf/core: Consistently fail fork on allocation failures

Vincent Guittot <[email protected]>
sched/pelt: Fix update of blocked PELT ordering

Peter Zijlstra <[email protected]>
sched/core: Avoid spurious lock dependencies

Pan Bian <[email protected]>
Input: cyttsp4_core - fix use after free bug

Junichi Nomura <[email protected]>
block: check bi_size overflow before merge

Xiaodong Xu <[email protected]>
xfrm: release device reference for invalid state

Stephan Gerhold <[email protected]>
NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error

Chiou, Cooper <[email protected]>
ALSA: hda: Add Cometlake-S PCI ID

Al Viro <[email protected]>
ecryptfs: fix unlink and rmdir in face of underlying fs modifications

Al Viro <[email protected]>
audit_get_nd(): don't unlock parent too early

Al Viro <[email protected]>
exportfs_decode_fh(): negative pinned may become positive without the parent locked

Al Viro <[email protected]>
cgroup: don't put ERR_PTR() into fc->root

Mordechay Goodstein <[email protected]>
iwlwifi: pcie: don't consider IV len in A-MSDU

Wenpeng Liang <[email protected]>
RDMA/hns: Correct the value of srq_desc_size

Sirong Wang <[email protected]>
RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN

Thomas Bogendoerfer <[email protected]>
MIPS: SGI-IP27: fix exception handler replication

Al Viro <[email protected]>
autofs: fix a leak in autofs_expire_indirect()

Guillem Jover <[email protected]>
aio: Fix io_pgetevents() struct __compat_aio_sigset layout

Chuhong Yuan <[email protected]>
serial: ifx6x60: add missed pm_runtime_disable

Fabrice Gasnier <[email protected]>
serial: stm32: fix clearing interrupt error flags

Jiangfeng Xiao <[email protected]>
serial: serial_core: Perform NULL checks for break_ctl ops

Vincent Whitchurch <[email protected]>
serial: pl011: Fix DMA ->flush_buffer()

Jeffrey Hugo <[email protected]>
tty: serial: msm_serial: Fix flow control

Peng Fan <[email protected]>
tty: serial: fsl_lpuart: use the sg count from dma_map_sg

Michał Mirosław <[email protected]>
usb: gadget: u_serial: add missing port entry locking

Dmitry Safonov <[email protected]>
time: Zero the upper 32-bits in __kernel_timespec on 32-bit

Arnd Bergmann <[email protected]>
lp: fix sparc64 LPSETTIMEOUT ioctl

Tuowen Zhao <[email protected]>
sparc64: implement ioremap_uc

Adrian Hunter <[email protected]>
perf scripts python: exported-sql-viewer.py: Fix use of TRUE with SQLite

Jon Hunter <[email protected]>
arm64: tegra: Fix 'active-low' warning for Jetson TX1 regulator

Navid Emamdoost <[email protected]>
rsi: release skb if rsi_prepare_beacon fails


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

Diffstat:

Makefile | 4 +-
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +-
arch/arm64/boot/dts/exynos/exynos7.dtsi | 6 +-
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 2 +-
arch/mips/sgi-ip27/Kconfig | 7 ---
arch/mips/sgi-ip27/ip27-init.c | 21 ++-----
arch/mips/sgi-ip27/ip27-memory.c | 4 --
arch/powerpc/kvm/book3s_xive.c | 11 ++--
arch/powerpc/kvm/book3s_xive_native.c | 46 +++++++++------
arch/sparc/include/asm/io_64.h | 1 +
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 --
arch/x86/kvm/vmx/nested.c | 10 ++++
arch/x86/kvm/vmx/vmx.c | 10 +++-
arch/x86/kvm/x86.c | 17 ++++--
arch/x86/mm/fault.c | 2 +-
arch/x86/pci/fixup.c | 11 ++++
block/bio.c | 2 +-
crypto/af_alg.c | 2 +-
crypto/crypto_user_base.c | 4 +-
crypto/crypto_user_stat.c | 4 +-
crypto/ecc.c | 3 +-
drivers/android/binder_alloc.c | 41 ++++++++------
drivers/block/rbd.c | 2 +-
drivers/block/rsxx/core.c | 2 +
drivers/char/lp.c | 4 ++
drivers/crypto/amcc/crypto4xx_core.c | 6 +-
drivers/crypto/atmel-aes.c | 53 ++++++++++--------
drivers/crypto/ccp/ccp-dmaengine.c | 1 +
drivers/crypto/geode-aes.c | 57 +++++++++++--------
drivers/crypto/geode-aes.h | 2 +-
drivers/gpu/drm/drm_damage_helper.c | 8 ++-
drivers/gpu/drm/i810/i810_dma.c | 4 +-
drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
.../hwtracing/coresight/coresight-etm4x-sysfs.c | 21 ++++---
drivers/i2c/i2c-core-of.c | 4 +-
drivers/infiniband/hw/hns/hns_roce_hem.h | 2 +-
drivers/infiniband/hw/hns/hns_roce_srq.c | 2 +-
drivers/infiniband/hw/qib/qib_sysfs.c | 6 ++
drivers/input/joystick/psxpad-spi.c | 2 +-
drivers/input/mouse/synaptics.c | 1 +
drivers/input/rmi4/rmi_f34v7.c | 3 +
drivers/input/rmi4/rmi_smbus.c | 2 -
drivers/input/touchscreen/cyttsp4_core.c | 7 ---
drivers/input/touchscreen/goodix.c | 9 +++
drivers/media/rc/rc-main.c | 1 +
drivers/net/can/slcan.c | 1 +
drivers/net/can/usb/ucan.c | 2 +-
drivers/net/ethernet/cirrus/ep93xx_eth.c | 5 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 19 ++++++-
drivers/net/ethernet/renesas/ravb.h | 3 +-
drivers/net/ethernet/renesas/ravb_main.c | 26 +++++----
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 20 +++----
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 1 +
drivers/nfc/nxp-nci/i2c.c | 6 +-
drivers/spi/spi-atmel.c | 6 +-
drivers/spi/spi-fsl-qspi.c | 38 +++++++++++--
drivers/spi/spi-stm32-qspi.c | 3 +-
drivers/spi/spi.c | 19 ++++---
drivers/thermal/thermal_core.c | 4 +-
drivers/tty/serial/amba-pl011.c | 6 +-
drivers/tty/serial/fsl_lpuart.c | 4 +-
drivers/tty/serial/ifx6x60.c | 3 +
drivers/tty/serial/msm_serial.c | 6 +-
drivers/tty/serial/serial_core.c | 2 +-
drivers/tty/serial/stm32-usart.c | 6 +-
drivers/tty/vt/keyboard.c | 2 +-
drivers/tty/vt/vc_screen.c | 3 +
drivers/usb/gadget/function/u_serial.c | 2 +
fs/afs/dir.c | 7 ++-
fs/aio.c | 10 ++--
fs/autofs/expire.c | 5 +-
fs/cifs/file.c | 7 ++-
fs/cifs/smb2misc.c | 7 +--
fs/ecryptfs/inode.c | 65 +++++++++++++---------
fs/exportfs/expfs.c | 31 +++++++----
fs/fuse/dir.c | 25 ++++++---
fs/fuse/fuse_i.h | 2 +
fs/fuse/readdir.c | 2 +-
fs/io_uring.c | 9 ++-
fs/iomap/direct-io.c | 9 ++-
fs/kernfs/dir.c | 5 +-
fs/nfsd/nfs4proc.c | 3 +-
fs/nfsd/nfssvc.c | 3 +-
fs/nfsd/vfs.c | 8 ++-
fs/nfsd/vfs.h | 2 +-
include/linux/jbd2.h | 4 +-
include/linux/kernfs.h | 1 +
include/sound/hdaudio.h | 1 +
kernel/audit_watch.c | 2 +-
kernel/cgroup/cgroup.c | 5 +-
kernel/events/core.c | 2 +-
kernel/sched/core.c | 3 +-
kernel/sched/fair.c | 29 +++++++---
kernel/time/time.c | 3 +-
net/sunrpc/sched.c | 2 +-
net/xfrm/xfrm_input.c | 3 +
sound/core/oss/linear.c | 2 +
sound/core/oss/mulaw.c | 2 +
sound/core/oss/route.c | 2 +
sound/core/pcm_lib.c | 8 ++-
sound/hda/hdac_stream.c | 19 ++++---
sound/pci/hda/hda_intel.c | 3 +
sound/pci/hda/patch_conexant.c | 1 +
sound/pci/hda/patch_hdmi.c | 5 ++
sound/pci/hda/patch_realtek.c | 18 +++++-
tools/perf/scripts/python/exported-sql-viewer.py | 10 +++-
tools/testing/selftests/kvm/lib/assert.c | 4 +-
virt/kvm/arm/vgic/vgic-v3.c | 6 +-
109 files changed, 597 insertions(+), 350 deletions(-)



2019-12-11 15:13:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 016/105] MIPS: SGI-IP27: fix exception handler replication

From: Thomas Bogendoerfer <[email protected]>

[ Upstream commit 637346748245e94c877aa746e6fe0d7079b7736a ]

Commit 775b089aeffa ("MIPS: tlbex: Remove cpu_has_local_ebase") removed
generating tlb refill handlers for every CPU, which was needed for
generating per node exception handlers on IP27. Instead of resurrecting
(and fixing) refill handler generation, we simply copy all exception
vectors from the boot node to the other nodes. Also remove the config
option since the memory tradeoff for expection handler replication
is just 8k per node.

Signed-off-by: Thomas Bogendoerfer <[email protected]>
Signed-off-by: Paul Burton <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/mips/sgi-ip27/Kconfig | 7 -------
arch/mips/sgi-ip27/ip27-init.c | 21 ++++++---------------
arch/mips/sgi-ip27/ip27-memory.c | 4 ----
3 files changed, 6 insertions(+), 26 deletions(-)

diff --git a/arch/mips/sgi-ip27/Kconfig b/arch/mips/sgi-ip27/Kconfig
index ef3847e7aee02..e5b6cadbec857 100644
--- a/arch/mips/sgi-ip27/Kconfig
+++ b/arch/mips/sgi-ip27/Kconfig
@@ -38,10 +38,3 @@ config REPLICATE_KTEXT
Say Y here to enable replicating the kernel text across multiple
nodes in a NUMA cluster. This trades memory for speed.

-config REPLICATE_EXHANDLERS
- bool "Exception handler replication support"
- depends on SGI_IP27
- help
- Say Y here to enable replicating the kernel exception handlers
- across multiple nodes in a NUMA cluster. This trades memory for
- speed.
diff --git a/arch/mips/sgi-ip27/ip27-init.c b/arch/mips/sgi-ip27/ip27-init.c
index 066b33f50bcc4..db58ebf02870f 100644
--- a/arch/mips/sgi-ip27/ip27-init.c
+++ b/arch/mips/sgi-ip27/ip27-init.c
@@ -69,23 +69,14 @@ static void per_hub_init(cnodeid_t cnode)

hub_rtc_init(cnode);

-#ifdef CONFIG_REPLICATE_EXHANDLERS
- /*
- * If this is not a headless node initialization,
- * copy over the caliased exception handlers.
- */
- if (get_compact_nodeid() == cnode) {
- extern char except_vec2_generic, except_vec3_generic;
- extern void build_tlb_refill_handler(void);
-
- memcpy((void *)(CKSEG0 + 0x100), &except_vec2_generic, 0x80);
- memcpy((void *)(CKSEG0 + 0x180), &except_vec3_generic, 0x80);
- build_tlb_refill_handler();
- memcpy((void *)(CKSEG0 + 0x100), (void *) CKSEG0, 0x80);
- memcpy((void *)(CKSEG0 + 0x180), &except_vec3_generic, 0x100);
+ if (nasid) {
+ /* copy exception handlers from first node to current node */
+ memcpy((void *)NODE_OFFSET_TO_K0(nasid, 0),
+ (void *)CKSEG0, 0x200);
__flush_cache_all();
+ /* switch to node local exception handlers */
+ REMOTE_HUB_S(nasid, PI_CALIAS_SIZE, PI_CALIAS_SIZE_8K);
}
-#endif
}

void per_cpu_init(void)
diff --git a/arch/mips/sgi-ip27/ip27-memory.c b/arch/mips/sgi-ip27/ip27-memory.c
index fb077a9475756..8624a885d95bf 100644
--- a/arch/mips/sgi-ip27/ip27-memory.c
+++ b/arch/mips/sgi-ip27/ip27-memory.c
@@ -332,11 +332,7 @@ static void __init mlreset(void)
* thinks it is a node 0 address.
*/
REMOTE_HUB_S(nasid, PI_REGION_PRESENT, (region_mask | 1));
-#ifdef CONFIG_REPLICATE_EXHANDLERS
- REMOTE_HUB_S(nasid, PI_CALIAS_SIZE, PI_CALIAS_SIZE_8K);
-#else
REMOTE_HUB_S(nasid, PI_CALIAS_SIZE, PI_CALIAS_SIZE_0);
-#endif

#ifdef LATER
/*
--
2.20.1



2019-12-11 15:13:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 018/105] RDMA/hns: Correct the value of srq_desc_size

From: Wenpeng Liang <[email protected]>

[ Upstream commit 411c1e6774e2e1f96b1ccce4f119376b94ade3e4 ]

srq_desc_size should be rounded up to pow of two before used, or related
calculation may cause allocating wrong size of memory for srq buffer.

Fixes: c7bcb13442e1 ("RDMA/hns: Add SRQ support for hip08 kernel mode")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Wenpeng Liang <[email protected]>
Signed-off-by: Weihang Li <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/hw/hns/hns_roce_srq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_srq.c b/drivers/infiniband/hw/hns/hns_roce_srq.c
index 38bb548eaa6d8..9768e377cd22c 100644
--- a/drivers/infiniband/hw/hns/hns_roce_srq.c
+++ b/drivers/infiniband/hw/hns/hns_roce_srq.c
@@ -221,7 +221,7 @@ int hns_roce_create_srq(struct ib_srq *ib_srq,
srq->max = roundup_pow_of_two(srq_init_attr->attr.max_wr + 1);
srq->max_gs = srq_init_attr->attr.max_sge;

- srq_desc_size = max(16, 16 * srq->max_gs);
+ srq_desc_size = roundup_pow_of_two(max(16, 16 * srq->max_gs));

srq->wqe_shift = ilog2(srq_desc_size);

--
2.20.1



2019-12-11 15:14:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 005/105] lp: fix sparc64 LPSETTIMEOUT ioctl

From: Arnd Bergmann <[email protected]>

commit 45a2d64696b11913bcf1087b041740edbade3e21 upstream.

The layout of struct timeval is different on sparc64 from
anything else, and the patch I did long ago failed to take
this into account.

Change it now to handle sparc64 user space correctly again.

Quite likely nobody cares about parallel ports on sparc64,
but there is no reason not to fix it.

Cc: [email protected]
Fixes: 9a450484089d ("lp: support 64-bit time_t user space")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/lp.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/char/lp.c
+++ b/drivers/char/lp.c
@@ -713,6 +713,10 @@ static int lp_set_timeout64(unsigned int
if (copy_from_user(karg, arg, sizeof(karg)))
return -EFAULT;

+ /* sparc64 suseconds_t is 32-bit only */
+ if (IS_ENABLED(CONFIG_SPARC64) && !in_compat_syscall())
+ karg[1] >>= 32;
+
return lp_set_timeout(minor, karg[0], karg[1]);
}



2019-12-11 15:14:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 001/105] rsi: release skb if rsi_prepare_beacon fails

From: Navid Emamdoost <[email protected]>

commit d563131ef23cbc756026f839a82598c8445bc45f upstream.

In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should
be released.

Signed-off-by: Navid Emamdoost <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -1756,6 +1756,7 @@ static int rsi_send_beacon(struct rsi_co
skb_pull(skb, (64 - dword_align_bytes));
if (rsi_prepare_beacon(common, skb)) {
rsi_dbg(ERR_ZONE, "Failed to prepare beacon\n");
+ dev_kfree_skb(skb);
return -EINVAL;
}
skb_queue_tail(&common->tx_queue[MGMT_BEACON_Q], skb);


2019-12-11 15:14:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 004/105] sparc64: implement ioremap_uc

From: Tuowen Zhao <[email protected]>

commit 38e45d81d14e5f78cd67922596b1c37b4c22ec74 upstream.

On sparc64, the whole physical IO address space is accessible using
physically addressed loads and stores. *_uc does nothing like the
others.

Cc: <[email protected]> # v4.19+
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Tuowen Zhao <[email protected]>
Acked-by: David S. Miller <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/sparc/include/asm/io_64.h | 1 +
1 file changed, 1 insertion(+)

--- a/arch/sparc/include/asm/io_64.h
+++ b/arch/sparc/include/asm/io_64.h
@@ -407,6 +407,7 @@ static inline void __iomem *ioremap(unsi
}

#define ioremap_nocache(X,Y) ioremap((X),(Y))
+#define ioremap_uc(X,Y) ioremap((X),(Y))
#define ioremap_wc(X,Y) ioremap((X),(Y))
#define ioremap_wt(X,Y) ioremap((X),(Y))



2019-12-11 15:14:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 020/105] cgroup: dont put ERR_PTR() into fc->root

From: Al Viro <[email protected]>

[ Upstream commit 630faf81b3e61bcc90dc6d8b497800657d2752a5 ]

the caller of ->get_tree() expects NULL left there on error...

Reported-by: Thibaut Sautereau <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/cgroup/cgroup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 8be1da1ebd9a4..f23862fa15146 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2119,11 +2119,12 @@ int cgroup_do_get_tree(struct fs_context *fc)

nsdentry = kernfs_node_dentry(cgrp->kn, sb);
dput(fc->root);
- fc->root = nsdentry;
if (IS_ERR(nsdentry)) {
- ret = PTR_ERR(nsdentry);
deactivate_locked_super(sb);
+ ret = PTR_ERR(nsdentry);
+ nsdentry = NULL;
}
+ fc->root = nsdentry;
}

if (!ctx->kfc.new_sb_created)
--
2.20.1



2019-12-11 15:14:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 036/105] rbd: silence bogus uninitialized warning in rbd_object_map_update_finish()

From: Ilya Dryomov <[email protected]>

[ Upstream commit 633739b2fedb6617d782ca252797b7a8ad754347 ]

Some versions of gcc (so far 6.3 and 7.4) throw a warning:

drivers/block/rbd.c: In function 'rbd_object_map_callback':
drivers/block/rbd.c:2124:21: warning: 'current_state' may be used uninitialized in this function [-Wmaybe-uninitialized]
(current_state == OBJECT_EXISTS && state == OBJECT_EXISTS_CLEAN))
drivers/block/rbd.c:2092:23: note: 'current_state' was declared here
u8 state, new_state, current_state;
^~~~~~~~~~~~~

It's bogus because all current_state accesses are guarded by
has_current_state.

Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Ilya Dryomov <[email protected]>
Reviewed-by: Dongsheng Yang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/block/rbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index c8fb886aebd4e..64e364c4a0fb8 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2089,7 +2089,7 @@ static int rbd_object_map_update_finish(struct rbd_obj_request *obj_req,
struct rbd_device *rbd_dev = obj_req->img_request->rbd_dev;
struct ceph_osd_data *osd_data;
u64 objno;
- u8 state, new_state, current_state;
+ u8 state, new_state, uninitialized_var(current_state);
bool has_current_state;
void *p;

--
2.20.1



2019-12-11 15:14:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 019/105] iwlwifi: pcie: dont consider IV len in A-MSDU

From: Mordechay Goodstein <[email protected]>

[ Upstream commit cb1a4badf59275eb7221dcec621e8154917eabd1 ]

>From gen2 PN is totally offloaded to hardware (also the space for the
IV isn't part of the skb). As you can see in mvm/mac80211.c:3545, the
MAC for cipher types CCMP/GCMP doesn't set
IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs.

This causes all the AMSDU data to be corrupted with cipher enabled.

Signed-off-by: Mordechay Goodstein <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
.../net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 20 +++++++------------
1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
index 9ef6b8fe03c1b..0fbf8c1d5c98b 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
@@ -252,27 +252,23 @@ static int iwl_pcie_gen2_build_amsdu(struct iwl_trans *trans,
struct ieee80211_hdr *hdr = (void *)skb->data;
unsigned int snap_ip_tcp_hdrlen, ip_hdrlen, total_len, hdr_room;
unsigned int mss = skb_shinfo(skb)->gso_size;
- u16 length, iv_len, amsdu_pad;
+ u16 length, amsdu_pad;
u8 *start_hdr;
struct iwl_tso_hdr_page *hdr_page;
struct page **page_ptr;
struct tso_t tso;

- /* if the packet is protected, then it must be CCMP or GCMP */
- iv_len = ieee80211_has_protected(hdr->frame_control) ?
- IEEE80211_CCMP_HDR_LEN : 0;
-
trace_iwlwifi_dev_tx(trans->dev, skb, tfd, sizeof(*tfd),
&dev_cmd->hdr, start_len, 0);

ip_hdrlen = skb_transport_header(skb) - skb_network_header(skb);
snap_ip_tcp_hdrlen = 8 + ip_hdrlen + tcp_hdrlen(skb);
- total_len = skb->len - snap_ip_tcp_hdrlen - hdr_len - iv_len;
+ total_len = skb->len - snap_ip_tcp_hdrlen - hdr_len;
amsdu_pad = 0;

/* total amount of header we may need for this A-MSDU */
hdr_room = DIV_ROUND_UP(total_len, mss) *
- (3 + snap_ip_tcp_hdrlen + sizeof(struct ethhdr)) + iv_len;
+ (3 + snap_ip_tcp_hdrlen + sizeof(struct ethhdr));

/* Our device supports 9 segments at most, it will fit in 1 page */
hdr_page = get_page_hdr(trans, hdr_room);
@@ -283,14 +279,12 @@ static int iwl_pcie_gen2_build_amsdu(struct iwl_trans *trans,
start_hdr = hdr_page->pos;
page_ptr = (void *)((u8 *)skb->cb + trans_pcie->page_offs);
*page_ptr = hdr_page->page;
- memcpy(hdr_page->pos, skb->data + hdr_len, iv_len);
- hdr_page->pos += iv_len;

/*
- * Pull the ieee80211 header + IV to be able to use TSO core,
+ * Pull the ieee80211 header to be able to use TSO core,
* we will restore it for the tx_status flow.
*/
- skb_pull(skb, hdr_len + iv_len);
+ skb_pull(skb, hdr_len);

/*
* Remove the length of all the headers that we don't actually
@@ -365,8 +359,8 @@ static int iwl_pcie_gen2_build_amsdu(struct iwl_trans *trans,
}
}

- /* re -add the WiFi header and IV */
- skb_push(skb, hdr_len + iv_len);
+ /* re -add the WiFi header */
+ skb_push(skb, hdr_len);

return 0;

--
2.20.1



2019-12-11 15:14:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 022/105] audit_get_nd(): dont unlock parent too early

From: Al Viro <[email protected]>

[ Upstream commit 69924b89687a2923e88cc42144aea27868913d0e ]

if the child has been negative and just went positive
under us, we want coherent d_is_positive() and ->d_inode.
Don't unlock the parent until we'd done that work...

Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/audit_watch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 1f31c2f1e6fc1..4508d5e0cf696 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -351,12 +351,12 @@ static int audit_get_nd(struct audit_watch *watch, struct path *parent)
struct dentry *d = kern_path_locked(watch->path, parent);
if (IS_ERR(d))
return PTR_ERR(d);
- inode_unlock(d_backing_inode(parent->dentry));
if (d_is_positive(d)) {
/* update watch filter fields */
watch->dev = d->d_sb->s_dev;
watch->ino = d_backing_inode(d)->i_ino;
}
+ inode_unlock(d_backing_inode(parent->dentry));
dput(d);
return 0;
}
--
2.20.1



2019-12-11 15:14:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 011/105] serial: serial_core: Perform NULL checks for break_ctl ops

From: Jiangfeng Xiao <[email protected]>

commit 7d73170e1c282576419f8b50a771f1fcd2b81a94 upstream.

Doing fuzz test on sbsa uart device, causes a kernel crash
due to NULL pointer dereference:

------------[ cut here ]------------
Unable to handle kernel paging request at virtual address fffffffffffffffc
pgd = ffffffe331723000
[fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O)
Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O)
hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O)
mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O)
uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4
iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd
usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid
ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod
yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand
nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe
cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry
nfsv3 nfs nfs_acl lockd sunrpc grace autofs4
CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G O 4.4.193 #1
task: ffffffe32b23f110 task.stack: ffffffe32bda4000
PC is at uart_break_ctl+0x44/0x84
LR is at uart_break_ctl+0x34/0x84
pc : [<ffffff8393196098>] lr : [<ffffff8393196088>] pstate: 80000005
sp : ffffffe32bda7cc0
x29: ffffffe32bda7cc0 x28: ffffffe32b23f110
x27: ffffff8393402000 x26: 0000000000000000
x25: ffffffe32b233f40 x24: ffffffc07a8ec680
x23: 0000000000005425 x22: 00000000ffffffff
x21: ffffffe33ed73c98 x20: 0000000000000000
x19: ffffffe33ed94168 x18: 0000000000000004
x17: 0000007f92ae9d30 x16: ffffff8392fa6064
x15: 0000000000000010 x14: 0000000000000000
x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000020 x10: 0000007ffdac1708
x9 : 0000000000000078 x8 : 000000000000001d
x7 : 0000000052a64887 x6 : ffffffe32bda7e08
x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000
x3 : ffffff83938d5018 x2 : 0000000000000080
x1 : ffffffe32b23c040 x0 : ffffff83934428f8
virtual start addr offset is 38ac00000
module base offset is 2cd4cf1000
linear region base offset is : 0
Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000)
Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000)
7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054
7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c
7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600
7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425
7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003
7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e
7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600
7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410
7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978
7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc
7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0
7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003
7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78
7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c
7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425
7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014
7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078
7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000
7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30
7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0
7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840
7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000
7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d
7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call trace:
Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0)
7aa0: 0000000000001000 0000007fffffffff
7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025
7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c
7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20
7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000
7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110
7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600
7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018
7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887
7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020
7be0: 0000000000000000 0000000000000000
[<ffffff8393196098>] uart_break_ctl+0x44/0x84
[<ffffff8393177718>] send_break+0xa0/0x114
[<ffffff8393179a1c>] tty_ioctl+0xc50/0xe84
[<ffffff8392fa5a40>] do_vfs_ioctl+0xc4/0x6e8
[<ffffff8392fa60cc>] SyS_ioctl+0x68/0x9c
[<ffffff8392e02e78>] __sys_trace_return+0x0/0x4
Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280)
---[ end trace 8606094f1960c5e0 ]---
Kernel panic - not syncing: Fatal exception

Fix this problem by adding NULL checks prior to calling break_ctl ops.

Signed-off-by: Jiangfeng Xiao <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/serial_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1106,7 +1106,7 @@ static int uart_break_ctl(struct tty_str
if (!uport)
goto out;

- if (uport->type != PORT_UNKNOWN)
+ if (uport->type != PORT_UNKNOWN && uport->ops->break_ctl)
uport->ops->break_ctl(uport, break_state);
ret = 0;
out:


2019-12-11 15:14:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 026/105] xfrm: release device reference for invalid state

From: Xiaodong Xu <[email protected]>

[ Upstream commit 4944a4b1077f74d89073624bd286219d2fcbfce3 ]

An ESP packet could be decrypted in async mode if the input handler for
this packet returns -EINPROGRESS in xfrm_input(). At this moment the device
reference in skb is held. Later xfrm_input() will be invoked again to
resume the processing.
If the transform state is still valid it would continue to release the
device reference and there won't be a problem; however if the transform
state is not valid when async resumption happens, the packet will be
dropped while the device reference is still being held.
When the device is deleted for some reason and the reference to this
device is not properly released, the kernel will keep logging like:

unregister_netdevice: waiting for ppp2 to become free. Usage count = 1

The issue is observed when running IPsec traffic over a PPPoE device based
on a bridge interface. By terminating the PPPoE connection on the server
end for multiple times, the PPPoE device on the client side will eventually
get stuck on the above warning message.

This patch will check the async mode first and continue to release device
reference in async resumption, before it is dropped due to invalid state.

v2: Do not assign address family from outer_mode in the transform if the
state is invalid

v3: Release device reference in the error path instead of jumping to resume

Fixes: 4ce3dbe397d7b ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)")
Signed-off-by: Xiaodong Xu <[email protected]>
Reported-by: Bo Chen <[email protected]>
Tested-by: Bo Chen <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/xfrm/xfrm_input.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 6088bc2dc11e3..fcd4b1f36e669 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -480,6 +480,9 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
else
XFRM_INC_STATS(net,
LINUX_MIB_XFRMINSTATEINVALID);
+
+ if (encap_type == -1)
+ dev_put(skb->dev);
goto drop;
}

--
2.20.1



2019-12-11 15:15:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 054/105] ALSA: hda: Modify stream stripe mask only when needed

From: Takashi Iwai <[email protected]>

commit e38e486d66e2a3b902768fd71c32dbf10f77e1cb upstream.

The recent commit in HD-audio stream management for changing the
stripe control seems causing a regression on some platforms. The
stripe control is currently used only by HDMI codec, and applying the
stripe mask unconditionally may lead to scratchy and static noises as
seen on some MacBooks.

For addressing the regression, this patch changes the stream
management code to apply the stripe mask conditionally only when the
codec driver requested.

Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477
Tested-by: Michael Pobega <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/sound/hdaudio.h | 1 +
sound/hda/hdac_stream.c | 19 ++++++++++++-------
sound/pci/hda/patch_hdmi.c | 5 +++++
3 files changed, 18 insertions(+), 7 deletions(-)

--- a/include/sound/hdaudio.h
+++ b/include/sound/hdaudio.h
@@ -504,6 +504,7 @@ struct hdac_stream {
bool prepared:1;
bool no_period_wakeup:1;
bool locked:1;
+ bool stripe:1; /* apply stripe control */

/* timestamp */
unsigned long start_wallclk; /* start + minimum wallclk */
--- a/sound/hda/hdac_stream.c
+++ b/sound/hda/hdac_stream.c
@@ -96,12 +96,14 @@ void snd_hdac_stream_start(struct hdac_s
1 << azx_dev->index,
1 << azx_dev->index);
/* set stripe control */
- if (azx_dev->substream)
- stripe_ctl = snd_hdac_get_stream_stripe_ctl(bus, azx_dev->substream);
- else
- stripe_ctl = 0;
- snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK,
- stripe_ctl);
+ if (azx_dev->stripe) {
+ if (azx_dev->substream)
+ stripe_ctl = snd_hdac_get_stream_stripe_ctl(bus, azx_dev->substream);
+ else
+ stripe_ctl = 0;
+ snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK,
+ stripe_ctl);
+ }
/* set DMA start and interrupt mask */
snd_hdac_stream_updateb(azx_dev, SD_CTL,
0, SD_CTL_DMA_START | SD_INT_MASK);
@@ -118,7 +120,10 @@ void snd_hdac_stream_clear(struct hdac_s
snd_hdac_stream_updateb(azx_dev, SD_CTL,
SD_CTL_DMA_START | SD_INT_MASK, 0);
snd_hdac_stream_writeb(azx_dev, SD_STS, SD_INT_MASK); /* to be sure */
- snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK, 0);
+ if (azx_dev->stripe) {
+ snd_hdac_stream_updateb(azx_dev, SD_CTL_3B, SD_CTL_STRIPE_MASK, 0);
+ azx_dev->stripe = 0;
+ }
azx_dev->running = false;
}
EXPORT_SYMBOL_GPL(snd_hdac_stream_clear);
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -31,6 +31,7 @@
#include <sound/hda_codec.h>
#include "hda_local.h"
#include "hda_jack.h"
+#include "hda_controller.h"

static bool static_hdmi_pcm;
module_param(static_hdmi_pcm, bool, 0644);
@@ -1226,6 +1227,10 @@ static int hdmi_pcm_open(struct hda_pcm_
per_pin->cvt_nid = per_cvt->cvt_nid;
hinfo->nid = per_cvt->cvt_nid;

+ /* flip stripe flag for the assigned stream if supported */
+ if (get_wcaps(codec, per_cvt->cvt_nid) & AC_WCAP_STRIPE)
+ azx_stream(get_azx_dev(substream))->stripe = 1;
+
snd_hda_set_dev_select(codec, per_pin->pin_nid, per_pin->dev_id);
snd_hda_codec_write_cache(codec, per_pin->pin_nid, 0,
AC_VERB_SET_CONNECT_SEL,


2019-12-11 15:15:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 034/105] drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.

From: Yunhao Tian <[email protected]>

[ Upstream commit 0b8e7bbde5e7e2c419567e1ee29587dae3b78ee3 ]

The datasheet of V3s (and various other chips) wrote
that TCON0_DCLK_DIV can be >= 1 if only dclk is used,
and must >= 6 if dclk1 or dclk2 is used. As currently
neither dclk1 nor dclk2 is used (no writes to these
bits), let's set minimal division to 1.

If this minimal division is 6, some common dot clock
frequencies can't be produced (e.g. 30MHz will not be
possible and will fallback to 25MHz), which is
obviously not an expected behaviour.

Signed-off-by: Yunhao Tian <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/linux-arm-kernel/MN2PR08MB57905AD8A00C08DA219377C989760@MN2PR08MB5790.namprd08.prod.outlook.com/
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index df0cc8f46d7bd..3491c4c7659e4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -486,7 +486,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,

WARN_ON(!tcon->quirks->has_channel_0);

- tcon->dclk_min_div = 6;
+ tcon->dclk_min_div = 1;
tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);

--
2.20.1



2019-12-11 15:15:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 059/105] coresight: etm4x: Fix input validation for sysfs.

From: Mike Leach <[email protected]>

commit 2fe6899e36aa174abefd017887f9cfe0cb60c43a upstream.

A number of issues are fixed relating to sysfs input validation:-

1) bb_ctrl_store() - incorrect compare of bit select field to absolute
value. Reworked per ETMv4 specification.
2) seq_event_store() - incorrect mask value - register has two
event values.
3) cyc_threshold_store() - must mask with max before checking min
otherwise wrapped values can set illegal value below min.
4) res_ctrl_store() - update to mask off all res0 bits.

Reviewed-by: Leo Yan <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Signed-off-by: Mike Leach <[email protected]>
Fixes: a77de2637c9eb ("coresight: etm4x: moving sysFS entries to a dedicated file")
Cc: stable <[email protected]> # 4.9+
Signed-off-by: Mathieu Poirier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/hwtracing/coresight/coresight-etm4x-sysfs.c | 21 ++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)

--- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
@@ -655,10 +655,13 @@ static ssize_t cyc_threshold_store(struc

if (kstrtoul(buf, 16, &val))
return -EINVAL;
+
+ /* mask off max threshold before checking min value */
+ val &= ETM_CYC_THRESHOLD_MASK;
if (val < drvdata->ccitmin)
return -EINVAL;

- config->ccctlr = val & ETM_CYC_THRESHOLD_MASK;
+ config->ccctlr = val;
return size;
}
static DEVICE_ATTR_RW(cyc_threshold);
@@ -689,14 +692,16 @@ static ssize_t bb_ctrl_store(struct devi
return -EINVAL;
if (!drvdata->nr_addr_cmp)
return -EINVAL;
+
/*
- * Bit[7:0] selects which address range comparator is used for
- * branch broadcast control.
+ * Bit[8] controls include(1) / exclude(0), bits[0-7] select
+ * individual range comparators. If include then at least 1
+ * range must be selected.
*/
- if (BMVAL(val, 0, 7) > drvdata->nr_addr_cmp)
+ if ((val & BIT(8)) && (BMVAL(val, 0, 7) == 0))
return -EINVAL;

- config->bb_ctrl = val;
+ config->bb_ctrl = val & GENMASK(8, 0);
return size;
}
static DEVICE_ATTR_RW(bb_ctrl);
@@ -1329,8 +1334,8 @@ static ssize_t seq_event_store(struct de

spin_lock(&drvdata->spinlock);
idx = config->seq_idx;
- /* RST, bits[7:0] */
- config->seq_ctrl[idx] = val & 0xFF;
+ /* Seq control has two masks B[15:8] F[7:0] */
+ config->seq_ctrl[idx] = val & 0xFFFF;
spin_unlock(&drvdata->spinlock);
return size;
}
@@ -1585,7 +1590,7 @@ static ssize_t res_ctrl_store(struct dev
if (idx % 2 != 0)
/* PAIRINV, bit[21] */
val &= ~BIT(21);
- config->res_ctrl[idx] = val;
+ config->res_ctrl[idx] = val & GENMASK(21, 0);
spin_unlock(&drvdata->spinlock);
return size;
}


2019-12-11 15:15:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 013/105] serial: ifx6x60: add missed pm_runtime_disable

From: Chuhong Yuan <[email protected]>

commit 50b2b571c5f3df721fc81bf9a12c521dfbe019ba upstream.

The driver forgets to call pm_runtime_disable in remove.
Add the missed calls to fix it.

Signed-off-by: Chuhong Yuan <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/ifx6x60.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -1230,6 +1230,9 @@ static int ifx_spi_spi_remove(struct spi
struct ifx_spi_device *ifx_dev = spi_get_drvdata(spi);
/* stop activity */
tasklet_kill(&ifx_dev->io_work_tasklet);
+
+ pm_runtime_disable(&spi->dev);
+
/* free irq */
free_irq(gpio_to_irq(ifx_dev->gpio.reset_out), ifx_dev);
free_irq(gpio_to_irq(ifx_dev->gpio.srdy), ifx_dev);


2019-12-11 15:15:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 062/105] x86/mm/32: Sync only to VMALLOC_END in vmalloc_sync_all()

From: Joerg Roedel <[email protected]>

commit 9a62d20027da3164a22244d9f022c0c987261687 upstream.

The job of vmalloc_sync_all() is to help the lazy freeing of vmalloc()
ranges: before such vmap ranges are reused we make sure that they are
unmapped from every task's page tables.

This is really easy on pagetable setups where the kernel page tables
are shared between all tasks - this is the case on 32-bit kernels
with SHARED_KERNEL_PMD = 1.

But on !SHARED_KERNEL_PMD 32-bit kernels this involves iterating
over the pgd_list and clearing all pmd entries in the pgds that
are cleared in the init_mm.pgd, which is the reference pagetable
that the vmalloc() code uses.

In that context the current practice of vmalloc_sync_all() iterating
until FIX_ADDR_TOP is buggy:

for (address = VMALLOC_START & PMD_MASK;
address >= TASK_SIZE_MAX && address < FIXADDR_TOP;
address += PMD_SIZE) {
struct page *page;

Because iterating up to FIXADDR_TOP will involve a lot of non-vmalloc
address ranges:

VMALLOC -> PKMAP -> LDT -> CPU_ENTRY_AREA -> FIX_ADDR

This is mostly harmless for the FIX_ADDR and CPU_ENTRY_AREA ranges
that don't clear their pmds, but it's lethal for the LDT range,
which relies on having different mappings in different processes,
and 'synchronizing' them in the vmalloc sense corrupts those
pagetable entries (clearing them).

This got particularly prominent with PTI, which turns SHARED_KERNEL_PMD
off and makes this the dominant mapping mode on 32-bit.

To make LDT working again vmalloc_sync_all() must only iterate over
the volatile parts of the kernel address range that are identical
between all processes.

So the correct check in vmalloc_sync_all() is "address < VMALLOC_END"
to make sure the VMALLOC areas are synchronized and the LDT
mapping is not falsely overwritten.

The CPU_ENTRY_AREA and the FIXMAP area are no longer synced either,
but this is not really a proplem since their PMDs get established
during bootup and never change.

This change fixes the ldt_gdt selftest in my setup.

[ mingo: Fixed up the changelog to explain the logic and modified the
copying to only happen up until VMALLOC_END. ]

Reported-by: Borislav Petkov <[email protected]>
Tested-by: Borislav Petkov <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Cc: <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Fixes: 7757d607c6b3: ("x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32")
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -197,7 +197,7 @@ void vmalloc_sync_all(void)
return;

for (address = VMALLOC_START & PMD_MASK;
- address >= TASK_SIZE_MAX && address < FIXADDR_TOP;
+ address >= TASK_SIZE_MAX && address < VMALLOC_END;
address += PMD_SIZE) {
struct page *page;



2019-12-11 15:15:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 046/105] fuse: verify attributes

From: Miklos Szeredi <[email protected]>

commit eb59bd17d2fa6e5e84fba61a5ebdea984222e6d5 upstream.

If a filesystem returns negative inode sizes, future reads on the file were
causing the cpu to spin on truncate_pagecache.

Create a helper to validate the attributes. This now does two things:

- check the file mode
- check if the file size fits in i_size without overflowing

Reported-by: Arijit Banerjee <[email protected]>
Fixes: d8a5ba45457e ("[PATCH] FUSE - core")
Cc: <[email protected]> # v2.6.14
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/fuse/dir.c | 22 ++++++++++++++++------
fs/fuse/fuse_i.h | 2 ++
fs/fuse/readdir.c | 2 +-
3 files changed, 19 insertions(+), 7 deletions(-)

--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -214,7 +214,8 @@ static int fuse_dentry_revalidate(struct
kfree(forget);
if (ret == -ENOMEM)
goto out;
- if (ret || (outarg.attr.mode ^ inode->i_mode) & S_IFMT)
+ if (ret || fuse_invalid_attr(&outarg.attr) ||
+ (outarg.attr.mode ^ inode->i_mode) & S_IFMT)
goto invalid;

forget_all_cached_acls(inode);
@@ -272,6 +273,12 @@ int fuse_valid_type(int m)
S_ISBLK(m) || S_ISFIFO(m) || S_ISSOCK(m);
}

+bool fuse_invalid_attr(struct fuse_attr *attr)
+{
+ return !fuse_valid_type(attr->mode) ||
+ attr->size > LLONG_MAX;
+}
+
int fuse_lookup_name(struct super_block *sb, u64 nodeid, const struct qstr *name,
struct fuse_entry_out *outarg, struct inode **inode)
{
@@ -303,7 +310,7 @@ int fuse_lookup_name(struct super_block
err = -EIO;
if (!outarg->nodeid)
goto out_put_forget;
- if (!fuse_valid_type(outarg->attr.mode))
+ if (fuse_invalid_attr(&outarg->attr))
goto out_put_forget;

*inode = fuse_iget(sb, outarg->nodeid, outarg->generation,
@@ -427,7 +434,8 @@ static int fuse_create_open(struct inode
goto out_free_ff;

err = -EIO;
- if (!S_ISREG(outentry.attr.mode) || invalid_nodeid(outentry.nodeid))
+ if (!S_ISREG(outentry.attr.mode) || invalid_nodeid(outentry.nodeid) ||
+ fuse_invalid_attr(&outentry.attr))
goto out_free_ff;

ff->fh = outopen.fh;
@@ -535,7 +543,7 @@ static int create_new_entry(struct fuse_
goto out_put_forget_req;

err = -EIO;
- if (invalid_nodeid(outarg.nodeid))
+ if (invalid_nodeid(outarg.nodeid) || fuse_invalid_attr(&outarg.attr))
goto out_put_forget_req;

if ((outarg.attr.mode ^ mode) & S_IFMT)
@@ -895,7 +903,8 @@ static int fuse_do_getattr(struct inode
args.out.args[0].value = &outarg;
err = fuse_simple_request(fc, &args);
if (!err) {
- if ((inode->i_mode ^ outarg.attr.mode) & S_IFMT) {
+ if (fuse_invalid_attr(&outarg.attr) ||
+ (inode->i_mode ^ outarg.attr.mode) & S_IFMT) {
make_bad_inode(inode);
err = -EIO;
} else {
@@ -1518,7 +1527,8 @@ int fuse_do_setattr(struct dentry *dentr
goto error;
}

- if ((inode->i_mode ^ outarg.attr.mode) & S_IFMT) {
+ if (fuse_invalid_attr(&outarg.attr) ||
+ (inode->i_mode ^ outarg.attr.mode) & S_IFMT) {
make_bad_inode(inode);
err = -EIO;
goto error;
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -1008,6 +1008,8 @@ void fuse_ctl_remove_conn(struct fuse_co
*/
int fuse_valid_type(int m);

+bool fuse_invalid_attr(struct fuse_attr *attr);
+
/**
* Is current process allowed to perform filesystem operation?
*/
--- a/fs/fuse/readdir.c
+++ b/fs/fuse/readdir.c
@@ -184,7 +184,7 @@ static int fuse_direntplus_link(struct f

if (invalid_nodeid(o->nodeid))
return -EIO;
- if (!fuse_valid_type(o->attr.mode))
+ if (fuse_invalid_attr(&o->attr))
return -EIO;

fc = get_fuse_conn(dir);


2019-12-11 15:16:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 056/105] Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash

From: Lucas Stach <[email protected]>

commit 86bcd3a12999447faad60ec59c2d64d18d8e61ac upstream.

F34 is a bit special as it reinitializes the device and related driver
structs during the firmware update. This clears the fn_irq_mask which
will then prevent F34 from receiving further interrupts, leading to
timeouts during the firmware update. Make sure to reinitialize the
IRQ enables at the appropriate times.

The issue is in F34 code, but the commit in the fixes tag exposed the
issue, as before this commit things would work by accident.

Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs)
Signed-off-by: Lucas Stach <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/rmi4/rmi_f34v7.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/input/rmi4/rmi_f34v7.c
+++ b/drivers/input/rmi4/rmi_f34v7.c
@@ -1189,6 +1189,9 @@ int rmi_f34v7_do_reflash(struct f34_data
{
int ret;

+ f34->fn->rmi_dev->driver->set_irq_bits(f34->fn->rmi_dev,
+ f34->fn->irq_mask);
+
rmi_f34v7_read_queries_bl_version(f34);

f34->v7.image = fw->data;


2019-12-11 15:16:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 075/105] arm64: dts: exynos: Revert "Remove unneeded address space mapping for soc node"

From: Marek Szyprowski <[email protected]>

commit bed903167ae5b5532eda5d7db26de451bd232da5 upstream.

Commit ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space
mapping for soc node") changed the address and size cells in root node from
2 to 1, but /memory nodes for the affected boards were not updated. This
went unnoticed on Exynos5433-based TM2(e) boards, because they use u-boot,
which updates /memory node to the correct values. On the other hand, the
mentioned commit broke boot on Exynos7-based Espresso board, which
bootloader doesn't touch /memory node at all.

This patch reverts commit ef72171b3621 ("arm64: dts: exynos: Remove
unneeded address space mapping for soc node"), so Exynos5433 and Exynos7
SoCs again matches other ARM64 platforms with 64bit mappings in root
node.

Reported-by: Alim Akhtar <[email protected]>
Fixes: ef72171b3621 ("arm64: dts: exynos: Remove unneeded address space mapping for soc node")
Signed-off-by: Marek Szyprowski <[email protected]>
Cc: <[email protected]> # 5.3.x: 72ddcf6aa224 arm64: dts: exynos: Move GPU under /soc node for Exynos5433
Cc: <[email protected]> # 5.3.x: ede87c3a2bdb arm64: dts: exynos: Move GPU under /soc node for Exynos7
Cc: <[email protected]> # 4.18.x
Tested-by: Alim Akhtar <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -18,8 +18,8 @@

/ {
compatible = "samsung,exynos5433";
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;

interrupt-parent = <&gic>;

@@ -311,7 +311,7 @@
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
- ranges;
+ ranges = <0x0 0x0 0x0 0x18000000>;

chipid@10000000 {
compatible = "samsung,exynos4210-chipid";
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -12,8 +12,8 @@
/ {
compatible = "samsung,exynos7";
interrupt-parent = <&gic>;
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;

aliases {
pinctrl0 = &pinctrl_alive;
@@ -98,7 +98,7 @@
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
- ranges;
+ ranges = <0 0 0 0x18000000>;

chipid@10000000 {
compatible = "samsung,exynos4210-chipid";


2019-12-11 15:16:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 100/105] iomap: Fix pipe page leakage during splicing

From: Jan Kara <[email protected]>

commit 419e9c38aa075ed0cd3c13d47e15954b686bcdb6 upstream.

When splicing using iomap_dio_rw() to a pipe, we may leak pipe pages
because bio_iov_iter_get_pages() records that the pipe will have full
extent worth of data however if file size is not block size aligned
iomap_dio_rw() returns less than what bio_iov_iter_get_pages() set up
and splice code gets confused leaking a pipe page with the file tail.

Handle the situation similarly to the old direct IO implementation and
revert iter to actually returned read amount which makes iter consistent
with value returned from iomap_dio_rw() and thus the splice code is
happy.

Fixes: ff6a9292e6f6 ("iomap: implement direct I/O")
CC: [email protected]
Reported-by: [email protected]
Signed-off-by: Jan Kara <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Signed-off-by: Darrick J. Wong <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/iomap/direct-io.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -501,8 +501,15 @@ iomap_dio_rw(struct kiocb *iocb, struct
}
pos += ret;

- if (iov_iter_rw(iter) == READ && pos >= dio->i_size)
+ if (iov_iter_rw(iter) == READ && pos >= dio->i_size) {
+ /*
+ * We only report that we've read data up to i_size.
+ * Revert iter to a state corresponding to that as
+ * some callers (such as splice code) rely on it.
+ */
+ iov_iter_revert(iter, pos - dio->i_size);
break;
+ }
} while ((count = iov_iter_count(iter)) > 0);
blk_finish_plug(&plug);



2019-12-11 15:17:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 073/105] drm: damage_helper: Fix race checking plane->state->fb

From: Sean Paul <[email protected]>

commit 354c2d310082d1c384213ba76c3757dd3cd8755d upstream.

Since the dirtyfb ioctl doesn't give us any hints as to which plane is
scanning out the fb it's marking as damaged, we need to loop through
planes to find it.

Currently we just reach into plane state and check, but that can race
with another commit changing the fb out from under us. This patch locks
the plane before checking the fb and will release the lock if the plane
is not displaying the dirty fb.

Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
Cc: Rob Clark <[email protected]>
Cc: Deepak Rawat <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Thomas Hellstrom <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # v5.0+
Reported-by: Daniel Vetter <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/drm_damage_helper.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -212,8 +212,14 @@ retry:
drm_for_each_plane(plane, fb->dev) {
struct drm_plane_state *plane_state;

- if (plane->state->fb != fb)
+ ret = drm_modeset_lock(&plane->mutex, state->acquire_ctx);
+ if (ret)
+ goto out;
+
+ if (plane->state->fb != fb) {
+ drm_modeset_unlock(&plane->mutex);
continue;
+ }

plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {


2019-12-11 15:17:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 072/105] drm/msm: fix memleak on release

From: Johan Hovold <[email protected]>

commit a64fc11b9a520c55ca34d82e5ca32274f49b6b15 upstream.

If a process is interrupted while accessing the "gpu" debugfs file and
the drm device struct_mutex is contended, release() could return early
and fail to free related resources.

Note that the return value from release() is ignored.

Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state")
Cc: stable <[email protected]> # 4.18
Cc: Jordan Crouse <[email protected]>
Cc: Rob Clark <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/msm/msm_debugfs.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -42,12 +42,8 @@ static int msm_gpu_release(struct inode
struct msm_gpu_show_priv *show_priv = m->private;
struct msm_drm_private *priv = show_priv->dev->dev_private;
struct msm_gpu *gpu = priv->gpu;
- int ret;
-
- ret = mutex_lock_interruptible(&show_priv->dev->struct_mutex);
- if (ret)
- return ret;

+ mutex_lock(&show_priv->dev->struct_mutex);
gpu->funcs->gpu_state_put(show_priv->state);
mutex_unlock(&show_priv->dev->struct_mutex);



2019-12-11 15:17:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 047/105] io_uring: ensure req->submit is copied when req is deferred

From: Jens Axboe <[email protected]>

There's an issue with deferred requests through drain, where if we do
need to defer, we're not copying over the sqe_submit state correctly.
This can result in using uninitialized data when we then later go and
submit the deferred request, like this check in __io_submit_sqe():

if (unlikely(s->index >= ctx->sq_entries))
return -EINVAL;

with 's' being uninitialized, we can randomly fail this check. Fix this
by copying sqe_submit state when we defer a request.

Because it was fixed as part of a cleanup series in mainline, before
anyone realized we had this issue. That removed the separate states
of ->index vs ->submit.sqe. That series is not something I was
comfortable putting into stable, hence the much simpler addition.
Here's the patch in the series that fixes the same issue:

commit cf6fd4bd559ee61a4454b161863c8de6f30f8dca
Author: Pavel Begunkov <[email protected]>
Date: Mon Nov 25 23:14:39 2019 +0300

io_uring: inline struct sqe_submit

Reported-by: Andres Freund <[email protected]>
Reported-by: Tomáš Chaloupka
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/io_uring.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1787,7 +1787,7 @@ static int io_poll_add(struct io_kiocb *
}

static int io_req_defer(struct io_ring_ctx *ctx, struct io_kiocb *req,
- const struct io_uring_sqe *sqe)
+ struct sqe_submit *s)
{
struct io_uring_sqe *sqe_copy;

@@ -1805,7 +1805,8 @@ static int io_req_defer(struct io_ring_c
return 0;
}

- memcpy(sqe_copy, sqe, sizeof(*sqe_copy));
+ memcpy(&req->submit, s, sizeof(*s));
+ memcpy(sqe_copy, s->sqe, sizeof(*sqe_copy));
req->submit.sqe = sqe_copy;

INIT_WORK(&req->work, io_sq_wq_submit_work);
@@ -2114,7 +2115,7 @@ static int io_queue_sqe(struct io_ring_c
{
int ret;

- ret = io_req_defer(ctx, req, s->sqe);
+ ret = io_req_defer(ctx, req, s);
if (ret) {
if (ret != -EIOCBQUEUED) {
io_free_req(req);


2019-12-11 15:17:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 081/105] KVM: x86: do not modify masked bits of shared MSRs

From: Paolo Bonzini <[email protected]>

commit de1fca5d6e0105c9d33924e1247e2f386efc3ece upstream.

"Shared MSRs" are guest MSRs that are written to the host MSRs but
keep their value until the next return to userspace. They support
a mask, so that some bits keep the host value, but this mask is
only used to skip an unnecessary MSR write and the value written
to the MSR is always the guest MSR.

Fix this and, while at it, do not update smsr->values[slot].curr if
for whatever reason the wrmsr fails. This should only happen due to
reserved bits, so the value written to smsr->values[slot].curr
will not match when the user-return notifier and the host value will
always be restored. However, it is untidy and in rare cases this
can actually avoid spurious WRMSRs on return to userspace.

Cc: [email protected]
Reviewed-by: Jim Mattson <[email protected]>
Tested-by: Jim Mattson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/x86.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -300,13 +300,14 @@ int kvm_set_shared_msr(unsigned slot, u6
struct kvm_shared_msrs *smsr = per_cpu_ptr(shared_msrs, cpu);
int err;

- if (((value ^ smsr->values[slot].curr) & mask) == 0)
+ value = (value & mask) | (smsr->values[slot].host & ~mask);
+ if (value == smsr->values[slot].curr)
return 0;
- smsr->values[slot].curr = value;
err = wrmsrl_safe(shared_msrs_global.msrs[slot], value);
if (err)
return 1;

+ smsr->values[slot].curr = value;
if (!smsr->registered) {
smsr->urn.on_user_return = kvm_on_user_return;
user_return_notifier_register(&smsr->urn);


2019-12-11 15:17:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 050/105] ALSA: hda/realtek - Enable the headset-mic on a Xiaomis laptop

From: Hui Wang <[email protected]>

commit 695d1ec3994f9de2cefae80ee2087c95d2e5a2f3 upstream.

The headset on this machine is not defined, after applying the quirk
ALC256_FIXUP_ASUS_HEADSET_MIC, the headset-mic works well

BugLink: https://bugs.launchpad.net/bugs/1846148
Cc: <[email protected]>
Signed-off-by: Hui Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7227,6 +7227,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9", ALC256_FIXUP_HUAWEI_MACH_WX9_PINS),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
+ SND_PCI_QUIRK(0x1d72, 0x1901, "RedmiBook 14", ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x10ec, 0x118c, "Medion EE4254 MD62100", ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE),

#if 0


2019-12-11 15:17:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 052/105] ALSA: pcm: oss: Avoid potential buffer overflows

From: Takashi Iwai <[email protected]>

commit 4cc8d6505ab82db3357613d36e6c58a297f57f7c upstream.

syzkaller reported an invalid access in PCM OSS read, and this seems
to be an overflow of the internal buffer allocated for a plugin.
Since the rate plugin adjusts its transfer size dynamically, the
calculation for the chained plugin might be bigger than the given
buffer size in some extreme cases, which lead to such an buffer
overflow as caught by KASAN.

Fix it by limiting the max transfer size properly by checking against
the destination size in each plugin transfer callback.

Reported-by: [email protected]
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/oss/linear.c | 2 ++
sound/core/oss/mulaw.c | 2 ++
sound/core/oss/route.c | 2 ++
3 files changed, 6 insertions(+)

--- a/sound/core/oss/linear.c
+++ b/sound/core/oss/linear.c
@@ -107,6 +107,8 @@ static snd_pcm_sframes_t linear_transfer
}
}
#endif
+ if (frames > dst_channels[0].frames)
+ frames = dst_channels[0].frames;
convert(plugin, src_channels, dst_channels, frames);
return frames;
}
--- a/sound/core/oss/mulaw.c
+++ b/sound/core/oss/mulaw.c
@@ -269,6 +269,8 @@ static snd_pcm_sframes_t mulaw_transfer(
}
}
#endif
+ if (frames > dst_channels[0].frames)
+ frames = dst_channels[0].frames;
data = (struct mulaw_priv *)plugin->extra_data;
data->func(plugin, src_channels, dst_channels, frames);
return frames;
--- a/sound/core/oss/route.c
+++ b/sound/core/oss/route.c
@@ -57,6 +57,8 @@ static snd_pcm_sframes_t route_transfer(
return -ENXIO;
if (frames == 0)
return 0;
+ if (frames > dst_channels[0].frames)
+ frames = dst_channels[0].frames;

nsrcs = plugin->src_format.channels;
ndsts = plugin->dst_format.channels;


2019-12-11 15:17:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 051/105] ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236

From: Kailang Yang <[email protected]>

commit e1e8c1fdce8b00fce08784d9d738c60ebf598ebc upstream.

headphone have noise even the volume is very small.
Let it fill up pcbeep hidden register to default value.
The issue was gone.

Fixes: 4344aec84bd8 ("ALSA: hda/realtek - New codec support for ALC256")
Fixes: 736f20a70608 ("ALSA: hda/realtek - Add support for ALC236/ALC3204")
Signed-off-by: Kailang Yang <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_realtek.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -367,9 +367,7 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0215:
case 0x10ec0233:
case 0x10ec0235:
- case 0x10ec0236:
case 0x10ec0255:
- case 0x10ec0256:
case 0x10ec0257:
case 0x10ec0282:
case 0x10ec0283:
@@ -381,6 +379,11 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0300:
alc_update_coef_idx(codec, 0x10, 1<<9, 0);
break;
+ case 0x10ec0236:
+ case 0x10ec0256:
+ alc_write_coef_idx(codec, 0x36, 0x5757);
+ alc_update_coef_idx(codec, 0x10, 1<<9, 0);
+ break;
case 0x10ec0275:
alc_update_coef_idx(codec, 0xe, 0, 1<<0);
break;


2019-12-11 15:17:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 087/105] crypto: af_alg - cast ki_complete ternary op to int

From: Ayush Sawal <[email protected]>

commit 64e7f852c47ce99f6c324c46d6a299a5a7ebead9 upstream.

when libkcapi test is executed using HW accelerator, cipher operation
return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int,
libkcapi receive 429467222 even though it expect -ve value.

Hence its required to cast resultlen to int so that proper
error is returned to libkcapi.

AEAD one shot non-aligned test 2(libkcapi test)
./../bin/kcapi -x 10 -c "gcm(aes)" -i 7815d4b06ae50c9c56e87bd7
-k ea38ac0c9b9998c80e28fb496a2b88d9 -a
"853f98a750098bec1aa7497e979e78098155c877879556bb51ddeb6374cbaefc"
-t "c4ce58985b7203094be1d134c1b8ab0b" -q
"b03692f86d1b8b39baf2abb255197c98"

Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management")
Cc: <[email protected]>
Signed-off-by: Ayush Sawal <[email protected]>
Signed-off-by: Atul Gupta <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Ayush Sawal <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -1043,7 +1043,7 @@ void af_alg_async_cb(struct crypto_async
af_alg_free_resources(areq);
sock_put(sk);

- iocb->ki_complete(iocb, err ? err : resultlen, 0);
+ iocb->ki_complete(iocb, err ? err : (int)resultlen, 0);
}
EXPORT_SYMBOL_GPL(af_alg_async_cb);



2019-12-11 15:17:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 089/105] crypto: ccp - fix uninitialized list head

From: Mark Salter <[email protected]>

commit 691505a803a7f223b2af621848d581259c61f77d upstream.

A NULL-pointer dereference was reported in fedora bz#1762199 while
reshaping a raid6 array after adding a fifth drive to an existing
array.

[ 47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2
[ 47.804017] md0: detected capacity change from 0 to 7885289422848
[ 47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000
...
[ 47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G W 5.2.18-200.fc30.aarch64 #1
[ 47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016
[ 47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO)
[ 47.963668] pc : __list_del_entry_valid+0x2c/0xa8
[ 47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp]
[ 47.972882] sp : ffff00001369b970
[ 47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8
[ 47.981483] x27: 00000000ffffffff x26: ffff8003b758af70
[ 47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818
[ 47.992080] x23: 0000000000000000 x22: ffff8003e62450c0
[ 47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003
[ 48.002678] x19: ffff8003e6245100 x18: 0000000000000000
[ 48.007976] x17: 0000000000000000 x16: 0000000000000000
[ 48.013274] x15: 0000000000000000 x14: 0000000000000000
[ 48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001
[ 48.023870] x11: ffff000010eff998 x10: 00000000000019a0
[ 48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180
[ 48.034467] x7 : 0000000000000000 x6 : 000000000000003f
[ 48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080
[ 48.045064] x3 : dead000000000200 x2 : 0000000000000000
[ 48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0
[ 48.055660] Call trace:
[ 48.058095] __list_del_entry_valid+0x2c/0xa8
[ 48.062442] ccp_tx_submit+0x84/0x168 [ccp]
[ 48.066615] async_tx_submit+0x224/0x368 [async_tx]
[ 48.071480] async_trigger_callback+0x68/0xfc [async_tx]
[ 48.076784] ops_run_biofill+0x178/0x1e8 [raid456]
[ 48.081566] raid_run_ops+0x248/0x818 [raid456]
[ 48.086086] handle_stripe+0x864/0x1208 [raid456]
[ 48.090781] handle_active_stripes.isra.0+0xb0/0x278 [raid456]
[ 48.096604] raid5d+0x378/0x618 [raid456]
[ 48.100602] md_thread+0xa0/0x150
[ 48.103905] kthread+0x104/0x130
[ 48.107122] ret_from_fork+0x10/0x18
[ 48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021)
[ 48.116766] ---[ end trace 23f390a527f7ad77 ]---

ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in
a ccp_dma_desc and adds it to a ccp channel's pending list:

list_del(&desc->entry);
list_add_tail(&desc->entry, &chan->pending);

The problem is that desc->entry may be uninitialized in the
async_trigger_callback path where the descriptor was gotten
from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc
which doesn't initialize the desc->entry list head. So, just
initialize the list head to avoid the problem.

Cc: <[email protected]>
Reported-by: Sahaj Sarup <[email protected]>
Signed-off-by: Mark Salter <[email protected]>
Acked-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/ccp/ccp-dmaengine.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/crypto/ccp/ccp-dmaengine.c
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -337,6 +337,7 @@ static struct ccp_dma_desc *ccp_alloc_dm
desc->tx_desc.flags = flags;
desc->tx_desc.tx_submit = ccp_tx_submit;
desc->ccp = chan->ccp;
+ INIT_LIST_HEAD(&desc->entry);
INIT_LIST_HEAD(&desc->pending);
INIT_LIST_HEAD(&desc->active);
desc->status = DMA_IN_PROGRESS;


2019-12-11 15:17:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 084/105] KVM: x86: Grab KVMs srcu lock when setting nested state

From: Sean Christopherson <[email protected]>

commit ad5996d9a0e8019c3ae5151e687939369acfe044 upstream.

Acquire kvm->srcu for the duration of ->set_nested_state() to fix a bug
where nVMX derefences ->memslots without holding ->srcu or ->slots_lock.

The other half of nested migration, ->get_nested_state(), does not need
to acquire ->srcu as it is a purely a dump of internal KVM (and CPU)
state to userspace.

Detected as an RCU lockdep splat that is 100% reproducible by running
KVM's state_test selftest with CONFIG_PROVE_LOCKING=y. Note that the
failing function, kvm_is_visible_gfn(), is only checking the validity of
a gfn, it's not actually accessing guest memory (which is more or less
unsupported during vmx_set_nested_state() due to incorrect MMU state),
i.e. vmx_set_nested_state() itself isn't fundamentally broken. In any
case, setting nested state isn't a fast path so there's no reason to go
out of our way to avoid taking ->srcu.

=============================
WARNING: suspicious RCU usage
5.4.0-rc7+ #94 Not tainted
-----------------------------
include/linux/kvm_host.h:626 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by evmcs_test/10939:
#0: ffff88826ffcb800 (&vcpu->mutex){+.+.}, at: kvm_vcpu_ioctl+0x85/0x630 [kvm]

stack backtrace:
CPU: 1 PID: 10939 Comm: evmcs_test Not tainted 5.4.0-rc7+ #94
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:
dump_stack+0x68/0x9b
kvm_is_visible_gfn+0x179/0x180 [kvm]
mmu_check_root+0x11/0x30 [kvm]
fast_cr3_switch+0x40/0x120 [kvm]
kvm_mmu_new_cr3+0x34/0x60 [kvm]
nested_vmx_load_cr3+0xbd/0x1f0 [kvm_intel]
nested_vmx_enter_non_root_mode+0xab8/0x1d60 [kvm_intel]
vmx_set_nested_state+0x256/0x340 [kvm_intel]
kvm_arch_vcpu_ioctl+0x491/0x11a0 [kvm]
kvm_vcpu_ioctl+0xde/0x630 [kvm]
do_vfs_ioctl+0xa2/0x6c0
ksys_ioctl+0x66/0x70
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x54/0x200
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f59a2b95f47

Fixes: 8fcc4b5923af5 ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
Cc: [email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/x86.c | 3 +++
1 file changed, 3 insertions(+)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4333,6 +4333,7 @@ long kvm_arch_vcpu_ioctl(struct file *fi
case KVM_SET_NESTED_STATE: {
struct kvm_nested_state __user *user_kvm_nested_state = argp;
struct kvm_nested_state kvm_state;
+ int idx;

r = -EINVAL;
if (!kvm_x86_ops->set_nested_state)
@@ -4356,7 +4357,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi
&& !(kvm_state.flags & KVM_STATE_NESTED_GUEST_MODE))
break;

+ idx = srcu_read_lock(&vcpu->kvm->srcu);
r = kvm_x86_ops->set_nested_state(vcpu, user_kvm_nested_state, &kvm_state);
+ srcu_read_unlock(&vcpu->kvm->srcu, idx);
break;
}
case KVM_GET_SUPPORTED_HV_CPUID: {


2019-12-11 15:31:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 024/105] ALSA: hda: Add Cometlake-S PCI ID

From: Chiou, Cooper <[email protected]>

[ Upstream commit b73a58549ea37a44434c7afab3c7ad9af210cfd9 ]

Add HD Audio Device PCI ID for the Intel Cometlake-S platform

Signed-off-by: Chiou, Cooper <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
sound/pci/hda/hda_intel.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e1791d01ccc01..46c2b1022495f 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2428,6 +2428,9 @@ static const struct pci_device_id azx_ids[] = {
/* CometLake-H */
{ PCI_DEVICE(0x8086, 0x06C8),
.driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
+ /* CometLake-S */
+ { PCI_DEVICE(0x8086, 0xa3f0),
+ .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
/* Icelake */
{ PCI_DEVICE(0x8086, 0x34c8),
.driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE},
--
2.20.1



2019-12-11 15:56:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 092/105] crypto: user - fix memory leak in crypto_reportstat

From: Navid Emamdoost <[email protected]>

commit c03b04dcdba1da39903e23cc4d072abf8f68f2dd upstream.

In crypto_reportstat, a new skb is created by nlmsg_new(). This skb is
leaked if crypto_reportstat_alg() fails. Required release for skb is
added.

Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto statistics")
Cc: <[email protected]>
Signed-off-by: Navid Emamdoost <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/crypto_user_stat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/crypto/crypto_user_stat.c
+++ b/crypto/crypto_user_stat.c
@@ -326,8 +326,10 @@ int crypto_reportstat(struct sk_buff *in
drop_alg:
crypto_mod_put(alg);

- if (err)
+ if (err) {
+ kfree_skb(skb);
return err;
+ }

return nlmsg_unicast(crypto_nlsk, skb, NETLINK_CB(in_skb).portid);
}


2019-12-11 15:56:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 093/105] spi: spi-fsl-qspi: Clear TDH bits in FLSHCR register

From: Frieder Schrempf <[email protected]>

commit f6910679e17ad4915f008bd2c614d38052426f7c upstream.

Later versions of the QSPI controller (e.g. in i.MX6UL/ULL and i.MX7)
seem to have an additional TDH setting in the FLSHCR register, that
needs to be set in accordance with the access mode that is used (DDR
or SDR).

Previous bootstages such as BootROM or bootloader might have used the
DDR mode to access the flash. As we currently only use SDR mode, we
need to make sure the TDH bits are cleared upon initialization.

Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller")
Cc: <[email protected]>
Signed-off-by: Frieder Schrempf <[email protected]>
Acked-by: Han Xu <[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/spi/spi-fsl-qspi.c | 38 +++++++++++++++++++++++++++++++++-----
1 file changed, 33 insertions(+), 5 deletions(-)

--- a/drivers/spi/spi-fsl-qspi.c
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -63,6 +63,11 @@
#define QUADSPI_IPCR 0x08
#define QUADSPI_IPCR_SEQID(x) ((x) << 24)

+#define QUADSPI_FLSHCR 0x0c
+#define QUADSPI_FLSHCR_TCSS_MASK GENMASK(3, 0)
+#define QUADSPI_FLSHCR_TCSH_MASK GENMASK(11, 8)
+#define QUADSPI_FLSHCR_TDH_MASK GENMASK(17, 16)
+
#define QUADSPI_BUF3CR 0x1c
#define QUADSPI_BUF3CR_ALLMST_MASK BIT(31)
#define QUADSPI_BUF3CR_ADATSZ(x) ((x) << 8)
@@ -95,6 +100,9 @@
#define QUADSPI_FR 0x160
#define QUADSPI_FR_TFF_MASK BIT(0)

+#define QUADSPI_RSER 0x164
+#define QUADSPI_RSER_TFIE BIT(0)
+
#define QUADSPI_SPTRCLR 0x16c
#define QUADSPI_SPTRCLR_IPPTRC BIT(8)
#define QUADSPI_SPTRCLR_BFPTRC BIT(0)
@@ -112,9 +120,6 @@
#define QUADSPI_LCKER_LOCK BIT(0)
#define QUADSPI_LCKER_UNLOCK BIT(1)

-#define QUADSPI_RSER 0x164
-#define QUADSPI_RSER_TFIE BIT(0)
-
#define QUADSPI_LUT_BASE 0x310
#define QUADSPI_LUT_OFFSET (SEQID_LUT * 4 * 4)
#define QUADSPI_LUT_REG(idx) \
@@ -181,6 +186,12 @@
*/
#define QUADSPI_QUIRK_BASE_INTERNAL BIT(4)

+/*
+ * Controller uses TDH bits in register QUADSPI_FLSHCR.
+ * They need to be set in accordance with the DDR/SDR mode.
+ */
+#define QUADSPI_QUIRK_USE_TDH_SETTING BIT(5)
+
struct fsl_qspi_devtype_data {
unsigned int rxfifo;
unsigned int txfifo;
@@ -209,7 +220,8 @@ static const struct fsl_qspi_devtype_dat
.rxfifo = SZ_128,
.txfifo = SZ_512,
.ahb_buf_size = SZ_1K,
- .quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_QUIRK_4X_INT_CLK,
+ .quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_QUIRK_4X_INT_CLK |
+ QUADSPI_QUIRK_USE_TDH_SETTING,
.little_endian = true,
};

@@ -217,7 +229,8 @@ static const struct fsl_qspi_devtype_dat
.rxfifo = SZ_128,
.txfifo = SZ_512,
.ahb_buf_size = SZ_1K,
- .quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_QUIRK_4X_INT_CLK,
+ .quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_QUIRK_4X_INT_CLK |
+ QUADSPI_QUIRK_USE_TDH_SETTING,
.little_endian = true,
};

@@ -275,6 +288,11 @@ static inline int needs_amba_base_offset
return !(q->devtype_data->quirks & QUADSPI_QUIRK_BASE_INTERNAL);
}

+static inline int needs_tdh_setting(struct fsl_qspi *q)
+{
+ return q->devtype_data->quirks & QUADSPI_QUIRK_USE_TDH_SETTING;
+}
+
/*
* An IC bug makes it necessary to rearrange the 32-bit data.
* Later chips, such as IMX6SLX, have fixed this bug.
@@ -710,6 +728,16 @@ static int fsl_qspi_default_setup(struct
qspi_writel(q, QUADSPI_MCR_MDIS_MASK | QUADSPI_MCR_RESERVED_MASK,
base + QUADSPI_MCR);

+ /*
+ * Previous boot stages (BootROM, bootloader) might have used DDR
+ * mode and did not clear the TDH bits. As we currently use SDR mode
+ * only, clear the TDH bits if necessary.
+ */
+ if (needs_tdh_setting(q))
+ qspi_writel(q, qspi_readl(q, base + QUADSPI_FLSHCR) &
+ ~QUADSPI_FLSHCR_TDH_MASK,
+ base + QUADSPI_FLSHCR);
+
reg = qspi_readl(q, base + QUADSPI_SMPR);
qspi_writel(q, reg & ~(QUADSPI_SMPR_FSDLY_MASK
| QUADSPI_SMPR_FSPHS_MASK


2019-12-11 15:57:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 053/105] ALSA: hda - Add mute led support for HP ProBook 645 G4

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

commit e190de6941db14813032af87873f5550ad5764fe upstream.

Mic mute led does not work on HP ProBook 645 G4.
We can use CXT_FIXUP_MUTE_LED_GPIO fixup to support it.

Signed-off-by: Kai-Heng Feng <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_conexant.c | 1 +
1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -910,6 +910,7 @@ static const struct snd_pci_quirk cxt506
SND_PCI_QUIRK(0x103c, 0x837f, "HP ProBook 470 G5", CXT_FIXUP_MUTE_LED_GPIO),
SND_PCI_QUIRK(0x103c, 0x8299, "HP 800 G3 SFF", CXT_FIXUP_HP_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x829a, "HP 800 G3 DM", CXT_FIXUP_HP_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x103c, 0x8402, "HP ProBook 645 G4", CXT_FIXUP_MUTE_LED_GPIO),
SND_PCI_QUIRK(0x103c, 0x8455, "HP Z2 G4", CXT_FIXUP_HP_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x8456, "HP Z2 G4 SFF", CXT_FIXUP_HP_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x8457, "HP Z2 G4 mini", CXT_FIXUP_HP_MIC_NO_PRESENCE),


2019-12-11 15:57:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 105/105] binder: Handle start==NULL in binder_update_page_range()

From: Jann Horn <[email protected]>

commit 2a9edd056ed4fbf9d2e797c3fc06335af35bccc4 upstream.

The old loop wouldn't stop when reaching `start` if `start==NULL`, instead
continuing backwards to index -1 and crashing.

Luckily you need to be highly privileged to map things at NULL, so it's not
a big problem.

Fix it by adjusting the loop so that the loop variable is always in bounds.

This patch is deliberately minimal to simplify backporting, but IMO this
function could use a refactor. The jump labels in the second loop body are
horrible (the error gotos should be jumping to free_range instead), and
both loops would look nicer if they just iterated upwards through indices.
And the up_read()+mmput() shouldn't be duplicated like that.

Cc: [email protected]
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Signed-off-by: Jann Horn <[email protected]>
Acked-by: Christian Brauner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/android/binder_alloc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -277,8 +277,7 @@ static int binder_update_page_range(stru
return 0;

free_range:
- for (page_addr = end - PAGE_SIZE; page_addr >= start;
- page_addr -= PAGE_SIZE) {
+ for (page_addr = end - PAGE_SIZE; 1; page_addr -= PAGE_SIZE) {
bool ret;
size_t index;

@@ -291,6 +290,8 @@ free_range:
WARN_ON(!ret);

trace_binder_free_lru_end(alloc, index);
+ if (page_addr == start)
+ break;
continue;

err_vm_insert_page_failed:
@@ -298,7 +299,8 @@ err_vm_insert_page_failed:
page->page_ptr = NULL;
err_alloc_page_failed:
err_page_ptr_cleared:
- ;
+ if (page_addr == start)
+ break;
}
err_no_vma:
if (mm) {


2019-12-11 15:57:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 091/105] crypto: user - fix memory leak in crypto_report

From: Navid Emamdoost <[email protected]>

commit ffdde5932042600c6807d46c1550b28b0db6a3bc upstream.

In crypto_report, a new skb is created via nlmsg_new(). This skb should
be released if crypto_report_alg() fails.

Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
Cc: <[email protected]>
Signed-off-by: Navid Emamdoost <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/crypto_user_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/crypto/crypto_user_base.c
+++ b/crypto/crypto_user_base.c
@@ -214,8 +214,10 @@ static int crypto_report(struct sk_buff
drop_alg:
crypto_mod_put(alg);

- if (err)
+ if (err) {
+ kfree_skb(skb);
return err;
+ }

return nlmsg_unicast(crypto_nlsk, skb, NETLINK_CB(in_skb).portid);
}


2019-12-11 15:57:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 104/105] binder: Prevent repeated use of ->mmap() via NULL mapping

From: Jann Horn <[email protected]>

commit a7a74d7ff55a0c657bc46238b050460b9eacea95 upstream.

binder_alloc_mmap_handler() attempts to detect the use of ->mmap() on a
binder_proc whose binder_alloc has already been initialized by checking
whether alloc->buffer is non-zero.

Before commit 880211667b20 ("binder: remove kernel vm_area for buffer
space"), alloc->buffer was a kernel mapping address, which is always
non-zero, but since that commit, it is a userspace mapping address.

A sufficiently privileged user can map /dev/binder at NULL, tricking
binder_alloc_mmap_handler() into assuming that the binder_proc has not been
mapped yet. This leads to memory unsafety.
Luckily, no context on Android has such privileges, and on a typical Linux
desktop system, you need to be root to do that.

Fix it by using the mapping size instead of the mapping address to
distinguish the mapped case. A valid VMA can't have size zero.

Fixes: 880211667b20 ("binder: remove kernel vm_area for buffer space")
Cc: [email protected]
Signed-off-by: Jann Horn <[email protected]>
Acked-by: Christian Brauner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/android/binder_alloc.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)

--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -681,17 +681,17 @@ int binder_alloc_mmap_handler(struct bin
struct binder_buffer *buffer;

mutex_lock(&binder_alloc_mmap_lock);
- if (alloc->buffer) {
+ if (alloc->buffer_size) {
ret = -EBUSY;
failure_string = "already mapped";
goto err_already_mapped;
}
+ alloc->buffer_size = min_t(unsigned long, vma->vm_end - vma->vm_start,
+ SZ_4M);
+ mutex_unlock(&binder_alloc_mmap_lock);

alloc->buffer = (void __user *)vma->vm_start;
- mutex_unlock(&binder_alloc_mmap_lock);

- alloc->buffer_size = min_t(unsigned long, vma->vm_end - vma->vm_start,
- SZ_4M);
alloc->pages = kcalloc(alloc->buffer_size / PAGE_SIZE,
sizeof(alloc->pages[0]),
GFP_KERNEL);
@@ -722,8 +722,9 @@ err_alloc_buf_struct_failed:
kfree(alloc->pages);
alloc->pages = NULL;
err_alloc_pages_failed:
- mutex_lock(&binder_alloc_mmap_lock);
alloc->buffer = NULL;
+ mutex_lock(&binder_alloc_mmap_lock);
+ alloc->buffer_size = 0;
err_already_mapped:
mutex_unlock(&binder_alloc_mmap_lock);
binder_alloc_debug(BINDER_DEBUG_USER_ERROR,


2019-12-11 15:57:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 086/105] crypto: atmel-aes - Fix IV handling when req->nbytes < ivsize

From: Tudor Ambarus <[email protected]>

commit 86ef1dfcb561473fbf5e199d58d18c55554d78be upstream.

commit 394a9e044702 ("crypto: cfb - add missing 'chunksize' property")
adds a test vector where the input length is smaller than the IV length
(the second test vector). This revealed a NULL pointer dereference in
the atmel-aes driver, that is caused by passing an incorrect offset in
scatterwalk_map_and_copy() when atmel_aes_complete() is called.

Do not save the IV in req->info of ablkcipher_request (or equivalently
req->iv of skcipher_request) when req->nbytes < ivsize, because the IV
will not be further used.

While touching the code, modify the type of ivsize from int to
unsigned int, to comply with the return type of
crypto_ablkcipher_ivsize().

Fixes: 91308019ecb4 ("crypto: atmel-aes - properly set IV after {en,de}crypt")
Cc: <[email protected]>
Signed-off-by: Tudor Ambarus <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/atmel-aes.c | 53 +++++++++++++++++++++++++--------------------
1 file changed, 30 insertions(+), 23 deletions(-)

--- a/drivers/crypto/atmel-aes.c
+++ b/drivers/crypto/atmel-aes.c
@@ -490,6 +490,29 @@ static inline bool atmel_aes_is_encrypt(
static void atmel_aes_authenc_complete(struct atmel_aes_dev *dd, int err);
#endif

+static void atmel_aes_set_iv_as_last_ciphertext_block(struct atmel_aes_dev *dd)
+{
+ struct ablkcipher_request *req = ablkcipher_request_cast(dd->areq);
+ struct atmel_aes_reqctx *rctx = ablkcipher_request_ctx(req);
+ struct crypto_ablkcipher *ablkcipher = crypto_ablkcipher_reqtfm(req);
+ unsigned int ivsize = crypto_ablkcipher_ivsize(ablkcipher);
+
+ if (req->nbytes < ivsize)
+ return;
+
+ if (rctx->mode & AES_FLAGS_ENCRYPT) {
+ scatterwalk_map_and_copy(req->info, req->dst,
+ req->nbytes - ivsize, ivsize, 0);
+ } else {
+ if (req->src == req->dst)
+ memcpy(req->info, rctx->lastc, ivsize);
+ else
+ scatterwalk_map_and_copy(req->info, req->src,
+ req->nbytes - ivsize,
+ ivsize, 0);
+ }
+}
+
static inline int atmel_aes_complete(struct atmel_aes_dev *dd, int err)
{
#ifdef CONFIG_CRYPTO_DEV_ATMEL_AUTHENC
@@ -500,26 +523,8 @@ static inline int atmel_aes_complete(str
clk_disable(dd->iclk);
dd->flags &= ~AES_FLAGS_BUSY;

- if (!dd->ctx->is_aead) {
- struct ablkcipher_request *req =
- ablkcipher_request_cast(dd->areq);
- struct atmel_aes_reqctx *rctx = ablkcipher_request_ctx(req);
- struct crypto_ablkcipher *ablkcipher =
- crypto_ablkcipher_reqtfm(req);
- int ivsize = crypto_ablkcipher_ivsize(ablkcipher);
-
- if (rctx->mode & AES_FLAGS_ENCRYPT) {
- scatterwalk_map_and_copy(req->info, req->dst,
- req->nbytes - ivsize, ivsize, 0);
- } else {
- if (req->src == req->dst) {
- memcpy(req->info, rctx->lastc, ivsize);
- } else {
- scatterwalk_map_and_copy(req->info, req->src,
- req->nbytes - ivsize, ivsize, 0);
- }
- }
- }
+ if (!dd->ctx->is_aead)
+ atmel_aes_set_iv_as_last_ciphertext_block(dd);

if (dd->is_async)
dd->areq->complete(dd->areq, err);
@@ -1125,10 +1130,12 @@ static int atmel_aes_crypt(struct ablkci
rctx->mode = mode;

if (!(mode & AES_FLAGS_ENCRYPT) && (req->src == req->dst)) {
- int ivsize = crypto_ablkcipher_ivsize(ablkcipher);
+ unsigned int ivsize = crypto_ablkcipher_ivsize(ablkcipher);

- scatterwalk_map_and_copy(rctx->lastc, req->src,
- (req->nbytes - ivsize), ivsize, 0);
+ if (req->nbytes >= ivsize)
+ scatterwalk_map_and_copy(rctx->lastc, req->src,
+ req->nbytes - ivsize,
+ ivsize, 0);
}

return atmel_aes_handle_queue(dd, &req->base);


2019-12-11 15:57:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 090/105] crypto: ecdh - fix big endian bug in ECC library

From: Ard Biesheuvel <[email protected]>

commit f398243e9fd6a3a059c1ea7b380c40628dbf0c61 upstream.

The elliptic curve arithmetic library used by the EC-DH KPP implementation
assumes big endian byte order, and unconditionally reverses the byte
and word order of multi-limb quantities. On big endian systems, the byte
reordering is not necessary, while the word ordering needs to be retained.

So replace the __swab64() invocation with a call to be64_to_cpu() which
should do the right thing for both little and big endian builds.

Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
Cc: <[email protected]> # v4.9+
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/ecc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -1284,10 +1284,11 @@ EXPORT_SYMBOL(ecc_point_mult_shamir);
static inline void ecc_swap_digits(const u64 *in, u64 *out,
unsigned int ndigits)
{
+ const __be64 *src = (__force __be64 *)in;
int i;

for (i = 0; i < ndigits; i++)
- out[i] = __swab64(in[ndigits - 1 - i]);
+ out[i] = be64_to_cpu(src[ndigits - 1 - i]);
}

static int __ecc_is_key_valid(const struct ecc_curve *curve,


2019-12-11 15:57:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 102/105] vcs: prevent write access to vcsu devices

From: Nicolas Pitre <[email protected]>

commit 0c9acb1af77a3cb8707e43f45b72c95266903cee upstream.

Commit d21b0be246bf ("vt: introduce unicode mode for /dev/vcs") guarded
against using devices containing attributes as this is not yet
implemented. It however failed to guard against writes to any devices
as this is also unimplemented.

Reported-by: Or Cohen <[email protected]>
Signed-off-by: Nicolas Pitre <[email protected]>
Cc: <[email protected]> # v4.19+
Cc: Jiri Slaby <[email protected]>
Fixes: d21b0be246bf ("vt: introduce unicode mode for /dev/vcs")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/vt/vc_screen.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -456,6 +456,9 @@ vcs_write(struct file *file, const char
size_t ret;
char *con_buf;

+ if (use_unicode(inode))
+ return -EOPNOTSUPP;
+
con_buf = (char *) __get_free_page(GFP_KERNEL);
if (!con_buf)
return -ENOMEM;


2019-12-11 15:58:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 085/105] crypto: crypto4xx - fix double-free in crypto4xx_destroy_sdr

From: Christian Lamparter <[email protected]>

commit 746c908c4d72e49068ab216c3926d2720d71a90d upstream.

This patch fixes a crash that can happen during probe
when the available dma memory is not enough (this can
happen if the crypto4xx is built as a module).

The descriptor window mapping would end up being free'd
twice, once in crypto4xx_build_pdr() and the second time
in crypto4xx_destroy_sdr().

Fixes: 5d59ad6eea82 ("crypto: crypto4xx - fix crypto4xx_build_pdr, crypto4xx_build_sdr leak")
Cc: <[email protected]>
Signed-off-by: Christian Lamparter <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/amcc/crypto4xx_core.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -365,12 +365,8 @@ static u32 crypto4xx_build_sdr(struct cr
dma_alloc_coherent(dev->core_dev->device,
PPC4XX_SD_BUFFER_SIZE * PPC4XX_NUM_SD,
&dev->scatter_buffer_pa, GFP_ATOMIC);
- if (!dev->scatter_buffer_va) {
- dma_free_coherent(dev->core_dev->device,
- sizeof(struct ce_sd) * PPC4XX_NUM_SD,
- dev->sdr, dev->sdr_pa);
+ if (!dev->scatter_buffer_va)
return -ENOMEM;
- }

for (i = 0; i < PPC4XX_NUM_SD; i++) {
dev->sdr[i].ptr = dev->scatter_buffer_pa +


2019-12-11 15:58:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 088/105] crypto: geode-aes - switch to skcipher for cbc(aes) fallback

From: Ard Biesheuvel <[email protected]>

commit 504582e8e40b90b8f8c58783e2d1e4f6a2b71a3a upstream.

Commit 79c65d179a40e145 ("crypto: cbc - Convert to skcipher") updated
the generic CBC template wrapper from a blkcipher to a skcipher algo,
to get away from the deprecated blkcipher interface. However, as a side
effect, drivers that instantiate CBC transforms using the blkcipher as
a fallback no longer work, since skciphers can wrap blkciphers but not
the other way around. This broke the geode-aes driver.

So let's fix it by moving to the sync skcipher interface when allocating
the fallback. At the same time, align with the generic API for ECB and
CBC by rejecting inputs that are not a multiple of the AES block size.

Fixes: 79c65d179a40e145 ("crypto: cbc - Convert to skcipher")
Cc: <[email protected]> # v4.20+ ONLY
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Florian Bezdeka <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/geode-aes.c | 57 ++++++++++++++++++++++++++-------------------
drivers/crypto/geode-aes.h | 2 -
2 files changed, 34 insertions(+), 25 deletions(-)

--- a/drivers/crypto/geode-aes.c
+++ b/drivers/crypto/geode-aes.c
@@ -10,6 +10,7 @@
#include <linux/spinlock.h>
#include <crypto/algapi.h>
#include <crypto/aes.h>
+#include <crypto/skcipher.h>

#include <linux/io.h>
#include <linux/delay.h>
@@ -166,13 +167,15 @@ static int geode_setkey_blk(struct crypt
/*
* The requested key size is not supported by HW, do a fallback
*/
- op->fallback.blk->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
- op->fallback.blk->base.crt_flags |= (tfm->crt_flags & CRYPTO_TFM_REQ_MASK);
+ crypto_sync_skcipher_clear_flags(op->fallback.blk, CRYPTO_TFM_REQ_MASK);
+ crypto_sync_skcipher_set_flags(op->fallback.blk,
+ tfm->crt_flags & CRYPTO_TFM_REQ_MASK);

- ret = crypto_blkcipher_setkey(op->fallback.blk, key, len);
+ ret = crypto_sync_skcipher_setkey(op->fallback.blk, key, len);
if (ret) {
tfm->crt_flags &= ~CRYPTO_TFM_RES_MASK;
- tfm->crt_flags |= (op->fallback.blk->base.crt_flags & CRYPTO_TFM_RES_MASK);
+ tfm->crt_flags |= crypto_sync_skcipher_get_flags(op->fallback.blk) &
+ CRYPTO_TFM_RES_MASK;
}
return ret;
}
@@ -181,33 +184,28 @@ static int fallback_blk_dec(struct blkci
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
{
- unsigned int ret;
- struct crypto_blkcipher *tfm;
struct geode_aes_op *op = crypto_blkcipher_ctx(desc->tfm);
+ SYNC_SKCIPHER_REQUEST_ON_STACK(req, op->fallback.blk);

- tfm = desc->tfm;
- desc->tfm = op->fallback.blk;
-
- ret = crypto_blkcipher_decrypt_iv(desc, dst, src, nbytes);
+ skcipher_request_set_sync_tfm(req, op->fallback.blk);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);

- desc->tfm = tfm;
- return ret;
+ return crypto_skcipher_decrypt(req);
}
+
static int fallback_blk_enc(struct blkcipher_desc *desc,
struct scatterlist *dst, struct scatterlist *src,
unsigned int nbytes)
{
- unsigned int ret;
- struct crypto_blkcipher *tfm;
struct geode_aes_op *op = crypto_blkcipher_ctx(desc->tfm);
+ SYNC_SKCIPHER_REQUEST_ON_STACK(req, op->fallback.blk);

- tfm = desc->tfm;
- desc->tfm = op->fallback.blk;
-
- ret = crypto_blkcipher_encrypt_iv(desc, dst, src, nbytes);
+ skcipher_request_set_sync_tfm(req, op->fallback.blk);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);

- desc->tfm = tfm;
- return ret;
+ return crypto_skcipher_encrypt(req);
}

static void
@@ -307,6 +305,9 @@ geode_cbc_decrypt(struct blkcipher_desc
struct blkcipher_walk walk;
int err, ret;

+ if (nbytes % AES_BLOCK_SIZE)
+ return -EINVAL;
+
if (unlikely(op->keylen != AES_KEYSIZE_128))
return fallback_blk_dec(desc, dst, src, nbytes);

@@ -339,6 +340,9 @@ geode_cbc_encrypt(struct blkcipher_desc
struct blkcipher_walk walk;
int err, ret;

+ if (nbytes % AES_BLOCK_SIZE)
+ return -EINVAL;
+
if (unlikely(op->keylen != AES_KEYSIZE_128))
return fallback_blk_enc(desc, dst, src, nbytes);

@@ -366,9 +370,8 @@ static int fallback_init_blk(struct cryp
const char *name = crypto_tfm_alg_name(tfm);
struct geode_aes_op *op = crypto_tfm_ctx(tfm);

- op->fallback.blk = crypto_alloc_blkcipher(name, 0,
- CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
-
+ op->fallback.blk = crypto_alloc_sync_skcipher(name, 0,
+ CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(op->fallback.blk)) {
printk(KERN_ERR "Error allocating fallback algo %s\n", name);
return PTR_ERR(op->fallback.blk);
@@ -381,7 +384,7 @@ static void fallback_exit_blk(struct cry
{
struct geode_aes_op *op = crypto_tfm_ctx(tfm);

- crypto_free_blkcipher(op->fallback.blk);
+ crypto_free_sync_skcipher(op->fallback.blk);
op->fallback.blk = NULL;
}

@@ -420,6 +423,9 @@ geode_ecb_decrypt(struct blkcipher_desc
struct blkcipher_walk walk;
int err, ret;

+ if (nbytes % AES_BLOCK_SIZE)
+ return -EINVAL;
+
if (unlikely(op->keylen != AES_KEYSIZE_128))
return fallback_blk_dec(desc, dst, src, nbytes);

@@ -450,6 +456,9 @@ geode_ecb_encrypt(struct blkcipher_desc
struct blkcipher_walk walk;
int err, ret;

+ if (nbytes % AES_BLOCK_SIZE)
+ return -EINVAL;
+
if (unlikely(op->keylen != AES_KEYSIZE_128))
return fallback_blk_enc(desc, dst, src, nbytes);

--- a/drivers/crypto/geode-aes.h
+++ b/drivers/crypto/geode-aes.h
@@ -60,7 +60,7 @@ struct geode_aes_op {
u8 *iv;

union {
- struct crypto_blkcipher *blk;
+ struct crypto_sync_skcipher *blk;
struct crypto_cipher *cip;
} fallback;
u32 keylen;


2019-12-11 15:58:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 099/105] RDMA/qib: Validate ->show()/store() callbacks before calling them

From: Viresh Kumar <[email protected]>

commit 7ee23491b39259ae83899dd93b2a29ef0f22f0a7 upstream.

The permissions of the read-only or write-only sysfs files can be
changed (as root) and the user can then try to read a write-only file or
write to a read-only file which will lead to kernel crash here.

Protect against that by always validating the show/store callbacks.

Link: https://lore.kernel.org/r/d45cc26361a174ae12dbb86c994ef334d257924b.1573096807.git.viresh.kumar@linaro.org
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/hw/qib/qib_sysfs.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/infiniband/hw/qib/qib_sysfs.c
+++ b/drivers/infiniband/hw/qib/qib_sysfs.c
@@ -301,6 +301,9 @@ static ssize_t qib_portattr_show(struct
struct qib_pportdata *ppd =
container_of(kobj, struct qib_pportdata, pport_kobj);

+ if (!pattr->show)
+ return -EIO;
+
return pattr->show(ppd, buf);
}

@@ -312,6 +315,9 @@ static ssize_t qib_portattr_store(struct
struct qib_pportdata *ppd =
container_of(kobj, struct qib_pportdata, pport_kobj);

+ if (!pattr->store)
+ return -EIO;
+
return pattr->store(ppd, buf, len);
}



2019-12-11 15:58:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 080/105] KVM: arm/arm64: vgic: Dont rely on the wrong pending table

From: Zenghui Yu <[email protected]>

commit ca185b260951d3b55108c0b95e188682d8a507b7 upstream.

It's possible that two LPIs locate in the same "byte_offset" but target
two different vcpus, where their pending status are indicated by two
different pending tables. In such a scenario, using last_byte_offset
optimization will lead KVM relying on the wrong pending table entry.
Let us use last_ptr instead, which can be treated as a byte index into
a pending table and also, can be vcpu specific.

Fixes: 280771252c1b ("KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES")
Cc: [email protected]
Signed-off-by: Zenghui Yu <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Eric Auger <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
virt/kvm/arm/vgic/vgic-v3.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -363,8 +363,8 @@ retry:
int vgic_v3_save_pending_tables(struct kvm *kvm)
{
struct vgic_dist *dist = &kvm->arch.vgic;
- int last_byte_offset = -1;
struct vgic_irq *irq;
+ gpa_t last_ptr = ~(gpa_t)0;
int ret;
u8 val;

@@ -384,11 +384,11 @@ int vgic_v3_save_pending_tables(struct k
bit_nr = irq->intid % BITS_PER_BYTE;
ptr = pendbase + byte_offset;

- if (byte_offset != last_byte_offset) {
+ if (ptr != last_ptr) {
ret = kvm_read_guest_lock(kvm, ptr, &val, 1);
if (ret)
return ret;
- last_byte_offset = byte_offset;
+ last_ptr = ptr;
}

stored = val & (1U << bit_nr);


2019-12-11 15:58:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 103/105] binder: Fix race between mmap() and binder_alloc_print_pages()

From: Jann Horn <[email protected]>

commit 8eb52a1ee37aafd9b796713aa0b3ab9cbc455be3 upstream.

binder_alloc_print_pages() iterates over
alloc->pages[0..alloc->buffer_size-1] under alloc->mutex.
binder_alloc_mmap_handler() writes alloc->pages and alloc->buffer_size
without holding that lock, and even writes them before the last bailout
point.

Unfortunately we can't take the alloc->mutex in the ->mmap() handler
because mmap_sem can be taken while alloc->mutex is held.
So instead, we have to locklessly check whether the binder_alloc has been
fully initialized with binder_alloc_get_vma(), like in
binder_alloc_new_buf_locked().

Fixes: 8ef4665aa129 ("android: binder: Add page usage in binder stats")
Cc: [email protected]
Signed-off-by: Jann Horn <[email protected]>
Acked-by: Christian Brauner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/android/binder_alloc.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)

--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -841,14 +841,20 @@ void binder_alloc_print_pages(struct seq
int free = 0;

mutex_lock(&alloc->mutex);
- for (i = 0; i < alloc->buffer_size / PAGE_SIZE; i++) {
- page = &alloc->pages[i];
- if (!page->page_ptr)
- free++;
- else if (list_empty(&page->lru))
- active++;
- else
- lru++;
+ /*
+ * Make sure the binder_alloc is fully initialized, otherwise we might
+ * read inconsistent state.
+ */
+ if (binder_alloc_get_vma(alloc) != NULL) {
+ for (i = 0; i < alloc->buffer_size / PAGE_SIZE; i++) {
+ page = &alloc->pages[i];
+ if (!page->page_ptr)
+ free++;
+ else if (list_empty(&page->lru))
+ active++;
+ else
+ lru++;
+ }
}
mutex_unlock(&alloc->mutex);
seq_printf(m, " pages: %d:%d:%d\n", active, lru, free);


2019-12-11 15:58:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 079/105] KVM: nVMX: Always write vmcs02.GUEST_CR3 during nested VM-Enter

From: Sean Christopherson <[email protected]>

commit 04f11ef45810da5ae2542dd78cc353f3761bd2cb upstream.

Write the desired L2 CR3 into vmcs02.GUEST_CR3 during nested VM-Enter
instead of deferring the VMWRITE until vmx_set_cr3(). If the VMWRITE
is deferred, then KVM can consume a stale vmcs02.GUEST_CR3 when it
refreshes vmcs12->guest_cr3 during nested_vmx_vmexit() if the emulated
VM-Exit occurs without actually entering L2, e.g. if the nested run
is squashed because nested VM-Enter (from L1) is putting L2 into HLT.

Note, the above scenario can occur regardless of whether L1 is
intercepting HLT, e.g. L1 can intercept HLT and then re-enter L2 with
vmcs.GUEST_ACTIVITY_STATE=HALTED. But practically speaking, a VMM will
likely put a guest into HALTED if and only if it's not intercepting HLT.

In an ideal world where EPT *requires* unrestricted guest (and vice
versa), VMX could handle CR3 similar to how it handles RSP and RIP,
e.g. mark CR3 dirty and conditionally load it at vmx_vcpu_run(). But
the unrestricted guest silliness complicates the dirty tracking logic
to the point that explicitly handling vmcs02.GUEST_CR3 during nested
VM-Enter is a simpler overall implementation.

Cc: [email protected]
Reported-and-tested-by: Reto Buerki <[email protected]>
Tested-by: Vitaly Kuznetsov <[email protected]>
Reviewed-by: Liran Alon <[email protected]>
Signed-off-by: Sean Christopherson <[email protected]>
Reviewed-by: Jim Mattson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/vmx/nested.c | 10 ++++++++++
arch/x86/kvm/vmx/vmx.c | 10 +++++++---
2 files changed, 17 insertions(+), 3 deletions(-)

--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -2392,6 +2392,16 @@ static int prepare_vmcs02(struct kvm_vcp
entry_failure_code))
return -EINVAL;

+ /*
+ * Immediately write vmcs02.GUEST_CR3. It will be propagated to vmcs12
+ * on nested VM-Exit, which can occur without actually running L2 and
+ * thus without hitting vmx_set_cr3(), e.g. if L1 is entering L2 with
+ * vmcs12.GUEST_ACTIVITYSTATE=HLT, in which case KVM will intercept the
+ * transition to HLT instead of running L2.
+ */
+ if (enable_ept)
+ vmcs_writel(GUEST_CR3, vmcs12->guest_cr3);
+
/* Late preparation of GUEST_PDPTRs now that EFER and CRs are set. */
if (load_guest_pdptrs_vmcs12 && nested_cpu_has_ept(vmcs12) &&
is_pae_paging(vcpu)) {
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2878,6 +2878,7 @@ u64 construct_eptp(struct kvm_vcpu *vcpu
void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
{
struct kvm *kvm = vcpu->kvm;
+ bool update_guest_cr3 = true;
unsigned long guest_cr3;
u64 eptp;

@@ -2894,15 +2895,18 @@ void vmx_set_cr3(struct kvm_vcpu *vcpu,
spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
}

- if (enable_unrestricted_guest || is_paging(vcpu) ||
- is_guest_mode(vcpu))
+ /* Loading vmcs02.GUEST_CR3 is handled by nested VM-Enter. */
+ if (is_guest_mode(vcpu))
+ update_guest_cr3 = false;
+ else if (enable_unrestricted_guest || is_paging(vcpu))
guest_cr3 = kvm_read_cr3(vcpu);
else
guest_cr3 = to_kvm_vmx(kvm)->ept_identity_map_addr;
ept_load_pdptrs(vcpu);
}

- vmcs_writel(GUEST_CR3, guest_cr3);
+ if (update_guest_cr3)
+ vmcs_writel(GUEST_CR3, guest_cr3);
}

int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)


2019-12-11 15:58:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 078/105] KVM: PPC: Book3S HV: XIVE: Set kvm->arch.xive when VPs are allocated

From: Greg Kurz <[email protected]>

commit e7d71c943040c23f2fd042033d319f56e84f845b upstream.

If we cannot allocate the XIVE VPs in OPAL, the creation of a XIVE or
XICS-on-XIVE device is aborted as expected, but we leave kvm->arch.xive
set forever since the release method isn't called in this case. Any
subsequent tentative to create a XIVE or XICS-on-XIVE for this VM will
thus always fail (DoS). This is a problem for QEMU since it destroys
and re-creates these devices when the VM is reset: the VM would be
restricted to using the much slower emulated XIVE or XICS forever.

As an alternative to adding rollback, do not assign kvm->arch.xive before
making sure the XIVE VPs are allocated in OPAL.

Cc: [email protected] # v5.2
Fixes: 5422e95103cf ("KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method by a 'release' method")
Signed-off-by: Greg Kurz <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kvm/book3s_xive.c | 11 +++++------
arch/powerpc/kvm/book3s_xive_native.c | 2 +-
2 files changed, 6 insertions(+), 7 deletions(-)

--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -2005,6 +2005,10 @@ static int kvmppc_xive_create(struct kvm

pr_devel("Creating xive for partition\n");

+ /* Already there ? */
+ if (kvm->arch.xive)
+ return -EEXIST;
+
xive = kvmppc_xive_get_device(kvm, type);
if (!xive)
return -ENOMEM;
@@ -2014,12 +2018,6 @@ static int kvmppc_xive_create(struct kvm
xive->kvm = kvm;
mutex_init(&xive->lock);

- /* Already there ? */
- if (kvm->arch.xive)
- ret = -EEXIST;
- else
- kvm->arch.xive = xive;
-
/* We use the default queue size set by the host */
xive->q_order = xive_native_default_eq_shift();
if (xive->q_order < PAGE_SHIFT)
@@ -2039,6 +2037,7 @@ static int kvmppc_xive_create(struct kvm
if (ret)
return ret;

+ kvm->arch.xive = xive;
return 0;
}

--- a/arch/powerpc/kvm/book3s_xive_native.c
+++ b/arch/powerpc/kvm/book3s_xive_native.c
@@ -1095,7 +1095,6 @@ static int kvmppc_xive_native_create(str
dev->private = xive;
xive->dev = dev;
xive->kvm = kvm;
- kvm->arch.xive = xive;
mutex_init(&xive->mapping_lock);
mutex_init(&xive->lock);

@@ -1116,6 +1115,7 @@ static int kvmppc_xive_native_create(str
if (ret)
return ret;

+ kvm->arch.xive = xive;
return 0;
}



2019-12-11 15:58:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 044/105] io_uring: transform send/recvmsg() -ERESTARTSYS to -EINTR

From: Jens Axboe <[email protected]>

commit 441cdbd5449b4923cd413d3ba748124f91388be9 upstream.

We should never return -ERESTARTSYS to userspace, transform it into
-EINTR.

Cc: [email protected] # v5.3+
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/io_uring.c | 2 ++
1 file changed, 2 insertions(+)

--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1535,6 +1535,8 @@ static int io_send_recvmsg(struct io_kio
ret = fn(sock, msg, flags);
if (force_nonblock && ret == -EAGAIN)
return ret;
+ if (ret == -ERESTARTSYS)
+ ret = -EINTR;
}

io_cqring_add_event(req->ctx, sqe->user_data, ret);


2019-12-11 15:59:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 067/105] can: slcan: Fix use-after-free Read in slcan_open

From: Jouni Hogander <[email protected]>

commit 9ebd796e24008f33f06ebea5a5e6aceb68b51794 upstream.

Slcan_open doesn't clean-up device which registration failed from the
slcan_devs device list. On next open this list is iterated and freed
device is accessed. Fix this by calling slc_free_netdev in error path.

Driver/net/can/slcan.c is derived from slip.c. Use-after-free error was
identified in slip_open by syzboz. Same bug is in slcan.c. Here is the
trace from the Syzbot slip report:

__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
__kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:634
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
sl_sync drivers/net/slip/slip.c:725 [inline]
slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801
tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469
tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596
tiocsetd drivers/tty/tty_io.c:2334 [inline]
tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: ed50e1600b44 ("slcan: Fix memory leak in error path")
Cc: Wolfgang Grandegger <[email protected]>
Cc: Marc Kleine-Budde <[email protected]>
Cc: David Miller <[email protected]>
Cc: Oliver Hartkopp <[email protected]>
Cc: Lukas Bulwahn <[email protected]>
Signed-off-by: Jouni Hogander <[email protected]>
Cc: linux-stable <[email protected]> # >= v5.4
Acked-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/can/slcan.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -613,6 +613,7 @@ err_free_chan:
sl->tty = NULL;
tty->disc_data = NULL;
clear_bit(SLF_INUSE, &sl->flags);
+ slc_free_netdev(sl->dev);
free_netdev(sl->dev);

err_exit:


2019-12-11 15:59:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 066/105] tty: vt: keyboard: reject invalid keycodes

From: Dmitry Torokhov <[email protected]>

commit b2b2dd71e0859436d4e05b2f61f86140250ed3f8 upstream.

Do not try to handle keycodes that are too big, otherwise we risk doing
out-of-bounds writes:

BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
...
kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
input_pass_values drivers/input/input.c:949 [inline]
input_set_keycode+0x290/0x320 drivers/input/input.c:954
evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
evdev_do_ioctl drivers/input/evdev.c:1150 [inline]

In this case we were dealing with a fuzzed HID device that declared over
12K buttons, and while HID layer should not be reporting to us such big
keycodes, we should also be defensive and reject invalid data ourselves as
well.

Reported-by: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-ws
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/vt/keyboard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -1491,7 +1491,7 @@ static void kbd_event(struct input_handl

if (event_type == EV_MSC && event_code == MSC_RAW && HW_RAW(handle->dev))
kbd_rawcode(value);
- if (event_type == EV_KEY)
+ if (event_type == EV_KEY && event_code <= KEY_MAX)
kbd_keycode(event_code, value, HW_RAW(handle->dev));

spin_unlock(&kbd_event_lock);


2019-12-11 15:59:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 101/105] thermal: Fix deadlock in thermal thermal_zone_device_check

From: Wei Wang <[email protected]>

commit 163b00cde7cf2206e248789d2780121ad5e6a70b upstream.

1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone
device") changed cancel_delayed_work to cancel_delayed_work_sync to avoid
a use-after-free issue. However, cancel_delayed_work_sync could be called
insides the WQ causing deadlock.

[54109.642398] c0 1162 kworker/u17:1 D 0 11030 2 0x00000000
[54109.642437] c0 1162 Workqueue: thermal_passive_wq thermal_zone_device_check
[54109.642447] c0 1162 Call trace:
[54109.642456] c0 1162 __switch_to+0x138/0x158
[54109.642467] c0 1162 __schedule+0xba4/0x1434
[54109.642480] c0 1162 schedule_timeout+0xa0/0xb28
[54109.642492] c0 1162 wait_for_common+0x138/0x2e8
[54109.642511] c0 1162 flush_work+0x348/0x40c
[54109.642522] c0 1162 __cancel_work_timer+0x180/0x218
[54109.642544] c0 1162 handle_thermal_trip+0x2c4/0x5a4
[54109.642553] c0 1162 thermal_zone_device_update+0x1b4/0x25c
[54109.642563] c0 1162 thermal_zone_device_check+0x18/0x24
[54109.642574] c0 1162 process_one_work+0x3cc/0x69c
[54109.642583] c0 1162 worker_thread+0x49c/0x7c0
[54109.642593] c0 1162 kthread+0x17c/0x1b0
[54109.642602] c0 1162 ret_from_fork+0x10/0x18
[54109.643051] c0 1162 kworker/u17:2 D 0 16245 2 0x00000000
[54109.643067] c0 1162 Workqueue: thermal_passive_wq thermal_zone_device_check
[54109.643077] c0 1162 Call trace:
[54109.643085] c0 1162 __switch_to+0x138/0x158
[54109.643095] c0 1162 __schedule+0xba4/0x1434
[54109.643104] c0 1162 schedule_timeout+0xa0/0xb28
[54109.643114] c0 1162 wait_for_common+0x138/0x2e8
[54109.643122] c0 1162 flush_work+0x348/0x40c
[54109.643131] c0 1162 __cancel_work_timer+0x180/0x218
[54109.643141] c0 1162 handle_thermal_trip+0x2c4/0x5a4
[54109.643150] c0 1162 thermal_zone_device_update+0x1b4/0x25c
[54109.643159] c0 1162 thermal_zone_device_check+0x18/0x24
[54109.643167] c0 1162 process_one_work+0x3cc/0x69c
[54109.643177] c0 1162 worker_thread+0x49c/0x7c0
[54109.643186] c0 1162 kthread+0x17c/0x1b0
[54109.643195] c0 1162 ret_from_fork+0x10/0x18
[54109.644500] c0 1162 cat D 0 7766 1 0x00000001
[54109.644515] c0 1162 Call trace:
[54109.644524] c0 1162 __switch_to+0x138/0x158
[54109.644536] c0 1162 __schedule+0xba4/0x1434
[54109.644546] c0 1162 schedule_preempt_disabled+0x80/0xb0
[54109.644555] c0 1162 __mutex_lock+0x3a8/0x7f0
[54109.644563] c0 1162 __mutex_lock_slowpath+0x14/0x20
[54109.644575] c0 1162 thermal_zone_get_temp+0x84/0x360
[54109.644586] c0 1162 temp_show+0x30/0x78
[54109.644609] c0 1162 dev_attr_show+0x5c/0xf0
[54109.644628] c0 1162 sysfs_kf_seq_show+0xcc/0x1a4
[54109.644636] c0 1162 kernfs_seq_show+0x48/0x88
[54109.644656] c0 1162 seq_read+0x1f4/0x73c
[54109.644664] c0 1162 kernfs_fop_read+0x84/0x318
[54109.644683] c0 1162 __vfs_read+0x50/0x1bc
[54109.644692] c0 1162 vfs_read+0xa4/0x140
[54109.644701] c0 1162 SyS_read+0xbc/0x144
[54109.644708] c0 1162 el0_svc_naked+0x34/0x38
[54109.845800] c0 1162 D 720.000s 1->7766->7766 cat [panic]

Fixes: 1851799e1d29 ("thermal: Fix use-after-free when unregistering thermal zone device")
Cc: [email protected]
Signed-off-by: Wei Wang <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/thermal/thermal_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -304,7 +304,7 @@ static void thermal_zone_device_set_poll
&tz->poll_queue,
msecs_to_jiffies(delay));
else
- cancel_delayed_work_sync(&tz->poll_queue);
+ cancel_delayed_work(&tz->poll_queue);
}

static void monitor_thermal_zone(struct thermal_zone_device *tz)
@@ -1404,7 +1404,7 @@ void thermal_zone_device_unregister(stru

mutex_unlock(&thermal_list_lock);

- thermal_zone_device_set_polling(tz, 0);
+ cancel_delayed_work_sync(&tz->poll_queue);

thermal_set_governor(tz, NULL);



2019-12-11 15:59:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 083/105] KVM: x86: Remove a spurious export of a static function

From: Sean Christopherson <[email protected]>

commit 24885d1d79e2e83d49201aeae0bc59f1402fd4f1 upstream.

A recent change inadvertently exported a static function, which results
in modpost throwing a warning. Fix it.

Fixes: cbbaa2727aa3 ("KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES")
Signed-off-by: Sean Christopherson <[email protected]>
Cc: [email protected]
Reviewed-by: Jim Mattson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/x86.c | 1 -
1 file changed, 1 deletion(-)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1303,7 +1303,6 @@ static u64 kvm_get_arch_capabilities(voi
data &= ~ARCH_CAP_TSX_CTRL_MSR;
return data;
}
-EXPORT_SYMBOL_GPL(kvm_get_arch_capabilities);

static int kvm_get_msr_feature(struct kvm_msr_entry *msr)
{


2019-12-11 15:59:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 098/105] can: ucan: fix non-atomic allocation in completion handler

From: Johan Hovold <[email protected]>

commit 870db5d1015c8bd63e93b579e857223c96249ff7 upstream.

USB completion handlers are called in atomic context and must
specifically not allocate memory using GFP_KERNEL.

Fixes: 9f2d3eae88d2 ("can: ucan: add driver for Theobroma Systems UCAN devices")
Cc: stable <[email protected]> # 4.19
Cc: Jakob Unterwurzacher <[email protected]>
Cc: Martin Elshuber <[email protected]>
Cc: Philipp Tomsich <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/can/usb/ucan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/can/usb/ucan.c
+++ b/drivers/net/can/usb/ucan.c
@@ -792,7 +792,7 @@ resubmit:
up);

usb_anchor_urb(urb, &up->rx_urbs);
- ret = usb_submit_urb(urb, GFP_KERNEL);
+ ret = usb_submit_urb(urb, GFP_ATOMIC);

if (ret < 0) {
netdev_err(up->netdev,


2019-12-11 15:59:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 097/105] spi: Fix NULL pointer when setting SPI_CS_HIGH for GPIO CS

From: Gregory CLEMENT <[email protected]>

commit 15f794bd977a0135328fbdd8a83cc64c1d267b39 upstream.

Even if the flag use_gpio_descriptors is set, it is possible that
cs_gpiods was not allocated, which leads to a kernel crash.

Reported-by: "kernelci.org bot" <[email protected]>
Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS")
Signed-off-by: Gregory CLEMENT <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Cc: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1779,7 +1779,8 @@ static int of_spi_parse_dt(struct spi_co
* handled in the gpiolib, so all gpio chip selects are "active high"
* in the logical sense, the gpiolib will invert the line if need be.
*/
- if ((ctlr->use_gpio_descriptors) && ctlr->cs_gpiods[spi->chip_select])
+ if ((ctlr->use_gpio_descriptors) && ctlr->cs_gpiods &&
+ ctlr->cs_gpiods[spi->chip_select])
spi->mode |= SPI_CS_HIGH;

/* Device speed */


2019-12-11 15:59:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 095/105] spi: atmel: Fix CS high support

From: Gregory CLEMENT <[email protected]>

commit 7cbb16b2122c09f2ae393a1542fed628505b9da6 upstream.

Until a few years ago, this driver was only used with CS GPIO. The
only exception is CS0 on AT91RM9200 which has to use internal CS. A
limitation of the internal CS is that they don't support CS High.

So by using the CS GPIO the CS high configuration was available except
for the particular case CS0 on RM9200.

When the support for the internal chip-select was added, the check of
the CS high support was not updated. Due to this the driver accepts
this configuration for all the SPI controller v2 (used by all SoCs
excepting the AT91RM9200) whereas the hardware doesn't support it for
infernal CS.

This patch fixes the test to match the hardware capabilities.

Fixes: 4820303480a1 ("spi: atmel: add support for the internal chip-select of the spi controller")
Cc: <[email protected]>
Signed-off-by: Gregory CLEMENT <[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/spi/spi-atmel.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1182,10 +1182,8 @@ static int atmel_spi_setup(struct spi_de
as = spi_master_get_devdata(spi->master);

/* see notes above re chipselect */
- if (!atmel_spi_is_v2(as)
- && spi->chip_select == 0
- && (spi->mode & SPI_CS_HIGH)) {
- dev_dbg(&spi->dev, "setup: can't be active-high\n");
+ if (!as->use_cs_gpios && (spi->mode & SPI_CS_HIGH)) {
+ dev_warn(&spi->dev, "setup: non GPIO CS can't be active-high\n");
return -EINVAL;
}



2019-12-11 15:59:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 096/105] spi: Fix SPI_CS_HIGH setting when using native and GPIO CS

From: Gregory CLEMENT <[email protected]>

commit 3e5ec1db8bfee845d9f8560d1c64aeaccd586398 upstream.

When improving the CS GPIO support at core level, the SPI_CS_HIGH
has been enabled for all the CS lines used for a given SPI controller.

However, the SPI framework allows to have on the same controller native
CS and GPIO CS. The native CS may not support the SPI_CS_HIGH, so they
should not be setup automatically.

With this patch the setting is done only for the CS that will use a
GPIO as CS

Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Cc: <[email protected]>
Signed-off-by: Gregory CLEMENT <[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/spi/spi.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)

--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1710,15 +1710,7 @@ static int of_spi_parse_dt(struct spi_co
spi->mode |= SPI_3WIRE;
if (of_property_read_bool(nc, "spi-lsb-first"))
spi->mode |= SPI_LSB_FIRST;
-
- /*
- * For descriptors associated with the device, polarity inversion is
- * handled in the gpiolib, so all chip selects are "active high" in
- * the logical sense, the gpiolib will invert the line if need be.
- */
- if (ctlr->use_gpio_descriptors)
- spi->mode |= SPI_CS_HIGH;
- else if (of_property_read_bool(nc, "spi-cs-high"))
+ if (of_property_read_bool(nc, "spi-cs-high"))
spi->mode |= SPI_CS_HIGH;

/* Device DUAL/QUAD mode */
@@ -1782,6 +1774,14 @@ static int of_spi_parse_dt(struct spi_co
}
spi->chip_select = value;

+ /*
+ * For descriptors associated with the device, polarity inversion is
+ * handled in the gpiolib, so all gpio chip selects are "active high"
+ * in the logical sense, the gpiolib will invert the line if need be.
+ */
+ if ((ctlr->use_gpio_descriptors) && ctlr->cs_gpiods[spi->chip_select])
+ spi->mode |= SPI_CS_HIGH;
+
/* Device speed */
rc = of_property_read_u32(nc, "spi-max-frequency", &value);
if (rc) {


2019-12-11 15:59:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 082/105] KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES

From: Paolo Bonzini <[email protected]>

commit cbbaa2727aa3ae9e0a844803da7cef7fd3b94f2b upstream.

KVM does not implement MSR_IA32_TSX_CTRL, so it must not be presented
to the guests. It is also confusing to have !ARCH_CAP_TSX_CTRL_MSR &&
!RTM && ARCH_CAP_TAA_NO: lack of MSR_IA32_TSX_CTRL suggests TSX was not
hidden (it actually was), yet the value says that TSX is not vulnerable
to microarchitectural data sampling. Fix both.

Cc: [email protected]
Tested-by: Jim Mattson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/x86.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1292,12 +1292,18 @@ static u64 kvm_get_arch_capabilities(voi
* If TSX is disabled on the system, guests are also mitigated against
* TAA and clear CPU buffer mitigation is not required for guests.
*/
- if (boot_cpu_has_bug(X86_BUG_TAA) && boot_cpu_has(X86_FEATURE_RTM) &&
- (data & ARCH_CAP_TSX_CTRL_MSR))
+ if (!boot_cpu_has(X86_FEATURE_RTM))
+ data &= ~ARCH_CAP_TAA_NO;
+ else if (!boot_cpu_has_bug(X86_BUG_TAA))
+ data |= ARCH_CAP_TAA_NO;
+ else if (data & ARCH_CAP_TSX_CTRL_MSR)
data &= ~ARCH_CAP_MDS_NO;

+ /* KVM does not emulate MSR_IA32_TSX_CTRL. */
+ data &= ~ARCH_CAP_TSX_CTRL_MSR;
return data;
}
+EXPORT_SYMBOL_GPL(kvm_get_arch_capabilities);

static int kvm_get_msr_feature(struct kvm_msr_entry *msr)
{


2019-12-11 15:59:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 094/105] spi: stm32-qspi: Fix kernel oops when unbinding driver

From: Patrice Chotard <[email protected]>

commit 3c0af1dd2fe78adc02fe21f6cfe7d6cb8602573e upstream.

spi_master_put() must only be called in .probe() in case of error.

As devm_spi_register_master() is used during probe, spi_master_put()
mustn't be called in .remove() callback.

It fixes the following kernel WARNING/Oops when executing
echo "58003000.spi" > /sys/bus/platform/drivers/stm32-qspi/unbind :

------------[ cut here ]------------
WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4
kernfs: can not remove 'uevent', no directory
Modules linked in:
CPU: 1 PID: 496 Comm: sh Not tainted 5.3.0-rc1-00219-ga0e07bb51a37 #62
Hardware name: STM32 (Device Tree Support)
[<c0111570>] (unwind_backtrace) from [<c010d384>] (show_stack+0x10/0x14)
[<c010d384>] (show_stack) from [<c08db558>] (dump_stack+0xb4/0xc8)
[<c08db558>] (dump_stack) from [<c01209d8>] (__warn.part.3+0xbc/0xd8)
[<c01209d8>] (__warn.part.3) from [<c0120a5c>] (warn_slowpath_fmt+0x68/0x8c)
[<c0120a5c>] (warn_slowpath_fmt) from [<c02e5844>] (kernfs_remove_by_name_ns+0x9c/0xa4)
[<c02e5844>] (kernfs_remove_by_name_ns) from [<c05833a4>] (device_del+0x128/0x358)
[<c05833a4>] (device_del) from [<c05835f8>] (device_unregister+0x24/0x64)
[<c05835f8>] (device_unregister) from [<c0638dac>] (spi_unregister_controller+0x88/0xe8)
[<c0638dac>] (spi_unregister_controller) from [<c058c580>] (release_nodes+0x1bc/0x200)
[<c058c580>] (release_nodes) from [<c0588a44>] (device_release_driver_internal+0xec/0x1ac)
[<c0588a44>] (device_release_driver_internal) from [<c0586840>] (unbind_store+0x60/0xd4)
[<c0586840>] (unbind_store) from [<c02e64e8>] (kernfs_fop_write+0xe8/0x1c4)
[<c02e64e8>] (kernfs_fop_write) from [<c0266b44>] (__vfs_write+0x2c/0x1c0)
[<c0266b44>] (__vfs_write) from [<c02694c0>] (vfs_write+0xa4/0x184)
[<c02694c0>] (vfs_write) from [<c0269710>] (ksys_write+0x58/0xd0)
[<c0269710>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xdd289fa8 to 0xdd289ff0)
9fa0: 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000
9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000
9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6
---[ end trace 1b15df8a02d76aef ]---
------------[ cut here ]------------
WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4
kernfs: can not remove 'online', no directory
Modules linked in:
CPU: 1 PID: 496 Comm: sh Tainted: G W 5.3.0-rc1-00219-ga0e07bb51a37 #62
Hardware name: STM32 (Device Tree Support)
[<c0111570>] (unwind_backtrace) from [<c010d384>] (show_stack+0x10/0x14)
[<c010d384>] (show_stack) from [<c08db558>] (dump_stack+0xb4/0xc8)
[<c08db558>] (dump_stack) from [<c01209d8>] (__warn.part.3+0xbc/0xd8)
[<c01209d8>] (__warn.part.3) from [<c0120a5c>] (warn_slowpath_fmt+0x68/0x8c)
[<c0120a5c>] (warn_slowpath_fmt) from [<c02e5844>] (kernfs_remove_by_name_ns+0x9c/0xa4)
[<c02e5844>] (kernfs_remove_by_name_ns) from [<c0582488>] (device_remove_attrs+0x20/0x5c)
[<c0582488>] (device_remove_attrs) from [<c05833b0>] (device_del+0x134/0x358)
[<c05833b0>] (device_del) from [<c05835f8>] (device_unregister+0x24/0x64)
[<c05835f8>] (device_unregister) from [<c0638dac>] (spi_unregister_controller+0x88/0xe8)
[<c0638dac>] (spi_unregister_controller) from [<c058c580>] (release_nodes+0x1bc/0x200)
[<c058c580>] (release_nodes) from [<c0588a44>] (device_release_driver_internal+0xec/0x1ac)
[<c0588a44>] (device_release_driver_internal) from [<c0586840>] (unbind_store+0x60/0xd4)
[<c0586840>] (unbind_store) from [<c02e64e8>] (kernfs_fop_write+0xe8/0x1c4)
[<c02e64e8>] (kernfs_fop_write) from [<c0266b44>] (__vfs_write+0x2c/0x1c0)
[<c0266b44>] (__vfs_write) from [<c02694c0>] (vfs_write+0xa4/0x184)
[<c02694c0>] (vfs_write) from [<c0269710>] (ksys_write+0x58/0xd0)
[<c0269710>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xdd289fa8 to 0xdd289ff0)
9fa0: 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000
9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000
9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6
---[ end trace 1b15df8a02d76af0 ]---
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000050
pgd = e612f14d
[00000050] *pgd=ff1f5835
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 496 Comm: sh Tainted: G W 5.3.0-rc1-00219-ga0e07bb51a37 #62
Hardware name: STM32 (Device Tree Support)
PC is at kernfs_find_ns+0x8/0xfc
LR is at kernfs_find_and_get_ns+0x30/0x48
pc : [<c02e49a4>] lr : [<c02e4ac8>] psr: 40010013
sp : dd289dac ip : 00000000 fp : 00000000
r10: 00000000 r9 : def6ec58 r8 : dd289e54
r7 : 00000000 r6 : c0abb234 r5 : 00000000 r4 : c0d26a30
r3 : ddab5080 r2 : 00000000 r1 : c0abb234 r0 : 00000000
Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: dd11c06a DAC: 00000051
Process sh (pid: 496, stack limit = 0xe13a592d)
Stack: (0xdd289dac to 0xdd28a000)
9da0: c0d26a30 00000000 c0abb234 00000000 c02e4ac8
9dc0: 00000000 c0976b44 def6ec00 dea53810 dd289e54 c02e864c c0a61a48 c0a4a5ec
9de0: c0d630a8 def6ec00 c0d04c48 c02e86e0 def6ec00 de909338 c0d04c48 c05833b0
9e00: 00000000 c0638144 dd289e54 def59900 00000000 475b3ee5 def6ec00 00000000
9e20: def6ec00 def59b80 dd289e54 def59900 00000000 c05835f8 def6ec00 c0638dac
9e40: 0000000a dea53810 c0d04c48 c058c580 dea53810 def59500 def59b80 475b3ee5
9e60: ddc63e00 dea53810 dea3fe10 c0d63a0c dea53810 ddc63e00 dd289f78 dd240d10
9e80: 00000000 c0588a44 c0d59a20 0000000d c0d63a0c c0586840 0000000d dd240d00
9ea0: 00000000 00000000 ddc63e00 c02e64e8 00000000 00000000 c0d04c48 dd9bbcc0
9ec0: c02e6400 dd289f78 00000000 000e20e8 0000000d c0266b44 00000055 00000cc0
9ee0: 000000e3 000e3000 dd11c000 dd11c000 00000000 00000000 00000000 00000000
9f00: ffeee38c dff99688 00000000 475b3ee5 00000001 dd289fb0 ddab5080 ddaa5800
9f20: 00000817 000e30ec dd9e7720 475b3ee5 ddaa583c 0000000d dd9bbcc0 000e20e8
9f40: dd289f78 00000000 000e20e8 0000000d 00000000 c02694c0 00000000 00000000
9f60: c0d04c48 dd9bbcc0 00000000 00000000 dd9bbcc0 c0269710 00000000 00000000
9f80: 000a91f4 475b3ee5 0000006c 000e20e8 b6f87da0 00000004 c0101204 dd288000
9fa0: 00000004 c0101000 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000
9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000
9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 600e0030 00000001 00000000 00000000
[<c02e49a4>] (kernfs_find_ns) from [<def6ec00>] (0xdef6ec00)
Code: ebf8eeab c0dc50b8 e92d40f0 e292c000 (e1d035b0)
---[ end trace 1b15df8a02d76af1 ]---

Fixes: a88eceb17ac7 ("spi: stm32-qspi: add spi_master_put in release function")
Cc: <[email protected]>
Signed-off-by: Patrice Chotard <[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/spi/spi-stm32-qspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -528,7 +528,6 @@ static void stm32_qspi_release(struct st
stm32_qspi_dma_free(qspi);
mutex_destroy(&qspi->lock);
clk_disable_unprepare(qspi->clk);
- spi_master_put(qspi->ctrl);
}

static int stm32_qspi_probe(struct platform_device *pdev)
@@ -629,6 +628,8 @@ static int stm32_qspi_probe(struct platf

err:
stm32_qspi_release(qspi);
+ spi_master_put(qspi->ctrl);
+
return ret;
}



2019-12-11 16:00:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 076/105] KVM: PPC: Book3S HV: XIVE: Free previous EQ page when setting up a new one

From: Greg Kurz <[email protected]>

commit 31a88c82b466d2f31a44e21c479f45b4732ccfd0 upstream.

The EQ page is allocated by the guest and then passed to the hypervisor
with the H_INT_SET_QUEUE_CONFIG hcall. A reference is taken on the page
before handing it over to the HW. This reference is dropped either when
the guest issues the H_INT_RESET hcall or when the KVM device is released.
But, the guest can legitimately call H_INT_SET_QUEUE_CONFIG several times,
either to reset the EQ (vCPU hot unplug) or to set a new EQ (guest reboot).
In both cases the existing EQ page reference is leaked because we simply
overwrite it in the XIVE queue structure without calling put_page().

This is especially visible when the guest memory is backed with huge pages:
start a VM up to the guest userspace, either reboot it or unplug a vCPU,
quit QEMU. The leak is observed by comparing the value of HugePages_Free in
/proc/meminfo before and after the VM is run.

Ideally we'd want the XIVE code to handle the EQ page de-allocation at the
platform level. This isn't the case right now because the various XIVE
drivers have different allocation needs. It could maybe worth introducing
hooks for this purpose instead of exposing XIVE internals to the drivers,
but this is certainly a huge work to be done later.

In the meantime, for easier backport, fix both vCPU unplug and guest reboot
leaks by introducing a wrapper around xive_native_configure_queue() that
does the necessary cleanup.

Reported-by: Satheesh Rajendran <[email protected]>
Cc: [email protected] # v5.2
Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration")
Signed-off-by: Cédric Le Goater <[email protected]>
Signed-off-by: Greg Kurz <[email protected]>
Tested-by: Lijun Pan <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kvm/book3s_xive_native.c | 31 ++++++++++++++++++++++---------
1 file changed, 22 insertions(+), 9 deletions(-)

--- a/arch/powerpc/kvm/book3s_xive_native.c
+++ b/arch/powerpc/kvm/book3s_xive_native.c
@@ -50,6 +50,24 @@ static void kvmppc_xive_native_cleanup_q
}
}

+static int kvmppc_xive_native_configure_queue(u32 vp_id, struct xive_q *q,
+ u8 prio, __be32 *qpage,
+ u32 order, bool can_escalate)
+{
+ int rc;
+ __be32 *qpage_prev = q->qpage;
+
+ rc = xive_native_configure_queue(vp_id, q, prio, qpage, order,
+ can_escalate);
+ if (rc)
+ return rc;
+
+ if (qpage_prev)
+ put_page(virt_to_page(qpage_prev));
+
+ return rc;
+}
+
void kvmppc_xive_native_cleanup_vcpu(struct kvm_vcpu *vcpu)
{
struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
@@ -582,19 +600,14 @@ static int kvmppc_xive_native_set_queue_
q->guest_qaddr = 0;
q->guest_qshift = 0;

- rc = xive_native_configure_queue(xc->vp_id, q, priority,
- NULL, 0, true);
+ rc = kvmppc_xive_native_configure_queue(xc->vp_id, q, priority,
+ NULL, 0, true);
if (rc) {
pr_err("Failed to reset queue %d for VCPU %d: %d\n",
priority, xc->server_num, rc);
return rc;
}

- if (q->qpage) {
- put_page(virt_to_page(q->qpage));
- q->qpage = NULL;
- }
-
return 0;
}

@@ -653,8 +666,8 @@ static int kvmppc_xive_native_set_queue_
* OPAL level because the use of END ESBs is not supported by
* Linux.
*/
- rc = xive_native_configure_queue(xc->vp_id, q, priority,
- (__be32 *) qaddr, kvm_eq.qshift, true);
+ rc = kvmppc_xive_native_configure_queue(xc->vp_id, q, priority,
+ (__be32 *) qaddr, kvm_eq.qshift, true);
if (rc) {
pr_err("Failed to configure queue %d for VCPU %d: %d\n",
priority, xc->server_num, rc);


2019-12-11 16:00:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 049/105] ALSA: hda/realtek - Enable internal speaker of ASUS UX431FLC

From: Jian-Hong Pan <[email protected]>

commit 436e25505f3458cc92c7f3c985e9cbc198a98209 upstream.

Laptops like ASUS UX431FLC and UX431FL can share the same audio quirks.
But UX431FLC needs one more step to enable the internal speaker: Pull
the GPIO from CODEC to initialize the AMP.

Fixes: 60083f9e94b2 ("ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL")
Signed-off-by: Jian-Hong Pan <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_realtek.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5878,6 +5878,7 @@ enum {
ALC299_FIXUP_PREDATOR_SPK,
ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC,
ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE,
+ ALC294_FIXUP_ASUS_INTSPK_GPIO,
};

static const struct hda_fixup alc269_fixups[] = {
@@ -6953,6 +6954,13 @@ static const struct hda_fixup alc269_fix
.chained = true,
.chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE
},
+ [ALC294_FIXUP_ASUS_INTSPK_GPIO] = {
+ .type = HDA_FIXUP_FUNC,
+ /* The GPIO must be pulled to initialize the AMP */
+ .v.func = alc_fixup_gpio4,
+ .chained = true,
+ .chain_id = ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC
+ },
};

static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7112,7 +7120,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
- SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", ALC294_FIXUP_ASUS_INTSPK_GPIO),
SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA", ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),


2019-12-11 16:00:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 048/105] SUNRPC: Avoid RPC delays when exiting suspend

From: Trond Myklebust <[email protected]>

commit 66eb3add452aa1be65ad536da99fac4b8f620b74 upstream.

Jon Hunter: "I have been tracking down another suspend/NFS related
issue where again I am seeing random delays exiting suspend. The delays
can be up to a couple minutes in the worst case and this is causing a
suspend test we have to fail."

Change the use of a deferrable work to a standard delayed one.

Reported-by: Jon Hunter <[email protected]>
Tested-by: Jon Hunter <[email protected]>
Fixes: 7e0a0e38fcfea ("SUNRPC: Replace the queue timer with a delayed work function")
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/sunrpc/sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -260,7 +260,7 @@ static void __rpc_init_priority_wait_que
rpc_reset_waitqueue_priority(queue);
queue->qlen = 0;
queue->timer_list.expires = 0;
- INIT_DEFERRABLE_WORK(&queue->timer_list.dwork, __rpc_queue_timer_fn);
+ INIT_DELAYED_WORK(&queue->timer_list.dwork, __rpc_queue_timer_fn);
INIT_LIST_HEAD(&queue->timer_list.list);
rpc_assign_waitqueue_name(queue, qname);
}


2019-12-11 16:00:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 077/105] KVM: PPC: Book3S HV: XIVE: Fix potential page leak on error path

From: Greg Kurz <[email protected]>

commit 30486e72093ea2e594f44876b7a445c219449bce upstream.

We need to check the host page size is big enough to accomodate the
EQ. Let's do this before taking a reference on the EQ page to avoid
a potential leak if the check fails.

Cc: [email protected] # v5.2
Fixes: 13ce3297c576 ("KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration")
Signed-off-by: Greg Kurz <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kvm/book3s_xive_native.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)

--- a/arch/powerpc/kvm/book3s_xive_native.c
+++ b/arch/powerpc/kvm/book3s_xive_native.c
@@ -637,12 +637,6 @@ static int kvmppc_xive_native_set_queue_

srcu_idx = srcu_read_lock(&kvm->srcu);
gfn = gpa_to_gfn(kvm_eq.qaddr);
- page = gfn_to_page(kvm, gfn);
- if (is_error_page(page)) {
- srcu_read_unlock(&kvm->srcu, srcu_idx);
- pr_err("Couldn't get queue page %llx!\n", kvm_eq.qaddr);
- return -EINVAL;
- }

page_size = kvm_host_page_size(kvm, gfn);
if (1ull << kvm_eq.qshift > page_size) {
@@ -651,6 +645,13 @@ static int kvmppc_xive_native_set_queue_
return -EINVAL;
}

+ page = gfn_to_page(kvm, gfn);
+ if (is_error_page(page)) {
+ srcu_read_unlock(&kvm->srcu, srcu_idx);
+ pr_err("Couldn't get queue page %llx!\n", kvm_eq.qaddr);
+ return -EINVAL;
+ }
+
qaddr = page_to_virt(page) + (kvm_eq.qaddr & ~PAGE_MASK);
srcu_read_unlock(&kvm->srcu, srcu_idx);



2019-12-11 16:01:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 071/105] jbd2: Fix possible overflow in jbd2_log_space_left()

From: Jan Kara <[email protected]>

commit add3efdd78b8a0478ce423bb9d4df6bd95e8b335 upstream.

When number of free space in the journal is very low, the arithmetic in
jbd2_log_space_left() could underflow resulting in very high number of
free blocks and thus triggering assertion failure in transaction commit
code complaining there's not enough space in the journal:

J_ASSERT(journal->j_free > 1);

Properly check for the low number of free blocks.

CC: [email protected]
Reviewed-by: Theodore Ts'o <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/jbd2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1584,7 +1584,7 @@ static inline int jbd2_space_needed(jour
static inline unsigned long jbd2_log_space_left(journal_t *journal)
{
/* Allow for rounding errors */
- unsigned long free = journal->j_free - 32;
+ long free = journal->j_free - 32;

if (journal->j_committing_transaction) {
unsigned long committing = atomic_read(&journal->
@@ -1593,7 +1593,7 @@ static inline unsigned long jbd2_log_spa
/* Transaction + control blocks */
free -= committing + (committing >> JBD2_CONTROL_BLOCKS_SHIFT);
}
- return free;
+ return max_t(long, free, 0);
}

/*


2019-12-11 16:01:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 074/105] drm/i810: Prevent underflow in ioctl

From: Dan Carpenter <[email protected]>

commit 4f69851fbaa26b155330be35ce8ac393e93e7442 upstream.

The "used" variables here come from the user in the ioctl and it can be
negative. It could result in an out of bounds write.

Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004102251.GC823@mwanda
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i810/i810_dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -721,7 +721,7 @@ static void i810_dma_dispatch_vertex(str
if (nbox > I810_NR_SAREA_CLIPRECTS)
nbox = I810_NR_SAREA_CLIPRECTS;

- if (used > 4 * 1024)
+ if (used < 0 || used > 4 * 1024)
used = 0;

if (sarea_priv->dirty)
@@ -1041,7 +1041,7 @@ static void i810_dma_dispatch_mc(struct
if (u != I810_BUF_CLIENT)
DRM_DEBUG("MC found buffer that isn't mine!\n");

- if (used > 4 * 1024)
+ if (used < 0 || used > 4 * 1024)
used = 0;

sarea_priv->dirty = 0x7f;


2019-12-11 16:02:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 069/105] nfsd: restore NFSv3 ACL support

From: J. Bruce Fields <[email protected]>

commit 7c149057d044c52ed1e1d4ee50cf412c8d0f7295 upstream.

An error in e333f3bbefe3 left the nfsd_acl_program->pg_vers array empty,
which effectively turned off the server's support for NFSv3 ACLs.

Fixes: e333f3bbefe3 "nfsd: Allow containers to set supported nfs versions"
Cc: [email protected]
Cc: Trond Myklebust <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfsd/nfssvc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -94,12 +94,11 @@ static const struct svc_version *nfsd_ac

#define NFSD_ACL_MINVERS 2
#define NFSD_ACL_NRVERS ARRAY_SIZE(nfsd_acl_version)
-static const struct svc_version *nfsd_acl_versions[NFSD_ACL_NRVERS];

static struct svc_program nfsd_acl_program = {
.pg_prog = NFS_ACL_PROGRAM,
.pg_nvers = NFSD_ACL_NRVERS,
- .pg_vers = nfsd_acl_versions,
+ .pg_vers = nfsd_acl_version,
.pg_name = "nfsacl",
.pg_class = "nfsd",
.pg_stats = &nfsd_acl_svcstats,


2019-12-11 16:02:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 063/105] x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect

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

commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream.

The AMD FCH USB XHCI Controller advertises support for generating PME#
while in D0. When in D0, it does signal PME# for USB 3.0 connect events,
but not for USB 2.0 or USB 1.1 connect events, which means the controller
doesn't wake correctly for those events.

00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
Subsystem: Dell FCH USB XHCI Controller [1028:087e]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)

Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not
assert PME# from D0 so we don't rely on it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kai-Heng Feng <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/pci/fixup.c | 11 +++++++++++
1 file changed, 11 insertions(+)

--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -589,6 +589,17 @@ static void pci_fixup_amd_ehci_pme(struc
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7808, pci_fixup_amd_ehci_pme);

/*
+ * Device [1022:7914]
+ * When in D0, PME# doesn't get asserted when plugging USB 2.0 device.
+ */
+static void pci_fixup_amd_fch_xhci_pme(struct pci_dev *dev)
+{
+ dev_info(&dev->dev, "PME# does not work under D0, disabling it\n");
+ dev->pme_support &= ~(PCI_PM_CAP_PME_D0 >> PCI_PM_CAP_PME_SHIFT);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7914, pci_fixup_amd_fch_xhci_pme);
+
+/*
* Apple MacBook Pro: Avoid [mem 0x7fa00000-0x7fbfffff]
*
* Using the [mem 0x7fa00000-0x7fbfffff] region, e.g., by assigning it to


2019-12-11 16:02:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 061/105] media: rc: mark input device as pointing stick

From: Sean Young <[email protected]>

commit ce819649b03d932dc19b0cb6be513779bf64fad3 upstream.

libinput refuses pointer movement from rc-core, since it believes it's not
a pointer-type device:

libinput error: event17 - Media Center Ed. eHome Infrared Remote Transceiver (1784:0008): libinput bug: REL_X/Y from a non-pointer device

Fixes: 158bc148a31e ("media: rc: mce_kbd: input events via rc-core's input device")
Fixes: 0ac5a603a732 ("media: rc: imon: report mouse events using rc-core's input device")
Cc: [email protected] # 4.20+
Signed-off-by: Sean Young <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/rc/rc-main.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1773,6 +1773,7 @@ static int rc_prepare_rx_device(struct r
set_bit(MSC_SCAN, dev->input_dev->mscbit);

/* Pointer/mouse events */
+ set_bit(INPUT_PROP_POINTING_STICK, dev->input_dev->propbit);
set_bit(EV_REL, dev->input_dev->evbit);
set_bit(REL_X, dev->input_dev->relbit);
set_bit(REL_Y, dev->input_dev->relbit);


2019-12-11 16:02:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 065/105] CIFS: Fix SMB2 oplock break processing

From: Pavel Shilovsky <[email protected]>

commit fa9c2362497fbd64788063288dc4e74daf977ebb upstream.

Even when mounting modern protocol version the server may be
configured without supporting SMB2.1 leases and the client
uses SMB2 oplock to optimize IO performance through local caching.

However there is a problem in oplock break handling that leads
to missing a break notification on the client who has a file
opened. It latter causes big latencies to other clients that
are trying to open the same file.

The problem reproduces when there are multiple shares from the
same server mounted on the client. The processing code tries to
match persistent and volatile file ids from the break notification
with an open file but it skips all share besides the first one.
Fix this by looking up in all shares belonging to the server that
issued the oplock break.

Cc: Stable <[email protected]>
Signed-off-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/smb2misc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

--- a/fs/cifs/smb2misc.c
+++ b/fs/cifs/smb2misc.c
@@ -673,10 +673,10 @@ smb2_is_valid_oplock_break(char *buffer,
spin_lock(&cifs_tcp_ses_lock);
list_for_each(tmp, &server->smb_ses_list) {
ses = list_entry(tmp, struct cifs_ses, smb_ses_list);
+
list_for_each(tmp1, &ses->tcon_list) {
tcon = list_entry(tmp1, struct cifs_tcon, tcon_list);

- cifs_stats_inc(&tcon->stats.cifs_stats.num_oplock_brks);
spin_lock(&tcon->open_file_lock);
list_for_each(tmp2, &tcon->openFileList) {
cfile = list_entry(tmp2, struct cifsFileInfo,
@@ -688,6 +688,8 @@ smb2_is_valid_oplock_break(char *buffer,
continue;

cifs_dbg(FYI, "file id match, oplock break\n");
+ cifs_stats_inc(
+ &tcon->stats.cifs_stats.num_oplock_brks);
cinode = CIFS_I(d_inode(cfile->dentry));
spin_lock(&cfile->file_info_lock);
if (!CIFS_CACHE_WRITE(cinode) &&
@@ -720,9 +722,6 @@ smb2_is_valid_oplock_break(char *buffer,
return true;
}
spin_unlock(&tcon->open_file_lock);
- spin_unlock(&cifs_tcp_ses_lock);
- cifs_dbg(FYI, "No matching file for oplock break\n");
- return true;
}
}
spin_unlock(&cifs_tcp_ses_lock);


2019-12-11 16:03:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 068/105] nfsd: Ensure CLONE persists data and metadata changes to the target file

From: Trond Myklebust <[email protected]>

commit a25e3726b32c746c0098125d4c7463bb84df72bb upstream.

The NFSv4.2 CLONE operation has implicit persistence requirements on the
target file, since there is no protocol requirement that the client issue
a separate operation to persist data.
For that reason, we should call vfs_fsync_range() on the destination file
after a successful call to vfs_clone_file_range().

Fixes: ffa0160a1039 ("nfsd: implement the NFSv4.2 CLONE operation")
Signed-off-by: Trond Myklebust <[email protected]>
Cc: [email protected] # v4.5+
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfsd/nfs4proc.c | 3 ++-
fs/nfsd/vfs.c | 8 +++++++-
fs/nfsd/vfs.h | 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)

--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1083,7 +1083,8 @@ nfsd4_clone(struct svc_rqst *rqstp, stru
goto out;

status = nfsd4_clone_file_range(src, clone->cl_src_pos,
- dst, clone->cl_dst_pos, clone->cl_count);
+ dst, clone->cl_dst_pos, clone->cl_count,
+ EX_ISSYNC(cstate->current_fh.fh_export));

fput(dst);
fput(src);
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -552,7 +552,7 @@ __be32 nfsd4_set_nfs4_label(struct svc_r
#endif

__be32 nfsd4_clone_file_range(struct file *src, u64 src_pos, struct file *dst,
- u64 dst_pos, u64 count)
+ u64 dst_pos, u64 count, bool sync)
{
loff_t cloned;

@@ -561,6 +561,12 @@ __be32 nfsd4_clone_file_range(struct fil
return nfserrno(cloned);
if (count && cloned != count)
return nfserrno(-EINVAL);
+ if (sync) {
+ loff_t dst_end = count ? dst_pos + count - 1 : LLONG_MAX;
+ int status = vfs_fsync_range(dst, dst_pos, dst_end, 0);
+ if (status < 0)
+ return nfserrno(status);
+ }
return 0;
}

--- a/fs/nfsd/vfs.h
+++ b/fs/nfsd/vfs.h
@@ -58,7 +58,7 @@ __be32 nfsd4_set_nfs4_label(str
__be32 nfsd4_vfs_fallocate(struct svc_rqst *, struct svc_fh *,
struct file *, loff_t, loff_t, int);
__be32 nfsd4_clone_file_range(struct file *, u64, struct file *,
- u64, u64);
+ u64, u64, bool);
#endif /* CONFIG_NFSD_V4 */
__be32 nfsd_create_locked(struct svc_rqst *, struct svc_fh *,
char *name, int len, struct iattr *attrs,


2019-12-11 16:03:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 064/105] CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks

From: Pavel Shilovsky <[email protected]>

commit 6f582b273ec23332074d970a7fb25bef835df71f upstream.

Currently when the client creates a cifsFileInfo structure for
a newly opened file, it allocates a list of byte-range locks
with a pointer to the new cfile and attaches this list to the
inode's lock list. The latter happens before initializing all
other fields, e.g. cfile->tlink. Thus a partially initialized
cifsFileInfo structure becomes available to other threads that
walk through the inode's lock list. One example of such a thread
may be an oplock break worker thread that tries to push all
cached byte-range locks. This causes NULL-pointer dereference
in smb2_push_mandatory_locks() when accessing cfile->tlink:

[598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038
...
[598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs]
[598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs]
...
[598428.945834] Call Trace:
[598428.945870] ? cifs_revalidate_mapping+0x45/0x90 [cifs]
[598428.945901] cifs_oplock_break+0x13d/0x450 [cifs]
[598428.945909] process_one_work+0x1db/0x380
[598428.945914] worker_thread+0x4d/0x400
[598428.945921] kthread+0x104/0x140
[598428.945925] ? process_one_work+0x380/0x380
[598428.945931] ? kthread_park+0x80/0x80
[598428.945937] ret_from_fork+0x35/0x40

Fix this by reordering initialization steps of the cifsFileInfo
structure: initialize all the fields first and then add the new
byte-range lock list to the inode's lock list.

Cc: Stable <[email protected]>
Signed-off-by: Pavel Shilovsky <[email protected]>
Reviewed-by: Aurelien Aptel <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/file.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -313,9 +313,6 @@ cifs_new_fileinfo(struct cifs_fid *fid,
INIT_LIST_HEAD(&fdlocks->locks);
fdlocks->cfile = cfile;
cfile->llist = fdlocks;
- cifs_down_write(&cinode->lock_sem);
- list_add(&fdlocks->llist, &cinode->llist);
- up_write(&cinode->lock_sem);

cfile->count = 1;
cfile->pid = current->tgid;
@@ -339,6 +336,10 @@ cifs_new_fileinfo(struct cifs_fid *fid,
oplock = 0;
}

+ cifs_down_write(&cinode->lock_sem);
+ list_add(&fdlocks->llist, &cinode->llist);
+ up_write(&cinode->lock_sem);
+
spin_lock(&tcon->open_file_lock);
if (fid->pending_open->oplock != CIFS_OPLOCK_NO_CHANGE && oplock)
oplock = fid->pending_open->oplock;


2019-12-11 16:03:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 057/105] Input: synaptics-rmi4 - dont increment rmiaddr for SMBus transfers

From: Hans Verkuil <[email protected]>

commit a284e11c371e446371675668d8c8120a27227339 upstream.

This increment of rmi_smbus in rmi_smb_read/write_block() causes
garbage to be read/written.

The first read of SMB_MAX_COUNT bytes is fine, but after that
it is nonsense. Trial-and-error showed that by dropping the
increment of rmiaddr everything is fine and the F54 function
properly works.

I tried a hack with rmi_smb_write_block() as well (writing to the
same F54 touchpad data area, then reading it back), and that
suggests that there too the rmiaddr increment has to be dropped.
It makes sense that if it has to be dropped for read, then it has
to be dropped for write as well.

It looks like the initial work with F54 was done using i2c, not smbus,
and it seems nobody ever tested F54 with smbus. The other functions
all read/write less than SMB_MAX_COUNT as far as I can tell, so this
issue was never noticed with non-F54 functions.

With this change I can read out the touchpad data correctly on my
Lenovo X1 Carbon 6th Gen laptop.

Signed-off-by: Hans Verkuil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/rmi4/rmi_smbus.c | 2 --
1 file changed, 2 deletions(-)

--- a/drivers/input/rmi4/rmi_smbus.c
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -163,7 +163,6 @@ static int rmi_smb_write_block(struct rm
/* prepare to write next block of bytes */
cur_len -= SMB_MAX_COUNT;
databuff += SMB_MAX_COUNT;
- rmiaddr += SMB_MAX_COUNT;
}
exit:
mutex_unlock(&rmi_smb->page_mutex);
@@ -215,7 +214,6 @@ static int rmi_smb_read_block(struct rmi
/* prepare to read next block of bytes */
cur_len -= SMB_MAX_COUNT;
databuff += SMB_MAX_COUNT;
- rmiaddr += SMB_MAX_COUNT;
}

retval = 0;


2019-12-11 16:03:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 055/105] Input: synaptics - switch another X1 Carbon 6 to RMI/SMbus

From: Hans Verkuil <[email protected]>

commit fc1156f373e3927e0dcf06678906c367588bfdd6 upstream.

Some Lenovo X1 Carbon Gen 6 laptops report LEN0091. Add this
to the smbus_pnp_ids list.

Signed-off-by: Hans Verkuil <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -172,6 +172,7 @@ static const char * const smbus_pnp_ids[
"LEN0071", /* T480 */
"LEN0072", /* X1 Carbon Gen 5 (2017) - Elan/ALPS trackpoint */
"LEN0073", /* X1 Carbon G5 (Elantech) */
+ "LEN0091", /* X1 Carbon 6 */
"LEN0092", /* X1 Carbon 6 */
"LEN0093", /* T480 */
"LEN0096", /* X280 */


2019-12-11 16:03:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 006/105] time: Zero the upper 32-bits in __kernel_timespec on 32-bit

From: Dmitry Safonov <[email protected]>

commit 7b8474466ed97be458c825f34a85f2c2b84c3f95 upstream.

On compat interfaces, the high order bits of nanoseconds should be zeroed
out. This is because the application code or the libc do not guarantee
zeroing of these. If used without zeroing, kernel might be at risk of using
timespec values incorrectly.

Originally it was handled correctly, but lost during is_compat_syscall()
cleanup. Revert the condition back to check CONFIG_64BIT.

Fixes: 98f76206b335 ("compat: Cleanup in_compat_syscall() callers")
Reported-by: Ben Hutchings <[email protected]>
Signed-off-by: Dmitry Safonov <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/time/time.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -881,7 +881,8 @@ int get_timespec64(struct timespec64 *ts
ts->tv_sec = kts.tv_sec;

/* Zero out the padding for 32 bit systems or in compat mode */
- if (IS_ENABLED(CONFIG_64BIT_TIME) && in_compat_syscall())
+ if (IS_ENABLED(CONFIG_64BIT_TIME) && (!IS_ENABLED(CONFIG_64BIT) ||
+ in_compat_syscall()))
kts.tv_nsec &= 0xFFFFFFFFUL;

ts->tv_nsec = kts.tv_nsec;


2019-12-11 16:04:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 058/105] Input: goodix - add upside-down quirk for Teclast X89 tablet

From: Hans de Goede <[email protected]>

commit df5b5e555b356662a5e4a23c6774fdfce8547d54 upstream.

The touchscreen on the Teclast X89 is mounted upside down in relation to
the display orientation (the touchscreen itself is mounted upright, but the
display is mounted upside-down). Add a quirk for this so that we send
coordinates which match the display orientation.

Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Bastien Nocera <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/touchscreen/goodix.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -127,6 +127,15 @@ static const unsigned long goodix_irq_fl
static const struct dmi_system_id rotated_screen[] = {
#if defined(CONFIG_DMI) && defined(CONFIG_X86)
{
+ .ident = "Teclast X89",
+ .matches = {
+ /* tPAD is too generic, also match on bios date */
+ DMI_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_BOARD_NAME, "tPAD"),
+ DMI_MATCH(DMI_BIOS_DATE, "12/19/2014"),
+ },
+ },
+ {
.ident = "WinBook TW100",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "WinBook"),


2019-12-11 16:04:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 045/105] fuse: verify nlink

From: Miklos Szeredi <[email protected]>

commit c634da718db9b2fac201df2ae1b1b095344ce5eb upstream.

When adding a new hard link, make sure that i_nlink doesn't overflow.

Fixes: ac45d61357e8 ("fuse: fix nlink after unlink")
Cc: <[email protected]> # v3.4
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/fuse/dir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -814,7 +814,8 @@ static int fuse_link(struct dentry *entr

spin_lock(&fi->lock);
fi->attr_version = atomic64_inc_return(&fc->attr_version);
- inc_nlink(inode);
+ if (likely(inode->i_nlink < UINT_MAX))
+ inc_nlink(inode);
spin_unlock(&fi->lock);
fuse_invalidate_attr(inode);
fuse_update_ctime(inode);


2019-12-11 16:04:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 060/105] Input: Fix memory leak in psxpad_spi_probe

From: Navid Emamdoost <[email protected]>

In the implementation of psxpad_spi_probe() the allocated memory for
pdev is leaked if psxpad_spi_init_ff() or input_register_polled_device()
fail. The solution is using device managed allocation, like the one used
for pad. Perform the allocation using
devm_input_allocate_polled_device().

Fixes: 8be193c7b1f4 ("Input: add support for PlayStation 1/2 joypads connected via SPI")
Signed-off-by: Navid Emamdoost <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/joystick/psxpad-spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/joystick/psxpad-spi.c
+++ b/drivers/input/joystick/psxpad-spi.c
@@ -292,7 +292,7 @@ static int psxpad_spi_probe(struct spi_d
if (!pad)
return -ENOMEM;

- pdev = input_allocate_polled_device();
+ pdev = devm_input_allocate_polled_device(&spi->dev);
if (!pdev) {
dev_err(&spi->dev, "failed to allocate input device\n");
return -ENOMEM;


2019-12-11 16:05:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 015/105] autofs: fix a leak in autofs_expire_indirect()

From: Al Viro <[email protected]>

[ Upstream commit 03ad0d703df75c43f78bd72e16124b5b94a95188 ]

if the second call of should_expire() in there ends up
grabbing and returning a new reference to dentry, we need
to drop it before continuing.

Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/autofs/expire.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/autofs/expire.c b/fs/autofs/expire.c
index cdff0567aacb3..2d01553a6d586 100644
--- a/fs/autofs/expire.c
+++ b/fs/autofs/expire.c
@@ -498,9 +498,10 @@ static struct dentry *autofs_expire_indirect(struct super_block *sb,
*/
how &= ~AUTOFS_EXP_LEAVES;
found = should_expire(expired, mnt, timeout, how);
- if (!found || found != expired)
- /* Something has changed, continue */
+ if (found != expired) { // something has changed, continue
+ dput(found);
goto next;
+ }

if (expired != dentry)
dput(dentry);
--
2.20.1



2019-12-11 16:05:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 014/105] aio: Fix io_pgetevents() struct __compat_aio_sigset layout

From: Guillem Jover <[email protected]>

[ Upstream commit 97eba80fcca754856d09e048f469db22773bec68 ]

This type is used to pass the sigset_t from userland to the kernel,
but it was using the kernel native pointer type for the member
representing the compat userland pointer to the userland sigset_t.

This messes up the layout, and makes the kernel eat up both the
userland pointer and the size members into the kernel pointer, and
then reads garbage into the kernel sigsetsize. Which makes the sigset_t
size consistency check fail, and consequently the syscall always
returns -EINVAL.

This breaks both libaio and strace on 32-bit userland running on 64-bit
kernels. And there are apparently no users in the wild of the current
broken layout (at least according to codesearch.debian.org and a brief
check over github.com search). So it looks safe to fix this directly
in the kernel, instead of either letting userland deal with this
permanently with the additional overhead or trying to make the syscall
infer what layout userland used, even though this is also being worked
around in libaio to temporarily cope with kernels that have not yet
been fixed.

We use a proper compat_uptr_t instead of a compat_sigset_t pointer.

Fixes: 7a074e96dee6 ("aio: implement io_pgetevents")
Signed-off-by: Guillem Jover <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/aio.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 01e0fb9ae45ae..0d9a559d488c1 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -2179,7 +2179,7 @@ SYSCALL_DEFINE5(io_getevents_time32, __u32, ctx_id,
#ifdef CONFIG_COMPAT

struct __compat_aio_sigset {
- compat_sigset_t __user *sigmask;
+ compat_uptr_t sigmask;
compat_size_t sigsetsize;
};

@@ -2193,7 +2193,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
struct old_timespec32 __user *, timeout,
const struct __compat_aio_sigset __user *, usig)
{
- struct __compat_aio_sigset ksig = { NULL, };
+ struct __compat_aio_sigset ksig = { 0, };
struct timespec64 t;
bool interrupted;
int ret;
@@ -2204,7 +2204,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents,
if (usig && copy_from_user(&ksig, usig, sizeof(ksig)))
return -EFAULT;

- ret = set_compat_user_sigmask(ksig.sigmask, ksig.sigsetsize);
+ ret = set_compat_user_sigmask(compat_ptr(ksig.sigmask), ksig.sigsetsize);
if (ret)
return ret;

@@ -2228,7 +2228,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents_time64,
struct __kernel_timespec __user *, timeout,
const struct __compat_aio_sigset __user *, usig)
{
- struct __compat_aio_sigset ksig = { NULL, };
+ struct __compat_aio_sigset ksig = { 0, };
struct timespec64 t;
bool interrupted;
int ret;
@@ -2239,7 +2239,7 @@ COMPAT_SYSCALL_DEFINE6(io_pgetevents_time64,
if (usig && copy_from_user(&ksig, usig, sizeof(ksig)))
return -EFAULT;

- ret = set_compat_user_sigmask(ksig.sigmask, ksig.sigsetsize);
+ ret = set_compat_user_sigmask(compat_ptr(ksig.sigmask), ksig.sigsetsize);
if (ret)
return ret;

--
2.20.1



2019-12-11 16:06:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 037/105] rsxx: add missed destroy_workqueue calls in remove

From: Chuhong Yuan <[email protected]>

[ Upstream commit dcb77e4b274b8f13ac6482dfb09160cd2fae9a40 ]

The driver misses calling destroy_workqueue in remove like what is done
when probe fails.
Add the missed calls to fix it.

Signed-off-by: Chuhong Yuan <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/block/rsxx/core.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 76b73ddf8fd73..10f6368117d81 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -1000,8 +1000,10 @@ static void rsxx_pci_remove(struct pci_dev *dev)

cancel_work_sync(&card->event_work);

+ destroy_workqueue(card->event_wq);
rsxx_destroy_dev(card);
rsxx_dma_destroy(card);
+ destroy_workqueue(card->creg_ctrl.creg_wq);

spin_lock_irqsave(&card->irq_lock, flags);
rsxx_disable_ier_and_isr(card, CR_INTR_ALL);
--
2.20.1



2019-12-11 16:06:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 043/105] i2c: core: fix use after free in of_i2c_notify

From: Wen Yang <[email protected]>

[ Upstream commit a4c2fec16f5e6a5fee4865e6e0e91e2bc2d10f37 ]

We can't use "adap->dev" after it has been freed.

Fixes: 5bf4fa7daea6 ("i2c: break out OF support into separate file")
Signed-off-by: Wen Yang <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/i2c/i2c-core-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index d1c48dec7118e..9b2fce4906c41 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -250,14 +250,14 @@ static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
}

client = of_i2c_register_device(adap, rd->dn);
- put_device(&adap->dev);
-
if (IS_ERR(client)) {
dev_err(&adap->dev, "failed to create client for '%pOF'\n",
rd->dn);
+ put_device(&adap->dev);
of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(client));
}
+ put_device(&adap->dev);
break;
case OF_RECONFIG_CHANGE_REMOVE:
/* already depopulated? */
--
2.20.1



2019-12-11 16:06:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 042/105] net: ep93xx_eth: fix mismatch of request_mem_region in remove

From: Chuhong Yuan <[email protected]>

[ Upstream commit 3df70afe8d33f4977d0e0891bdcfb639320b5257 ]

The driver calls release_resource in remove to match request_mem_region
in probe, which is incorrect.
Fix it by using the right one, release_mem_region.

Signed-off-by: Chuhong Yuan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/cirrus/ep93xx_eth.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cirrus/ep93xx_eth.c b/drivers/net/ethernet/cirrus/ep93xx_eth.c
index f1a0c4dceda0c..f37c9a08c4cf5 100644
--- a/drivers/net/ethernet/cirrus/ep93xx_eth.c
+++ b/drivers/net/ethernet/cirrus/ep93xx_eth.c
@@ -763,6 +763,7 @@ static int ep93xx_eth_remove(struct platform_device *pdev)
{
struct net_device *dev;
struct ep93xx_priv *ep;
+ struct resource *mem;

dev = platform_get_drvdata(pdev);
if (dev == NULL)
@@ -778,8 +779,8 @@ static int ep93xx_eth_remove(struct platform_device *pdev)
iounmap(ep->base_addr);

if (ep->res != NULL) {
- release_resource(ep->res);
- kfree(ep->res);
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ release_mem_region(mem->start, resource_size(mem));
}

free_netdev(dev);
--
2.20.1



2019-12-11 16:07:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 012/105] serial: stm32: fix clearing interrupt error flags

From: Fabrice Gasnier <[email protected]>

commit 1250ed7114a977cdc2a67a0c09d6cdda63970eb9 upstream.

The interrupt clear flag register is a "write 1 to clear" register.
So, only writing ones allows to clear flags:
- Replace buggy stm32_clr_bits() by a simple write to clear error flags
- Replace useless read/modify/write stm32_set_bits() routine by a
simple write to clear TC (transfer complete) flag.

Fixes: 4f01d833fdcd ("serial: stm32: fix rx error handling")
Signed-off-by: Fabrice Gasnier <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/stm32-usart.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -239,8 +239,8 @@ static void stm32_receive_chars(struct u
* cleared by the sequence [read SR - read DR].
*/
if ((sr & USART_SR_ERR_MASK) && ofs->icr != UNDEF_REG)
- stm32_clr_bits(port, ofs->icr, USART_ICR_ORECF |
- USART_ICR_PECF | USART_ICR_FECF);
+ writel_relaxed(sr & USART_SR_ERR_MASK,
+ port->membase + ofs->icr);

c = stm32_get_char(port, &sr, &stm32_port->last_res);
port->icount.rx++;
@@ -434,7 +434,7 @@ static void stm32_transmit_chars(struct
if (ofs->icr == UNDEF_REG)
stm32_clr_bits(port, ofs->isr, USART_SR_TC);
else
- stm32_set_bits(port, ofs->icr, USART_ICR_TCCF);
+ writel_relaxed(USART_ICR_TCCF, port->membase + ofs->icr);

if (stm32_port->tx_ch)
stm32_transmit_chars_dma(port);


2019-12-11 16:08:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 031/105] perf/core: Consistently fail fork on allocation failures

From: Alexander Shishkin <[email protected]>

[ Upstream commit 697d877849d4b34ab58d7078d6930bad0ef6fc66 ]

Commit:

313ccb9615948 ("perf: Allocate context task_ctx_data for child event")

makes the inherit path skip over the current event in case of task_ctx_data
allocation failure. This, however, is inconsistent with allocation failures
in perf_event_alloc(), which would abort the fork.

Correct this by returning an error code on task_ctx_data allocation
failure and failing the fork in that case.

Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 53173883513c1..25942e43b8d48 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11719,7 +11719,7 @@ inherit_event(struct perf_event *parent_event,
GFP_KERNEL);
if (!child_ctx->task_ctx_data) {
free_event(child_event);
- return NULL;
+ return ERR_PTR(-ENOMEM);
}
}

--
2.20.1



2019-12-11 16:08:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 041/105] afs: Fix race in commit bulk status fetch

From: David Howells <[email protected]>

[ Upstream commit a28f239e296767ebf4ec4ae8a9ecb57d0d444b3f ]

When a lookup is done, the afs filesystem will perform a bulk status-fetch
operation on the requested vnode (file) plus the next 49 other vnodes from
the directory list (in AFS, directory contents are downloaded as blobs and
parsed locally). When the results are received, it will speculatively
populate the inode cache from the extra data.

However, if the lookup races with another lookup on the same directory, but
for a different file - one that's in the 49 extra fetches, then if the bulk
status-fetch operation finishes first, it will try and update the inode
from the other lookup.

If this other inode is still in the throes of being created, however, this
will cause an assertion failure in afs_apply_status():

BUG_ON(test_bit(AFS_VNODE_UNSET, &vnode->flags));

on or about fs/afs/inode.c:175 because it expects data to be there already
that it can compare to.

Fix this by skipping the update if the inode is being created as the
creator will presumably set up the inode with the same information.

Fixes: 39db9815da48 ("afs: Fix application of the results of a inline bulk status fetch")
Signed-off-by: David Howells <[email protected]>
Reviewed-by: Marc Dionne <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/afs/dir.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 139b4e3cc9464..f4fdf3eaa5709 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -803,7 +803,12 @@ success:
continue;

if (cookie->inodes[i]) {
- afs_vnode_commit_status(&fc, AFS_FS_I(cookie->inodes[i]),
+ struct afs_vnode *iv = AFS_FS_I(cookie->inodes[i]);
+
+ if (test_bit(AFS_VNODE_UNSET, &iv->flags))
+ continue;
+
+ afs_vnode_commit_status(&fc, iv,
scb->cb_break, NULL, scb);
continue;
}
--
2.20.1



2019-12-11 16:08:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 030/105] sched/pelt: Fix update of blocked PELT ordering

From: Vincent Guittot <[email protected]>

[ Upstream commit b90f7c9d2198d789709390280a43e0a46345682b ]

update_cfs_rq_load_avg() can call cpufreq_update_util() to trigger an
update of the frequency. Make sure that RT, DL and IRQ PELT signals have
been updated before calling cpufreq.

Signed-off-by: Vincent Guittot <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: 371bf4273269 ("sched/rt: Add rt_rq utilization tracking")
Fixes: 3727e0e16340 ("sched/dl: Add dl_rq utilization tracking")
Fixes: 91c27493e78d ("sched/irq: Add IRQ utilization tracking")
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/sched/fair.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 649c6b60929e2..ba7cc68a39935 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7530,6 +7530,19 @@ static void update_blocked_averages(int cpu)
rq_lock_irqsave(rq, &rf);
update_rq_clock(rq);

+ /*
+ * update_cfs_rq_load_avg() can call cpufreq_update_util(). Make sure
+ * that RT, DL and IRQ signals have been updated before updating CFS.
+ */
+ curr_class = rq->curr->sched_class;
+ update_rt_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &rt_sched_class);
+ update_dl_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &dl_sched_class);
+ update_irq_load_avg(rq, 0);
+
+ /* Don't need periodic decay once load/util_avg are null */
+ if (others_have_blocked(rq))
+ done = false;
+
/*
* Iterates the task_group tree in a bottom up fashion, see
* list_add_leaf_cfs_rq() for details.
@@ -7557,14 +7570,6 @@ static void update_blocked_averages(int cpu)
done = false;
}

- curr_class = rq->curr->sched_class;
- update_rt_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &rt_sched_class);
- update_dl_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &dl_sched_class);
- update_irq_load_avg(rq, 0);
- /* Don't need periodic decay once load/util_avg are null */
- if (others_have_blocked(rq))
- done = false;
-
update_blocked_load_status(rq, !done);
rq_unlock_irqrestore(rq, &rf);
}
@@ -7625,12 +7630,18 @@ static inline void update_blocked_averages(int cpu)

rq_lock_irqsave(rq, &rf);
update_rq_clock(rq);
- update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq);

+ /*
+ * update_cfs_rq_load_avg() can call cpufreq_update_util(). Make sure
+ * that RT, DL and IRQ signals have been updated before updating CFS.
+ */
curr_class = rq->curr->sched_class;
update_rt_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &rt_sched_class);
update_dl_rq_load_avg(rq_clock_pelt(rq), rq, curr_class == &dl_sched_class);
update_irq_load_avg(rq, 0);
+
+ update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq);
+
update_blocked_load_status(rq, cfs_rq_has_blocked(cfs_rq) || others_have_blocked(rq));
rq_unlock_irqrestore(rq, &rf);
}
--
2.20.1



2019-12-11 16:08:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 040/105] net: hns3: fix ETS bandwidth validation bug

From: Yonglong Liu <[email protected]>

[ Upstream commit c2d56897819338eb0ba8b93184f7d10329b36653 ]

Some device only support 4 TCs, but the driver check the total
bandwidth of 8 TCs, so may cause wrong configurations write to
the hw.

This patch uses hdev->tc_max to instead HNAE3_MAX_TC to fix it.

Fixes: e432abfb99e5 ("net: hns3: add common validation in hclge_dcb")
Signed-off-by: Yonglong Liu <[email protected]>
Signed-off-by: Huazhong Tan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index d9136a199d8db..f5c323e798343 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -124,7 +124,7 @@ static int hclge_ets_validate(struct hclge_dev *hdev, struct ieee_ets *ets,
if (ret)
return ret;

- for (i = 0; i < HNAE3_MAX_TC; i++) {
+ for (i = 0; i < hdev->tc_max; i++) {
switch (ets->tc_tsa[i]) {
case IEEE_8021QAZ_TSA_STRICT:
if (hdev->tm_info.tc_info[i].tc_sch_mode !=
--
2.20.1



2019-12-11 16:08:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 039/105] net: hns3: reallocate SSU buffer size when pfc_en changes

From: Yunsheng Lin <[email protected]>

[ Upstream commit aea8cfb35a82d6c2f3517c86694933ba766635e5 ]

When a TC's PFC is disabled or enabled, the RX private buffer for
this TC need to be changed too, otherwise this may cause packet
dropped problem.

This patch fixes it by calling hclge_buffer_alloc to reallocate
buffer when pfc_en changes.

Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature")
Signed-off-by: Yunsheng Lin <[email protected]>
Signed-off-by: Huazhong Tan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index bac4ce13f6ae4..d9136a199d8db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -302,6 +302,7 @@ static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
struct hclge_vport *vport = hclge_get_vport(h);
struct hclge_dev *hdev = vport->back;
u8 i, j, pfc_map, *prio_tc;
+ int ret;

if (!(hdev->dcbx_cap & DCB_CAP_DCBX_VER_IEEE) ||
hdev->flag & HCLGE_FLAG_MQPRIO_ENABLE)
@@ -327,7 +328,21 @@ static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)

hclge_tm_pfc_info_update(hdev);

- return hclge_pause_setup_hw(hdev, false);
+ ret = hclge_pause_setup_hw(hdev, false);
+ if (ret)
+ return ret;
+
+ ret = hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ if (ret)
+ return ret;
+
+ ret = hclge_buffer_alloc(hdev);
+ if (ret) {
+ hclge_notify_client(hdev, HNAE3_UP_CLIENT);
+ return ret;
+ }
+
+ return hclge_notify_client(hdev, HNAE3_UP_CLIENT);
}

/* DCBX configuration */
--
2.20.1



2019-12-11 16:08:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 038/105] ravb: implement MTU change while device is up

From: Ulrich Hecht <[email protected]>

[ Upstream commit 15fb35fa9ff456b81159033eba6397fcee85e671 ]

Pre-allocates buffers sufficient for the maximum supported MTU (2026) in
order to eliminate the possibility of resource exhaustion when changing the
MTU while the device is up.

Signed-off-by: Ulrich Hecht <[email protected]>
Reviewed-by: Sergei Shtylyov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/renesas/ravb.h | 3 ++-
drivers/net/ethernet/renesas/ravb_main.c | 26 +++++++++++++-----------
2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index ac9195add8116..7090229398227 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -960,6 +960,8 @@ enum RAVB_QUEUE {
#define NUM_RX_QUEUE 2
#define NUM_TX_QUEUE 2

+#define RX_BUF_SZ (2048 - ETH_FCS_LEN + sizeof(__sum16))
+
/* TX descriptors per packet */
#define NUM_TX_DESC_GEN2 2
#define NUM_TX_DESC_GEN3 1
@@ -1023,7 +1025,6 @@ struct ravb_private {
u32 dirty_rx[NUM_RX_QUEUE]; /* Producer ring indices */
u32 cur_tx[NUM_TX_QUEUE];
u32 dirty_tx[NUM_TX_QUEUE];
- u32 rx_buf_sz; /* Based on MTU+slack. */
struct napi_struct napi[NUM_RX_QUEUE];
struct work_struct work;
/* MII transceiver section. */
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 6cacd5e893aca..393644833cd57 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -230,7 +230,7 @@ static void ravb_ring_free(struct net_device *ndev, int q)
le32_to_cpu(desc->dptr)))
dma_unmap_single(ndev->dev.parent,
le32_to_cpu(desc->dptr),
- priv->rx_buf_sz,
+ RX_BUF_SZ,
DMA_FROM_DEVICE);
}
ring_size = sizeof(struct ravb_ex_rx_desc) *
@@ -293,9 +293,9 @@ static void ravb_ring_format(struct net_device *ndev, int q)
for (i = 0; i < priv->num_rx_ring[q]; i++) {
/* RX descriptor */
rx_desc = &priv->rx_ring[q][i];
- rx_desc->ds_cc = cpu_to_le16(priv->rx_buf_sz);
+ rx_desc->ds_cc = cpu_to_le16(RX_BUF_SZ);
dma_addr = dma_map_single(ndev->dev.parent, priv->rx_skb[q][i]->data,
- priv->rx_buf_sz,
+ RX_BUF_SZ,
DMA_FROM_DEVICE);
/* We just set the data size to 0 for a failed mapping which
* should prevent DMA from happening...
@@ -342,9 +342,6 @@ static int ravb_ring_init(struct net_device *ndev, int q)
int ring_size;
int i;

- priv->rx_buf_sz = (ndev->mtu <= 1492 ? PKT_BUF_SZ : ndev->mtu) +
- ETH_HLEN + VLAN_HLEN + sizeof(__sum16);
-
/* Allocate RX and TX skb rings */
priv->rx_skb[q] = kcalloc(priv->num_rx_ring[q],
sizeof(*priv->rx_skb[q]), GFP_KERNEL);
@@ -354,7 +351,7 @@ static int ravb_ring_init(struct net_device *ndev, int q)
goto error;

for (i = 0; i < priv->num_rx_ring[q]; i++) {
- skb = netdev_alloc_skb(ndev, priv->rx_buf_sz + RAVB_ALIGN - 1);
+ skb = netdev_alloc_skb(ndev, RX_BUF_SZ + RAVB_ALIGN - 1);
if (!skb)
goto error;
ravb_set_buffer_align(skb);
@@ -590,7 +587,7 @@ static bool ravb_rx(struct net_device *ndev, int *quota, int q)
skb = priv->rx_skb[q][entry];
priv->rx_skb[q][entry] = NULL;
dma_unmap_single(ndev->dev.parent, le32_to_cpu(desc->dptr),
- priv->rx_buf_sz,
+ RX_BUF_SZ,
DMA_FROM_DEVICE);
get_ts &= (q == RAVB_NC) ?
RAVB_RXTSTAMP_TYPE_V2_L2_EVENT :
@@ -623,11 +620,11 @@ static bool ravb_rx(struct net_device *ndev, int *quota, int q)
for (; priv->cur_rx[q] - priv->dirty_rx[q] > 0; priv->dirty_rx[q]++) {
entry = priv->dirty_rx[q] % priv->num_rx_ring[q];
desc = &priv->rx_ring[q][entry];
- desc->ds_cc = cpu_to_le16(priv->rx_buf_sz);
+ desc->ds_cc = cpu_to_le16(RX_BUF_SZ);

if (!priv->rx_skb[q][entry]) {
skb = netdev_alloc_skb(ndev,
- priv->rx_buf_sz +
+ RX_BUF_SZ +
RAVB_ALIGN - 1);
if (!skb)
break; /* Better luck next round. */
@@ -1814,10 +1811,15 @@ static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)

static int ravb_change_mtu(struct net_device *ndev, int new_mtu)
{
- if (netif_running(ndev))
- return -EBUSY;
+ struct ravb_private *priv = netdev_priv(ndev);

ndev->mtu = new_mtu;
+
+ if (netif_running(ndev)) {
+ synchronize_irq(priv->emac_irq);
+ ravb_emac_init(ndev);
+ }
+
netdev_update_features(ndev);

return 0;
--
2.20.1



2019-12-11 16:09:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 033/105] x86/resctrl: Fix potential lockdep warning

From: Xiaochen Shen <[email protected]>

[ Upstream commit c8eafe1495303bfd0eedaa8156b1ee9082ee9642 ]

rdtgroup_cpus_write() and mkdir_rdt_prepare() call
rdtgroup_kn_lock_live() -> kernfs_to_rdtgroup() to get 'rdtgrp', and
then call the rdt_last_cmd_{clear,puts,...}() functions which will check
if rdtgroup_mutex is held/requires its caller to hold rdtgroup_mutex.

But if 'rdtgrp' returned from kernfs_to_rdtgroup() is NULL,
rdtgroup_mutex is not held and calling rdt_last_cmd_{clear,puts,...}()
will result in a self-incurred, potential lockdep warning.

Remove the rdt_last_cmd_{clear,puts,...}() calls in these two paths.
Just returning error should be sufficient to report to the user that the
entry doesn't exist any more.

[ bp: Massage. ]

Fixes: 94457b36e8a5 ("x86/intel_rdt: Add diagnostics when writing the cpus file")
Fixes: cfd0f34e4cd5 ("x86/intel_rdt: Add diagnostics when making directories")
Signed-off-by: Xiaochen Shen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Reviewed-by: Fenghua Yu <[email protected]>
Reviewed-by: Reinette Chatre <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
Cc: Thomas Gleixner <[email protected]>
Cc: x86-ml <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 ----
1 file changed, 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index a46dee8e78db4..2e3b06d6bbc6d 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -461,10 +461,8 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_file *of,
}

rdtgrp = rdtgroup_kn_lock_live(of->kn);
- rdt_last_cmd_clear();
if (!rdtgrp) {
ret = -ENOENT;
- rdt_last_cmd_puts("Directory was removed\n");
goto unlock;
}

@@ -2648,10 +2646,8 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
int ret;

prdtgrp = rdtgroup_kn_lock_live(prgrp_kn);
- rdt_last_cmd_clear();
if (!prdtgrp) {
ret = -ENODEV;
- rdt_last_cmd_puts("Directory was removed\n");
goto out_unlock;
}

--
2.20.1



2019-12-11 16:09:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 009/105] tty: serial: msm_serial: Fix flow control

From: Jeffrey Hugo <[email protected]>

commit b027ce258369cbfa88401a691c23dad01deb9f9b upstream.

hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and
Lenovo Miix 630 laptop. As part of initializing the wcn3990, hci_qca
disables flow, configures the uart baudrate, and then reenables flow - at
which point an event is expected to be received over the uart from the
wcn3990. It is observed that this event comes after the baudrate change
but before hci_qca re-enables flow. This is unexpected, and is a result of
msm_reset() being broken.

According to the uart_dm hardware documentation, it is recommended that
automatic hardware flow control be enabled by setting RX_RDY_CTL. Auto
hw flow control will manage RFR based on the configured watermark. When
there is space to receive data, the hw will assert RFR. When the watermark
is hit, the hw will de-assert RFR.

The hardware documentation indicates that RFR can me manually managed via
CR when RX_RDY_CTL is not set. SET_RFR asserts RFR, and RESET_RFR
de-asserts RFR.

msm_reset() is broken because after resetting the hardware, it
unconditionally asserts RFR via SET_RFR. This enables flow regardless of
the current configuration, and would undo a previous flow disable
operation. It should instead de-assert RFR via RESET_RFR to block flow
until the hardware is reconfigured. msm_serial should rely on the client
to specify that flow should be enabled, either via mctrl() or the termios
structure, and only assert RFR in response to those triggers.

Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
Signed-off-by: Jeffrey Hugo <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Cc: stable <[email protected]>
Reviewed-by: Andy Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/msm_serial.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -980,6 +980,7 @@ static unsigned int msm_get_mctrl(struct
static void msm_reset(struct uart_port *port)
{
struct msm_port *msm_port = UART_TO_MSM(port);
+ unsigned int mr;

/* reset everything */
msm_write(port, UART_CR_CMD_RESET_RX, UART_CR);
@@ -987,7 +988,10 @@ static void msm_reset(struct uart_port *
msm_write(port, UART_CR_CMD_RESET_ERR, UART_CR);
msm_write(port, UART_CR_CMD_RESET_BREAK_INT, UART_CR);
msm_write(port, UART_CR_CMD_RESET_CTS, UART_CR);
- msm_write(port, UART_CR_CMD_SET_RFR, UART_CR);
+ msm_write(port, UART_CR_CMD_RESET_RFR, UART_CR);
+ mr = msm_read(port, UART_MR1);
+ mr &= ~UART_MR1_RX_RDY_CTL;
+ msm_write(port, mr, UART_MR1);

/* Disable DM modes */
if (msm_port->is_uartdm)


2019-12-11 16:09:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 032/105] ALSA: pcm: Fix stream lock usage in snd_pcm_period_elapsed()

From: paulhsia <[email protected]>

[ Upstream commit f5cdc9d4003a2f66ea57b3edd3e04acc2b1a4439 ]

If the nullity check for `substream->runtime` is outside of the lock
region, it is possible to have a null runtime in the critical section
if snd_pcm_detach_substream is called right before the lock.

Signed-off-by: paulhsia <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
sound/core/pcm_lib.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index d80041ea4e01c..2236b5e0c1f25 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -1782,11 +1782,14 @@ void snd_pcm_period_elapsed(struct snd_pcm_substream *substream)
struct snd_pcm_runtime *runtime;
unsigned long flags;

- if (PCM_RUNTIME_CHECK(substream))
+ if (snd_BUG_ON(!substream))
return;
- runtime = substream->runtime;

snd_pcm_stream_lock_irqsave(substream, flags);
+ if (PCM_RUNTIME_CHECK(substream))
+ goto _unlock;
+ runtime = substream->runtime;
+
if (!snd_pcm_running(substream) ||
snd_pcm_update_hw_ptr0(substream, 1) < 0)
goto _end;
@@ -1797,6 +1800,7 @@ void snd_pcm_period_elapsed(struct snd_pcm_substream *substream)
#endif
_end:
kill_fasync(&runtime->fasync, SIGIO, POLL_IN);
+ _unlock:
snd_pcm_stream_unlock_irqrestore(substream, flags);
}
EXPORT_SYMBOL(snd_pcm_period_elapsed);
--
2.20.1



2019-12-11 16:09:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 035/105] selftests: kvm: fix build with glibc >= 2.30

From: Vitaly Kuznetsov <[email protected]>

[ Upstream commit e37f9f139f62deddff90c7298ae3a85026a71067 ]

Glibc-2.30 gained gettid() wrapper, selftests fail to compile:

lib/assert.c:58:14: error: static declaration of ‘gettid’ follows non-static declaration
58 | static pid_t gettid(void)
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from include/test_util.h:18,
from lib/assert.c:10:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~

Signed-off-by: Vitaly Kuznetsov <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
tools/testing/selftests/kvm/lib/assert.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/kvm/lib/assert.c b/tools/testing/selftests/kvm/lib/assert.c
index 4911fc77d0f6a..d1cf9f6e0e6bc 100644
--- a/tools/testing/selftests/kvm/lib/assert.c
+++ b/tools/testing/selftests/kvm/lib/assert.c
@@ -55,7 +55,7 @@ static void test_dump_stack(void)
#pragma GCC diagnostic pop
}

-static pid_t gettid(void)
+static pid_t _gettid(void)
{
return syscall(SYS_gettid);
}
@@ -72,7 +72,7 @@ test_assert(bool exp, const char *exp_str,
fprintf(stderr, "==== Test Assertion Failure ====\n"
" %s:%u: %s\n"
" pid=%d tid=%d - %s\n",
- file, line, exp_str, getpid(), gettid(),
+ file, line, exp_str, getpid(), _gettid(),
strerror(errno));
test_dump_stack();
if (fmt) {
--
2.20.1



2019-12-11 16:09:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 008/105] tty: serial: fsl_lpuart: use the sg count from dma_map_sg

From: Peng Fan <[email protected]>

commit 487ee861de176090b055eba5b252b56a3b9973d6 upstream.

The dmaengine_prep_slave_sg needs to use sg count returned
by dma_map_sg, not use sport->dma_tx_nents, because the return
value of dma_map_sg is not always same with "nents".

When enabling iommu for lpuart + edma, iommu framework may concatenate
two sgs into one.

Fixes: 6250cc30c4c4e ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx")
Cc: <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/fsl_lpuart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -436,8 +436,8 @@ static void lpuart_dma_tx(struct lpuart_
}

sport->dma_tx_desc = dmaengine_prep_slave_sg(sport->dma_tx_chan, sgl,
- sport->dma_tx_nents,
- DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
+ ret, DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT);
if (!sport->dma_tx_desc) {
dma_unmap_sg(dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
dev_err(dev, "Cannot prepare TX slave DMA!\n");


2019-12-11 16:10:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 027/105] block: check bi_size overflow before merge

From: Junichi Nomura <[email protected]>

[ Upstream commit e3a5d8e386c3fb973fa75f2403622a8f3640ec06 ]

__bio_try_merge_page() may merge a page to bio without bio_full() check
and cause bi_size overflow.

The overflow typically ends up with sd_init_command() warning on zero
segment request with call trace like this:

------------[ cut here ]------------
WARNING: CPU: 2 PID: 1986 at drivers/scsi/scsi_lib.c:1025 scsi_init_io+0x156/0x180
CPU: 2 PID: 1986 Comm: kworker/2:1H Kdump: loaded Not tainted 5.4.0-rc7 #1
Workqueue: kblockd blk_mq_run_work_fn
RIP: 0010:scsi_init_io+0x156/0x180
RSP: 0018:ffffa11487663bf0 EFLAGS: 00010246
RAX: 00000000002be0a0 RBX: ffff8e6e9ff30118 RCX: 0000000000000000
RDX: 00000000ffffffe1 RSI: 0000000000000000 RDI: ffff8e6e9ff30118
RBP: ffffa11487663c18 R08: ffffa11487663d28 R09: ffff8e6e9ff30150
R10: 0000000000000001 R11: 0000000000000000 R12: ffff8e6e9ff30000
R13: 0000000000000001 R14: ffff8e74a1cf1800 R15: ffff8e6e9ff30000
FS: 0000000000000000(0000) GS:ffff8e6ea7680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff18cf0fe8 CR3: 0000000659f0a001 CR4: 00000000001606e0
Call Trace:
sd_init_command+0x326/0xb40 [sd_mod]
scsi_queue_rq+0x502/0xaa0
? blk_mq_get_driver_tag+0xe7/0x120
blk_mq_dispatch_rq_list+0x256/0x5a0
? elv_rb_del+0x24/0x30
? deadline_remove_request+0x7b/0xc0
blk_mq_do_dispatch_sched+0xa3/0x140
blk_mq_sched_dispatch_requests+0xfb/0x170
__blk_mq_run_hw_queue+0x81/0x130
blk_mq_run_work_fn+0x1b/0x20
process_one_work+0x179/0x390
worker_thread+0x4f/0x3e0
kthread+0x105/0x140
? max_active_store+0x80/0x80
? kthread_bind+0x20/0x20
ret_from_fork+0x35/0x40
---[ end trace f9036abf5af4a4d3 ]---
blk_update_request: I/O error, dev sdd, sector 2875552 op 0x1:(WRITE) flags 0x0 phys_seg 0 prio class 0
XFS (sdd1): writeback error on sector 2875552

__bio_try_merge_page() should check the overflow before actually doing
merge.

Fixes: 07173c3ec276c ("block: enable multipage bvecs")
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Ming Lei <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Jun'ichi Nomura <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
block/bio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/bio.c b/block/bio.c
index 299a0e7651ec0..31d56e7e2ce05 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -769,7 +769,7 @@ bool __bio_try_merge_page(struct bio *bio, struct page *page,
if (WARN_ON_ONCE(bio_flagged(bio, BIO_CLONED)))
return false;

- if (bio->bi_vcnt > 0) {
+ if (bio->bi_vcnt > 0 && !bio_full(bio, len)) {
struct bio_vec *bv = &bio->bi_io_vec[bio->bi_vcnt - 1];

if (page_is_mergeable(bv, page, len, off, same_page)) {
--
2.20.1



2019-12-11 16:10:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 025/105] NFC: nxp-nci: Fix NULL pointer dereference after I2C communication error

From: Stephan Gerhold <[email protected]>

[ Upstream commit a71a29f50de1ef97ab55c151a1598eb12dde379d ]

I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci
result in a NULL pointer dereference at the moment:

BUG: kernel NULL pointer dereference, address: 0000000000000000
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1
RIP: 0010:skb_queue_tail+0x25/0x50
Call Trace:
nci_recv_frame+0x36/0x90 [nci]
nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c]
? preempt_count_add+0x68/0xa0
? irq_forced_thread_fn+0x80/0x80
irq_thread_fn+0x20/0x60
irq_thread+0xee/0x180
? wake_threads_waitq+0x30/0x30
kthread+0xfb/0x130
? irq_thread_check_affinity+0xd0/0xd0
? kthread_park+0x90/0x90
ret_from_fork+0x1f/0x40

Afterward the kernel must be rebooted to work properly again.

This happens because it attempts to call nci_recv_frame() with skb == NULL.
However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any
NULL checks for skb, causing the NULL pointer dereference.

Change the code to call only nxp_nci_fw_recv_frame() in case of an error.
Make sure to log it so it is obvious that a communication error occurred.
The error above then becomes:

nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121
nci: __nci_request: wait_for_completion_interruptible_timeout failed 0
nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121

Fixes: 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver")
Signed-off-by: Stephan Gerhold <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/nfc/nxp-nci/i2c.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 4aeb3861b4095..6c468899f2ffe 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -225,8 +225,10 @@ static irqreturn_t nxp_nci_i2c_irq_thread_fn(int irq, void *phy_id)

if (r == -EREMOTEIO) {
phy->hard_fault = r;
- skb = NULL;
- } else if (r < 0) {
+ if (info->mode == NXP_NCI_MODE_FW)
+ nxp_nci_fw_recv_frame(phy->ndev, NULL);
+ }
+ if (r < 0) {
nfc_err(&client->dev, "Read failed with error %d\n", r);
goto exit_irq_handled;
}
--
2.20.1



2019-12-11 16:10:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 029/105] sched/core: Avoid spurious lock dependencies

From: Peter Zijlstra <[email protected]>

[ Upstream commit ff51ff84d82aea5a889b85f2b9fb3aa2b8691668 ]

While seemingly harmless, __sched_fork() does hrtimer_init(), which,
when DEBUG_OBJETS, can end up doing allocations.

This then results in the following lock order:

rq->lock
zone->lock.rlock
batched_entropy_u64.lock

Which in turn causes deadlocks when we do wakeups while holding that
batched_entropy lock -- as the random code does.

Solve this by moving __sched_fork() out from under rq->lock. This is
safe because nothing there relies on rq->lock, as also evident from the
other __sched_fork() callsite.

Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Qian Cai <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: b7d5dc21072c ("random: add a spinlock_t to struct batched_entropy")
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/sched/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index fffe790d98bb2..9a839798851c2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5874,10 +5874,11 @@ void init_idle(struct task_struct *idle, int cpu)
struct rq *rq = cpu_rq(cpu);
unsigned long flags;

+ __sched_fork(0, idle);
+
raw_spin_lock_irqsave(&idle->pi_lock, flags);
raw_spin_lock(&rq->lock);

- __sched_fork(0, idle);
idle->state = TASK_RUNNING;
idle->se.exec_start = sched_clock();
idle->flags |= PF_IDLE;
--
2.20.1



2019-12-11 16:10:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 028/105] Input: cyttsp4_core - fix use after free bug

From: Pan Bian <[email protected]>

[ Upstream commit 79aae6acbef16f720a7949f8fc6ac69816c79d62 ]

The device md->input is used after it is released. Setting the device
data to NULL is unnecessary as the device is never used again. Instead,
md->input should be assigned NULL to avoid accessing the freed memory
accidently. Besides, checking md->si against NULL is superfluous as it
points to a variable address, which cannot be NULL.

Signed-off-by: Pan Bian <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/input/touchscreen/cyttsp4_core.c | 7 -------
1 file changed, 7 deletions(-)

diff --git a/drivers/input/touchscreen/cyttsp4_core.c b/drivers/input/touchscreen/cyttsp4_core.c
index 4b22d49a0f49a..6bcffc930384a 100644
--- a/drivers/input/touchscreen/cyttsp4_core.c
+++ b/drivers/input/touchscreen/cyttsp4_core.c
@@ -1990,11 +1990,6 @@ static int cyttsp4_mt_probe(struct cyttsp4 *cd)

/* get sysinfo */
md->si = &cd->sysinfo;
- if (!md->si) {
- dev_err(dev, "%s: Fail get sysinfo pointer from core p=%p\n",
- __func__, md->si);
- goto error_get_sysinfo;
- }

rc = cyttsp4_setup_input_device(cd);
if (rc)
@@ -2004,8 +1999,6 @@ static int cyttsp4_mt_probe(struct cyttsp4 *cd)

error_init_input:
input_free_device(md->input);
-error_get_sysinfo:
- input_set_drvdata(md->input, NULL);
error_alloc_failed:
dev_err(dev, "%s failed.\n", __func__);
return rc;
--
2.20.1



2019-12-11 16:11:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 021/105] exportfs_decode_fh(): negative pinned may become positive without the parent locked

From: Al Viro <[email protected]>

[ Upstream commit a2ece088882666e1dc7113744ac912eb161e3f87 ]

Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/exportfs/expfs.c | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
index f0e549783caf9..ba6de72a3e34a 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -519,26 +519,33 @@ struct dentry *exportfs_decode_fh(struct vfsmount *mnt, struct fid *fid,
* inode is actually connected to the parent.
*/
err = exportfs_get_name(mnt, target_dir, nbuf, result);
- if (!err) {
- inode_lock(target_dir->d_inode);
- nresult = lookup_one_len(nbuf, target_dir,
- strlen(nbuf));
- inode_unlock(target_dir->d_inode);
- if (!IS_ERR(nresult)) {
- if (nresult->d_inode) {
- dput(result);
- result = nresult;
- } else
- dput(nresult);
- }
+ if (err) {
+ dput(target_dir);
+ goto err_result;
}

+ inode_lock(target_dir->d_inode);
+ nresult = lookup_one_len(nbuf, target_dir, strlen(nbuf));
+ if (!IS_ERR(nresult)) {
+ if (unlikely(nresult->d_inode != result->d_inode)) {
+ dput(nresult);
+ nresult = ERR_PTR(-ESTALE);
+ }
+ }
+ inode_unlock(target_dir->d_inode);
/*
* At this point we are done with the parent, but it's pinned
* by the child dentry anyway.
*/
dput(target_dir);

+ if (IS_ERR(nresult)) {
+ err = PTR_ERR(nresult);
+ goto err_result;
+ }
+ dput(result);
+ result = nresult;
+
/*
* And finally make sure the dentry is actually acceptable
* to NFSD.
--
2.20.1



2019-12-11 16:11:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 017/105] RDMA/hns: Correct the value of HNS_ROCE_HEM_CHUNK_LEN

From: Sirong Wang <[email protected]>

[ Upstream commit 531eb45b3da4267fc2a64233ba256c8ffb02edd2 ]

Size of pointer to buf field of struct hns_roce_hem_chunk should be
considered when calculating HNS_ROCE_HEM_CHUNK_LEN, or sg table size will
be larger than expected when allocating hem.

Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sirong Wang <[email protected]>
Signed-off-by: Weihang Li <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/hw/hns/hns_roce_hem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_hem.h b/drivers/infiniband/hw/hns/hns_roce_hem.h
index f1ccb8f35fe59..e41ebc25b1f90 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hem.h
+++ b/drivers/infiniband/hw/hns/hns_roce_hem.h
@@ -59,7 +59,7 @@ enum {

#define HNS_ROCE_HEM_CHUNK_LEN \
((256 - sizeof(struct list_head) - 2 * sizeof(int)) / \
- (sizeof(struct scatterlist)))
+ (sizeof(struct scatterlist) + sizeof(void *)))

#define check_whether_bt_num_3(type, hop_num) \
(type < HEM_TYPE_MTT && hop_num == 2)
--
2.20.1



2019-12-11 16:12:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 007/105] usb: gadget: u_serial: add missing port entry locking

From: Michał Mirosław <[email protected]>

commit daf82bd24e308c5a83758047aff1bd81edda4f11 upstream.

gserial_alloc_line() misses locking (for a release barrier) while
resetting port entry on TTY allocation failure. Fix this.

Cc: [email protected]
Signed-off-by: Michał Mirosław <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Tested-by: Ladislav Michl <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/function/u_serial.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1239,8 +1239,10 @@ int gserial_alloc_line(unsigned char *li
__func__, port_num, PTR_ERR(tty_dev));

ret = PTR_ERR(tty_dev);
+ mutex_lock(&ports[port_num].lock);
port = ports[port_num].port;
ports[port_num].port = NULL;
+ mutex_unlock(&ports[port_num].lock);
gserial_free_port(port);
goto err;
}


2019-12-11 16:12:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 023/105] ecryptfs: fix unlink and rmdir in face of underlying fs modifications

From: Al Viro <[email protected]>

[ Upstream commit bcf0d9d4b76976f892154efdfc509b256fd898e8 ]

A problem similar to the one caught in commit 74dd7c97ea2a ("ecryptfs_rename():
verify that lower dentries are still OK after lock_rename()") exists for
unlink/rmdir as well.

Instead of playing with dget_parent() of underlying dentry of victim
and hoping it's the same as underlying dentry of our directory,
do the following:
* find the underlying dentry of victim
* find the underlying directory of victim's parent (stable
since the victim is ecryptfs dentry and inode of its parent is
held exclusive by the caller).
* lock the inode of dentry underlying the victim's parent
* check that underlying dentry of victim is still hashed and
has the right parent - it can be moved, but it can't be moved to/from
the directory we are holding exclusive. So while ->d_parent itself
might not be stable, the result of comparison is.

If the check passes, everything is fine - underlying directory is locked,
underlying victim is still a child of that directory and we can go ahead
and feed them to vfs_unlink(). As in the current mainline we need to
pin the underlying dentry of victim, so that it wouldn't go negative under
us, but that's the only temporary reference that needs to be grabbed there.
Underlying dentry of parent won't go away (it's pinned by the parent,
which is held by caller), so there's no need to grab it.

The same problem (with the same solution) exists for rmdir. Moreover,
rename gets simpler and more robust with the same "don't bother with
dget_parent()" approach.

Fixes: 74dd7c97ea2 "ecryptfs_rename(): verify that lower dentries are still OK after lock_rename()"
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
fs/ecryptfs/inode.c | 65 ++++++++++++++++++++++++++++-----------------
1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 0c7ea4596202a..e23752d9a79f3 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -128,13 +128,20 @@ static int ecryptfs_do_unlink(struct inode *dir, struct dentry *dentry,
struct inode *inode)
{
struct dentry *lower_dentry = ecryptfs_dentry_to_lower(dentry);
- struct inode *lower_dir_inode = ecryptfs_inode_to_lower(dir);
struct dentry *lower_dir_dentry;
+ struct inode *lower_dir_inode;
int rc;

- dget(lower_dentry);
- lower_dir_dentry = lock_parent(lower_dentry);
- rc = vfs_unlink(lower_dir_inode, lower_dentry, NULL);
+ lower_dir_dentry = ecryptfs_dentry_to_lower(dentry->d_parent);
+ lower_dir_inode = d_inode(lower_dir_dentry);
+ inode_lock_nested(lower_dir_inode, I_MUTEX_PARENT);
+ dget(lower_dentry); // don't even try to make the lower negative
+ if (lower_dentry->d_parent != lower_dir_dentry)
+ rc = -EINVAL;
+ else if (d_unhashed(lower_dentry))
+ rc = -EINVAL;
+ else
+ rc = vfs_unlink(lower_dir_inode, lower_dentry, NULL);
if (rc) {
printk(KERN_ERR "Error in vfs_unlink; rc = [%d]\n", rc);
goto out_unlock;
@@ -142,10 +149,11 @@ static int ecryptfs_do_unlink(struct inode *dir, struct dentry *dentry,
fsstack_copy_attr_times(dir, lower_dir_inode);
set_nlink(inode, ecryptfs_inode_to_lower(inode)->i_nlink);
inode->i_ctime = dir->i_ctime;
- d_drop(dentry);
out_unlock:
- unlock_dir(lower_dir_dentry);
dput(lower_dentry);
+ inode_unlock(lower_dir_inode);
+ if (!rc)
+ d_drop(dentry);
return rc;
}

@@ -519,22 +527,30 @@ static int ecryptfs_rmdir(struct inode *dir, struct dentry *dentry)
{
struct dentry *lower_dentry;
struct dentry *lower_dir_dentry;
+ struct inode *lower_dir_inode;
int rc;

lower_dentry = ecryptfs_dentry_to_lower(dentry);
- dget(dentry);
- lower_dir_dentry = lock_parent(lower_dentry);
- dget(lower_dentry);
- rc = vfs_rmdir(d_inode(lower_dir_dentry), lower_dentry);
- dput(lower_dentry);
- if (!rc && d_really_is_positive(dentry))
+ lower_dir_dentry = ecryptfs_dentry_to_lower(dentry->d_parent);
+ lower_dir_inode = d_inode(lower_dir_dentry);
+
+ inode_lock_nested(lower_dir_inode, I_MUTEX_PARENT);
+ dget(lower_dentry); // don't even try to make the lower negative
+ if (lower_dentry->d_parent != lower_dir_dentry)
+ rc = -EINVAL;
+ else if (d_unhashed(lower_dentry))
+ rc = -EINVAL;
+ else
+ rc = vfs_rmdir(lower_dir_inode, lower_dentry);
+ if (!rc) {
clear_nlink(d_inode(dentry));
- fsstack_copy_attr_times(dir, d_inode(lower_dir_dentry));
- set_nlink(dir, d_inode(lower_dir_dentry)->i_nlink);
- unlock_dir(lower_dir_dentry);
+ fsstack_copy_attr_times(dir, lower_dir_inode);
+ set_nlink(dir, lower_dir_inode->i_nlink);
+ }
+ dput(lower_dentry);
+ inode_unlock(lower_dir_inode);
if (!rc)
d_drop(dentry);
- dput(dentry);
return rc;
}

@@ -572,20 +588,22 @@ ecryptfs_rename(struct inode *old_dir, struct dentry *old_dentry,
struct dentry *lower_new_dentry;
struct dentry *lower_old_dir_dentry;
struct dentry *lower_new_dir_dentry;
- struct dentry *trap = NULL;
+ struct dentry *trap;
struct inode *target_inode;

if (flags)
return -EINVAL;

+ lower_old_dir_dentry = ecryptfs_dentry_to_lower(old_dentry->d_parent);
+ lower_new_dir_dentry = ecryptfs_dentry_to_lower(new_dentry->d_parent);
+
lower_old_dentry = ecryptfs_dentry_to_lower(old_dentry);
lower_new_dentry = ecryptfs_dentry_to_lower(new_dentry);
- dget(lower_old_dentry);
- dget(lower_new_dentry);
- lower_old_dir_dentry = dget_parent(lower_old_dentry);
- lower_new_dir_dentry = dget_parent(lower_new_dentry);
+
target_inode = d_inode(new_dentry);
+
trap = lock_rename(lower_old_dir_dentry, lower_new_dir_dentry);
+ dget(lower_new_dentry);
rc = -EINVAL;
if (lower_old_dentry->d_parent != lower_old_dir_dentry)
goto out_lock;
@@ -613,11 +631,8 @@ ecryptfs_rename(struct inode *old_dir, struct dentry *old_dentry,
if (new_dir != old_dir)
fsstack_copy_attr_all(old_dir, d_inode(lower_old_dir_dentry));
out_lock:
- unlock_rename(lower_old_dir_dentry, lower_new_dir_dentry);
- dput(lower_new_dir_dentry);
- dput(lower_old_dir_dentry);
dput(lower_new_dentry);
- dput(lower_old_dentry);
+ unlock_rename(lower_old_dir_dentry, lower_new_dir_dentry);
return rc;
}

--
2.20.1



2019-12-11 16:18:03

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

i get the following when i try to compile...

-------------------x--------------------x--------------------x--------------
$sudo make -j4
DESCEND objtool
make[4]: *** No rule to make target 'arch/x86/lib/x86-opcode-map.txt', needed by '/home/jeffrin/UP/linux-stable-rc/tools/objtool/arch/x86/lib/inat-tables.c'. Stop.
make[3]: *** [/home/jeffrin/UP/linux-stable-rc/tools/build/Makefile.build:139: arch/x86] Error 2
make[2]: *** [Makefile:50: /home/jeffrin/UP/linux-stable-rc/tools/objtool/objtool-in.o] Error 2
make[1]: *** [Makefile:67: objtool] Error 2
make: *** [Makefile:1752: tools/objtool] Error 2
make: *** Waiting for unfinished jobs.
------------------x-------------------------x----------------x-----------

the file "x86-opcode-map.txt" has been deleted upstream.


--
software engineer
rajagiri school of engineering and technology

2019-12-11 16:45:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 003/105] perf scripts python: exported-sql-viewer.py: Fix use of TRUE with SQLite

From: Adrian Hunter <[email protected]>

commit af833988c088d3fed3e7188e7c3dd9ca17178dc3 upstream.

Prior to version 3.23 SQLite does not support TRUE or FALSE, so always
use 1 and 0 for SQLite.

Fixes: 26c11206f433 ("perf scripts python: exported-sql-viewer.py: Use new 'has_calls' column")
Signed-off-by: Adrian Hunter <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: [email protected] # v5.3+
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
[Adrian: backported to v5.3, v5.4]
Signed-off-by: Adrian Hunter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/perf/scripts/python/exported-sql-viewer.py | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/tools/perf/scripts/python/exported-sql-viewer.py
+++ b/tools/perf/scripts/python/exported-sql-viewer.py
@@ -625,7 +625,7 @@ class CallGraphRootItem(CallGraphLevelIt
self.query_done = True
if_has_calls = ""
if IsSelectable(glb.db, "comms", columns = "has_calls"):
- if_has_calls = " WHERE has_calls = TRUE"
+ if_has_calls = " WHERE has_calls = " + glb.dbref.TRUE
query = QSqlQuery(glb.db)
QueryExec(query, "SELECT id, comm FROM comms" + if_has_calls)
while query.next():
@@ -905,7 +905,7 @@ class CallTreeRootItem(CallGraphLevelIte
self.query_done = True
if_has_calls = ""
if IsSelectable(glb.db, "comms", columns = "has_calls"):
- if_has_calls = " WHERE has_calls = TRUE"
+ if_has_calls = " WHERE has_calls = " + glb.dbref.TRUE
query = QSqlQuery(glb.db)
QueryExec(query, "SELECT id, comm FROM comms" + if_has_calls)
while query.next():
@@ -3509,6 +3509,12 @@ class DBRef():
def __init__(self, is_sqlite3, dbname):
self.is_sqlite3 = is_sqlite3
self.dbname = dbname
+ self.TRUE = "TRUE"
+ self.FALSE = "FALSE"
+ # SQLite prior to version 3.23 does not support TRUE and FALSE
+ if self.is_sqlite3:
+ self.TRUE = "1"
+ self.FALSE = "0"

def Open(self, connection_name):
dbname = self.dbname


2019-12-11 16:47:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 010/105] serial: pl011: Fix DMA ->flush_buffer()

From: Vincent Whitchurch <[email protected]>

commit f6a196477184b99a31d16366a8e826558aa11f6d upstream.

PL011's ->flush_buffer() implementation releases and reacquires the port
lock. Due to a race condition here, data can end up being added to the
circular buffer but neither being discarded nor being sent out. This
leads to, for example, tcdrain(2) waiting indefinitely.

Process A Process B

uart_flush_buffer()
- acquire lock
- circ_clear
- pl011_flush_buffer()
-- release lock
-- dmaengine_terminate_all()

uart_write()
- acquire lock
- add chars to circ buffer
- start_tx()
-- start DMA
- release lock

-- acquire lock
-- turn off DMA
-- release lock

// Data in circ buffer but DMA is off

According to the comment in the code, the releasing of the lock around
dmaengine_terminate_all() is to avoid a deadlock with the DMA engine
callback. However, since the time this code was written, the DMA engine
API documentation seems to have been clarified to say that
dmaengine_terminate_all() (in the identically implemented but
differently named dmaengine_terminate_async() variant) does not wait for
any running complete callback to be completed and can even be called
from a complete callback. So there is no possibility of deadlock if the
DMA engine driver implements this API correctly.

So we should be able to just remove this release and reacquire of the
lock to prevent the aforementioned race condition.

Signed-off-by: Vincent Whitchurch <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/amba-pl011.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -813,10 +813,8 @@ __acquires(&uap->port.lock)
if (!uap->using_tx_dma)
return;

- /* Avoid deadlock with the DMA engine callback */
- spin_unlock(&uap->port.lock);
- dmaengine_terminate_all(uap->dmatx.chan);
- spin_lock(&uap->port.lock);
+ dmaengine_terminate_async(uap->dmatx.chan);
+
if (uap->dmatx.queued) {
dma_unmap_sg(uap->dmatx.chan->device->dev, &uap->dmatx.sg, 1,
DMA_TO_DEVICE);


2019-12-11 16:47:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 070/105] kernfs: fix ino wrap-around detection

From: Tejun Heo <[email protected]>

commit e23f568aa63f64cd6b355094224cc9356c0f696b upstream.

When the 32bit ino wraps around, kernfs increments the generation
number to distinguish reused ino instances. The wrap-around detection
tests whether the allocated ino is lower than what the cursor but the
cursor is pointing to the next ino to allocate so the condition never
triggers.

Fix it by remembering the last ino and comparing against that.

Signed-off-by: Tejun Heo <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Fixes: 4a3ef68acacf ("kernfs: implement i_generation")
Cc: Namhyung Kim <[email protected]>
Cc: [email protected] # v4.14+
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/kernfs/dir.c | 5 ++---
include/linux/kernfs.h | 1 +
2 files changed, 3 insertions(+), 3 deletions(-)

--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -621,7 +621,6 @@ static struct kernfs_node *__kernfs_new_
{
struct kernfs_node *kn;
u32 gen;
- int cursor;
int ret;

name = kstrdup_const(name, GFP_KERNEL);
@@ -634,11 +633,11 @@ static struct kernfs_node *__kernfs_new_

idr_preload(GFP_KERNEL);
spin_lock(&kernfs_idr_lock);
- cursor = idr_get_cursor(&root->ino_idr);
ret = idr_alloc_cyclic(&root->ino_idr, kn, 1, 0, GFP_ATOMIC);
- if (ret >= 0 && ret < cursor)
+ if (ret >= 0 && ret < root->last_ino)
root->next_generation++;
gen = root->next_generation;
+ root->last_ino = ret;
spin_unlock(&kernfs_idr_lock);
idr_preload_end();
if (ret < 0)
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -187,6 +187,7 @@ struct kernfs_root {

/* private fields, do not use outside kernfs proper */
struct idr ino_idr;
+ u32 last_ino;
u32 next_generation;
struct kernfs_syscall_ops *syscall_ops;



2019-12-11 18:30:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, Dec 11, 2019 at 09:46:05PM +0530, Jeffrin Jose wrote:
> On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.16 release.
> > There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> i get the following when i try to compile...
>
> -------------------x--------------------x--------------------x--------------
> $sudo make -j4
> DESCEND objtool
> make[4]: *** No rule to make target 'arch/x86/lib/x86-opcode-map.txt', needed by '/home/jeffrin/UP/linux-stable-rc/tools/objtool/arch/x86/lib/inat-tables.c'. Stop.
> make[3]: *** [/home/jeffrin/UP/linux-stable-rc/tools/build/Makefile.build:139: arch/x86] Error 2
> make[2]: *** [Makefile:50: /home/jeffrin/UP/linux-stable-rc/tools/objtool/objtool-in.o] Error 2
> make[1]: *** [Makefile:67: objtool] Error 2
> make: *** [Makefile:1752: tools/objtool] Error 2
> make: *** Waiting for unfinished jobs.
> ------------------x-------------------------x----------------x-----------
>
> the file "x86-opcode-map.txt" has been deleted upstream.

that's really odd. How are you building this, from the git tree, or the
tarball generated?

And I still see that file in the 5.3 tree, what do you mean it was
deleted?

thanks,

greg k-h

2019-12-11 19:23:23

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, Dec 11, 2019 at 07:28:52PM +0100, Greg Kroah-Hartman wrote:
> that's really odd. How are you building this, from the git tree, or the
> tarball generated?
git tree
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git


> And I still see that file in the 5.3 tree, what do you mean it was
> deleted?

may be during "git checkout linux-5.3.y" or may be i did "git pull" inside that branch

that was a git status which showed "D" at the start of a few lines
and one of that lines showed that file.
i also checked that path locally and found it was not there

--
software engineer
rajagiri school of engineering and technology

2019-12-11 21:14:05

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review


On 11/12/2019 15:04, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------

All tests are passing for Tegra ...

Test results for stable-v5.3:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail

Linux version: 5.3.16-rc1-g0b6bd9e91738
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2019-12-11 21:25:05

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Thu, Dec 12, 2019 at 12:52:32AM +0530, Jeffrin Jose wrote:
> On Wed, Dec 11, 2019 at 07:28:52PM +0100, Greg Kroah-Hartman wrote:
> > that's really odd. How are you building this, from the git tree, or the
> > tarball generated?
> git tree
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>
>
> > And I still see that file in the 5.3 tree, what do you mean it was
> > deleted?
>
> may be during "git checkout linux-5.3.y" or may be i did "git pull" inside that branch
>
> that was a git status which showed "D" at the start of a few lines
> and one of that lines showed that file.
> i also checked that path locally and found it was not there
>

i downloaded the tree to another directory.
i compiled the kernel and it was a success

--
soffware engineer
rajagiri school of engineering and technology

2019-12-11 21:44:32

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review [warning related]

On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> and the diffstat can be found below.
>

the following is from "dmesg -l warn"

-------------------x------------x------------------------
================================================
WARNING: lock held when returning to user space!
5.3.16-rc1+ #1 Tainted: G E
------------------------------------------------
tpm2-abrmd/679 is leaving the kernel with locks still held!
2 locks held by tpm2-abrmd/679:
#0: 00000000d3bc394f (&chip->ops_sem){.+.+}, at: tpm_try_get_ops+0x2b/0xb0 [tpm]
#1: 000000004a4d7099 (&chip->tpm_mutex){+.+.}, at: tpm_try_get_ops+0x4b/0xb0 [tpm]

------------x----------------------x---------------------

the fix for the above to a typical kernel is here ...

https://patchwork.kernel.org/patch/11283317/

--
software engineer
rajagiri school of engineering and technology

2019-12-12 02:49:46

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On 12/11/19 8:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

thanks,
-- Shuah

2019-12-12 05:23:32

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, 11 Dec 2019 at 20:41, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.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.3.16-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.3.y
git commit: 0b6bd9e917380a84aa7cc28de11f897e121cd092
git describe: v5.3.15-106-g0b6bd9e91738
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.3-oe/build/v5.3.15-106-g0b6bd9e91738

No regressions (compared to build v5.3.15)

No fixes (compared to build v5.3.15)

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

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* 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-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

2019-12-12 06:53:12

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

there are different things going in my log.

i have attached the output of "sudo dmesg -l err"

--
software engineer
rajagiri school of engineering and technology



Attachments:
(No filename) (946.00 B)
5.3.16-rc1+-err.txt (63.55 kB)
Download all attachments

2019-12-12 07:42:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Thu, Dec 12, 2019 at 12:22:14PM +0530, Jeffrin Jose wrote:
> On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.16 release.
> > There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> there are different things going in my log.
>
> i have attached the output of "sudo dmesg -l err"
>
> --
> software engineer
> rajagiri school of engineering and technology
>
>

> [ 1973.058279] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.058300] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.078477] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.078493] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.078506] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.114038] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.114067] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.114092] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.141900] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.141944] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.142050] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.149220] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.149240] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.149257] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.162646] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.162668] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.162684] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.169524] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.169558] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.169582] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.169730] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.169764] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.169796] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.184198] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.184219] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.184235] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.184491] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.184523] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.184550] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.191496] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.191530] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.191578] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.198592] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.198628] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.198657] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.205030] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.205064] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.205095] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.226036] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.226053] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.226065] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.226188] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.226203] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.226215] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.226429] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.226455] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.226476] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.247452] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.247478] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.247500] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.254752] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.254791] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.254812] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.261862] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.261878] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.261898] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.303751] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.303767] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.303780] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.317722] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.317751] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.317773] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.334983] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.335000] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.335013] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.338946] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.338961] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.338973] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.339255] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.339270] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.339282] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.345770] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.345785] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.345798] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.352897] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.352914] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.352927] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.370143] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.370161] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.370174] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.402549] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.402565] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.402582] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.409863] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.409889] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.409911] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.416320] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.416353] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.416375] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.423348] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.423371] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.423389] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.430519] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.430549] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.430569] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.437378] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.437407] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.437430] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.444421] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.444444] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.444461] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.451055] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.451073] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.451086] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.451443] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.451470] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.451491] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.458319] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.458335] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.458354] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.473061] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.473087] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.473104] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.493455] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.493471] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.493483] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.493808] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.493832] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.493849] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.500367] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.500384] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.500396] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.528877] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.528898] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.528911] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.550383] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.550399] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.550412] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.577843] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.577860] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.577873] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.578227] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.578252] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.578274] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.584999] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.585029] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.585050] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.592103] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.592119] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.592132] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.599286] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.599311] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.599332] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.613416] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.613447] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.613461] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.641416] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.641432] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.641445] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.648425] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.648441] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.648455] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.648554] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.648568] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.648581] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.655675] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.655700] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.655721] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.662146] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.662161] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.662174] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.662294] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.662322] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.662341] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.669559] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.669575] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.669587] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.690894] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.690910] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.690923] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.698008] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.698047] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.698070] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.704952] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.704968] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.704981] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.705096] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.705110] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.705128] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.711811] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.711826] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.711839] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.718443] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.718469] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.718493] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.725456] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.725472] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.725484] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.725743] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.725757] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.725769] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.739748] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.739764] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.739777] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.739964] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.739979] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.739992] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.746795] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.746812] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.746826] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.796210] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.796227] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.796240] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.803277] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.803293] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.803305] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.810020] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.810036] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.810048] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.824240] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.824257] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.824270] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.824452] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.824477] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.824498] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.831195] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.831222] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.831243] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.845722] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.845739] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.845751] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.845885] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.845899] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.845912] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.846963] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.846994] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.847007] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.852715] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.852739] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.852753] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.852991] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.853007] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.853020] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.887434] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.887452] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.887465] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.894838] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.894864] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.894883] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.901240] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.901268] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.901291] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.901563] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.901599] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.901630] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.916125] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.916141] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.916154] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.923217] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.923233] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.923247] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.930073] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.930101] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.930124] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.930332] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.930357] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.930379] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.936915] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.936932] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.936944] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.943853] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.943869] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.943881] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.950167] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.950183] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.950196] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.950882] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.950898] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.950911] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.957921] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.957938] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1973.958006] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.964791] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.964808] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.964821] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.978885] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.978913] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.978936] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1973.979189] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1973.979203] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1973.979216] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.000635] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.000651] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1974.000664] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.007395] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.007410] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.007430] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.014312] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.014335] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.014348] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.029785] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.029813] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1974.029871] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.030144] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.030167] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.030187] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.051770] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.051801] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.051814] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.242264] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.242285] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1974.242302] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.250471] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.250511] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.250540] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.265274] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.265296] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.265313] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.296408] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.296482] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.296511] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.296721] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.296751] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.296780] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.304833] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.304869] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1974.304903] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.312576] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.312596] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.312612] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.328024] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.328051] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.328065] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.334679] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.334695] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1974.334708] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.342340] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.342401] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.342423] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.349708] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.349733] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.349754] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.461399] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.461417] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.461429] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.563686] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.563729] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.563748] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.666132] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.666157] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.666176] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1974.870964] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1974.870987] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1974.871005] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.076663] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.076686] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.076704] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.178198] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.178219] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.178237] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.280508] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.280542] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.280571] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.382955] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.382976] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.382993] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.587770] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.587790] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.587807] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.690163] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.690185] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.690202] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.895884] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.895915] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.895932] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.897639] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.897661] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.897678] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.900631] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.900650] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.900666] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1975.997406] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1975.997443] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1975.997476] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.099856] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.099899] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.099926] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.130758] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.130794] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.130822] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.202267] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.202312] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.202350] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.611839] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.611860] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.611878] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.816611] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.816632] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.816650] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.919077] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.919099] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.919116] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.938176] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.938198] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.938215] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.938406] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.938427] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.938444] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1976.986459] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1976.986482] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1976.986499] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1977.328621] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1977.328647] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1977.328678] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1977.466194] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1977.466217] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1977.466235] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1978.250301] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1978.250342] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1978.250375] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1978.352660] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1978.352685] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1978.352704] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1978.455028] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1978.455050] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1978.455067] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1978.557391] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1978.557453] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1978.557491] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1978.762232] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1978.762269] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1978.762298] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1978.864656] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1978.864691] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1978.864720] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1978.967065] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1978.967090] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1978.967109] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1979.069489] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1979.069520] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1979.069548] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1979.171862] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1979.171895] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1979.171926] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1979.479054] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1979.479093] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1979.479138] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1979.683757] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1979.683784] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1979.683806] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1979.888649] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1979.888673] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1979.888689] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1979.990964] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1979.990999] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1979.991025] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1980.195911] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1980.195950] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1980.195982] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1980.503179] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1980.503202] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1980.503221] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1980.538106] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1980.538128] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1980.538145] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1980.707846] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1980.707871] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1980.707890] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1980.810274] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1980.810297] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1980.810315] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1980.912734] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1980.912782] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1980.912822] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.130583] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.130624] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1981.130649] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.219936] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.219958] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1981.219975] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.322230] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.322251] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1981.322268] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.424718] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.424740] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1981.424759] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.562033] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.562055] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1981.562071] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.629363] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.629383] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1981.629400] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.731831] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.731867] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1981.731896] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1981.834251] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1981.834292] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1981.834323] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1982.039099] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1982.039123] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1982.039141] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1982.346209] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1982.346244] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1982.346283] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1982.551075] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1982.551098] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1982.551117] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1982.586020] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1982.586044] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1982.586064] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1982.653534] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1982.653557] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1982.653575] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1982.755876] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1982.755899] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1982.755917] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1982.960658] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1982.960686] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1982.960704] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1983.063086] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1983.063123] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1983.063152] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1983.165399] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1983.165420] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1983.165442] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1983.267991] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1983.268027] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1983.268057] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1983.370255] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1983.370277] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1983.370294] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1983.614017] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1983.614040] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1983.614059] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1983.677485] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1983.677510] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1983.677530] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1983.984677] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1983.984707] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1983.984728] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1984.087104] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1984.087135] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1984.087153] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1984.291892] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1984.291917] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1984.291937] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1984.394213] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1984.394249] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1984.394267] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1984.701520] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1984.701544] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1984.701562] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1984.803892] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1984.803917] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1984.803936] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1984.906192] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1984.906215] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1984.906233] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1985.008726] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1985.008747] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1985.008765] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1985.213481] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1985.213519] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1985.213552] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1985.520675] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1985.520713] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1985.520732] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1985.661996] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1985.662018] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1985.662035] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1985.827901] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1985.827940] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1985.827979] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1985.930229] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1985.930269] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1985.930301] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1986.339941] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1986.339975] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1986.340004] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1986.442280] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1986.442304] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1986.442322] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1986.544660] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1986.544694] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1986.544721] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1986.749471] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1986.749492] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1986.749509] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1986.851827] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1986.851864] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1986.851895] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1987.056737] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1987.056767] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1987.056786] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1987.159074] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1987.159096] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1987.159117] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1987.363923] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1987.363962] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1987.363990] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1987.466246] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1987.466279] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1987.466308] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1987.773439] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1987.773472] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1987.773491] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1988.080687] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1988.080709] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1988.080726] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1988.490237] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1988.490264] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1988.490278] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1988.592766] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1988.592783] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1988.592795] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1988.729994] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1988.730030] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1988.730063] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1988.899831] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1988.899853] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1988.899871] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1989.104708] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1989.104732] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1989.104750] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1989.514342] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1989.514365] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1989.514384] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1989.719024] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1989.719045] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1989.719061] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1989.821472] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1989.821493] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1989.821509] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1990.128697] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1990.128734] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1990.128769] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1990.231058] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1990.231081] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1990.231099] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1990.435860] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1990.435883] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1990.435901] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1990.538325] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1990.538360] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1990.538378] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1990.947870] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1990.947907] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1990.947937] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1991.050271] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1991.050311] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1991.050349] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1991.357513] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1991.357553] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1991.357570] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1991.664695] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1991.664723] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1991.664741] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1991.802028] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1991.802072] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00003000/00002000
> [ 1991.802105] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1991.869540] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1991.869563] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1991.869579] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1992.176708] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1992.176749] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1992.176781] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1992.279061] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1992.279101] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1992.279133] pcieport 0000:00:1c.5: AER: [12] Timeout
> [ 1992.483844] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
> [ 1992.483878] pcieport 0000:00:1c.5: AER: device [8086:9d15] error status/mask=00001000/00002000
> [ 1992.483905] pcieport 0000:00:1c.5: AER: [12] Timeout

Are these things new to this release, or have they always been there?

thanks,

greg k-h

2019-12-12 07:44:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review [warning related]

On Thu, Dec 12, 2019 at 03:13:37AM +0530, Jeffrin Jose wrote:
> On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.16 release.
> > There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> > and the diffstat can be found below.
> >
>
> the following is from "dmesg -l warn"
>
> -------------------x------------x------------------------
> ================================================
> WARNING: lock held when returning to user space!
> 5.3.16-rc1+ #1 Tainted: G E
> ------------------------------------------------
> tpm2-abrmd/679 is leaving the kernel with locks still held!
> 2 locks held by tpm2-abrmd/679:
> #0: 00000000d3bc394f (&chip->ops_sem){.+.+}, at: tpm_try_get_ops+0x2b/0xb0 [tpm]
> #1: 000000004a4d7099 (&chip->tpm_mutex){+.+.}, at: tpm_try_get_ops+0x4b/0xb0 [tpm]
>
> ------------x----------------------x---------------------
>
> the fix for the above to a typical kernel is here ...
>
> https://patchwork.kernel.org/patch/11283317/

I need to wait for that to get into Linus's tree before we can do
anything about it for a stable kernel release.

thanks,

greg k-h

2019-12-12 08:06:13

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Thu, Dec 12, 2019 at 08:41:24AM +0100, Greg Kroah-Hartman wrote:
> Are these things new to this release, or have they always been there?
Normally these are not new things. it has been there.

--
software engineer
rajagiri school of engineering and technology


2019-12-12 09:11:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Thu, Dec 12, 2019 at 01:35:18PM +0530, Jeffrin Jose wrote:
> On Thu, Dec 12, 2019 at 08:41:24AM +0100, Greg Kroah-Hartman wrote:
> > Are these things new to this release, or have they always been there?
> Normally these are not new things. it has been there.

Then nothing new broke :)

2019-12-12 09:32:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, Dec 11, 2019 at 09:13:06PM +0000, Jon Hunter wrote:
>
> On 11/12/2019 15:04, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.16 release.
> > There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > -------------
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.3:
> 13 builds: 13 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 38 tests: 38 pass, 0 fail
>
> Linux version: 5.3.16-rc1-g0b6bd9e91738
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra30-cardhu-a04
>

Thanks for testing these and letting me know.

greg k-h

2019-12-12 10:07:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> and the diffstat can be found below.

I have pushed out -rc2 with a number of additional fixes:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz

2019-12-12 12:19:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Thu, Dec 12, 2019 at 11:04:56AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.16 release.
> > There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> > and the diffstat can be found below.
>
> I have pushed out -rc2 with a number of additional fixes:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz

That was the 5.4 patch, here is the correct 5.3 patch:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.16-rc2.gz

2019-12-12 13:18:27

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review


On 12/12/2019 12:18, Greg Kroah-Hartman wrote:
> On Thu, Dec 12, 2019 at 11:04:56AM +0100, Greg Kroah-Hartman wrote:
>> On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.3.16 release.
>>> There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
>>> and the diffstat can be found below.
>>
>> I have pushed out -rc2 with a number of additional fixes:
>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz
>
> That was the 5.4 patch, here is the correct 5.3 patch:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.16-rc2.gz
>


All tests are passing for Tegra ...

Test results for stable-v5.3:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 38 pass, 0 fail

Linux version: 5.3.16-rc2-g9f27b7f4a193
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2019-12-12 18:26:01

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.16 release.
> There are 105 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 Fri, 13 Dec 2019 14:56:06 +0000.
> Anything received after that time might be too late.
>

For v5.3.15-116-g9f27b7f4a193:

Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 394 pass: 394 fail: 0

Guenter

2019-12-13 04:55:43

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.3 000/105] 5.3.16-stable review

On Thu, 12 Dec 2019 at 17:48, Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Thu, Dec 12, 2019 at 11:04:56AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Dec 11, 2019 at 04:04:49PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.3.16 release.
> > > There are 105 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 Fri, 13 Dec 2019 14:56:06 +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.3.16-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.3.y
> > > and the diffstat can be found below.
> >
> > I have pushed out -rc2 with a number of additional fixes:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.3-rc2.gz
>
> That was the 5.4 patch, here is the correct 5.3 patch:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.16-rc2.gz


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

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

kernel: 5.3.16-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.3.y
git commit: 9f27b7f4a193786bae731a293fc61de389cd549f
git describe: v5.3.15-116-g9f27b7f4a193
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.3-oe/build/v5.3.15-116-g9f27b7f4a193


No regressions (compared to build v5.3.15)


No fixes (compared to build v5.3.15)

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

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* 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-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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