2019-09-20 07:56:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 00/21] 5.3.1-stable review

This is the start of the stable review cycle for the 5.3.1 release.
There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
Anything received after that time might be too late.

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

thanks,

greg k-h

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

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

Sean Young <[email protected]>
media: technisat-usb2: break out of loop at end of buffer

Jann Horn <[email protected]>
floppy: fix usercopy direction

Bjorn Andersson <[email protected]>
phy: qcom-qmp: Correct ready status, again

Amir Goldstein <[email protected]>
ovl: fix regression caused by overlapping layers detection

Will Deacon <[email protected]>
Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}"

Masashi Honma <[email protected]>
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds

Razvan Stefanescu <[email protected]>
tty/serial: atmel: reschedule TX after RX was started

Chunyan Zhang <[email protected]>
serial: sprd: correct the wrong sequence of arguments

Hung-Te Lin <[email protected]>
firmware: google: check if size is valid when decoding VPD data

Jonathan Neuschäfer <[email protected]>
Documentation: sphinx: Add missing comma to list of strings

Matt Delco <[email protected]>
KVM: coalesced_mmio: add bounds checking

Jose Abreu <[email protected]>
net: stmmac: Hold rtnl lock in suspend/resume callbacks

Andrew Lunn <[email protected]>
net: dsa: Fix load order between DSA drivers and taggers

Dongli Zhang <[email protected]>
xen-netfront: do not assume sk_buff_head list is empty in error handling

Willem de Bruijn <[email protected]>
udp: correct reuseport selection with connected sockets

Cong Wang <[email protected]>
net_sched: let qdisc_put() accept NULL pointer

Paolo Abeni <[email protected]>
net/sched: fix race between deactivation and dequeue for NOLOCK qdisc

Xin Long <[email protected]>
ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit

Yoshihiro Shimoda <[email protected]>
phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current

Sean Young <[email protected]>
media: tm6000: double free if usb disconnect while streaming

Alan Stern <[email protected]>
USB: usbcore: Fix slab-out-of-bounds bug during device reset


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

Diffstat:

Documentation/filesystems/overlayfs.txt | 2 +-
Documentation/sphinx/automarkup.py | 2 +-
Makefile | 4 +-
arch/arm64/include/asm/pgtable.h | 12 +++-
drivers/block/floppy.c | 4 +-
drivers/firmware/google/vpd.c | 4 +-
drivers/firmware/google/vpd_decode.c | 55 ++++++++++-------
drivers/firmware/google/vpd_decode.h | 6 +-
drivers/media/usb/dvb-usb/technisat-usb2.c | 22 ++++---
drivers/media/usb/tm6000/tm6000-dvb.c | 3 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 ++--
drivers/net/xen-netfront.c | 2 +-
drivers/phy/qualcomm/phy-qcom-qmp.c | 33 +++++-----
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +
drivers/tty/serial/atmel_serial.c | 1 -
drivers/tty/serial/sprd_serial.c | 2 +-
drivers/usb/core/config.c | 12 ++--
fs/overlayfs/ovl_entry.h | 1 +
fs/overlayfs/super.c | 73 +++++++++++++++--------
include/net/pkt_sched.h | 7 ++-
include/net/sock_reuseport.h | 20 ++++++-
net/core/dev.c | 16 +++--
net/core/sock_reuseport.c | 15 ++++-
net/dsa/dsa2.c | 2 +
net/ipv4/datagram.c | 2 +
net/ipv4/udp.c | 5 +-
net/ipv6/datagram.c | 2 +
net/ipv6/ip6_gre.c | 2 +-
net/ipv6/udp.c | 5 +-
net/sched/sch_generic.c | 3 +
net/wireless/nl80211.c | 4 +-
virt/kvm/coalesced_mmio.c | 19 +++---
32 files changed, 227 insertions(+), 127 deletions(-)



2019-09-20 07:56:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 04/21] ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit

From: Xin Long <[email protected]>

[ Upstream commit 28e486037747c2180470b77c290d4090ad42f259 ]

In ip6erspan_tunnel_xmit(), if the skb will not be sent out, it has to
be freed on the tx_err path. Otherwise when deleting a netns, it would
cause dst/dev to leak, and dmesg shows:

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

Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode")
Signed-off-by: Xin Long <[email protected]>
Acked-by: William Tu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -968,7 +968,7 @@ static netdev_tx_t ip6erspan_tunnel_xmit
if (unlikely(!tun_info ||
!(tun_info->mode & IP_TUNNEL_INFO_TX) ||
ip_tunnel_info_af(tun_info) != AF_INET6))
- return -EINVAL;
+ goto tx_err;

key = &tun_info->key;
memset(&fl6, 0, sizeof(fl6));


2019-09-20 19:55:26

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review

On 9/19/19 3:03 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>

Build results:
total: 158 pass: 158 fail: 0
Qemu test results:
total: 391 pass: 391 fail: 0

Guenter

2019-09-20 20:32:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review

On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote:
>
> On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.1 release.
> > There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> No new regressions* for Tegra ...
>
> Test results for stable-v5.3:
> 12 builds: 12 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 38 tests: 37 pass, 1 fail
>
> Linux version: 5.3.1-rc1-g0aa7f3d6baae
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra30-cardhu-a04
>
> * Note we had one regression in v5.3 for a warnings test for Tegra194
> causing the above test failure. This has since been fixed by the
> following commits [0] but given it is just a warning, I have not
> bothered CC'ing for stable.
>
> Cheers
> Jon
>
> [0] https://lkml.org/lkml/2019/8/21/602

I'll be glad to take this in stable for 5.3.y, what is the git commit
id?

Also, thanks for testing all of these and letting me know.

greg k-h

>
> --
> nvpublic

2019-09-20 20:48:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 05/21] net/sched: fix race between deactivation and dequeue for NOLOCK qdisc

From: Paolo Abeni <[email protected]>

[ Upstream commit d518d2ed8640c1cbbbb6f63939e3e65471817367 ]

The test implemented by some_qdisc_is_busy() is somewhat loosy for
NOLOCK qdisc, as we may hit the following scenario:

CPU1 CPU2
// in net_tx_action()
clear_bit(__QDISC_STATE_SCHED...);
// in some_qdisc_is_busy()
val = (qdisc_is_running(q) ||
test_bit(__QDISC_STATE_SCHED,
&q->state));
// here val is 0 but...
qdisc_run(q)
// ... CPU1 is going to run the qdisc next

As a conseguence qdisc_run() in net_tx_action() can race with qdisc_reset()
in dev_qdisc_reset(). Such race is not possible for !NOLOCK qdisc as
both the above bit operations are under the root qdisc lock().

After commit 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
the race can cause use after free and/or null ptr dereference, but the root
cause is likely older.

This patch addresses the issue explicitly checking for deactivation under
the seqlock for NOLOCK qdisc, so that the qdisc_run() in the critical
scenario becomes a no-op.

Note that the enqueue() op can still execute concurrently with dev_qdisc_reset(),
but that is safe due to the skb_array() locking, and we can't avoid that
for NOLOCK qdiscs.

Fixes: 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
Reported-by: Li Shuang <[email protected]>
Reported-and-tested-by: Davide Caratti <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/pkt_sched.h | 7 ++++++-
net/core/dev.c | 16 ++++++++++------
2 files changed, 16 insertions(+), 7 deletions(-)

--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h
@@ -118,7 +118,12 @@ void __qdisc_run(struct Qdisc *q);
static inline void qdisc_run(struct Qdisc *q)
{
if (qdisc_run_begin(q)) {
- __qdisc_run(q);
+ /* NOLOCK qdisc must check 'state' under the qdisc seqlock
+ * to avoid racing with dev_qdisc_reset()
+ */
+ if (!(q->flags & TCQ_F_NOLOCK) ||
+ likely(!test_bit(__QDISC_STATE_DEACTIVATED, &q->state)))
+ __qdisc_run(q);
qdisc_run_end(q);
}
}
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3467,18 +3467,22 @@ static inline int __dev_xmit_skb(struct
qdisc_calculate_pkt_len(skb, q);

if (q->flags & TCQ_F_NOLOCK) {
- if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
- __qdisc_drop(skb, &to_free);
- rc = NET_XMIT_DROP;
- } else if ((q->flags & TCQ_F_CAN_BYPASS) && q->empty &&
- qdisc_run_begin(q)) {
+ if ((q->flags & TCQ_F_CAN_BYPASS) && q->empty &&
+ qdisc_run_begin(q)) {
+ if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED,
+ &q->state))) {
+ __qdisc_drop(skb, &to_free);
+ rc = NET_XMIT_DROP;
+ goto end_run;
+ }
qdisc_bstats_cpu_update(q, skb);

+ rc = NET_XMIT_SUCCESS;
if (sch_direct_xmit(skb, q, dev, txq, NULL, true))
__qdisc_run(q);

+end_run:
qdisc_run_end(q);
- rc = NET_XMIT_SUCCESS;
} else {
rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
qdisc_run(q);


2019-09-20 21:14:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 08/21] xen-netfront: do not assume sk_buff_head list is empty in error handling

From: Dongli Zhang <[email protected]>

[ Upstream commit 00b368502d18f790ab715e055869fd4bb7484a9b ]

When skb_shinfo(skb) is not able to cache extra fragment (that is,
skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes
the sk_buff_head list is already empty. As a result, cons is increased only
by 1 and returns to error handling path in xennet_poll().

However, if the sk_buff_head list is not empty, queue->rx.rsp_cons may be
set incorrectly. That is, queue->rx.rsp_cons would point to the rx ring
buffer entries whose queue->rx_skbs[i] and queue->grant_rx_ref[i] are
already cleared to NULL. This leads to NULL pointer access in the next
iteration to process rx ring buffer entries.

Below is how xennet_poll() does error handling. All remaining entries in
tmpq are accounted to queue->rx.rsp_cons without assuming how many
outstanding skbs are remained in the list.

985 static int xennet_poll(struct napi_struct *napi, int budget)
... ...
1032 if (unlikely(xennet_set_skb_gso(skb, gso))) {
1033 __skb_queue_head(&tmpq, skb);
1034 queue->rx.rsp_cons += skb_queue_len(&tmpq);
1035 goto err;
1036 }

It is better to always have the error handling in the same way.

Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Signed-off-by: Dongli Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -906,7 +906,7 @@ static RING_IDX xennet_fill_frags(struct
__pskb_pull_tail(skb, pull_to - skb_headlen(skb));
}
if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) {
- queue->rx.rsp_cons = ++cons;
+ queue->rx.rsp_cons = ++cons + skb_queue_len(list);
kfree_skb(nskb);
return ~0U;
}


2019-09-20 21:14:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.3 06/21] net_sched: let qdisc_put() accept NULL pointer

From: Cong Wang <[email protected]>

[ Upstream commit 6efb971ba8edfbd80b666f29de12882852f095ae ]

When tcf_block_get() fails in sfb_init(), q->qdisc is still a NULL
pointer which leads to a crash in sfb_destroy(). Similar for
sch_dsmark.

Instead of fixing each separately, Linus suggested to just accept
NULL pointer in qdisc_put(), which would make callers easier.

(For sch_dsmark, the bug probably exists long before commit
6529eaba33f0.)

Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
Reported-by: [email protected]
Suggested-by: Linus Torvalds <[email protected]>
Cc: Jamal Hadi Salim <[email protected]>
Cc: Jiri Pirko <[email protected]>
Signed-off-by: Cong Wang <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/sch_generic.c | 3 +++
1 file changed, 3 insertions(+)

--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -985,6 +985,9 @@ static void qdisc_destroy(struct Qdisc *

void qdisc_put(struct Qdisc *qdisc)
{
+ if (!qdisc)
+ return;
+
if (qdisc->flags & TCQ_F_BUILTIN ||
!refcount_dec_and_test(&qdisc->refcnt))
return;


2019-09-21 20:28:31

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review


On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

No new regressions* for Tegra ...

Test results for stable-v5.3:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
38 tests: 37 pass, 1 fail

Linux version: 5.3.1-rc1-g0aa7f3d6baae
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

* Note we had one regression in v5.3 for a warnings test for Tegra194
causing the above test failure. This has since been fixed by the
following commits [0] but given it is just a warning, I have not
bothered CC'ing for stable.

Cheers
Jon

[0] https://lkml.org/lkml/2019/8/21/602

--
nvpublic

2019-09-22 18:48:00

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review

On Fri, 20 Sep 2019 at 03:36, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

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

kernel: 5.3.0
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git branch: master
git commit: 574cc4539762561d96b456dbc0544d8898bd4c6e
git describe: v5.3-10169-g574cc4539762
Test details: https://qa-reports.linaro.org/lkft/linux-mainline-oe/build/v5.3-10169-g574cc4539762


No regressions (compared to build v5.3-3662-g04cbfba62085)


No fixes (compared to build v5.3-3662-g04cbfba62085)

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

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* perf
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* spectre-meltdown-checker-test
* v4l2-compliance
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

2019-09-22 19:14:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review

On Fri, Sep 20, 2019 at 03:17:48PM -0600, shuah wrote:
> On 9/19/19 4:03 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.1 release.
> > There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

2019-09-22 19:16:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review

On Fri, Sep 20, 2019 at 08:11:35PM +0530, Naresh Kamboju wrote:
> On Fri, 20 Sep 2019 at 03:36, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.3.1 release.
> > There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Nice to see 5.3.0 pass everything :)

Thanks for testing all of these and letting me know.

greg k-h

2019-09-23 05:19:26

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review


On 20/09/2019 15:24, Greg Kroah-Hartman wrote:
> On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote:
>>
>> On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.3.1 release.
>>> There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
>>> or in the git tree and branch at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> No new regressions* for Tegra ...
>>
>> Test results for stable-v5.3:
>> 12 builds: 12 pass, 0 fail
>> 22 boots: 22 pass, 0 fail
>> 38 tests: 37 pass, 1 fail
>>
>> Linux version: 5.3.1-rc1-g0aa7f3d6baae
>> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
>> tegra194-p2972-0000, tegra20-ventana,
>> tegra210-p2371-2180, tegra30-cardhu-a04
>>
>> * Note we had one regression in v5.3 for a warnings test for Tegra194
>> causing the above test failure. This has since been fixed by the
>> following commits [0] but given it is just a warning, I have not
>> bothered CC'ing for stable.
>>
>> Cheers
>> Jon
>>
>> [0] https://lkml.org/lkml/2019/8/21/602
>
> I'll be glad to take this in stable for 5.3.y, what is the git commit
> id?

OK, that would be great. The IDs are ...

commit 763719771e84b8c8c2f53af668cdc905faa608de
Author: Jon Hunter <[email protected]>
Date: Wed Aug 21 16:02:40 2019 +0100

clocksource/drivers/timer-of: Do not warn on deferred probe


commit 14e019df1e64c8b19ce8e0b3da25b6f40c8716be
Author: Jon Hunter <[email protected]>
Date: Wed Aug 21 16:02:41 2019 +0100

clocksource/drivers: Do not warn on probe defer


> Also, thanks for testing all of these and letting me know.

No problem!

Cheers
Jon

--
nvpublic

2019-09-23 11:04:04

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review

On 9/19/19 4:03 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.3.1 release.
> There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

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

thanks,
-- Shuah

2019-09-23 18:30:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.3 00/21] 5.3.1-stable review

On Fri, Sep 20, 2019 at 05:01:35PM +0100, Jon Hunter wrote:
>
> On 20/09/2019 15:24, Greg Kroah-Hartman wrote:
> > On Fri, Sep 20, 2019 at 02:54:26PM +0100, Jon Hunter wrote:
> >>
> >> On 19/09/2019 23:03, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 5.3.1 release.
> >>> There are 21 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 Sat 21 Sep 2019 09:44:25 PM UTC.
> >>> Anything received after that time might be too late.
> >>>
> >>> The whole patch series can be found in one patch at:
> >>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.1-rc1.gz
> >>> or in the git tree and branch at:
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.3.y
> >>> and the diffstat can be found below.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>
> >> No new regressions* for Tegra ...
> >>
> >> Test results for stable-v5.3:
> >> 12 builds: 12 pass, 0 fail
> >> 22 boots: 22 pass, 0 fail
> >> 38 tests: 37 pass, 1 fail
> >>
> >> Linux version: 5.3.1-rc1-g0aa7f3d6baae
> >> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> >> tegra194-p2972-0000, tegra20-ventana,
> >> tegra210-p2371-2180, tegra30-cardhu-a04
> >>
> >> * Note we had one regression in v5.3 for a warnings test for Tegra194
> >> causing the above test failure. This has since been fixed by the
> >> following commits [0] but given it is just a warning, I have not
> >> bothered CC'ing for stable.
> >>
> >> Cheers
> >> Jon
> >>
> >> [0] https://lkml.org/lkml/2019/8/21/602
> >
> > I'll be glad to take this in stable for 5.3.y, what is the git commit
> > id?
>
> OK, that would be great. The IDs are ...
>
> commit 763719771e84b8c8c2f53af668cdc905faa608de
> Author: Jon Hunter <[email protected]>
> Date: Wed Aug 21 16:02:40 2019 +0100
>
> clocksource/drivers/timer-of: Do not warn on deferred probe
>
>
> commit 14e019df1e64c8b19ce8e0b3da25b6f40c8716be
> Author: Jon Hunter <[email protected]>
> Date: Wed Aug 21 16:02:41 2019 +0100
>
> clocksource/drivers: Do not warn on probe defer
>
>

Now queued up, thanks!

greg k-h