On Mon, 12 Jul 2021, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.13.2 release.
> There are 800 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, 14 Jul 2021 06:02:46 +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.13.2-rc1…
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.13.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> Linux 5.13.2-rc1
Hi Greg,
Sorry to be making waves, but please, what's up with the 5.13.2-rc,
5.12.17-rc, 5.10.50-rc, 5.4.132-rc stable release candidates?
Amongst the 2000+ patches posted today, there are a significant number
of them Signed-off-by Andrew, Signed-off-by Linus, Signed-off-by Sasha:
yet never Cc'ed to stable (nor even posted as AUTOSELs, I think).
Am I out of date? I thought that had been agreed not to happen:
https://lore.kernel.org/linux-mm/20190808000533.7701-1-mike.kravetz@oracle.…
is the thread I found when I looked for confirmation, but I believe the
same has been agreed before and since too.
Andrew goes to a lot of trouble to establish which Fixes from his tree
ought to go to stable. Of course there will be exceptions which we
later decide should go in after all; but it's worrying when there's a
wholesale breach like this, and I think most of them should be dropped.
To pick on just one of many examples (sorry Miaohe!), a patch that
surprises me, but I've not had time to look into so far, and would
not want accelerated into X stable releases, 385/800
> Miaohe Lin <linmiaohe(a)huawei.com>
> mm/shmem: fix shmem_swapin() race with swapoff
Hugh
From: Petr Mladek <pmladek(a)suse.com>
The standard printk() tries to flush the message to the console
immediately. It tries to take the console lock. If the lock is
already taken then the current owner is responsible for flushing
even the new message.
There is a small race window between checking whether a new message is
available and releasing the console lock. It is solved by re-checking
the state after releasing the console lock. If the check is positive
then console_unlock() tries to take the lock again and process the new
message as well.
The commit 996e966640ddea7b535c ("printk: remove logbuf_lock") causes that
console_seq is not longer read atomically. As a result, the re-check might
be done with an inconsistent 64-bit index.
Solve it by using the last sequence number that has been checked under
the console lock. In the worst case, it will take the lock again only
to realized that the new message has already been proceed. But it
was possible even before.
The variable next_seq is marked as __maybe_unused to call down compiler
warning when CONFIG_PRINTK is not defined.
Fixes: commit 996e966640ddea7b535c ("printk: remove logbuf_lock")
Reported-by: kernel test robot <lkp(a)intel.com> # unused next_seq warning
Cc: stable(a)vger.kernel.org # 5.13
Signed-off-by: Petr Mladek <pmladek(a)suse.com>
Acked-by: Sergey Senozhatsky <senozhatsky(a)chromium.org>
Reviewed-by: John Ogness <john.ogness(a)linutronix.de>
Link: https://lore.kernel.org/r/20210702150657.26760-1-pmladek@suse.com
---
kernel/printk/printk.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 142a58d124d9..6dad7da8f383 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2545,6 +2545,7 @@ void console_unlock(void)
bool do_cond_resched, retry;
struct printk_info info;
struct printk_record r;
+ u64 __maybe_unused next_seq;
if (console_suspended) {
up_console_sem();
@@ -2654,8 +2655,10 @@ void console_unlock(void)
cond_resched();
}
- console_locked = 0;
+ /* Get consistent value of the next-to-be-used sequence number. */
+ next_seq = console_seq;
+ console_locked = 0;
up_console_sem();
/*
@@ -2664,7 +2667,7 @@ void console_unlock(void)
* there's a new owner and the console_unlock() from them will do the
* flush, no worries.
*/
- retry = prb_read_valid(prb, console_seq, NULL);
+ retry = prb_read_valid(prb, next_seq, NULL);
printk_safe_exit_irqrestore(flags);
if (retry && console_trylock())
--
2.20.1
There's a small window where a USB 2 remote wake may be left unhandled
due to a race between hub thread and xhci port event interrupt handler.
When the resume event is detected in the xhci interrupt handler it kicks
the hub timer, which should move the port from resume to U0 once resume
has been signalled for long enough.
To keep the hub "thread" running we set a bus_state->resuming_ports flag.
This flag makes sure hub timer function kicks itself.
checking this flag was not properly protected by the spinlock. Flag was
copied to a local variable before lock was taken. The local variable was
then checked later with spinlock held.
If interrupt is handled right after copying the flag to the local variable
we end up stopping the hub thread before it can handle the USB 2 resume.
CPU0 CPU1
(hub thread) (xhci event handler)
xhci_hub_status_data()
status = bus_state->resuming_ports;
<Interrupt>
handle_port_status()
spin_lock()
bus_state->resuming_ports = 1
set_flag(HCD_FLAG_POLL_RH)
spin_unlock()
spin_lock()
if (!status)
clear_flag(HCD_FLAG_POLL_RH)
spin_unlock()
Fix this by taking the lock a bit earlier so that it covers
the resuming_ports flag copy in the hub thread
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci-hub.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index e9b18fc17617..151e93c4bd57 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1638,11 +1638,12 @@ int xhci_hub_status_data(struct usb_hcd *hcd, char *buf)
* Inform the usbcore about resume-in-progress by returning
* a non-zero value even if there are no status changes.
*/
+ spin_lock_irqsave(&xhci->lock, flags);
+
status = bus_state->resuming_ports;
mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC | PORT_CEC;
- spin_lock_irqsave(&xhci->lock, flags);
/* For each port, did anything change? If so, set that bit in buf. */
for (i = 0; i < max_ports; i++) {
temp = readl(ports[i]->addr);
--
2.25.1