2022-02-28 20:11:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 00/53] 5.4.182-rc1 review

This is the start of the stable review cycle for the 5.4.182 release.
There are 53 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, 02 Mar 2022 17:20:16 +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.182-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.182-rc1

Linus Torvalds <[email protected]>
fget: clarify and improve __fget_files() implementation

Miaohe Lin <[email protected]>
memblock: use kfree() to release kmalloced memblock regions

Karol Herbst <[email protected]>
Revert "drm/nouveau/pmu/gm200-: avoid touching PMU outside of DEVINIT/PREOS/ACR"

Marc Zyngier <[email protected]>
gpio: tegra186: Fix chip_data type confusion

[email protected] <[email protected]>
tty: n_gsm: fix NULL pointer access due to DLCI release

[email protected] <[email protected]>
tty: n_gsm: fix proper link termination after failed open

[email protected] <[email protected]>
tty: n_gsm: fix encoding of control signal octet bit DV

Hongyu Xie <[email protected]>
xhci: Prevent futile URB re-submissions due to incorrect return value.

Puma Hsu <[email protected]>
xhci: re-initialize the HC during resume if HCE was set

Sebastian Andrzej Siewior <[email protected]>
usb: dwc3: gadget: Let the interrupt handler disable bottom halves.

Hans de Goede <[email protected]>
usb: dwc3: pci: Fix Bay Trail phy GPIO mappings

Daniele Palmas <[email protected]>
USB: serial: option: add Telit LE910R1 compositions

Slark Xiao <[email protected]>
USB: serial: option: add support for DW5829e

Steven Rostedt (Google) <[email protected]>
tracefs: Set the group ownership in apply_options() not parse_options()

Szymon Heidrich <[email protected]>
USB: gadget: validate endpoint index for xilinx udc

Daehwan Jung <[email protected]>
usb: gadget: rndis: add spinlock for rndis response list

Dmytro Bagrii <[email protected]>
Revert "USB: serial: ch341: add new Product ID for CH341A"

Sergey Shtylyov <[email protected]>
ata: pata_hpt37x: disable primary channel on HPT371

Miaoqian Lin <[email protected]>
iio: Fix error handling for PM

Cosmin Tanislav <[email protected]>
iio: adc: ad7124: fix mask used for setting AIN_BUFP & AIN_BUFM bits

Christophe JAILLET <[email protected]>
iio: adc: men_z188_adc: Fix a resource leak in an error handling path

Steven Rostedt (Google) <[email protected]>
tracing: Have traceon and traceoff trigger honor the instance

Bart Van Assche <[email protected]>
RDMA/ib_srp: Fix a deadlock

ChenXiaoSong <[email protected]>
configfs: fix a race in configfs_{,un}register_subsystem()

Zhou Qingyang <[email protected]>
spi: spi-zynq-qspi: Fix a NULL pointer dereference in zynq_qspi_exec_mem_op()

Ariel Levkovich <[email protected]>
net/mlx5: Fix wrong limitation of metadata match on ecpf

Maor Gottlieb <[email protected]>
net/mlx5: Fix possible deadlock on rule deletion

Florian Westphal <[email protected]>
netfilter: nf_tables: fix memory leak during stateful obj update

Christophe JAILLET <[email protected]>
nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac()

Christophe Leroy <[email protected]>
net: Force inlining of checksum functions in net/checksum.h

Xiaoke Wang <[email protected]>
net: ll_temac: check the return value of devm_kmalloc()

Gal Pressman <[email protected]>
net/mlx5e: Fix wrong return value on ioctl EEPROM query failure

Maxime Ripard <[email protected]>
drm/edid: Always set RGB444

Paul Blakey <[email protected]>
openvswitch: Fix setting ipv6 fields causing hw csum failure

Tao Liu <[email protected]>
gso: do not skip outer ip header in case of ipip and net_failover

Dan Carpenter <[email protected]>
tipc: Fix end of loop tests for list_for_each_entry()

Eric Dumazet <[email protected]>
net: __pskb_pull_tail() & pskb_carve_frag_list() drop_monitor friends

Felix Maurer <[email protected]>
bpf: Do not try bpf_msg_push_data with len 0

Alexey Bayduraev <[email protected]>
perf data: Fix double free in perf_session__delete()

Xin Long <[email protected]>
ping: remove pr_err from ping_lookup

Heiner Kallweit <[email protected]>
lan743x: fix deadlock in lan743x_phy_link_status_change()

Jens Wiklander <[email protected]>
optee: use driver internal tee_context for some rpc

Jens Wiklander <[email protected]>
tee: export teedev_open() and teedev_close_context()

Brian Geffon <[email protected]>
x86/fpu: Correct pkru/xstate inconsistency

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables_offload: incorrect flow offload action array size

Oliver Neukum <[email protected]>
USB: zaurus: support another broken Zaurus

Oliver Neukum <[email protected]>
sr9700: sanity check for packet length

Evan Quan <[email protected]>
drm/amdgpu: disable MMHUB PG for Picasso

Helge Deller <[email protected]>
parisc/unaligned: Fix ldw() and stw() unalignment handlers

Helge Deller <[email protected]>
parisc/unaligned: Fix fldd and fstd unaligned handlers on 32-bit kernel

Stefano Garzarella <[email protected]>
vhost/vsock: don't check owner in vhost_vsock_stop() while releasing

Siarhei Volkau <[email protected]>
clk: jz4725b: fix mmc0 clock gating

Zhang Qiao <[email protected]>
cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug


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

Diffstat:

Makefile | 4 +-
arch/parisc/kernel/unaligned.c | 14 ++---
arch/x86/include/asm/fpu/internal.h | 13 ++--
arch/x86/kernel/process_32.c | 6 +-
arch/x86/kernel/process_64.c | 6 +-
drivers/ata/pata_hpt37x.c | 14 +++++
drivers/clk/ingenic/jz4725b-cgu.c | 3 +-
drivers/gpio/gpio-tegra186.c | 14 +++--
drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +-
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/base.c | 37 +++++------
drivers/iio/accel/bmc150-accel-core.c | 5 +-
drivers/iio/accel/kxcjk-1013.c | 5 +-
drivers/iio/accel/mma9551.c | 5 +-
drivers/iio/accel/mma9553.c | 5 +-
drivers/iio/adc/ad7124.c | 2 +-
drivers/iio/adc/men_z188_adc.c | 9 ++-
drivers/iio/gyro/bmg160_core.c | 5 +-
drivers/iio/imu/kmx61.c | 5 +-
drivers/iio/magnetometer/bmc150_magn.c | 5 +-
drivers/infiniband/ulp/srp/ib_srp.c | 6 +-
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 2 +-
.../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 4 --
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +
drivers/net/ethernet/microchip/lan743x_main.c | 12 +---
.../ethernet/netronome/nfp/flower/tunnel_conf.c | 4 +-
drivers/net/ethernet/xilinx/ll_temac_main.c | 2 +
drivers/net/usb/cdc_ether.c | 12 ++++
drivers/net/usb/sr9700.c | 2 +-
drivers/net/usb/zaurus.c | 12 ++++
drivers/spi/spi-zynq-qspi.c | 3 +
drivers/tee/optee/core.c | 8 +++
drivers/tee/optee/optee_private.h | 2 +
drivers/tee/optee/rpc.c | 8 ++-
drivers/tee/tee_core.c | 6 +-
drivers/tty/n_gsm.c | 11 +++-
drivers/usb/dwc3/dwc3-pci.c | 4 +-
drivers/usb/dwc3/gadget.c | 2 +
drivers/usb/gadget/function/rndis.c | 8 +++
drivers/usb/gadget/function/rndis.h | 1 +
drivers/usb/gadget/udc/udc-xilinx.c | 6 ++
drivers/usb/host/xhci.c | 28 ++++++---
drivers/usb/serial/ch341.c | 1 -
drivers/usb/serial/option.c | 12 ++++
drivers/vhost/vsock.c | 21 ++++---
fs/configfs/dir.c | 14 +++++
fs/file.c | 73 +++++++++++++++++-----
fs/tracefs/inode.c | 5 +-
include/linux/tee_drv.h | 14 +++++
include/net/checksum.h | 46 ++++++++------
include/net/netfilter/nf_tables.h | 2 +-
include/net/netfilter/nf_tables_offload.h | 2 -
kernel/cgroup/cpuset.c | 2 +
kernel/trace/trace_events_trigger.c | 52 +++++++++++++--
mm/memblock.c | 10 ++-
net/core/filter.c | 3 +
net/core/skbuff.c | 4 +-
net/ipv4/af_inet.c | 5 +-
net/ipv4/ping.c | 1 -
net/ipv6/ip6_offload.c | 2 +
net/netfilter/nf_tables_api.c | 13 ++--
net/netfilter/nf_tables_offload.c | 3 +-
net/netfilter/nft_dup_netdev.c | 6 ++
net/netfilter/nft_fwd_netdev.c | 6 ++
net/netfilter/nft_immediate.c | 12 +++-
net/openvswitch/actions.c | 46 +++++++++++---
net/tipc/name_table.c | 2 +-
net/tipc/socket.c | 2 +-
tools/perf/util/data.c | 7 +--
69 files changed, 495 insertions(+), 180 deletions(-)



2022-02-28 20:11:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 28/53] net/mlx5: Fix wrong limitation of metadata match on ecpf

From: Ariel Levkovich <[email protected]>

commit 07666c75ad17d7389b18ac0235c8cf41e1504ea8 upstream.

Match metadata support check returns false for ecpf device.
However, this support does exist for ecpf and therefore this
limitation should be removed to allow feature such as stacked
devices and internal port offloaded to be supported.

Fixes: 92ab1eb392c6 ("net/mlx5: E-Switch, Enable vport metadata matching if firmware supports it")
Signed-off-by: Ariel Levkovich <[email protected]>
Reviewed-by: Maor Dickman <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 4 ----
1 file changed, 4 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -1977,10 +1977,6 @@ esw_check_vport_match_metadata_supported
if (!MLX5_CAP_ESW_FLOWTABLE(esw->dev, flow_source))
return false;

- if (mlx5_core_is_ecpf_esw_manager(esw->dev) ||
- mlx5_ecpf_vport_exists(esw->dev))
- return false;
-
return true;
}



2022-02-28 20:13:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 05/53] parisc/unaligned: Fix ldw() and stw() unalignment handlers

From: Helge Deller <[email protected]>

commit a97279836867b1cb50a3d4f0b1bf60e0abe6d46c upstream.

Fix 3 bugs:

a) emulate_stw() doesn't return the error code value, so faulting
instructions are not reported and aborted.

b) Tell emulate_ldw() to handle fldw_l as floating point instruction

c) Tell emulate_ldw() to handle ldw_m as integer instruction

Signed-off-by: Helge Deller <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/kernel/unaligned.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/parisc/kernel/unaligned.c
+++ b/arch/parisc/kernel/unaligned.c
@@ -340,7 +340,7 @@ static int emulate_stw(struct pt_regs *r
: "r" (val), "r" (regs->ior), "r" (regs->isr)
: "r19", "r20", "r21", "r22", "r1", FIXUP_BRANCH_CLOBBER );

- return 0;
+ return ret;
}
static int emulate_std(struct pt_regs *regs, int frreg, int flop)
{
@@ -619,10 +619,10 @@ void handle_unaligned(struct pt_regs *re
{
case OPCODE_FLDW_L:
flop=1;
- ret = emulate_ldw(regs, R2(regs->iir),0);
+ ret = emulate_ldw(regs, R2(regs->iir), 1);
break;
case OPCODE_LDW_M:
- ret = emulate_ldw(regs, R2(regs->iir),1);
+ ret = emulate_ldw(regs, R2(regs->iir), 0);
break;

case OPCODE_FSTW_L:


2022-02-28 20:14:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 43/53] usb: dwc3: pci: Fix Bay Trail phy GPIO mappings

From: Hans de Goede <[email protected]>

commit 62e3f0afe246720f7646eb1b034a6897dac34405 upstream.

When the Bay Trail phy GPIO mappings where added cs and reset were swapped,
this did not cause any issues sofar, because sofar they were always driven
high/low at the same time.

Note the new mapping has been verified both in /sys/kernel/debug/gpio
output on Android factory images on multiple devices, as well as in
the schematics for some devices.

Fixes: 5741022cbdf3 ("usb: dwc3: pci: Add GPIO lookup table on platforms without ACPI GPIO resources")
Cc: stable <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc3/dwc3-pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -81,8 +81,8 @@ static const struct acpi_gpio_mapping ac
static struct gpiod_lookup_table platform_bytcr_gpios = {
.dev_id = "0000:00:16.0",
.table = {
- GPIO_LOOKUP("INT33FC:00", 54, "reset", GPIO_ACTIVE_HIGH),
- GPIO_LOOKUP("INT33FC:02", 14, "cs", GPIO_ACTIVE_HIGH),
+ GPIO_LOOKUP("INT33FC:00", 54, "cs", GPIO_ACTIVE_HIGH),
+ GPIO_LOOKUP("INT33FC:02", 14, "reset", GPIO_ACTIVE_HIGH),
{}
},
};


2022-02-28 20:14:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 31/53] RDMA/ib_srp: Fix a deadlock

From: Bart Van Assche <[email protected]>

[ Upstream commit 081bdc9fe05bb23248f5effb6f811da3da4b8252 ]

Remove the flush_workqueue(system_long_wq) call since flushing
system_long_wq is deadlock-prone and since that call is redundant with a
preceding cancel_work_sync()

Link: https://lore.kernel.org/r/[email protected]
Fixes: ef6c49d87c34 ("IB/srp: Eliminate state SRP_TARGET_DEAD")
Reported-by: [email protected]
Signed-off-by: Bart Van Assche <[email protected]>
Reviewed-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/infiniband/ulp/srp/ib_srp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index 8708ed5477e99..dac806b715afa 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -4222,9 +4222,11 @@ static void srp_remove_one(struct ib_device *device, void *client_data)
spin_unlock(&host->target_lock);

/*
- * Wait for tl_err and target port removal tasks.
+ * srp_queue_remove_work() queues a call to
+ * srp_remove_target(). The latter function cancels
+ * target->tl_err_work so waiting for the remove works to
+ * finish is sufficient.
*/
- flush_workqueue(system_long_wq);
flush_workqueue(srp_remove_wq);

kfree(host);
--
2.34.1



2022-02-28 20:14:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 23/53] net: ll_temac: check the return value of devm_kmalloc()

From: Xiaoke Wang <[email protected]>

commit b352c3465bb808ab700d03f5bac2f7a6f37c5350 upstream.

devm_kmalloc() returns a pointer to allocated memory on success, NULL
on failure. While lp->indirect_lock is allocated by devm_kmalloc()
without proper check. It is better to check the value of it to
prevent potential wrong memory access.

Fixes: f14f5c11f051 ("net: ll_temac: Support indirect_mutex share within TEMAC IP")
Signed-off-by: Xiaoke Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/xilinx/ll_temac_main.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/xilinx/ll_temac_main.c
+++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
@@ -1345,6 +1345,8 @@ static int temac_probe(struct platform_d
lp->indirect_lock = devm_kmalloc(&pdev->dev,
sizeof(*lp->indirect_lock),
GFP_KERNEL);
+ if (!lp->indirect_lock)
+ return -ENOMEM;
spin_lock_init(lp->indirect_lock);
}



2022-02-28 20:14:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 52/53] memblock: use kfree() to release kmalloced memblock regions

From: Miaohe Lin <[email protected]>

commit c94afc46cae7ad41b2ad6a99368147879f4b0e56 upstream.

memblock.{reserved,memory}.regions may be allocated using kmalloc() in
memblock_double_array(). Use kfree() to release these kmalloced regions
indicated by memblock_{reserved,memory}_in_slab.

Signed-off-by: Miaohe Lin <[email protected]>
Fixes: 3010f876500f ("mm: discard memblock data later")
Signed-off-by: Mike Rapoport <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/memblock.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -348,14 +348,20 @@ void __init memblock_discard(void)
addr = __pa(memblock.reserved.regions);
size = PAGE_ALIGN(sizeof(struct memblock_region) *
memblock.reserved.max);
- __memblock_free_late(addr, size);
+ if (memblock_reserved_in_slab)
+ kfree(memblock.reserved.regions);
+ else
+ __memblock_free_late(addr, size);
}

if (memblock.memory.regions != memblock_memory_init_regions) {
addr = __pa(memblock.memory.regions);
size = PAGE_ALIGN(sizeof(struct memblock_region) *
memblock.memory.max);
- __memblock_free_late(addr, size);
+ if (memblock_memory_in_slab)
+ kfree(memblock.memory.regions);
+ else
+ __memblock_free_late(addr, size);
}
}
#endif


2022-02-28 20:15:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 10/53] x86/fpu: Correct pkru/xstate inconsistency

From: Brian Geffon <[email protected]>

When eagerly switching PKRU in switch_fpu_finish() it checks that
current is not a kernel thread as kernel threads will never use PKRU.
It's possible that this_cpu_read_stable() on current_task
(ie. get_current()) is returning an old cached value. To resolve this
reference next_p directly rather than relying on current.

As written it's possible when switching from a kernel thread to a
userspace thread to observe a cached PF_KTHREAD flag and never restore
the PKRU. And as a result this issue only occurs when switching
from a kernel thread to a userspace thread, switching from a non kernel
thread works perfectly fine because all that is considered in that
situation are the flags from some other non kernel task and the next fpu
is passed in to switch_fpu_finish().

This behavior only exists between 5.2 and 5.13 when it was fixed by a
rewrite decoupling PKRU from xstate, in:
commit 954436989cc5 ("x86/fpu: Remove PKRU handling from switch_fpu_finish()")

Unfortunately backporting the fix from 5.13 is probably not realistic as
it's part of a 60+ patch series which rewrites most of the PKRU handling.

Fixes: 0cecca9d03c9 ("x86/fpu: Eager switch PKRU state")
Signed-off-by: Brian Geffon <[email protected]>
Signed-off-by: Willis Kung <[email protected]>
Tested-by: Willis Kung <[email protected]>
Cc: <[email protected]> # v5.4.x
Cc: <[email protected]> # v5.10.x
Acked-by: Dave Hansen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/include/asm/fpu/internal.h | 13 ++++++++-----
arch/x86/kernel/process_32.c | 6 ++----
arch/x86/kernel/process_64.c | 6 ++----
3 files changed, 12 insertions(+), 13 deletions(-)

--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -560,9 +560,11 @@ static inline void __fpregs_load_activat
* The FPU context is only stored/restored for a user task and
* PF_KTHREAD is used to distinguish between kernel and user threads.
*/
-static inline void switch_fpu_prepare(struct fpu *old_fpu, int cpu)
+static inline void switch_fpu_prepare(struct task_struct *prev, int cpu)
{
- if (static_cpu_has(X86_FEATURE_FPU) && !(current->flags & PF_KTHREAD)) {
+ struct fpu *old_fpu = &prev->thread.fpu;
+
+ if (static_cpu_has(X86_FEATURE_FPU) && !(prev->flags & PF_KTHREAD)) {
if (!copy_fpregs_to_fpstate(old_fpu))
old_fpu->last_cpu = -1;
else
@@ -581,10 +583,11 @@ static inline void switch_fpu_prepare(st
* Load PKRU from the FPU context if available. Delay loading of the
* complete FPU state until the return to userland.
*/
-static inline void switch_fpu_finish(struct fpu *new_fpu)
+static inline void switch_fpu_finish(struct task_struct *next)
{
u32 pkru_val = init_pkru_value;
struct pkru_state *pk;
+ struct fpu *next_fpu = &next->thread.fpu;

if (!static_cpu_has(X86_FEATURE_FPU))
return;
@@ -598,7 +601,7 @@ static inline void switch_fpu_finish(str
* PKRU state is switched eagerly because it needs to be valid before we
* return to userland e.g. for a copy_to_user() operation.
*/
- if (!(current->flags & PF_KTHREAD)) {
+ if (!(next->flags & PF_KTHREAD)) {
/*
* If the PKRU bit in xsave.header.xfeatures is not set,
* then the PKRU component was in init state, which means
@@ -607,7 +610,7 @@ static inline void switch_fpu_finish(str
* in memory is not valid. This means pkru_val has to be
* set to 0 and not to init_pkru_value.
*/
- pk = get_xsave_addr(&new_fpu->state.xsave, XFEATURE_PKRU);
+ pk = get_xsave_addr(&next_fpu->state.xsave, XFEATURE_PKRU);
pkru_val = pk ? pk->pkru : 0;
}
__write_pkru(pkru_val);
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -229,14 +229,12 @@ __switch_to(struct task_struct *prev_p,
{
struct thread_struct *prev = &prev_p->thread,
*next = &next_p->thread;
- struct fpu *prev_fpu = &prev->fpu;
- struct fpu *next_fpu = &next->fpu;
int cpu = smp_processor_id();

/* never put a printk in __switch_to... printk() calls wake_up*() indirectly */

if (!test_thread_flag(TIF_NEED_FPU_LOAD))
- switch_fpu_prepare(prev_fpu, cpu);
+ switch_fpu_prepare(prev_p, cpu);

/*
* Save away %gs. No need to save %fs, as it was saved on the
@@ -292,7 +290,7 @@ __switch_to(struct task_struct *prev_p,

this_cpu_write(current_task, next_p);

- switch_fpu_finish(next_fpu);
+ switch_fpu_finish(next_p);

/* Load the Intel cache allocation PQR MSR. */
resctrl_sched_in();
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -505,15 +505,13 @@ __switch_to(struct task_struct *prev_p,
{
struct thread_struct *prev = &prev_p->thread;
struct thread_struct *next = &next_p->thread;
- struct fpu *prev_fpu = &prev->fpu;
- struct fpu *next_fpu = &next->fpu;
int cpu = smp_processor_id();

WARN_ON_ONCE(IS_ENABLED(CONFIG_DEBUG_ENTRY) &&
this_cpu_read(irq_count) != -1);

if (!test_thread_flag(TIF_NEED_FPU_LOAD))
- switch_fpu_prepare(prev_fpu, cpu);
+ switch_fpu_prepare(prev_p, cpu);

/* We must save %fs and %gs before load_TLS() because
* %fs and %gs may be cleared by load_TLS().
@@ -565,7 +563,7 @@ __switch_to(struct task_struct *prev_p,
this_cpu_write(current_task, next_p);
this_cpu_write(cpu_current_top_of_stack, task_top_of_stack(next_p));

- switch_fpu_finish(next_fpu);
+ switch_fpu_finish(next_p);

/* Reload sp0. */
update_task_stack(next_p);


2022-02-28 20:16:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 38/53] usb: gadget: rndis: add spinlock for rndis response list

From: Daehwan Jung <[email protected]>

commit aaaba1c86d04dac8e49bf508b492f81506257da3 upstream.

There's no lock for rndis response list. It could cause list corruption
if there're two different list_add at the same time like below.
It's better to add in rndis_add_response / rndis_free_response
/ rndis_get_next_response to prevent any race condition on response list.

[ 361.894299] [1: irq/191-dwc3:16979] list_add corruption.
next->prev should be prev (ffffff80651764d0),
but was ffffff883dc36f80. (next=ffffff80651764d0).

[ 361.904380] [1: irq/191-dwc3:16979] Call trace:
[ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90
[ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0
[ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84
[ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4
[ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60
[ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0
[ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc
[ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc
[ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec
[ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c

Fixes: f6281af9d62e ("usb: gadget: rndis: use list_for_each_entry_safe")
Cc: stable <[email protected]>
Signed-off-by: Daehwan Jung <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/rndis.c | 8 ++++++++
drivers/usb/gadget/function/rndis.h | 1 +
2 files changed, 9 insertions(+)

--- a/drivers/usb/gadget/function/rndis.c
+++ b/drivers/usb/gadget/function/rndis.c
@@ -922,6 +922,7 @@ struct rndis_params *rndis_register(void
params->resp_avail = resp_avail;
params->v = v;
INIT_LIST_HEAD(&params->resp_queue);
+ spin_lock_init(&params->resp_lock);
pr_debug("%s: configNr = %d\n", __func__, i);

return params;
@@ -1015,12 +1016,14 @@ void rndis_free_response(struct rndis_pa
{
rndis_resp_t *r, *n;

+ spin_lock(&params->resp_lock);
list_for_each_entry_safe(r, n, &params->resp_queue, list) {
if (r->buf == buf) {
list_del(&r->list);
kfree(r);
}
}
+ spin_unlock(&params->resp_lock);
}
EXPORT_SYMBOL_GPL(rndis_free_response);

@@ -1030,14 +1033,17 @@ u8 *rndis_get_next_response(struct rndis

if (!length) return NULL;

+ spin_lock(&params->resp_lock);
list_for_each_entry_safe(r, n, &params->resp_queue, list) {
if (!r->send) {
r->send = 1;
*length = r->length;
+ spin_unlock(&params->resp_lock);
return r->buf;
}
}

+ spin_unlock(&params->resp_lock);
return NULL;
}
EXPORT_SYMBOL_GPL(rndis_get_next_response);
@@ -1054,7 +1060,9 @@ static rndis_resp_t *rndis_add_response(
r->length = length;
r->send = 0;

+ spin_lock(&params->resp_lock);
list_add_tail(&r->list, &params->resp_queue);
+ spin_unlock(&params->resp_lock);
return r;
}

--- a/drivers/usb/gadget/function/rndis.h
+++ b/drivers/usb/gadget/function/rndis.h
@@ -174,6 +174,7 @@ typedef struct rndis_params {
void (*resp_avail)(void *v);
void *v;
struct list_head resp_queue;
+ spinlock_t resp_lock;
} rndis_params;

/* RNDIS Message parser and other useless functions */


2022-02-28 20:16:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 08/53] USB: zaurus: support another broken Zaurus

From: Oliver Neukum <[email protected]>

commit 6605cc67ca18b9d583eb96e18a20f5f4e726103c upstream.

This SL-6000 says Direct Line, not Ethernet

v2: added Reporter and Link

Signed-off-by: Oliver Neukum <[email protected]>
Reported-by: Ross Maynard <[email protected]>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215361
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/cdc_ether.c | 12 ++++++++++++
drivers/net/usb/zaurus.c | 12 ++++++++++++
2 files changed, 24 insertions(+)

--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -571,6 +571,11 @@ static const struct usb_device_id produc
.bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, \
.bInterfaceProtocol = USB_CDC_PROTO_NONE

+#define ZAURUS_FAKE_INTERFACE \
+ .bInterfaceClass = USB_CLASS_COMM, \
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_MDLM, \
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE
+
/* SA-1100 based Sharp Zaurus ("collie"), or compatible;
* wire-incompatible with true CDC Ethernet implementations.
* (And, it seems, needlessly so...)
@@ -626,6 +631,13 @@ static const struct usb_device_id produc
.driver_info = 0,
}, {
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+ | USB_DEVICE_ID_MATCH_DEVICE,
+ .idVendor = 0x04DD,
+ .idProduct = 0x9032, /* SL-6000 */
+ ZAURUS_FAKE_INTERFACE,
+ .driver_info = 0,
+}, {
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_DEVICE,
.idVendor = 0x04DD,
/* reported with some C860 units */
--- a/drivers/net/usb/zaurus.c
+++ b/drivers/net/usb/zaurus.c
@@ -256,6 +256,11 @@ static const struct usb_device_id produc
.bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, \
.bInterfaceProtocol = USB_CDC_PROTO_NONE

+#define ZAURUS_FAKE_INTERFACE \
+ .bInterfaceClass = USB_CLASS_COMM, \
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_MDLM, \
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE
+
/* SA-1100 based Sharp Zaurus ("collie"), or compatible. */
{
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
@@ -315,6 +320,13 @@ static const struct usb_device_id produc
.driver_info = ZAURUS_PXA_INFO,
}, {
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+ | USB_DEVICE_ID_MATCH_DEVICE,
+ .idVendor = 0x04DD,
+ .idProduct = 0x9032, /* SL-6000 */
+ ZAURUS_FAKE_INTERFACE,
+ .driver_info = (unsigned long)&bogus_mdlm_info,
+}, {
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_DEVICE,
.idVendor = 0x04DD,
/* reported with some C860 units */


2022-02-28 20:17:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 14/53] ping: remove pr_err from ping_lookup

From: Xin Long <[email protected]>

commit cd33bdcbead882c2e58fdb4a54a7bd75b610a452 upstream.

As Jakub noticed, prints should be avoided on the datapath.
Also, as packets would never come to the else branch in
ping_lookup(), remove pr_err() from ping_lookup().

Fixes: 35a79e64de29 ("ping: fix the dif and sdif check in ping_lookup")
Reported-by: Jakub Kicinski <[email protected]>
Signed-off-by: Xin Long <[email protected]>
Link: https://lore.kernel.org/r/1ef3f2fcd31bd681a193b1fcf235eee1603819bd.1645674068.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/ping.c | 1 -
1 file changed, 1 deletion(-)

--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -187,7 +187,6 @@ static struct sock *ping_lookup(struct n
(int)ident, &ipv6_hdr(skb)->daddr, dif);
#endif
} else {
- pr_err("ping: protocol(%x) is not supported\n", ntohs(skb->protocol));
return NULL;
}



2022-02-28 20:20:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 04/53] parisc/unaligned: Fix fldd and fstd unaligned handlers on 32-bit kernel

From: Helge Deller <[email protected]>

commit dd2288f4a020d693360e3e8d72f8b9d9c25f5ef6 upstream.

Usually the kernel provides fixup routines to emulate the fldd and fstd
floating-point instructions if they load or store 8-byte from/to a not
natuarally aligned memory location.

On a 32-bit kernel I noticed that those unaligned handlers didn't worked and
instead the application got a SEGV.
While checking the code I found two problems:

First, the OPCODE_FLDD_L and OPCODE_FSTD_L cases were ifdef'ed out by the
CONFIG_PA20 option, and as such those weren't built on a pure 32-bit kernel.
This is now fixed by moving the CONFIG_PA20 #ifdef to prevent the compilation
of OPCODE_LDD_L and OPCODE_FSTD_L only, and handling the fldd and fstd
instructions.

The second problem are two bugs in the 32-bit inline assembly code, where the
wrong registers where used. The calculation of the natural alignment used %2
(vall) instead of %3 (ior), and the first word was stored back to address %1
(valh) instead of %3 (ior).

Signed-off-by: Helge Deller <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/kernel/unaligned.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/parisc/kernel/unaligned.c
+++ b/arch/parisc/kernel/unaligned.c
@@ -397,7 +397,7 @@ static int emulate_std(struct pt_regs *r
__asm__ __volatile__ (
" mtsp %4, %%sr1\n"
" zdep %2, 29, 2, %%r19\n"
-" dep %%r0, 31, 2, %2\n"
+" dep %%r0, 31, 2, %3\n"
" mtsar %%r19\n"
" zvdepi -2, 32, %%r19\n"
"1: ldw 0(%%sr1,%3),%%r20\n"
@@ -409,7 +409,7 @@ static int emulate_std(struct pt_regs *r
" andcm %%r21, %%r19, %%r21\n"
" or %1, %%r20, %1\n"
" or %2, %%r21, %2\n"
-"3: stw %1,0(%%sr1,%1)\n"
+"3: stw %1,0(%%sr1,%3)\n"
"4: stw %%r1,4(%%sr1,%3)\n"
"5: stw %2,8(%%sr1,%3)\n"
" copy %%r0, %0\n"
@@ -596,7 +596,6 @@ void handle_unaligned(struct pt_regs *re
ret = ERR_NOTHANDLED; /* "undefined", but lets kill them. */
break;
}
-#ifdef CONFIG_PA20
switch (regs->iir & OPCODE2_MASK)
{
case OPCODE_FLDD_L:
@@ -607,14 +606,15 @@ void handle_unaligned(struct pt_regs *re
flop=1;
ret = emulate_std(regs, R2(regs->iir),1);
break;
+#ifdef CONFIG_PA20
case OPCODE_LDD_L:
ret = emulate_ldd(regs, R2(regs->iir),0);
break;
case OPCODE_STD_L:
ret = emulate_std(regs, R2(regs->iir),0);
break;
- }
#endif
+ }
switch (regs->iir & OPCODE3_MASK)
{
case OPCODE_FLDW_L:


2022-02-28 20:21:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 29/53] spi: spi-zynq-qspi: Fix a NULL pointer dereference in zynq_qspi_exec_mem_op()

From: Zhou Qingyang <[email protected]>

[ Upstream commit ab3824427b848da10e9fe2727f035bbeecae6ff4 ]

In zynq_qspi_exec_mem_op(), kzalloc() is directly used in memset(),
which could lead to a NULL pointer dereference on failure of
kzalloc().

Fix this bug by adding a check of tmpbuf.

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_SPI_ZYNQ_QSPI=m show no new warnings,
and our static analyzer no longer warns about this code.

Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller")
Signed-off-by: Zhou Qingyang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/spi/spi-zynq-qspi.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
index 1ced6eb8b3303..b3588240eb39b 100644
--- a/drivers/spi/spi-zynq-qspi.c
+++ b/drivers/spi/spi-zynq-qspi.c
@@ -558,6 +558,9 @@ static int zynq_qspi_exec_mem_op(struct spi_mem *mem,

if (op->dummy.nbytes) {
tmpbuf = kzalloc(op->dummy.nbytes, GFP_KERNEL);
+ if (!tmpbuf)
+ return -ENOMEM;
+
memset(tmpbuf, 0xff, op->dummy.nbytes);
reinit_completion(&xqspi->data_completion);
xqspi->txbuf = tmpbuf;
--
2.34.1



2022-02-28 20:23:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 01/53] cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug

From: Zhang Qiao <[email protected]>

commit 05c7b7a92cc87ff8d7fde189d0fade250697573c upstream.

As previously discussed(https://lkml.org/lkml/2022/1/20/51),
cpuset_attach() is affected with similar cpu hotplug race,
as follow scenario:

cpuset_attach() cpu hotplug
--------------------------- ----------------------
down_write(cpuset_rwsem)
guarantee_online_cpus() // (load cpus_attach)
sched_cpu_deactivate
set_cpu_active()
// will change cpu_active_mask
set_cpus_allowed_ptr(cpus_attach)
__set_cpus_allowed_ptr_locked()
// (if the intersection of cpus_attach and
cpu_active_mask is empty, will return -EINVAL)
up_write(cpuset_rwsem)

To avoid races such as described above, protect cpuset_attach() call
with cpu_hotplug_lock.

Fixes: be367d099270 ("cgroups: let ss->can_attach and ss->attach do whole threadgroups at a time")
Cc: [email protected] # v2.6.32+
Reported-by: Zhao Gongyi <[email protected]>
Signed-off-by: Zhang Qiao <[email protected]>
Acked-by: Waiman Long <[email protected]>
Reviewed-by: Michal Koutný <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/cgroup/cpuset.c | 2 ++
1 file changed, 2 insertions(+)

--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -2204,6 +2204,7 @@ static void cpuset_attach(struct cgroup_
cgroup_taskset_first(tset, &css);
cs = css_cs(css);

+ cpus_read_lock();
percpu_down_write(&cpuset_rwsem);

/* prepare for attach */
@@ -2259,6 +2260,7 @@ static void cpuset_attach(struct cgroup_
wake_up(&cpuset_attach_wq);

percpu_up_write(&cpuset_rwsem);
+ cpus_read_unlock();
}

/* The various types of files and directories in a cpuset file system */


2022-02-28 20:23:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 33/53] iio: adc: men_z188_adc: Fix a resource leak in an error handling path

From: Christophe JAILLET <[email protected]>

commit e0a2e37f303828d030a83f33ffe14b36cb88d563 upstream.

If iio_device_register() fails, a previous ioremap() is left unbalanced.

Update the error handling path and add the missing iounmap() call, as
already done in the remove function.

Fixes: 74aeac4da66f ("iio: adc: Add MEN 16z188 ADC driver")
Signed-off-by: Christophe JAILLET <[email protected]>
Link: https://lore.kernel.org/r/320fc777863880247c2aff4a9d1a54ba69abf080.1643445149.git.christophe.jaillet@wanadoo.fr
Cc: <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iio/adc/men_z188_adc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/iio/adc/men_z188_adc.c
+++ b/drivers/iio/adc/men_z188_adc.c
@@ -103,6 +103,7 @@ static int men_z188_probe(struct mcb_dev
struct z188_adc *adc;
struct iio_dev *indio_dev;
struct resource *mem;
+ int ret;

indio_dev = devm_iio_device_alloc(&dev->dev, sizeof(struct z188_adc));
if (!indio_dev)
@@ -129,8 +130,14 @@ static int men_z188_probe(struct mcb_dev
adc->mem = mem;
mcb_set_drvdata(dev, indio_dev);

- return iio_device_register(indio_dev);
+ ret = iio_device_register(indio_dev);
+ if (ret)
+ goto err_unmap;

+ return 0;
+
+err_unmap:
+ iounmap(adc->base);
err:
mcb_release_mem(mem);
return -ENXIO;


2022-02-28 20:25:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.4 37/53] Revert "USB: serial: ch341: add new Product ID for CH341A"

From: Dmytro Bagrii <[email protected]>

commit 198a7ebd5fa17b4d0be8cb70240ee1be885175c0 upstream.

This reverts commit 46ee4abb10a07bd8f8ce910ee6b4ae6a947d7f63.

CH341 has Product ID 0x5512 in EPP/MEM mode which is used for
I2C/SPI/GPIO interfaces. In asynchronous serial interface mode
CH341 has PID 0x5523 which is already in the table.

Mode is selected by corresponding jumper setting.

Signed-off-by: Dmytro Bagrii <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/YJ0OCS/sh+1ifD/[email protected]
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/ch341.c | 1 -
1 file changed, 1 deletion(-)

--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -80,7 +80,6 @@
#define CH341_LCR_CS5 0x00

static const struct usb_device_id id_table[] = {
- { USB_DEVICE(0x1a86, 0x5512) },
{ USB_DEVICE(0x1a86, 0x5523) },
{ USB_DEVICE(0x1a86, 0x7522) },
{ USB_DEVICE(0x1a86, 0x7523) },


2022-02-28 21:48:50

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/53] 5.4.182-rc1 review

On 2/28/22 10:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.182 release.
> There are 53 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, 02 Mar 2022 17:20:16 +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.182-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

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

thanks,
-- Shuah

2022-03-01 02:10:47

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/53] 5.4.182-rc1 review



On 2/28/2022 9:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.182 release.
> There are 53 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, 02 Mar 2022 17:20:16 +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.182-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

2022-03-01 19:04:53

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/53] 5.4.182-rc1 review

On Mon, 28 Feb 2022 at 23:01, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.182 release.
> There are 53 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, 02 Mar 2022 17:20:16 +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.182-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.182-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.4.y
* git commit: aa9d24e3c1088399a4cd2b031c4c6abee5d58a60
* git describe: v5.4.181-54-gaa9d24e3c108
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.181-54-gaa9d24e3c108

## Test Regressions (compared to v5.4.181)
No test regressions found.

## Metric Regressions (compared to v5.4.181)
No metric regressions found.

## Test Fixes (compared to v5.4.181)
No test fixes found.

## Metric Fixes (compared to v5.4.181)
No metric fixes found.

## Test result summary
total: 94463, pass: 80146, fail: 534, skip: 12639, xfail: 1144

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 290 total, 290 passed, 0 failed
* arm64: 41 total, 32 passed, 9 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 20 total, 20 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 37 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 60 total, 49 passed, 11 failed
* riscv: 27 total, 27 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 40 total, 40 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-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
* vdso

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

2022-03-01 19:48:12

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/53] 5.4.182-rc1 review

Hi Greg,

On Mon, Feb 28, 2022 at 06:23:58PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.182 release.
> There are 53 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, 02 Mar 2022 17:20:16 +0000.
> Anything received after that time might be too late.

Build test:
mips (gcc version 11.2.1 20220213): 65 configs -> no failure
arm (gcc version 11.2.1 20220213): 107 configs -> no new failure
arm64 (gcc version 11.2.1 20220213): 2 configs -> no failure
x86_64 (gcc version 11.2.1 20220213): 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/820


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

--
Regards
Sudip

2022-03-01 20:17:22

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/53] 5.4.182-rc1 review

On Mon, Feb 28, 2022 at 06:23:58PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.182 release.
> There are 53 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, 02 Mar 2022 17:20:16 +0000.
> Anything received after that time might be too late.
>

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

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

Guenter

2022-03-02 18:41:32

by Slade's Kernel Patch Bot

[permalink] [raw]
Subject: Re: [PATCH 5.4 00/53] 5.4.182-rc1 review

On Mon, Feb 28, 2022, at 12:23 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.182 release.
> There are 53 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, 02 Mar 2022 17:20:16 +0000.
> Anything received after that time might be too late.

5.4.182-rc1 compiled and booted with no errors or regressions on my x86_64 test system.

Tested-by: Slade Watkins <[email protected]>

Cheers,
Slade