2021-01-22 15:00:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 00/43] 5.10.10-rc1 review

This is the start of the stable review cycle for the 5.10.10 release.
There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
Anything received after that time might be too late.

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

thanks,

greg k-h

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

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

Michael Hennerich <[email protected]>
spi: cadence: cache reference clock rate during probe

Christophe Leroy <[email protected]>
spi: fsl: Fix driver breakage when SPI_CS_HIGH is not set in spi->mode

Ayush Sawal <[email protected]>
cxgb4/chtls: Fix tid stuck due to wrong update of qid

Vladimir Oltean <[email protected]>
net: dsa: unbind all switches from tree when DSA master unbinds

Lorenzo Bianconi <[email protected]>
mac80211: check if atf has been disabled in __ieee80211_schedule_txq

Felix Fietkau <[email protected]>
mac80211: do not drop tx nulldata packets on encrypted links

Antonio Borneo <[email protected]>
drm/panel: otm8009a: allow using non-continuous dsi clock

Qinglang Miao <[email protected]>
can: mcp251xfd: mcp251xfd_handle_rxif_one(): fix wrong NULL pointer check

Seb Laveze <[email protected]>
net: stmmac: use __napi_schedule() for PREEMPT_RT

David Howells <[email protected]>
rxrpc: Fix handling of an unsupported token type in rxrpc_read()

Vladimir Oltean <[email protected]>
net: dsa: clear devlink port type before unregistering slave netdevs

Marco Felsch <[email protected]>
net: phy: smsc: fix clk error handling

Geert Uytterhoeven <[email protected]>
dt-bindings: net: renesas,etheravb: RZ/G2H needs tx-internal-delay-ps

Eric Dumazet <[email protected]>
net: avoid 32 x truesize under-estimation for tiny skbs

Yannick Vignon <[email protected]>
net: stmmac: fix taprio configuration when base_time is in the past

Yannick Vignon <[email protected]>
net: stmmac: fix taprio schedule configuration

Jakub Kicinski <[email protected]>
net: sit: unregister_netdevice on newlink's error path

David Wu <[email protected]>
net: stmmac: Fixed mtu channged by cache aligned

Cristian Dumitrescu <[email protected]>
i40e: fix potential NULL pointer dereferencing

Baptiste Lepers <[email protected]>
rxrpc: Call state should be read with READ_ONCE() under some circumstances

Petr Machata <[email protected]>
net: dcb: Accept RTM_GETDCB messages carrying set-like DCB commands

Petr Machata <[email protected]>
net: dcb: Validate netlink message in DCB handler

Willem de Bruijn <[email protected]>
esp: avoid unneeded kmap_atomic call

Andrey Zhizhikin <[email protected]>
rndis_host: set proper input size for OID_GEN_PHYSICAL_MEDIUM request

Stefan Chulski <[email protected]>
net: mvpp2: Remove Pause and Asym_Pause support

Vadim Pasternak <[email protected]>
mlxsw: core: Increase critical threshold for ASIC thermal zone

Vadim Pasternak <[email protected]>
mlxsw: core: Add validation of transceiver temperature thresholds

Hoang Le <[email protected]>
tipc: fix NULL deref in tipc_link_xmit()

Aya Levin <[email protected]>
net: ipv6: Validate GSO SKB before finish IPv6 processing

Manish Chopra <[email protected]>
netxen_nic: fix MSI/MSI-x interrupts

Baptiste Lepers <[email protected]>
udp: Prevent reuseport_select_sock from reading uninitialized socks

Dongseok Yi <[email protected]>
net: fix use-after-free when UDP GRO with shared fraglist

Stephan Gerhold <[email protected]>
net: ipa: modem: add missing SET_NETDEV_DEV() for proper sysfs links

Mircea Cirjaliu <[email protected]>
bpf: Fix helper bpf_map_peek_elem_proto pointing to wrong callback

Gilad Reti <[email protected]>
bpf: Support PTR_TO_MEM{,_OR_NULL} register spilling

Stanislav Fomichev <[email protected]>
bpf: Don't leak memory in bpf getsockopt when optlen == 0

J. Bruce Fields <[email protected]>
nfsd4: readdirplus shouldn't return parent of export

Tianjia Zhang <[email protected]>
X.509: Fix crash caused by NULL pointer

Daniel Borkmann <[email protected]>
bpf: Fix signed_{sub,add32}_overflows type handling

Alex Deucher <[email protected]>
drm/amdgpu/display: drop DCN support for aarch64

Dexuan Cui <[email protected]>
x86/hyperv: Initialize clockevents after LAPIC is initialized

Andrei Matei <[email protected]>
bpf: Fix selftest compilation on clang 11

Greg Kroah-Hartman <[email protected]>
Revert "kconfig: remove 'kvmconfig' and 'xenconfig' shorthands"


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

Diffstat:

.../devicetree/bindings/net/renesas,etheravb.yaml | 1 +
Makefile | 4 +-
arch/x86/hyperv/hv_init.c | 29 +++++++-
crypto/asymmetric_keys/public_key.c | 3 +-
drivers/gpu/drm/amd/display/Kconfig | 2 +-
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 7 --
drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile | 7 --
drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 --
.../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 81 +++++++++-------------
drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 --
drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 --
drivers/gpu/drm/amd/display/dc/dml/Makefile | 13 ----
drivers/gpu/drm/amd/display/dc/dsc/Makefile | 5 --
drivers/gpu/drm/amd/display/dc/os_types.h | 4 --
drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 2 +-
drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/t4_tcb.h | 7 ++
.../ethernet/chelsio/inline_crypto/chtls/chtls.h | 4 ++
.../chelsio/inline_crypto/chtls/chtls_cm.c | 32 ++++++++-
.../chelsio/inline_crypto/chtls/chtls_hw.c | 41 +++++++++++
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 2 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 -
drivers/net/ethernet/mellanox/mlxsw/core_thermal.c | 13 ++--
.../net/ethernet/qlogic/netxen/netxen_nic_main.c | 7 +-
drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 52 ++------------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c | 20 +++++-
drivers/net/ipa/ipa_modem.c | 1 +
drivers/net/phy/smsc.c | 3 +-
drivers/net/usb/rndis_host.c | 2 +-
drivers/spi/spi-cadence.c | 6 +-
drivers/spi/spi-fsl-spi.c | 5 +-
fs/nfsd/nfs3xdr.c | 7 +-
kernel/bpf/cgroup.c | 5 +-
kernel/bpf/helpers.c | 2 +-
kernel/bpf/verifier.c | 8 ++-
net/core/skbuff.c | 29 +++++++-
net/core/sock_reuseport.c | 2 +-
net/dcb/dcbnl.c | 2 +
net/dsa/dsa2.c | 4 ++
net/dsa/master.c | 10 +++
net/ipv4/esp4.c | 7 +-
net/ipv6/esp6.c | 7 +-
net/ipv6/ip6_output.c | 41 ++++++++++-
net/ipv6/sit.c | 5 +-
net/mac80211/tx.c | 4 +-
net/rxrpc/input.c | 2 +-
net/rxrpc/key.c | 6 +-
net/tipc/link.c | 9 ++-
scripts/kconfig/Makefile | 10 +++
tools/testing/selftests/bpf/progs/profiler.inc.h | 2 +
51 files changed, 323 insertions(+), 218 deletions(-)



2021-01-22 15:01:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 29/43] net: stmmac: fix taprio configuration when base_time is in the past

From: Yannick Vignon <[email protected]>

[ Upstream commit fe28c53ed71d463e187748b6b10e1130dd72ceeb ]

The Synopsys TSN MAC supports Qbv base times in the past, but only up to a
certain limit. As a result, a taprio qdisc configuration with a small
base time (for example when treating the base time as a simple phase
offset) is not applied by the hardware and silently ignored.

This was observed on an NXP i.MX8MPlus device, but likely affects all
TSN-variants of the MAC.

Fix the issue by making sure the base time is in the future, pushing it by
an integer amount of cycle times if needed. (a similar check is already
done in several other taprio implementations, see for example
drivers/net/ethernet/intel/igc/igc_tsn.c#L116 or
drivers/net/dsa/sja1105/sja1105_ptp.h#L39).

Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API")
Signed-off-by: Yannick Vignon <[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/stmicro/stmmac/stmmac_tc.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
@@ -605,7 +605,8 @@ static int tc_setup_taprio(struct stmmac
{
u32 size, wid = priv->dma_cap.estwid, dep = priv->dma_cap.estdep;
struct plat_stmmacenet_data *plat = priv->plat;
- struct timespec64 time;
+ struct timespec64 time, current_time;
+ ktime_t current_time_ns;
bool fpe = false;
int i, ret = 0;
u64 ctr;
@@ -700,7 +701,22 @@ static int tc_setup_taprio(struct stmmac
}

/* Adjust for real system time */
- time = ktime_to_timespec64(qopt->base_time);
+ priv->ptp_clock_ops.gettime64(&priv->ptp_clock_ops, &current_time);
+ current_time_ns = timespec64_to_ktime(current_time);
+ if (ktime_after(qopt->base_time, current_time_ns)) {
+ time = ktime_to_timespec64(qopt->base_time);
+ } else {
+ ktime_t base_time;
+ s64 n;
+
+ n = div64_s64(ktime_sub_ns(current_time_ns, qopt->base_time),
+ qopt->cycle_time);
+ base_time = ktime_add_ns(qopt->base_time,
+ (n + 1) * qopt->cycle_time);
+
+ time = ktime_to_timespec64(base_time);
+ }
+
priv->plat->est->btr[0] = (u32)time.tv_nsec;
priv->plat->est->btr[1] = (u32)time.tv_sec;



2021-01-22 15:01:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 09/43] bpf: Support PTR_TO_MEM{,_OR_NULL} register spilling

From: Gilad Reti <[email protected]>

commit 744ea4e3885eccb6d332a06fae9eb7420a622c0f upstream.

Add support for pointer to mem register spilling, to allow the verifier
to track pointers to valid memory addresses. Such pointers are returned
for example by a successful call of the bpf_ringbuf_reserve helper.

The patch was partially contributed by CyberArk Software, Inc.

Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
Suggested-by: Yonghong Song <[email protected]>
Signed-off-by: Gilad Reti <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Acked-by: KP Singh <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/bpf/verifier.c | 2 ++
1 file changed, 2 insertions(+)

--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2214,6 +2214,8 @@ static bool is_spillable_regtype(enum bp
case PTR_TO_RDWR_BUF:
case PTR_TO_RDWR_BUF_OR_NULL:
case PTR_TO_PERCPU_BTF_ID:
+ case PTR_TO_MEM:
+ case PTR_TO_MEM_OR_NULL:
return true;
default:
return false;


2021-01-22 15:02:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 08/43] bpf: Dont leak memory in bpf getsockopt when optlen == 0

From: Stanislav Fomichev <[email protected]>

commit 4be34f3d0731b38a1b24566b37fbb39500aaf3a2 upstream.

optlen == 0 indicates that the kernel should ignore BPF buffer
and use the original one from the user. We, however, forget
to free the temporary buffer that we've allocated for BPF.

Fixes: d8fe449a9c51 ("bpf: Don't return EINVAL from {get,set}sockopt when optlen > PAGE_SIZE")
Reported-by: Martin KaFai Lau <[email protected]>
Signed-off-by: Stanislav Fomichev <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Martin KaFai Lau <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/bpf/cgroup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1391,12 +1391,13 @@ int __cgroup_bpf_run_filter_setsockopt(s
if (ctx.optlen != 0) {
*optlen = ctx.optlen;
*kernel_optval = ctx.optval;
+ /* export and don't free sockopt buf */
+ return 0;
}
}

out:
- if (ret)
- sockopt_free_buf(&ctx);
+ sockopt_free_buf(&ctx);
return ret;
}



2021-01-22 15:02:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 13/43] udp: Prevent reuseport_select_sock from reading uninitialized socks

From: Baptiste Lepers <[email protected]>

[ Upstream commit fd2ddef043592e7de80af53f47fa46fd3573086e ]

reuse->socks[] is modified concurrently by reuseport_add_sock. To
prevent reading values that have not been fully initialized, only read
the array up until the last known safe index instead of incorrectly
re-reading the last index of the array.

Fixes: acdcecc61285f ("udp: correct reuseport selection with connected sockets")
Signed-off-by: Baptiste Lepers <[email protected]>
Acked-by: Willem de Bruijn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/sock_reuseport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/core/sock_reuseport.c
+++ b/net/core/sock_reuseport.c
@@ -293,7 +293,7 @@ select_by_hash:
i = j = reciprocal_scale(hash, socks);
while (reuse->socks[i]->sk_state == TCP_ESTABLISHED) {
i++;
- if (i >= reuse->num_socks)
+ if (i >= socks)
i = 0;
if (i == j)
goto out;


2021-01-22 15:04:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 30/43] net: avoid 32 x truesize under-estimation for tiny skbs

From: Eric Dumazet <[email protected]>

[ Upstream commit 3226b158e67cfaa677fd180152bfb28989cb2fac ]

Both virtio net and napi_get_frags() allocate skbs
with a very small skb->head

While using page fragments instead of a kmalloc backed skb->head might give
a small performance improvement in some cases, there is a huge risk of
under estimating memory usage.

For both GOOD_COPY_LEN and GRO_MAX_HEAD, we can fit at least 32 allocations
per page (order-3 page in x86), or even 64 on PowerPC

We have been tracking OOM issues on GKE hosts hitting tcp_mem limits
but consuming far more memory for TCP buffers than instructed in tcp_mem[2]

Even if we force napi_alloc_skb() to only use order-0 pages, the issue
would still be there on arches with PAGE_SIZE >= 32768

This patch makes sure that small skb head are kmalloc backed, so that
other objects in the slab page can be reused instead of being held as long
as skbs are sitting in socket queues.

Note that we might in the future use the sk_buff napi cache,
instead of going through a more expensive __alloc_skb()

Another idea would be to use separate page sizes depending
on the allocated length (to never have more than 4 frags per page)

I would like to thank Greg Thelen for his precious help on this matter,
analysing crash dumps is always a time consuming task.

Fixes: fd11a83dd363 ("net: Pull out core bits of __netdev_alloc_skb and add __napi_alloc_skb")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Paolo Abeni <[email protected]>
Cc: Greg Thelen <[email protected]>
Reviewed-by: Alexander Duyck <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/skbuff.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -496,13 +496,17 @@ EXPORT_SYMBOL(__netdev_alloc_skb);
struct sk_buff *__napi_alloc_skb(struct napi_struct *napi, unsigned int len,
gfp_t gfp_mask)
{
- struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache);
+ struct napi_alloc_cache *nc;
struct sk_buff *skb;
void *data;

len += NET_SKB_PAD + NET_IP_ALIGN;

- if ((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) ||
+ /* If requested length is either too small or too big,
+ * we use kmalloc() for skb->head allocation.
+ */
+ if (len <= SKB_WITH_OVERHEAD(1024) ||
+ len > SKB_WITH_OVERHEAD(PAGE_SIZE) ||
(gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) {
skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE);
if (!skb)
@@ -510,6 +514,7 @@ struct sk_buff *__napi_alloc_skb(struct
goto skb_success;
}

+ nc = this_cpu_ptr(&napi_alloc_cache);
len += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
len = SKB_DATA_ALIGN(len);



2021-01-22 15:04:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.10 32/43] net: phy: smsc: fix clk error handling

From: Marco Felsch <[email protected]>

[ Upstream commit a18caa97b1bda0a3d126a7be165ddcfc56c2dde6 ]

Commit bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in
support") added the phy clk support. The commit already checks if
clk_get_optional() throw an error but instead of returning the error it
ignores it.

Fixes: bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in support")
Suggested-by: Jakub Kicinski <[email protected]>
Signed-off-by: Marco Felsch <[email protected]>
Reviewed-by: Andrew Lunn <[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/phy/smsc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -284,7 +284,8 @@ static int smsc_phy_probe(struct phy_dev
/* Make clk optional to keep DTB backward compatibility. */
priv->refclk = clk_get_optional(dev, NULL);
if (IS_ERR(priv->refclk))
- dev_err_probe(dev, PTR_ERR(priv->refclk), "Failed to request clock\n");
+ return dev_err_probe(dev, PTR_ERR(priv->refclk),
+ "Failed to request clock\n");

ret = clk_prepare_enable(priv->refclk);
if (ret)


2021-01-23 00:27:16

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On 1/22/21 7:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.10 release.
> There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.10-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

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

thanks,
-- Shuah

2021-01-23 05:48:29

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On Fri, 22 Jan 2021 at 19:49, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.10.10 release.
> There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.10-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

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

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

kernel: 5.10.10-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.10.y
git commit: 402284178c914c87fd7b41bc9bd93f2772c43904
git describe: v5.10.9-44-g402284178c91
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.9-44-g402284178c91


No regressions (compared to build v5.10.9)


No fixes (compared to build v5.10.9)

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

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- x15
- x86
- x86-kasan

Test Suites
-----------
* build
* igt-gpu-tools
* install-android-platform-tools-r2600
* libhugetlbfs
* linux-log-parser
* ltp-commands-tests
* ltp-containers-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-sched-tests
* ltp-tracing-tests
* fwts
* kselftest
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* ltp-controllers-tests
* ltp-open-posix-tests
* v4l2-compliance
* kvm-unit-tests
* kunit
* rcutorture
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

2021-01-23 07:23:37

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On Sat, 23 Jan 2021 at 11:14, Naresh Kamboju <[email protected]> wrote:
>
> On Fri, 22 Jan 2021 at 19:49, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.10.10 release.
> > There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.10-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

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

>
> Summary
> ------------------------------------------------------------------------
>
> kernel: 5.10.10-rc1
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> git branch: linux-5.10.y
> git commit: 402284178c914c87fd7b41bc9bd93f2772c43904
> git describe: v5.10.9-44-g402284178c91
> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.9-44-g402284178c91
>
>
> No regressions (compared to build v5.10.9)
>
>
> No fixes (compared to build v5.10.9)
>
> Ran 55124 total tests in the following environments and test suites.
>
> Environments
> --------------
> - dragonboard-410c
> - hi6220-hikey
> - i386
> - juno-r2
> - juno-r2-compat
> - juno-r2-kasan
> - nxp-ls2088
> - qemu-arm-clang
> - qemu-arm64-clang
> - qemu-arm64-kasan
> - qemu-i386-clang
> - qemu-x86_64-clang
> - qemu-x86_64-kasan
> - qemu-x86_64-kcsan
> - qemu_arm
> - qemu_arm64
> - qemu_arm64-compat
> - qemu_i386
> - qemu_x86_64
> - qemu_x86_64-compat
> - x15
> - x86
> - x86-kasan
>
> Test Suites
> -----------
> * build
> * igt-gpu-tools
> * install-android-platform-tools-r2600
> * libhugetlbfs
> * linux-log-parser
> * ltp-commands-tests
> * ltp-containers-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-sched-tests
> * ltp-tracing-tests
> * fwts
> * kselftest
> * ltp-cap_bounds-tests
> * ltp-cpuhotplug-tests
> * ltp-crypto-tests
> * ltp-nptl-tests
> * ltp-pty-tests
> * ltp-securebits-tests
> * ltp-syscalls-tests
> * network-basic-tests
> * perf
> * ltp-controllers-tests
> * ltp-open-posix-tests
> * v4l2-compliance
> * kvm-unit-tests
> * kunit
> * rcutorture
> * kselftest-vsyscall-mode-native
> * kselftest-vsyscall-mode-none
>
> --
> Linaro LKFT
> https://lkft.linaro.org

2021-01-23 09:55:36

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

Hi!

> This is the start of the stable review cycle for the 5.10.10 release.
> There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> Anything received after that time might be too late.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (784.00 B)
signature.asc (188.00 B)
Digital signature
Download all attachments

2021-01-23 14:40:22

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On Fri, Jan 22, 2021 at 03:12:16PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.10 release.
> There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> Anything received after that time might be too late.
>

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

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

Guenter

2021-01-23 15:08:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On Fri, Jan 22, 2021 at 05:24:01PM -0700, Shuah Khan wrote:
> On 1/22/21 7:12 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.10 release.
> > There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.10-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
>
> Tested-by: Shuah Khan <[email protected]>

Thanks for testing these and letting me know.

greg k-h

2021-01-23 15:09:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On Sat, Jan 23, 2021 at 12:50:24PM +0530, Naresh Kamboju wrote:
> On Sat, 23 Jan 2021 at 11:14, Naresh Kamboju <[email protected]> wrote:
> >
> > On Fri, 22 Jan 2021 at 19:49, Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > This is the start of the stable review cycle for the 5.10.10 release.
> > > There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.10-rc1.gz
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Results from Linaro’s test farm.
> > No regressions on arm64, arm, x86_64, and i386.
>
> Tested-by: Linux Kernel Functional Testing <[email protected]>

Thanks for testing them all and letting me know.

greg k-h

2021-01-23 15:09:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On Sat, Jan 23, 2021 at 10:52:45AM +0100, Pavel Machek wrote:
> Hi!
>
> > This is the start of the stable review cycle for the 5.10.10 release.
> > There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> > Anything received after that time might be too late.
>
> CIP testing did not find any problems here:
>
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
>
> Tested-by: Pavel Machek (CIP) <[email protected]>

Thanks for testing some of these and letting me know.

greg k-h

2021-01-23 15:12:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.10 00/43] 5.10.10-rc1 review

On Sat, Jan 23, 2021 at 06:36:01AM -0800, Guenter Roeck wrote:
> On Fri, Jan 22, 2021 at 03:12:16PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.10 release.
> > There are 43 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 Sun, 24 Jan 2021 13:57:23 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 154 pass: 154 fail: 0
> Qemu test results:
> total: 427 pass: 427 fail: 0
>
> Tested-by: Guenter Roeck <[email protected]>

Thanks for testing them all and letting me know.

greg k-h