-------------------
Note, ok, this is really going to be the final 5.7.y kernel release. I
mean it this time....
-------------------
This is the start of the stable review cycle for the 5.7.19 release.
There are 15 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Fri, 28 Aug 2020 11:48:35 +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.7.19-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.7.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.7.19-rc1
Max Filippov <[email protected]>
binfmt_flat: revert "binfmt_flat: don't offset the data start"
Michael Ellerman <[email protected]>
powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()
Maxim Mikityanskiy <[email protected]>
ethtool: Don't omit the netlink reply if no features were changed
Maxim Mikityanskiy <[email protected]>
ethtool: Account for hw_features in netlink interface
Maxim Mikityanskiy <[email protected]>
ethtool: Fix preserving of wanted feature bits in netlink interface
Shay Agroskin <[email protected]>
net: ena: Make missed_tx stat incremental
Cong Wang <[email protected]>
tipc: fix uninit skb->data in tipc_nl_compat_dumpit()
Xin Long <[email protected]>
tipc: call rcu_read_lock() in tipc_aead_encrypt_done()
Peilin Ye <[email protected]>
net/smc: Prevent kernel-infoleak in __smc_diag_dump()
David Laight <[email protected]>
net: sctp: Fix negotiation of the number of data streams.
Alaa Hleihel <[email protected]>
net/sched: act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow
Necip Fazil Yildiran <[email protected]>
net: qrtr: fix usage of idr in port assignment to socket
Nikolay Aleksandrov <[email protected]>
net: nexthop: don't allow empty NHA_GROUP
Miaohe Lin <[email protected]>
net: Fix potential wrong skb->protocol in skb_vlan_untag()
Mark Tomlinson <[email protected]>
gre6: Fix reception with IP6_TNL_F_RCV_DSCP_COPY
-------------
Diffstat:
Makefile | 4 ++--
arch/powerpc/kernel/cpu_setup_power.S | 2 +-
drivers/net/ethernet/amazon/ena/ena_netdev.c | 5 ++++-
fs/binfmt_flat.c | 20 ++++++++++++--------
net/core/skbuff.c | 4 ++--
net/ethtool/features.c | 19 ++++++++++---------
net/ipv4/nexthop.c | 5 ++++-
net/ipv6/ip6_tunnel.c | 10 +++++++++-
net/qrtr/qrtr.c | 20 +++++++++++---------
net/sched/act_ct.c | 2 +-
net/sctp/stream.c | 6 ++++--
net/smc/smc_diag.c | 16 +++++++++-------
net/tipc/crypto.c | 2 ++
net/tipc/netlink_compat.c | 12 +++++++++++-
14 files changed, 82 insertions(+), 45 deletions(-)
From: Xin Long <[email protected]>
[ Upstream commit f6db9096416209474090d64d8284e7c16c3d8873 ]
b->media->send_msg() requires rcu_read_lock(), as we can see
elsewhere in tipc, tipc_bearer_xmit, tipc_bearer_xmit_skb
and tipc_bearer_bc_xmit().
Syzbot has reported this issue as:
net/tipc/bearer.c:466 suspicious rcu_dereference_check() usage!
Workqueue: cryptd cryptd_queue_worker
Call Trace:
tipc_l2_send_msg+0x354/0x420 net/tipc/bearer.c:466
tipc_aead_encrypt_done+0x204/0x3a0 net/tipc/crypto.c:761
cryptd_aead_crypt+0xe8/0x1d0 crypto/cryptd.c:739
cryptd_queue_worker+0x118/0x1b0 crypto/cryptd.c:181
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
So fix it by calling rcu_read_lock() in tipc_aead_encrypt_done()
for b->media->send_msg().
Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
Reported-by: [email protected]
Signed-off-by: Xin Long <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tipc/crypto.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -757,10 +757,12 @@ static void tipc_aead_encrypt_done(struc
switch (err) {
case 0:
this_cpu_inc(tx->stats->stat[STAT_ASYNC_OK]);
+ rcu_read_lock();
if (likely(test_bit(0, &b->up)))
b->media->send_msg(net, skb, b, &tx_ctx->dst);
else
kfree_skb(skb);
+ rcu_read_unlock();
break;
case -EINPROGRESS:
return;
From: Cong Wang <[email protected]>
[ Upstream commit 47733f9daf4fe4f7e0eb9e273f21ad3a19130487 ]
__tipc_nl_compat_dumpit() has two callers, and it expects them to
pass a valid nlmsghdr via arg->data. This header is artificial and
crafted just for __tipc_nl_compat_dumpit().
tipc_nl_compat_publ_dump() does so by putting a genlmsghdr as well
as some nested attribute, TIPC_NLA_SOCK. But the other caller
tipc_nl_compat_dumpit() does not, this leaves arg->data uninitialized
on this call path.
Fix this by just adding a similar nlmsghdr without any payload in
tipc_nl_compat_dumpit().
This bug exists since day 1, but the recent commit 6ea67769ff33
("net: tipc: prepare attrs in __tipc_nl_compat_dumpit()") makes it
easier to appear.
Reported-and-tested-by: [email protected]
Fixes: d0796d1ef63d ("tipc: convert legacy nl bearer dump to nl compat")
Cc: Jon Maloy <[email protected]>
Cc: Ying Xue <[email protected]>
Cc: Richard Alpe <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Acked-by: Ying Xue <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tipc/netlink_compat.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/net/tipc/netlink_compat.c
+++ b/net/tipc/netlink_compat.c
@@ -275,8 +275,9 @@ err_out:
static int tipc_nl_compat_dumpit(struct tipc_nl_compat_cmd_dump *cmd,
struct tipc_nl_compat_msg *msg)
{
- int err;
+ struct nlmsghdr *nlh;
struct sk_buff *arg;
+ int err;
if (msg->req_type && (!msg->req_size ||
!TLV_CHECK_TYPE(msg->req, msg->req_type)))
@@ -305,6 +306,15 @@ static int tipc_nl_compat_dumpit(struct
return -ENOMEM;
}
+ nlh = nlmsg_put(arg, 0, 0, tipc_genl_family.id, 0, NLM_F_MULTI);
+ if (!nlh) {
+ kfree_skb(arg);
+ kfree_skb(msg->rep);
+ msg->rep = NULL;
+ return -EMSGSIZE;
+ }
+ nlmsg_end(arg, nlh);
+
err = __tipc_nl_compat_dumpit(cmd, msg, arg);
if (err) {
kfree_skb(msg->rep);
From: Max Filippov <[email protected]>
commit 2217b982624680d19a80ebb4600d05c8586c4f96 upstream.
binfmt_flat loader uses the gap between text and data to store data
segment pointers for the libraries. Even in the absence of shared
libraries it stores at least one pointer to the executable's own data
segment. Text and data can go back to back in the flat binary image and
without offsetting data segment last few instructions in the text
segment may get corrupted by the data segment pointer.
Fix it by reverting commit a2357223c50a ("binfmt_flat: don't offset the
data start").
Cc: [email protected]
Fixes: a2357223c50a ("binfmt_flat: don't offset the data start")
Signed-off-by: Max Filippov <[email protected]>
Signed-off-by: Greg Ungerer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/binfmt_flat.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -571,7 +571,7 @@ static int load_flat_file(struct linux_b
goto err;
}
- len = data_len + extra;
+ len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
realdatastart = vm_mmap(NULL, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
@@ -585,7 +585,9 @@ static int load_flat_file(struct linux_b
vm_munmap(textpos, text_len);
goto err;
}
- datapos = ALIGN(realdatastart, FLAT_DATA_ALIGN);
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(unsigned long),
+ FLAT_DATA_ALIGN);
pr_debug("Allocated data+bss+stack (%u bytes): %lx\n",
data_len + bss_len + stack_len, datapos);
@@ -615,7 +617,7 @@ static int load_flat_file(struct linux_b
memp_size = len;
} else {
- len = text_len + data_len + extra;
+ len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(u32);
len = PAGE_ALIGN(len);
textpos = vm_mmap(NULL, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0);
@@ -630,7 +632,9 @@ static int load_flat_file(struct linux_b
}
realdatastart = textpos + ntohl(hdr->data_start);
- datapos = ALIGN(realdatastart, FLAT_DATA_ALIGN);
+ datapos = ALIGN(realdatastart +
+ MAX_SHARED_LIBS * sizeof(u32),
+ FLAT_DATA_ALIGN);
reloc = (__be32 __user *)
(datapos + (ntohl(hdr->reloc_start) - text_len));
@@ -647,9 +651,8 @@ static int load_flat_file(struct linux_b
(text_len + full_data
- sizeof(struct flat_hdr)),
0);
- if (datapos != realdatastart)
- memmove((void *)datapos, (void *)realdatastart,
- full_data);
+ memmove((void *) datapos, (void *) realdatastart,
+ full_data);
#else
/*
* This is used on MMU systems mainly for testing.
@@ -705,7 +708,8 @@ static int load_flat_file(struct linux_b
if (IS_ERR_VALUE(result)) {
ret = result;
pr_err("Unable to read code+data+bss, errno %d\n", ret);
- vm_munmap(textpos, text_len + data_len + extra);
+ vm_munmap(textpos, text_len + data_len + extra +
+ MAX_SHARED_LIBS * sizeof(u32));
goto err;
}
}
From: Mark Tomlinson <[email protected]>
[ Upstream commit 272502fcb7cda01ab07fc2fcff82d1d2f73d43cc ]
When receiving an IPv4 packet inside an IPv6 GRE packet, and the
IP6_TNL_F_RCV_DSCP_COPY flag is set on the tunnel, the IPv4 header would
get corrupted. This is due to the common ip6_tnl_rcv() function assuming
that the inner header is always IPv6. This patch checks the tunnel
protocol for IPv4 inner packets, but still defaults to IPv6.
Fixes: 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE functions")
Signed-off-by: Mark Tomlinson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_tunnel.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -886,7 +886,15 @@ int ip6_tnl_rcv(struct ip6_tnl *t, struc
struct metadata_dst *tun_dst,
bool log_ecn_err)
{
- return __ip6_tnl_rcv(t, skb, tpi, tun_dst, ip6ip6_dscp_ecn_decapsulate,
+ int (*dscp_ecn_decapsulate)(const struct ip6_tnl *t,
+ const struct ipv6hdr *ipv6h,
+ struct sk_buff *skb);
+
+ dscp_ecn_decapsulate = ip6ip6_dscp_ecn_decapsulate;
+ if (tpi->proto == htons(ETH_P_IP))
+ dscp_ecn_decapsulate = ip4ip6_dscp_ecn_decapsulate;
+
+ return __ip6_tnl_rcv(t, skb, tpi, tun_dst, dscp_ecn_decapsulate,
log_ecn_err);
}
EXPORT_SYMBOL(ip6_tnl_rcv);
From: David Laight <[email protected]>
[ Upstream commit ab921f3cdbec01c68705a7ade8bec628d541fc2b ]
The number of output and input streams was never being reduced, eg when
processing received INIT or INIT_ACK chunks.
The effect is that DATA chunks can be sent with invalid stream ids
and then discarded by the remote system.
Fixes: 2075e50caf5ea ("sctp: convert to genradix")
Signed-off-by: David Laight <[email protected]>
Acked-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sctp/stream.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -88,12 +88,13 @@ static int sctp_stream_alloc_out(struct
int ret;
if (outcnt <= stream->outcnt)
- return 0;
+ goto out;
ret = genradix_prealloc(&stream->out, outcnt, gfp);
if (ret)
return ret;
+out:
stream->outcnt = outcnt;
return 0;
}
@@ -104,12 +105,13 @@ static int sctp_stream_alloc_in(struct s
int ret;
if (incnt <= stream->incnt)
- return 0;
+ goto out;
ret = genradix_prealloc(&stream->in, incnt, gfp);
if (ret)
return ret;
+out:
stream->incnt = incnt;
return 0;
}
From: Shay Agroskin <[email protected]>
[ Upstream commit ccd143e5150f24b9ba15145c7221b61dd9e41021 ]
Most statistics in ena driver are incremented, meaning that a stat's
value is a sum of all increases done to it since driver/queue
initialization.
This patch makes all statistics this way, effectively making missed_tx
statistic incremental.
Also added a comment regarding rx_drops and tx_drops to make it
clearer how these counters are calculated.
Fixes: 11095fdb712b ("net: ena: add statistics for missed tx packets")
Signed-off-by: Shay Agroskin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -3594,7 +3594,7 @@ static int check_missing_comp_in_tx_queu
}
u64_stats_update_begin(&tx_ring->syncp);
- tx_ring->tx_stats.missed_tx = missed_tx;
+ tx_ring->tx_stats.missed_tx += missed_tx;
u64_stats_update_end(&tx_ring->syncp);
return rc;
@@ -4519,6 +4519,9 @@ static void ena_keep_alive_wd(void *adap
rx_drops = ((u64)desc->rx_drops_high << 32) | desc->rx_drops_low;
u64_stats_update_begin(&adapter->syncp);
+ /* These stats are accumulated by the device, so the counters indicate
+ * all drops since last reset.
+ */
adapter->dev_stats.rx_drops = rx_drops;
u64_stats_update_end(&adapter->syncp);
}
On Wed, Aug 26, 2020 at 02:02:28PM +0200, Greg Kroah-Hartman wrote:
> -------------------
> Note, ok, this is really going to be the final 5.7.y kernel release. I
> mean it this time....
> -------------------
Hello,
This is probably not very relevant but let me just bring this up here since your manner of posting mail on the list seems to differ quite a bit from what most people on the list are doing.
From my understanding, an email regarding to a certain patch or kernel issue should be sent to a list and not to a maintainer. This is however not the habit that people are in, though but instead, most people will send the email to the maintainers, then cc a few probably random mailing lists. This leads to emails flooding on the mailing list and consequently, beats the purpose of one ever having sent the mail to a list because lists will get increasingly difficult to follow.
Is it just me who has made this observation? From your mail, it clearly looks and seems like you are following the above. Not following the above could make it very hard for a new kernel developer to pick up working on the kernel.
Sincerely,
David Kiarie
>
> This is the start of the stable review cycle for the 5.7.19 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 28 Aug 2020 11:48:35 +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.7.19-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.7.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 5.7.19-rc1
>
> Max Filippov <[email protected]>
> binfmt_flat: revert "binfmt_flat: don't offset the data start"
>
> Michael Ellerman <[email protected]>
> powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()
>
> Maxim Mikityanskiy <[email protected]>
> ethtool: Don't omit the netlink reply if no features were changed
>
> Maxim Mikityanskiy <[email protected]>
> ethtool: Account for hw_features in netlink interface
>
> Maxim Mikityanskiy <[email protected]>
> ethtool: Fix preserving of wanted feature bits in netlink interface
>
> Shay Agroskin <[email protected]>
> net: ena: Make missed_tx stat incremental
>
> Cong Wang <[email protected]>
> tipc: fix uninit skb->data in tipc_nl_compat_dumpit()
>
> Xin Long <[email protected]>
> tipc: call rcu_read_lock() in tipc_aead_encrypt_done()
>
> Peilin Ye <[email protected]>
> net/smc: Prevent kernel-infoleak in __smc_diag_dump()
>
> David Laight <[email protected]>
> net: sctp: Fix negotiation of the number of data streams.
>
> Alaa Hleihel <[email protected]>
> net/sched: act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow
>
> Necip Fazil Yildiran <[email protected]>
> net: qrtr: fix usage of idr in port assignment to socket
>
> Nikolay Aleksandrov <[email protected]>
> net: nexthop: don't allow empty NHA_GROUP
>
> Miaohe Lin <[email protected]>
> net: Fix potential wrong skb->protocol in skb_vlan_untag()
>
> Mark Tomlinson <[email protected]>
> gre6: Fix reception with IP6_TNL_F_RCV_DSCP_COPY
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 ++--
> arch/powerpc/kernel/cpu_setup_power.S | 2 +-
> drivers/net/ethernet/amazon/ena/ena_netdev.c | 5 ++++-
> fs/binfmt_flat.c | 20 ++++++++++++--------
> net/core/skbuff.c | 4 ++--
> net/ethtool/features.c | 19 ++++++++++---------
> net/ipv4/nexthop.c | 5 ++++-
> net/ipv6/ip6_tunnel.c | 10 +++++++++-
> net/qrtr/qrtr.c | 20 +++++++++++---------
> net/sched/act_ct.c | 2 +-
> net/sctp/stream.c | 6 ++++--
> net/smc/smc_diag.c | 16 +++++++++-------
> net/tipc/crypto.c | 2 ++
> net/tipc/netlink_compat.c | 12 +++++++++++-
> 14 files changed, 82 insertions(+), 45 deletions(-)
>
>
On Wed, Aug 26, 2020 at 05:49:15PM +0300, David K. Kahurani wrote:
> On Wed, Aug 26, 2020 at 02:02:28PM +0200, Greg Kroah-Hartman wrote:
> > -------------------
> > Note, ok, this is really going to be the final 5.7.y kernel release. I
> > mean it this time....
> > -------------------
>
> Hello,
>
> This is probably not very relevant but let me just bring this up here
> since your manner of posting mail on the list seems to differ quite a
> bit from what most people on the list are doing.
It's not all that relevant as what I am doing here is not what anyone
else on this list is doing :)
> From my understanding, an email regarding to a certain patch or kernel
> issue should be sent to a list and not to a maintainer. This is
> however not the habit that people are in, though but instead, most
> people will send the email to the maintainers, then cc a few probably
> random mailing lists. This leads to emails flooding on the mailing
> list and consequently, beats the purpose of one ever having sent the
> mail to a list because lists will get increasingly difficult to
> follow.
So is the complaint that these stable -rc emails are drowning out seeing
other patches that are relevant?
If so, there are some wonderfully helpfuly headers that I add to all of
these emails so you can easily filter them away to /dev/null if you so
desire.
If not, then I don't understand the complaint.
> Is it just me who has made this observation? From your mail, it
> clearly looks and seems like you are following the above. Not
> following the above could make it very hard for a new kernel developer
> to pick up working on the kernel.
Have you read the Documentation/process/1.Intro.rst file? If not,
please start there, as trying to read the firehose that is lkml all at
once is _not_ how anyone does kernel development.
thanks,
greg k-h
On 8/26/20 5:02 AM, Greg Kroah-Hartman wrote:
> -------------------
> Note, ok, this is really going to be the final 5.7.y kernel release. I
> mean it this time....
> -------------------
>
> This is the start of the stable review cycle for the 5.7.19 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 28 Aug 2020 11:48:35 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 431 pass: 431 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Wed, 26 Aug 2020 at 17:32, Greg Kroah-Hartman
<[email protected]> wrote:
>
> -------------------
> Note, ok, this is really going to be the final 5.7.y kernel release. I
> mean it this time....
> -------------------
>
> This is the start of the stable review cycle for the 5.7.19 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 28 Aug 2020 11:48:35 +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.7.19-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.7.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
------------------------------------------------------------------------
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.7.y
git commit: 6ae4171ed2cd47d945dbd8ce6a2918c00b498022
git describe: v5.7.18-16-g6ae4171ed2cd
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.7-oe/build/v5.7.18-16-g6ae4171ed2cd
No regressions (compared to build v5.7.17-128-gf16d132bb2de)
No fixes (compared to build v5.7.17-128-gf16d132bb2de)
Ran 35766 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
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libhugetlbfs
* linux-log-parser
* ltp-controllers-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-sched-tests
* ltp-tracing-tests
* perf
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* network-basic-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-open-posix-tests
* ltp-syscalls-tests
* v4l2-compliance
* igt-gpu-tools
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
--
Linaro LKFT
https://lkft.linaro.org