2021-12-06 15:25:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 00/70] 5.4.164-rc1 review

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

Responses should be made by Wed, 08 Dec 2021 14:55:37 +0000.
Anything received after that time might be too late.

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

thanks,

greg k-h

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

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

Wei Yongjun <[email protected]>
ipmi: msghandler: Make symbol 'remove_work_wq' static

Tianjia Zhang <[email protected]>
net/tls: Fix authentication failure in CCM mode

Helge Deller <[email protected]>
parisc: Mark cr16 CPU clocksource unstable on all SMP machines

Mordechay Goodstein <[email protected]>
iwlwifi: mvm: retry init flow if failed

Jay Dolan <[email protected]>
serial: 8250_pci: rewrite pericom_do_set_divisor()

Jay Dolan <[email protected]>
serial: 8250_pci: Fix ACCES entries in pci_serial_quirks array

Johan Hovold <[email protected]>
serial: core: fix transmit-buffer reset and memleak

Pierre Gondois <[email protected]>
serial: pl011: Add ACPI SBSA UART match id

Sven Eckelmann <[email protected]>
tty: serial: msm_serial: Deactivate RX DMA for polling support

Joerg Roedel <[email protected]>
x86/64/mm: Map all kernel memory into trampoline_pgd

Feng Tang <[email protected]>
x86/tsc: Disable clocksource watchdog for TSC on qualified platorms

Feng Tang <[email protected]>
x86/tsc: Add a timer to make sure TSC_adjust is always checked

Badhri Jagan Sridharan <[email protected]>
usb: typec: tcpm: Wait in SNK_DEBOUNCED until disconnect

Ole Ernst <[email protected]>
USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub

Mathias Nyman <[email protected]>
xhci: Fix commad ring abort, write all 64 bits to CRCR register.

Maciej W. Rozycki <[email protected]>
vgacon: Propagate console boot parameters before calling `vc_resize'

Helge Deller <[email protected]>
parisc: Fix "make install" on newer debian releases

Helge Deller <[email protected]>
parisc: Fix KBUILD_IMAGE for self-extracting kernel

Qais Yousef <[email protected]>
sched/uclamp: Fix rq->uclamp_max not set on first enqueue

Like Xu <[email protected]>
KVM: x86/pmu: Fix reserved bits for AMD PerfEvtSeln register

msizanoen1 <[email protected]>
ipv6: fix memory leak in fib6_rule_suppress

Rob Clark <[email protected]>
drm/msm: Do hw_init() before capturing GPU state

Tony Lu <[email protected]>
net/smc: Keep smc_close_final rc during active close

William Kucharski <[email protected]>
net/rds: correct socket tunable error in rds_tcp_tune()

Eric Dumazet <[email protected]>
ipv4: convert fib_num_tclassid_users to atomic_t

Eric Dumazet <[email protected]>
net: annotate data-races on txq->xmit_lock_owner

Christophe JAILLET <[email protected]>
net: marvell: mvpp2: Fix the computation of shared CPUs

Sven Schuchmann <[email protected]>
net: usb: lan78xx: lan78xx_phy_init(): use PHY_POLL instead of "0" if no IRQ is available

Eiichi Tsukata <[email protected]>
rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()

Li Zhijian <[email protected]>
selftests: net: Correct case name

Zhou Qingyang <[email protected]>
net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()

Arnd Bergmann <[email protected]>
siphash: use _unaligned version by default

Benjamin Poirier <[email protected]>
net: mpls: Fix notifications when deleting a device

Zhou Qingyang <[email protected]>
net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()

Randy Dunlap <[email protected]>
natsemi: xtensa: fix section mismatch warnings

Aaro Koskinen <[email protected]>
i2c: cbus-gpio: set atomic transfer callback

Alain Volmat <[email protected]>
i2c: stm32f7: stop dma transfer in case of NACK

Alain Volmat <[email protected]>
i2c: stm32f7: recover the bus on access timeout

Alain Volmat <[email protected]>
i2c: stm32f7: flush TX FIFO upon transfer errors

Baokun Li <[email protected]>
sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl

Baokun Li <[email protected]>
sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl

Linus Torvalds <[email protected]>
fget: check that the fd still exists after getting a ref to it

Niklas Schnelle <[email protected]>
s390/pci: move pseudo-MMIO to prevent MIO overlap

Xiongfeng Wang <[email protected]>
cpufreq: Fix get_cpu_device() failure in add_cpu_dev_symlink()

Ioanna Alifieraki <[email protected]>
ipmi: Move remove_work to dedicated workqueue

Stanislaw Gruszka <[email protected]>
rt2x00: do not mark device gone on EPROTO errors during start

Masami Hiramatsu <[email protected]>
kprobes: Limit max data_size of the kretprobe instances

Stephen Suryaputra <[email protected]>
vrf: Reset IPCB/IP6CB when processing outbound pkts in vrf dev xmit

Wen Gu <[email protected]>
net/smc: Avoid warning of possible recursive locking

Ian Rogers <[email protected]>
perf report: Fix memory leaks around perf_tip()

Ian Rogers <[email protected]>
perf hist: Fix memory leak of a perf_hpp_fmt

Teng Qi <[email protected]>
net: ethernet: dec: tulip: de4x5: fix possible array overflows in type3_infoblock()

zhangyue <[email protected]>
net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound

Teng Qi <[email protected]>
ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()

Mario Limonciello <[email protected]>
ata: ahci: Add Green Sardine vendor ID as board_ahci_mobile

Mike Christie <[email protected]>
scsi: iscsi: Unblock session then wake up error handler

Manaf Meethalavalappu Pallikunhi <[email protected]>
thermal: core: Reset previous low and high trip during thermal zone init

Wang Yugui <[email protected]>
btrfs: check-integrity: fix a warning on write caching disabled disk

Vasily Gorbik <[email protected]>
s390/setup: avoid using memblock_enforce_memory_limit

Slark Xiao <[email protected]>
platform/x86: thinkpad_acpi: Fix WWAN device disabled issue after S3 deep

liuguoqiang <[email protected]>
net: return correct error code

Zekun Shen <[email protected]>
atlantic: Fix OOB read and write in hw_atl_utils_fw_rpc_wait

Wen Gu <[email protected]>
net/smc: Transfer remaining wait queue entries during fallback

Xing Song <[email protected]>
mac80211: do not access the IV when it was stripped

Julian Braha <[email protected]>
drm/sun4i: fix unmet dependency on RESET_CONTROLLER for PHY_SUN6I_MIPI_DPHY

Andreas Gruenbacher <[email protected]>
gfs2: Fix length of holes reported at end-of-file

Zhang Changzhong <[email protected]>
can: j1939: j1939_tp_cmd_recv(): check the dst address of TP.CM_BAM

Russell King <[email protected]>
arm64: dts: mcbin: support 2W SFP modules

Geert Uytterhoeven <[email protected]>
of: clk: Make <linux/of_clk.h> self-contained

Benjamin Coddington <[email protected]>
NFSv42: Fix pagecache invalidation after COPY/CLONE


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

Diffstat:

Makefile | 4 +-
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi | 3 +
arch/parisc/Makefile | 5 ++
arch/parisc/install.sh | 1 +
arch/parisc/kernel/time.c | 24 ++------
arch/s390/include/asm/pci_io.h | 7 ++-
arch/s390/kernel/setup.c | 3 -
arch/x86/kernel/tsc.c | 28 +++++++--
arch/x86/kernel/tsc_sync.c | 41 +++++++++++++
arch/x86/kvm/pmu_amd.c | 2 +-
arch/x86/realmode/init.c | 12 +++-
drivers/ata/ahci.c | 1 +
drivers/ata/sata_fsl.c | 20 ++++---
drivers/char/ipmi/ipmi_msghandler.c | 13 ++++-
drivers/cpufreq/cpufreq.c | 9 ++-
drivers/gpu/drm/msm/msm_debugfs.c | 1 +
drivers/gpu/drm/sun4i/Kconfig | 1 +
drivers/i2c/busses/i2c-cbus-gpio.c | 5 +-
drivers/i2c/busses/i2c-stm32f7.c | 31 +++++++++-
.../aquantia/atlantic/hw_atl/hw_atl_utils.c | 10 ++++
drivers/net/ethernet/dec/tulip/de4x5.c | 34 ++++++-----
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 4 ++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 9 ++-
drivers/net/ethernet/natsemi/xtsonic.c | 2 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 10 +++-
drivers/net/usb/lan78xx.c | 2 +-
drivers/net/vrf.c | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 22 ++++---
drivers/net/wireless/intel/iwlwifi/iwl-drv.h | 3 +
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 24 +++++++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 +
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +
drivers/platform/x86/thinkpad_acpi.c | 12 ----
drivers/scsi/scsi_transport_iscsi.c | 6 +-
drivers/thermal/thermal_core.c | 2 +
drivers/tty/serial/8250/8250_pci.c | 39 ++++++++-----
drivers/tty/serial/amba-pl011.c | 1 +
drivers/tty/serial/msm_serial.c | 3 +
drivers/tty/serial/serial_core.c | 13 ++++-
drivers/usb/core/quirks.c | 3 +
drivers/usb/host/xhci-ring.c | 21 ++++---
drivers/usb/typec/tcpm/tcpm.c | 4 --
drivers/video/console/vgacon.c | 14 +++--
fs/btrfs/disk-io.c | 14 ++++-
fs/file.c | 4 ++
fs/gfs2/bmap.c | 2 +-
fs/nfs/nfs42proc.c | 5 +-
include/linux/kprobes.h | 2 +
include/linux/netdevice.h | 19 ++++--
include/linux/of_clk.h | 3 +
include/linux/siphash.h | 14 ++---
include/net/fib_rules.h | 2 +-
include/net/ip_fib.h | 2 +-
include/net/netns/ipv4.h | 2 +-
kernel/kprobes.c | 3 +
kernel/sched/core.c | 2 +-
lib/siphash.c | 12 ++--
net/can/j1939/transport.c | 6 ++
net/core/dev.c | 5 +-
net/core/fib_rules.c | 2 +-
net/ipv4/devinet.c | 2 +-
net/ipv4/fib_frontend.c | 2 +-
net/ipv4/fib_rules.c | 6 +-
net/ipv4/fib_semantics.c | 4 +-
net/ipv6/fib6_rules.c | 5 +-
net/mac80211/rx.c | 3 +-
net/mpls/af_mpls.c | 68 +++++++++++++++++-----
net/rds/tcp.c | 2 +-
net/rxrpc/peer_object.c | 14 +++--
net/smc/af_smc.c | 14 +++++
net/smc/smc_close.c | 8 ++-
net/tls/tls_sw.c | 4 +-
tools/perf/builtin-report.c | 15 +++--
tools/perf/ui/hist.c | 28 ++++-----
tools/perf/util/hist.h | 1 -
tools/perf/util/util.c | 14 ++---
tools/perf/util/util.h | 2 +-
tools/testing/selftests/net/fcnal-test.sh | 4 +-
80 files changed, 532 insertions(+), 225 deletions(-)




2021-12-06 15:26:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 49/70] drm/msm: Do hw_init() before capturing GPU state

From: Rob Clark <[email protected]>

commit e4840d537c2c6b1189d4de16ee0f4820e069dcea upstream.

In particular, we need to ensure all the necessary blocks are switched
to 64b mode (a5xx+) otherwise the high bits of the address of the BO to
snapshot state into will be ignored, resulting in:

*** gpu fault: ttbr0=0000000000000000 iova=0000000000012000 dir=READ type=TRANSLATION source=CP (0,0,0,0)
platform 506a000.gmu: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set BOOT_SLUMBER: 0x0

Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state")
Signed-off-by: Rob Clark <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/msm/msm_debugfs.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -77,6 +77,7 @@ static int msm_gpu_open(struct inode *in
goto free_priv;

pm_runtime_get_sync(&gpu->pdev->dev);
+ msm_gpu_hw_init(gpu);
show_priv->state = gpu->funcs->gpu_state_get(gpu);
pm_runtime_put_sync(&gpu->pdev->dev);




2021-12-06 15:26:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 45/70] net: annotate data-races on txq->xmit_lock_owner

From: Eric Dumazet <[email protected]>

commit 7a10d8c810cfad3e79372d7d1c77899d86cd6662 upstream.

syzbot found that __dev_queue_xmit() is reading txq->xmit_lock_owner
without annotations.

No serious issue there, let's document what is happening there.

BUG: KCSAN: data-race in __dev_queue_xmit / __dev_queue_xmit

write to 0xffff888139d09484 of 4 bytes by interrupt on cpu 0:
__netif_tx_unlock include/linux/netdevice.h:4437 [inline]
__dev_queue_xmit+0x948/0xf70 net/core/dev.c:4229
dev_queue_xmit_accel+0x19/0x20 net/core/dev.c:4265
macvlan_queue_xmit drivers/net/macvlan.c:543 [inline]
macvlan_start_xmit+0x2b3/0x3d0 drivers/net/macvlan.c:567
__netdev_start_xmit include/linux/netdevice.h:4987 [inline]
netdev_start_xmit include/linux/netdevice.h:5001 [inline]
xmit_one+0x105/0x2f0 net/core/dev.c:3590
dev_hard_start_xmit+0x72/0x120 net/core/dev.c:3606
sch_direct_xmit+0x1b2/0x7c0 net/sched/sch_generic.c:342
__dev_xmit_skb+0x83d/0x1370 net/core/dev.c:3817
__dev_queue_xmit+0x590/0xf70 net/core/dev.c:4194
dev_queue_xmit+0x13/0x20 net/core/dev.c:4259
neigh_hh_output include/net/neighbour.h:511 [inline]
neigh_output include/net/neighbour.h:525 [inline]
ip6_finish_output2+0x995/0xbb0 net/ipv6/ip6_output.c:126
__ip6_finish_output net/ipv6/ip6_output.c:191 [inline]
ip6_finish_output+0x444/0x4c0 net/ipv6/ip6_output.c:201
NF_HOOK_COND include/linux/netfilter.h:296 [inline]
ip6_output+0x10e/0x210 net/ipv6/ip6_output.c:224
dst_output include/net/dst.h:450 [inline]
NF_HOOK include/linux/netfilter.h:307 [inline]
ndisc_send_skb+0x486/0x610 net/ipv6/ndisc.c:508
ndisc_send_rs+0x3b0/0x3e0 net/ipv6/ndisc.c:702
addrconf_rs_timer+0x370/0x540 net/ipv6/addrconf.c:3898
call_timer_fn+0x2e/0x240 kernel/time/timer.c:1421
expire_timers+0x116/0x240 kernel/time/timer.c:1466
__run_timers+0x368/0x410 kernel/time/timer.c:1734
run_timer_softirq+0x2e/0x60 kernel/time/timer.c:1747
__do_softirq+0x158/0x2de kernel/softirq.c:558
__irq_exit_rcu kernel/softirq.c:636 [inline]
irq_exit_rcu+0x37/0x70 kernel/softirq.c:648
sysvec_apic_timer_interrupt+0x3e/0xb0 arch/x86/kernel/apic/apic.c:1097
asm_sysvec_apic_timer_interrupt+0x12/0x20

read to 0xffff888139d09484 of 4 bytes by interrupt on cpu 1:
__dev_queue_xmit+0x5e3/0xf70 net/core/dev.c:4213
dev_queue_xmit_accel+0x19/0x20 net/core/dev.c:4265
macvlan_queue_xmit drivers/net/macvlan.c:543 [inline]
macvlan_start_xmit+0x2b3/0x3d0 drivers/net/macvlan.c:567
__netdev_start_xmit include/linux/netdevice.h:4987 [inline]
netdev_start_xmit include/linux/netdevice.h:5001 [inline]
xmit_one+0x105/0x2f0 net/core/dev.c:3590
dev_hard_start_xmit+0x72/0x120 net/core/dev.c:3606
sch_direct_xmit+0x1b2/0x7c0 net/sched/sch_generic.c:342
__dev_xmit_skb+0x83d/0x1370 net/core/dev.c:3817
__dev_queue_xmit+0x590/0xf70 net/core/dev.c:4194
dev_queue_xmit+0x13/0x20 net/core/dev.c:4259
neigh_resolve_output+0x3db/0x410 net/core/neighbour.c:1523
neigh_output include/net/neighbour.h:527 [inline]
ip6_finish_output2+0x9be/0xbb0 net/ipv6/ip6_output.c:126
__ip6_finish_output net/ipv6/ip6_output.c:191 [inline]
ip6_finish_output+0x444/0x4c0 net/ipv6/ip6_output.c:201
NF_HOOK_COND include/linux/netfilter.h:296 [inline]
ip6_output+0x10e/0x210 net/ipv6/ip6_output.c:224
dst_output include/net/dst.h:450 [inline]
NF_HOOK include/linux/netfilter.h:307 [inline]
ndisc_send_skb+0x486/0x610 net/ipv6/ndisc.c:508
ndisc_send_rs+0x3b0/0x3e0 net/ipv6/ndisc.c:702
addrconf_rs_timer+0x370/0x540 net/ipv6/addrconf.c:3898
call_timer_fn+0x2e/0x240 kernel/time/timer.c:1421
expire_timers+0x116/0x240 kernel/time/timer.c:1466
__run_timers+0x368/0x410 kernel/time/timer.c:1734
run_timer_softirq+0x2e/0x60 kernel/time/timer.c:1747
__do_softirq+0x158/0x2de kernel/softirq.c:558
__irq_exit_rcu kernel/softirq.c:636 [inline]
irq_exit_rcu+0x37/0x70 kernel/softirq.c:648
sysvec_apic_timer_interrupt+0x8d/0xb0 arch/x86/kernel/apic/apic.c:1097
asm_sysvec_apic_timer_interrupt+0x12/0x20
kcsan_setup_watchpoint+0x94/0x420 kernel/kcsan/core.c:443
folio_test_anon include/linux/page-flags.h:581 [inline]
PageAnon include/linux/page-flags.h:586 [inline]
zap_pte_range+0x5ac/0x10e0 mm/memory.c:1347
zap_pmd_range mm/memory.c:1467 [inline]
zap_pud_range mm/memory.c:1496 [inline]
zap_p4d_range mm/memory.c:1517 [inline]
unmap_page_range+0x2dc/0x3d0 mm/memory.c:1538
unmap_single_vma+0x157/0x210 mm/memory.c:1583
unmap_vmas+0xd0/0x180 mm/memory.c:1615
exit_mmap+0x23d/0x470 mm/mmap.c:3170
__mmput+0x27/0x1b0 kernel/fork.c:1113
mmput+0x3d/0x50 kernel/fork.c:1134
exit_mm+0xdb/0x170 kernel/exit.c:507
do_exit+0x608/0x17a0 kernel/exit.c:819
do_group_exit+0xce/0x180 kernel/exit.c:929
get_signal+0xfc3/0x1550 kernel/signal.c:2852
arch_do_signal_or_restart+0x8c/0x2e0 arch/x86/kernel/signal.c:868
handle_signal_work kernel/entry/common.c:148 [inline]
exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
exit_to_user_mode_prepare+0x113/0x190 kernel/entry/common.c:207
__syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:300
do_syscall_64+0x50/0xd0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x44/0xae

value changed: 0x00000000 -> 0xffffffff

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

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/netdevice.h | 19 +++++++++++++------
net/core/dev.c | 5 ++++-
2 files changed, 17 insertions(+), 7 deletions(-)

--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3943,7 +3943,8 @@ static inline u32 netif_msg_init(int deb
static inline void __netif_tx_lock(struct netdev_queue *txq, int cpu)
{
spin_lock(&txq->_xmit_lock);
- txq->xmit_lock_owner = cpu;
+ /* Pairs with READ_ONCE() in __dev_queue_xmit() */
+ WRITE_ONCE(txq->xmit_lock_owner, cpu);
}

static inline bool __netif_tx_acquire(struct netdev_queue *txq)
@@ -3960,26 +3961,32 @@ static inline void __netif_tx_release(st
static inline void __netif_tx_lock_bh(struct netdev_queue *txq)
{
spin_lock_bh(&txq->_xmit_lock);
- txq->xmit_lock_owner = smp_processor_id();
+ /* Pairs with READ_ONCE() in __dev_queue_xmit() */
+ WRITE_ONCE(txq->xmit_lock_owner, smp_processor_id());
}

static inline bool __netif_tx_trylock(struct netdev_queue *txq)
{
bool ok = spin_trylock(&txq->_xmit_lock);
- if (likely(ok))
- txq->xmit_lock_owner = smp_processor_id();
+
+ if (likely(ok)) {
+ /* Pairs with READ_ONCE() in __dev_queue_xmit() */
+ WRITE_ONCE(txq->xmit_lock_owner, smp_processor_id());
+ }
return ok;
}

static inline void __netif_tx_unlock(struct netdev_queue *txq)
{
- txq->xmit_lock_owner = -1;
+ /* Pairs with READ_ONCE() in __dev_queue_xmit() */
+ WRITE_ONCE(txq->xmit_lock_owner, -1);
spin_unlock(&txq->_xmit_lock);
}

static inline void __netif_tx_unlock_bh(struct netdev_queue *txq)
{
- txq->xmit_lock_owner = -1;
+ /* Pairs with READ_ONCE() in __dev_queue_xmit() */
+ WRITE_ONCE(txq->xmit_lock_owner, -1);
spin_unlock_bh(&txq->_xmit_lock);
}

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3766,7 +3766,10 @@ static int __dev_queue_xmit(struct sk_bu
if (dev->flags & IFF_UP) {
int cpu = smp_processor_id(); /* ok because BHs are off */

- if (txq->xmit_lock_owner != cpu) {
+ /* Other cpus might concurrently change txq->xmit_lock_owner
+ * to -1 or to their cpu id, but not to our id.
+ */
+ if (READ_ONCE(txq->xmit_lock_owner) != cpu) {
if (dev_xmit_recursion())
goto recursion_alert;




2021-12-06 15:29:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 52/70] sched/uclamp: Fix rq->uclamp_max not set on first enqueue

From: Qais Yousef <[email protected]>

[ Upstream commit 315c4f884800c45cb6bd8c90422fad554a8b9588 ]

Commit d81ae8aac85c ("sched/uclamp: Fix initialization of struct
uclamp_rq") introduced a bug where uclamp_max of the rq is not reset to
match the woken up task's uclamp_max when the rq is idle.

The code was relying on rq->uclamp_max initialized to zero, so on first
enqueue

static inline void uclamp_rq_inc_id(struct rq *rq, struct task_struct *p,
enum uclamp_id clamp_id)
{
...

if (uc_se->value > READ_ONCE(uc_rq->value))
WRITE_ONCE(uc_rq->value, uc_se->value);
}

was actually resetting it. But since commit d81ae8aac85c changed the
default to 1024, this no longer works. And since rq->uclamp_flags is
also initialized to 0, neither above code path nor uclamp_idle_reset()
update the rq->uclamp_max on first wake up from idle.

This is only visible from first wake up(s) until the first dequeue to
idle after enabling the static key. And it only matters if the
uclamp_max of this task is < 1024 since only then its uclamp_max will be
effectively ignored.

Fix it by properly initializing rq->uclamp_flags = UCLAMP_FLAG_IDLE to
ensure uclamp_idle_reset() is called which then will update the rq
uclamp_max value as expected.

Fixes: d81ae8aac85c ("sched/uclamp: Fix initialization of struct uclamp_rq")
Signed-off-by: Qais Yousef <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Valentin Schneider <[email protected]>
Tested-by: Dietmar Eggemann <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f8ca0738d729e..5befdecefe947 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1337,7 +1337,7 @@ static void __init init_uclamp_rq(struct rq *rq)
};
}

- rq->uclamp_flags = 0;
+ rq->uclamp_flags = UCLAMP_FLAG_IDLE;
}

static void __init init_uclamp(void)
--
2.33.0




2021-12-06 15:29:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 17/70] ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()

From: Teng Qi <[email protected]>

[ Upstream commit a66998e0fbf213d47d02813b9679426129d0d114 ]

The if statement:
if (port >= DSAF_GE_NUM)
return;

limits the value of port less than DSAF_GE_NUM (i.e., 8).
However, if the value of port is 6 or 7, an array overflow could occur:
port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;

because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).

To fix this possible array overflow, we first check port and if it is
greater than or equal to DSAF_MAX_PORT_NUM, the function returns.

Reported-by: TOTE Robot <[email protected]>
Signed-off-by: Teng Qi <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index ed3829ae4ef1b..580199fdd0c22 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -398,6 +398,10 @@ static void hns_dsaf_ge_srst_by_port(struct dsaf_device *dsaf_dev, u32 port,
return;

if (!HNS_DSAF_IS_DEBUG(dsaf_dev)) {
+ /* DSAF_MAX_PORT_NUM is 6, but DSAF_GE_NUM is 8.
+ We need check to prevent array overflow */
+ if (port >= DSAF_MAX_PORT_NUM)
+ return;
reg_val_1 = 0x1 << port;
port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
/* there is difference between V1 and V2 in register.*/
--
2.33.0




2021-12-06 15:29:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 02/70] of: clk: Make <linux/of_clk.h> self-contained

From: Geert Uytterhoeven <[email protected]>

commit 5df867145f8adad9e5cdf9d67db1fbc0f71351e9 upstream.

Depending on include order:

include/linux/of_clk.h:11:45: warning: ‘struct device_node’ declared inside parameter list will not be visible outside of this definition or declaration
unsigned int of_clk_get_parent_count(struct device_node *np);
^~~~~~~~~~~
include/linux/of_clk.h:12:43: warning: ‘struct device_node’ declared inside parameter list will not be visible outside of this definition or declaration
const char *of_clk_get_parent_name(struct device_node *np, int index);
^~~~~~~~~~~
include/linux/of_clk.h:13:31: warning: ‘struct of_device_id’ declared inside parameter list will not be visible outside of this definition or declaration
void of_clk_init(const struct of_device_id *matches);
^~~~~~~~~~~~

Fix this by adding forward declarations for struct device_node and
struct of_device_id.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/of_clk.h | 3 +++
1 file changed, 3 insertions(+)

--- a/include/linux/of_clk.h
+++ b/include/linux/of_clk.h
@@ -6,6 +6,9 @@
#ifndef __LINUX_OF_CLK_H
#define __LINUX_OF_CLK_H

+struct device_node;
+struct of_device_id;
+
#if defined(CONFIG_COMMON_CLK) && defined(CONFIG_OF)

unsigned int of_clk_get_parent_count(struct device_node *np);



2021-12-06 15:29:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 14/70] thermal: core: Reset previous low and high trip during thermal zone init

From: Manaf Meethalavalappu Pallikunhi <[email protected]>

[ Upstream commit 99b63316c39988039965693f5f43d8b4ccb1c86c ]

During the suspend is in process, thermal_zone_device_update bails out
thermal zone re-evaluation for any sensor trip violation without
setting next valid trip to that sensor. It assumes during resume
it will re-evaluate same thermal zone and update trip. But when it is
in suspend temperature goes down and on resume path while updating
thermal zone if temperature is less than previously violated trip,
thermal zone set trip function evaluates the same previous high and
previous low trip as new high and low trip. Since there is no change
in high/low trip, it bails out from thermal zone set trip API without
setting any trip. It leads to a case where sensor high trip or low
trip is disabled forever even though thermal zone has a valid high
or low trip.

During thermal zone device init, reset thermal zone previous high
and low trip. It resolves above mentioned scenario.

Signed-off-by: Manaf Meethalavalappu Pallikunhi <[email protected]>
Reviewed-by: Thara Gopinath <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/thermal/thermal_core.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 20eab56b02cb9..f4490b8120176 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -460,6 +460,8 @@ static void thermal_zone_device_init(struct thermal_zone_device *tz)
{
struct thermal_instance *pos;
tz->temperature = THERMAL_TEMP_INVALID;
+ tz->prev_low_trip = -INT_MAX;
+ tz->prev_high_trip = INT_MAX;
list_for_each_entry(pos, &tz->thermal_instances, tz_node)
pos->initialized = false;
}
--
2.33.0




2021-12-06 15:29:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 38/70] net: mpls: Fix notifications when deleting a device

From: Benjamin Poirier <[email protected]>

commit 7d4741eacdefa5f0475431645b56baf00784df1f upstream.

There are various problems related to netlink notifications for mpls route
changes in response to interfaces being deleted:
* delete interface of only nexthop
DELROUTE notification is missing RTA_OIF attribute
* delete interface of non-last nexthop
NEWROUTE notification is missing entirely
* delete interface of last nexthop
DELROUTE notification is missing nexthop

All of these problems stem from the fact that existing routes are modified
in-place before sending a notification. Restructure mpls_ifdown() to avoid
changing the route in the DELROUTE cases and to create a copy in the
NEWROUTE case.

Fixes: f8efb73c97e2 ("mpls: multipath route support")
Signed-off-by: Benjamin Poirier <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mpls/af_mpls.c | 68 ++++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 52 insertions(+), 16 deletions(-)

--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -1491,22 +1491,52 @@ static void mpls_dev_destroy_rcu(struct
kfree(mdev);
}

-static void mpls_ifdown(struct net_device *dev, int event)
+static int mpls_ifdown(struct net_device *dev, int event)
{
struct mpls_route __rcu **platform_label;
struct net *net = dev_net(dev);
- u8 alive, deleted;
unsigned index;

platform_label = rtnl_dereference(net->mpls.platform_label);
for (index = 0; index < net->mpls.platform_labels; index++) {
struct mpls_route *rt = rtnl_dereference(platform_label[index]);
+ bool nh_del = false;
+ u8 alive = 0;

if (!rt)
continue;

- alive = 0;
- deleted = 0;
+ if (event == NETDEV_UNREGISTER) {
+ u8 deleted = 0;
+
+ for_nexthops(rt) {
+ struct net_device *nh_dev =
+ rtnl_dereference(nh->nh_dev);
+
+ if (!nh_dev || nh_dev == dev)
+ deleted++;
+ if (nh_dev == dev)
+ nh_del = true;
+ } endfor_nexthops(rt);
+
+ /* if there are no more nexthops, delete the route */
+ if (deleted == rt->rt_nhn) {
+ mpls_route_update(net, index, NULL, NULL);
+ continue;
+ }
+
+ if (nh_del) {
+ size_t size = sizeof(*rt) + rt->rt_nhn *
+ rt->rt_nh_size;
+ struct mpls_route *orig = rt;
+
+ rt = kmalloc(size, GFP_KERNEL);
+ if (!rt)
+ return -ENOMEM;
+ memcpy(rt, orig, size);
+ }
+ }
+
change_nexthops(rt) {
unsigned int nh_flags = nh->nh_flags;

@@ -1530,16 +1560,15 @@ static void mpls_ifdown(struct net_devic
next:
if (!(nh_flags & (RTNH_F_DEAD | RTNH_F_LINKDOWN)))
alive++;
- if (!rtnl_dereference(nh->nh_dev))
- deleted++;
} endfor_nexthops(rt);

WRITE_ONCE(rt->rt_nhn_alive, alive);

- /* if there are no more nexthops, delete the route */
- if (event == NETDEV_UNREGISTER && deleted == rt->rt_nhn)
- mpls_route_update(net, index, NULL, NULL);
+ if (nh_del)
+ mpls_route_update(net, index, rt, NULL);
}
+
+ return 0;
}

static void mpls_ifup(struct net_device *dev, unsigned int flags)
@@ -1607,8 +1636,12 @@ static int mpls_dev_notify(struct notifi
return NOTIFY_OK;

switch (event) {
+ int err;
+
case NETDEV_DOWN:
- mpls_ifdown(dev, event);
+ err = mpls_ifdown(dev, event);
+ if (err)
+ return notifier_from_errno(err);
break;
case NETDEV_UP:
flags = dev_get_flags(dev);
@@ -1619,13 +1652,18 @@ static int mpls_dev_notify(struct notifi
break;
case NETDEV_CHANGE:
flags = dev_get_flags(dev);
- if (flags & (IFF_RUNNING | IFF_LOWER_UP))
+ if (flags & (IFF_RUNNING | IFF_LOWER_UP)) {
mpls_ifup(dev, RTNH_F_DEAD | RTNH_F_LINKDOWN);
- else
- mpls_ifdown(dev, event);
+ } else {
+ err = mpls_ifdown(dev, event);
+ if (err)
+ return notifier_from_errno(err);
+ }
break;
case NETDEV_UNREGISTER:
- mpls_ifdown(dev, event);
+ err = mpls_ifdown(dev, event);
+ if (err)
+ return notifier_from_errno(err);
mdev = mpls_dev_get(dev);
if (mdev) {
mpls_dev_sysctl_unregister(dev, mdev);
@@ -1636,8 +1674,6 @@ static int mpls_dev_notify(struct notifi
case NETDEV_CHANGENAME:
mdev = mpls_dev_get(dev);
if (mdev) {
- int err;
-
mpls_dev_sysctl_unregister(dev, mdev);
err = mpls_dev_sysctl_register(dev, mdev);
if (err)



2021-12-06 15:29:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 04/70] can: j1939: j1939_tp_cmd_recv(): check the dst address of TP.CM_BAM

From: Zhang Changzhong <[email protected]>

commit 164051a6ab5445bd97f719f50b16db8b32174269 upstream.

The TP.CM_BAM message must be sent to the global address [1], so add a
check to drop TP.CM_BAM sent to a non-global address.

Without this patch, the receiver will treat the following packets as
normal RTS/CTS transport:
18EC0102#20090002FF002301
18EB0102#0100000000000000
18EB0102#020000FFFFFFFFFF

[1] SAE-J1939-82 2015 A.3.3 Row 1.

Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Link: https://lore.kernel.org/all/[email protected]
Cc: [email protected]
Signed-off-by: Zhang Changzhong <[email protected]>
Acked-by: Oleksij Rempel <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/can/j1939/transport.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -2004,6 +2004,12 @@ static void j1939_tp_cmd_recv(struct j19
extd = J1939_ETP;
/* fall through */
case J1939_TP_CMD_BAM: /* fall through */
+ if (cmd == J1939_TP_CMD_BAM && !j1939_cb_is_broadcast(skcb)) {
+ netdev_err_once(priv->ndev, "%s: BAM to unicast (%02x), ignoring!\n",
+ __func__, skcb->addr.sa);
+ return;
+ }
+ fallthrough;
case J1939_TP_CMD_RTS: /* fall through */
if (skcb->addr.type != extd)
return;



2021-12-06 15:29:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 44/70] net: marvell: mvpp2: Fix the computation of shared CPUs

From: Christophe JAILLET <[email protected]>

commit b83f5ac7d922e69a109261f5f940eebbd4e514c4 upstream.

'bitmap_fill()' fills a bitmap one 'long' at a time.
It is likely that an exact number of bits is expected.

Use 'bitmap_set()' instead in order not to set unexpected bits.

Fixes: e531f76757eb ("net: mvpp2: handle cases where more CPUs are available than s/w threads")
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -5773,7 +5773,7 @@ static int mvpp2_probe(struct platform_d

shared = num_present_cpus() - priv->nthreads;
if (shared > 0)
- bitmap_fill(&priv->lock_map,
+ bitmap_set(&priv->lock_map, 0,
min_t(int, shared, MVPP2_MAX_THREADS));

for (i = 0; i < MVPP2_MAX_THREADS; i++) {



2021-12-06 15:29:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 51/70] KVM: x86/pmu: Fix reserved bits for AMD PerfEvtSeln register

From: Like Xu <[email protected]>

[ Upstream commit cb1d220da0faa5ca0deb93449aff953f0c2cce6d ]

If we run the following perf command in an AMD Milan guest:

perf stat \
-e cpu/event=0x1d0/ \
-e cpu/event=0x1c7/ \
-e cpu/umask=0x1f,event=0x18e/ \
-e cpu/umask=0x7,event=0x18e/ \
-e cpu/umask=0x18,event=0x18e/ \
./workload

dmesg will report a #GP warning from an unchecked MSR access
error on MSR_F15H_PERF_CTLx.

This is because according to APM (Revision: 4.03) Figure 13-7,
the bits [35:32] of AMD PerfEvtSeln register is a part of the
event select encoding, which extends the EVENT_SELECT field
from 8 bits to 12 bits.

Opportunistically update pmu->reserved_bits for reserved bit 19.

Reported-by: Jim Mattson <[email protected]>
Fixes: ca724305a2b0 ("KVM: x86/vPMU: Implement AMD vPMU code for KVM")
Signed-off-by: Like Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/x86/kvm/pmu_amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/pmu_amd.c b/arch/x86/kvm/pmu_amd.c
index c8388389a3b05..d9990951fd0ac 100644
--- a/arch/x86/kvm/pmu_amd.c
+++ b/arch/x86/kvm/pmu_amd.c
@@ -266,7 +266,7 @@ static void amd_pmu_refresh(struct kvm_vcpu *vcpu)
pmu->nr_arch_gp_counters = AMD64_NUM_COUNTERS;

pmu->counter_bitmask[KVM_PMC_GP] = ((u64)1 << 48) - 1;
- pmu->reserved_bits = 0xffffffff00200000ull;
+ pmu->reserved_bits = 0xfffffff000280000ull;
pmu->version = 1;
/* not applicable to AMD; but clean them to prevent any fall out */
pmu->counter_bitmask[KVM_PMC_FIXED] = 0;
--
2.33.0




2021-12-06 15:30:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 29/70] fget: check that the fd still exists after getting a ref to it

From: Linus Torvalds <[email protected]>

commit 054aa8d439b9185d4f5eb9a90282d1ce74772969 upstream.

Jann Horn points out that there is another possible race wrt Unix domain
socket garbage collection, somewhat reminiscent of the one fixed in
commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").

See the extended comment about the garbage collection requirements added
to unix_peek_fds() by that commit for details.

The race comes from how we can locklessly look up a file descriptor just
as it is in the process of being closed, and with the right artificial
timing (Jann added a few strategic 'mdelay(500)' calls to do that), the
Unix domain socket garbage collector could see the reference count
decrement of the close() happen before fget() took its reference to the
file and the file was attached onto a new file descriptor.

This is all (intentionally) correct on the 'struct file *' side, with
RCU lookups and lockless reference counting very much part of the
design. Getting that reference count out of order isn't a problem per
se.

But the garbage collector can get confused by seeing this situation of
having seen a file not having any remaining external references and then
seeing it being attached to an fd.

In commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK") the
fix was to serialize the file descriptor install with the garbage
collector by taking and releasing the unix_gc_lock.

That's not really an option here, but since this all happens when we are
in the process of looking up a file descriptor, we can instead simply
just re-check that the file hasn't been closed in the meantime, and just
re-do the lookup if we raced with a concurrent close() of the same file
descriptor.

Reported-and-tested-by: Jann Horn <[email protected]>
Acked-by: Miklos Szeredi <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/file.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/fs/file.c
+++ b/fs/file.c
@@ -723,6 +723,10 @@ loop:
file = NULL;
else if (!get_file_rcu_many(file, refs))
goto loop;
+ else if (__fcheck_files(files, fd) != file) {
+ fput_many(file, refs);
+ goto loop;
+ }
}
rcu_read_unlock();




2021-12-06 15:30:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 34/70] i2c: stm32f7: stop dma transfer in case of NACK

From: Alain Volmat <[email protected]>

commit 31b90a95ccbbb4b628578ac17e3b3cc8eeacfe31 upstream.

In case of receiving a NACK, the dma transfer should be stopped
to avoid feeding data into the FIFO.
Also ensure to properly return the proper error code and avoid
waiting for the end of the dma completion in case of
error happening during the transmission.

Fixes: 7ecc8cfde553 ("i2c: i2c-stm32f7: Add DMA support")
Signed-off-by: Alain Volmat <[email protected]>
Reviewed-by: Pierre-Yves MORDRET <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-stm32f7.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1394,6 +1394,7 @@ static irqreturn_t stm32f7_i2c_isr_event
{
struct stm32f7_i2c_dev *i2c_dev = data;
struct stm32f7_i2c_msg *f7_msg = &i2c_dev->f7_msg;
+ struct stm32_i2c_dma *dma = i2c_dev->dma;
void __iomem *base = i2c_dev->base;
u32 status, mask;
int ret = IRQ_HANDLED;
@@ -1418,6 +1419,10 @@ static irqreturn_t stm32f7_i2c_isr_event
if (status & STM32F7_I2C_ISR_NACKF) {
dev_dbg(i2c_dev->dev, "<%s>: Receive NACK\n", __func__);
writel_relaxed(STM32F7_I2C_ICR_NACKCF, base + STM32F7_I2C_ICR);
+ if (i2c_dev->use_dma) {
+ stm32f7_i2c_disable_dma_req(i2c_dev);
+ dmaengine_terminate_all(dma->chan_using);
+ }
f7_msg->result = -ENXIO;
}

@@ -1433,7 +1438,7 @@ static irqreturn_t stm32f7_i2c_isr_event
/* Clear STOP flag */
writel_relaxed(STM32F7_I2C_ICR_STOPCF, base + STM32F7_I2C_ICR);

- if (i2c_dev->use_dma) {
+ if (i2c_dev->use_dma && !f7_msg->result) {
ret = IRQ_WAKE_THREAD;
} else {
i2c_dev->master_mode = false;
@@ -1446,7 +1451,7 @@ static irqreturn_t stm32f7_i2c_isr_event
if (f7_msg->stop) {
mask = STM32F7_I2C_CR2_STOP;
stm32f7_i2c_set_bits(base + STM32F7_I2C_CR2, mask);
- } else if (i2c_dev->use_dma) {
+ } else if (i2c_dev->use_dma && !f7_msg->result) {
ret = IRQ_WAKE_THREAD;
} else if (f7_msg->smbus) {
stm32f7_i2c_smbus_rep_start(i2c_dev);



2021-12-06 15:30:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 25/70] rt2x00: do not mark device gone on EPROTO errors during start

From: Stanislaw Gruszka <[email protected]>

commit ed53ae75693096f1c10b4561edd31a07b631bd72 upstream.

As reported by Exuvo is possible that we have lot's of EPROTO errors
during device start i.e. firmware load. But after that device works
correctly. Hence marking device gone by few EPROTO errors done by
commit e383c70474db ("rt2x00: check number of EPROTO errors") caused
regression - Exuvo device stop working after kernel update. To fix
disable the check during device start.

Link: https://lore.kernel.org/linux-wireless/[email protected]/
Reported-and-tested-by: Exuvo <[email protected]>
Fixes: e383c70474db ("rt2x00: check number of EPROTO errors")
Cc: [email protected]
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(st
if (status == -ENODEV || status == -ENOENT)
return true;

+ if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags))
+ return false;
+
if (status == -EPROTO || status == -ETIMEDOUT)
rt2x00dev->num_proto_errs++;
else



2021-12-06 15:30:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 63/70] serial: pl011: Add ACPI SBSA UART match id

From: Pierre Gondois <[email protected]>

commit ac442a077acf9a6bf1db4320ec0c3f303be092b3 upstream.

The document 'ACPI for Arm Components 1.0' defines the following
_HID mappings:
-'Prime cell UART (PL011)': ARMH0011
-'SBSA UART': ARMHB000

Use the sbsa-uart driver when a device is described with
the 'ARMHB000' _HID.

Note:
PL011 devices currently use the sbsa-uart driver instead of the
uart-pl011 driver. Indeed, PL011 devices are not bound to a clock
in ACPI. It is not possible to change their baudrate.

Cc: <[email protected]>
Signed-off-by: Pierre Gondois <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/amba-pl011.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2770,6 +2770,7 @@ MODULE_DEVICE_TABLE(of, sbsa_uart_of_mat

static const struct acpi_device_id sbsa_uart_acpi_match[] = {
{ "ARMH0011", 0 },
+ { "ARMHB000", 0 },
{},
};
MODULE_DEVICE_TABLE(acpi, sbsa_uart_acpi_match);



2021-12-06 15:30:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 65/70] serial: 8250_pci: Fix ACCES entries in pci_serial_quirks array

From: Jay Dolan <[email protected]>

commit c525c5d2437f93520388920baac6d9340c65d239 upstream.

Fix error in table for PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S that caused it
and PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4 to be missing their fourth port.

Fixes: 78d3820b9bd3 ("serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 chip use the pci_pericom_setup()")
Cc: stable <[email protected]>
Signed-off-by: Jay Dolan <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/8250/8250_pci.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -2285,11 +2285,18 @@ static struct pci_serial_quirk pci_seria
.setup = pci_pericom_setup_four_at_eight,
},
{
- .vendor = PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S,
+ .vendor = PCI_VENDOR_ID_ACCESIO,
.device = PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
.setup = pci_pericom_setup_four_at_eight,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_ACCESIO,
+ .device = PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_pericom_setup_four_at_eight,
},
{
.vendor = PCI_VENDOR_ID_ACCESIO,



2021-12-06 15:30:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 03/70] arm64: dts: mcbin: support 2W SFP modules

From: Russell King <[email protected]>

commit 05abc6a5dec2a8c123a50235ecd1ad8d75ffa7b4 upstream.

Allow the SFP cages to be used with 2W SFP modules.

Signed-off-by: Russell King <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Cc: Christian Lamparter <[email protected]>
Cc: 照山周一郎 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi | 3 +++
1 file changed, 3 insertions(+)

--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
@@ -71,6 +71,7 @@
tx-fault-gpio = <&cp1_gpio1 26 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&cp1_sfpp0_pins>;
+ maximum-power-milliwatt = <2000>;
};

sfp_eth1: sfp-eth1 {
@@ -83,6 +84,7 @@
tx-fault-gpio = <&cp0_gpio2 30 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&cp1_sfpp1_pins &cp0_sfpp1_pins>;
+ maximum-power-milliwatt = <2000>;
};

sfp_eth3: sfp-eth3 {
@@ -95,6 +97,7 @@
tx-fault-gpio = <&cp0_gpio2 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&cp0_sfp_1g_pins &cp1_sfp_1g_pins>;
+ maximum-power-milliwatt = <2000>;
};
};




2021-12-06 15:30:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 53/70] parisc: Fix KBUILD_IMAGE for self-extracting kernel

From: Helge Deller <[email protected]>

commit 1d7c29b77725d05faff6754d2f5e7c147aedcf93 upstream.

Default KBUILD_IMAGE to $(boot)/bzImage if a self-extracting
(CONFIG_PARISC_SELF_EXTRACT=y) kernel is to be built.
This fixes the bindeb-pkg make target.

Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]> # v4.14+
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/Makefile | 5 +++++
1 file changed, 5 insertions(+)

--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -17,7 +17,12 @@
# Mike Shaver, Helge Deller and Martin K. Petersen
#

+ifdef CONFIG_PARISC_SELF_EXTRACT
+boot := arch/parisc/boot
+KBUILD_IMAGE := $(boot)/bzImage
+else
KBUILD_IMAGE := vmlinuz
+endif

NM = sh $(srctree)/arch/parisc/nm
CHECKFLAGS += -D__hppa__=1



2021-12-06 15:30:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 54/70] parisc: Fix "make install" on newer debian releases

From: Helge Deller <[email protected]>

commit 0f9fee4cdebfbe695c297e5b603a275e2557c1cc upstream.

On newer debian releases the debian-provided "installkernel" script is
installed in /usr/sbin. Fix the kernel install.sh script to look for the
script in this directory as well.

Signed-off-by: Helge Deller <[email protected]>
Cc: <[email protected]> # v3.13+
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/install.sh | 1 +
1 file changed, 1 insertion(+)

--- a/arch/parisc/install.sh
+++ b/arch/parisc/install.sh
@@ -39,6 +39,7 @@ verify "$3"
if [ -n "${INSTALLKERNEL}" ]; then
if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
+ if [ -x /usr/sbin/${INSTALLKERNEL} ]; then exec /usr/sbin/${INSTALLKERNEL} "$@"; fi
fi

# Default install



2021-12-06 15:30:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 59/70] x86/tsc: Add a timer to make sure TSC_adjust is always checked

From: Feng Tang <[email protected]>

commit c7719e79347803b8e3b6b50da8c6db410a3012b5 upstream.

The TSC_ADJUST register is checked every time a CPU enters idle state, but
Thomas Gleixner mentioned there is still a caveat that a system won't enter
idle [1], either because it's too busy or configured purposely to not enter
idle.

Setup a periodic timer (every 10 minutes) to make sure the check is
happening on a regular base.

[1] https://lore.kernel.org/lkml/[email protected]/

Fixes: 6e3cd95234dc ("x86/hpet: Use another crystalball to evaluate HPET usability")
Requested-by: Thomas Gleixner <[email protected]>
Signed-off-by: Feng Tang <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/tsc_sync.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)

--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -30,6 +30,7 @@ struct tsc_adjust {
};

static DEFINE_PER_CPU(struct tsc_adjust, tsc_adjust);
+static struct timer_list tsc_sync_check_timer;

/*
* TSC's on different sockets may be reset asynchronously.
@@ -77,6 +78,46 @@ void tsc_verify_tsc_adjust(bool resume)
}
}

+/*
+ * Normally the tsc_sync will be checked every time system enters idle
+ * state, but there is still caveat that a system won't enter idle,
+ * either because it's too busy or configured purposely to not enter
+ * idle.
+ *
+ * So setup a periodic timer (every 10 minutes) to make sure the check
+ * is always on.
+ */
+
+#define SYNC_CHECK_INTERVAL (HZ * 600)
+
+static void tsc_sync_check_timer_fn(struct timer_list *unused)
+{
+ int next_cpu;
+
+ tsc_verify_tsc_adjust(false);
+
+ /* Run the check for all onlined CPUs in turn */
+ next_cpu = cpumask_next(raw_smp_processor_id(), cpu_online_mask);
+ if (next_cpu >= nr_cpu_ids)
+ next_cpu = cpumask_first(cpu_online_mask);
+
+ tsc_sync_check_timer.expires += SYNC_CHECK_INTERVAL;
+ add_timer_on(&tsc_sync_check_timer, next_cpu);
+}
+
+static int __init start_sync_check_timer(void)
+{
+ if (!cpu_feature_enabled(X86_FEATURE_TSC_ADJUST) || tsc_clocksource_reliable)
+ return 0;
+
+ timer_setup(&tsc_sync_check_timer, tsc_sync_check_timer_fn, 0);
+ tsc_sync_check_timer.expires = jiffies + SYNC_CHECK_INTERVAL;
+ add_timer(&tsc_sync_check_timer);
+
+ return 0;
+}
+late_initcall(start_sync_check_timer);
+
static void tsc_sanitize_first_cpu(struct tsc_adjust *cur, s64 bootval,
unsigned int cpu, bool bootcpu)
{



2021-12-06 15:30:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 37/70] net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()

From: Zhou Qingyang <[email protected]>

commit e2dabc4f7e7b60299c20a36d6a7b24ed9bf8e572 upstream.

In qlcnic_83xx_add_rings(), the indirect function of
ahw->hw_ops->alloc_mbx_args will be called to allocate memory for
cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),
which could lead to a NULL pointer dereference on failure of the
indirect function like qlcnic_83xx_alloc_mbx_args().

Fix this bug by adding a check of alloc_mbx_args(), this patch
imitates the logic of mbx_cmd()'s failure handling.

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_QLCNIC=m show no new warnings, and our
static analyzer no longer warns about this code.

Fixes: 7f9664525f9c ("qlcnic: 83xx memory map and HW access routine")
Signed-off-by: Zhou Qingyang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
@@ -1079,8 +1079,14 @@ static int qlcnic_83xx_add_rings(struct
sds_mbx_size = sizeof(struct qlcnic_sds_mbx);
context_id = recv_ctx->context_id;
num_sds = adapter->drv_sds_rings - QLCNIC_MAX_SDS_RINGS;
- ahw->hw_ops->alloc_mbx_args(&cmd, adapter,
- QLCNIC_CMD_ADD_RCV_RINGS);
+ err = ahw->hw_ops->alloc_mbx_args(&cmd, adapter,
+ QLCNIC_CMD_ADD_RCV_RINGS);
+ if (err) {
+ dev_err(&adapter->pdev->dev,
+ "Failed to alloc mbx args %d\n", err);
+ return err;
+ }
+
cmd.req.arg[1] = 0 | (num_sds << 8) | (context_id << 16);

/* set up status rings, mbx 2-81 */



2021-12-06 15:30:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 62/70] tty: serial: msm_serial: Deactivate RX DMA for polling support

From: Sven Eckelmann <[email protected]>

commit 7492ffc90fa126afb67d4392d56cb4134780194a upstream.

The CONSOLE_POLLING mode is used for tools like k(g)db. In this kind of
setup, it is often sharing a serial device with the normal system console.
This is usually no problem because the polling helpers can consume input
values directly (when in kgdb context) and the normal Linux handlers can
only consume new input values after kgdb switched back.

This is not true anymore when RX DMA is enabled for UARTDM controllers.
Single input values can no longer be received correctly. Instead following
seems to happen:

* on 1. input, some old input is read (continuously)
* on 2. input, two old inputs are read (continuously)
* on 3. input, three old input values are read (continuously)
* on 4. input, 4 previous inputs are received

This repeats then for each group of 4 input values.

This behavior changes slightly depending on what state the controller was
when the first input was received. But this makes working with kgdb
basically impossible because control messages are always corrupted when
kgdboc tries to parse them.

RX DMA should therefore be off when CONSOLE_POLLING is enabled to avoid
these kind of problems. No such problem was noticed for TX DMA.

Fixes: 99693945013a ("tty: serial: msm: Add RX DMA support")
Cc: [email protected]
Signed-off-by: Sven Eckelmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/msm_serial.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -603,6 +603,9 @@ static void msm_start_rx_dma(struct msm_
u32 val;
int ret;

+ if (IS_ENABLED(CONFIG_CONSOLE_POLL))
+ return;
+
if (!dma->chan)
return;




2021-12-06 15:31:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 64/70] serial: core: fix transmit-buffer reset and memleak

From: Johan Hovold <[email protected]>

commit 00de977f9e0aa9760d9a79d1e41ff780f74e3424 upstream.

Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use
tty_port_close") converted serial core to use tty_port_close() but
failed to notice that the transmit buffer still needs to be freed on
final close.

Not freeing the transmit buffer means that the buffer is no longer
cleared on next open so that any ioctl() waiting for the buffer to drain
might wait indefinitely (e.g. on termios changes) or that stale data can
end up being transmitted in case tx is restarted.

Furthermore, the buffer of any port that has been opened would leak on
driver unbind.

Note that the port lock is held when clearing the buffer pointer due to
the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race
between uart_put_char() and uart_shutdown()").

Also note that the tty-port shutdown() callback is not called for
console ports so it is not strictly necessary to free the buffer page
after releasing the lock (cf. d72402145ace ("tty/serial: do not free
trasnmit buffer page under port lock")).

Link: https://lore.kernel.org/r/319321886d97c456203d5c6a576a5480d07c3478.1635781688.git.baruch@tkos.co.il
Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close")
Cc: [email protected] # 4.9
Cc: Rob Herring <[email protected]>
Reported-by: Baruch Siach <[email protected]>
Tested-by: Baruch Siach <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/serial_core.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1573,6 +1573,7 @@ static void uart_tty_port_shutdown(struc
{
struct uart_state *state = container_of(port, struct uart_state, port);
struct uart_port *uport = uart_port_check(state);
+ char *buf;

/*
* At this point, we stop accepting input. To do this, we
@@ -1594,8 +1595,18 @@ static void uart_tty_port_shutdown(struc
*/
tty_port_set_suspended(port, 0);

- uart_change_pm(state, UART_PM_STATE_OFF);
+ /*
+ * Free the transmit buffer.
+ */
+ spin_lock_irq(&uport->lock);
+ buf = state->xmit.buf;
+ state->xmit.buf = NULL;
+ spin_unlock_irq(&uport->lock);
+
+ if (buf)
+ free_page((unsigned long)buf);

+ uart_change_pm(state, UART_PM_STATE_OFF);
}

static void uart_wait_until_sent(struct tty_struct *tty, int timeout)



2021-12-06 18:57:26

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/70] 5.4.164-rc1 review

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

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

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

2021-12-06 21:57:32

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/70] 5.4.164-rc1 review

On 12/6/21 11:57 AM, Florian Fainelli wrote:
> On 12/6/21 6:56 AM, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 5.4.164 release.
>> There are 70 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Wed, 08 Dec 2021 14:55:37 +0000.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.164-rc1.gz
>> or in the git tree and branch at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>
> On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
>
> Tested-by: Florian Fainelli <[email protected]>
>

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

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

thanks,
-- Shuah

2021-12-07 02:19:34

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/70] 5.4.164-rc1 review



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

Tested on arm64 and x86 for 5.4.164-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.4.y
Version: 5.4.164-rc1
Commit: 9be61260aa6e3ae7ea41db14cbb9dd8e933670f5
Compiler: gcc version 7.3.0 (GCC)

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

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

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

2021-12-07 09:17:08

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/70] 5.4.164-rc1 review

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


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

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

## Build
* kernel: 5.4.164-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.4.y
* git commit: 5d289daa9fc282e333cd99893062f9ce3e69e842
* git describe: v5.4.163-71-g5d289daa9fc2
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.163-71-g5d289daa9fc2

## No Test Regressions (compared to v5.4.163)

## No Test Fixes (compared to v5.4.163)

## Test result summary
total: 90099, pass: 74767, fail: 727, skip: 13223, xfail: 1382

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 259 total, 259 passed, 0 failed
* arm64: 41 total, 36 passed, 5 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 24 total, 22 passed, 2 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 35 passed, 2 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 58 total, 50 passed, 8 failed
* riscv: 27 total, 24 passed, 3 failed
* s390: 16 total, 13 passed, 3 failed
* sh: 22 total, 20 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 41 total, 40 passed, 1 failed

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

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

2021-12-07 20:41:31

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/70] 5.4.164-rc1 review

On Mon, Dec 06, 2021 at 03:56:04PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.164 release.
> There are 70 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 08 Dec 2021 14:55:37 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 446 pass: 446 fail: 0

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

Guenter

2021-12-08 10:29:42

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/70] 5.4.164-rc1 review

Hi Greg,

On Mon, Dec 06, 2021 at 03:56:04PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.164 release.
> There are 70 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 08 Dec 2021 14:55:37 +0000.
> Anything received after that time might be too late.

Build test:
mips (gcc version 11.2.1 20211112): 65 configs -> no new failure
arm (gcc version 11.2.1 20211112): 107 configs -> no new failure
arm64 (gcc version 11.2.1 20211112): 2 configs -> no failure
x86_64 (gcc version 11.2.1 20211112): 4 configs -> no failure

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

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


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

--
Regards
Sudip