* [PATCH 5.10 00/63] 5.10.162-rc1 review
@ 2023-01-03 8:13 Greg Kroah-Hartman
2023-01-03 8:14 ` [PATCH 5.10 51/63] x86/process: setup io_threads more like normal user space threads Greg Kroah-Hartman
` (7 more replies)
0 siblings, 8 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2023-01-03 8:13 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
This is the start of the stable review cycle for the 5.10.162 release.
There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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 <gregkh@linuxfoundation.org>
Linux 5.10.162-rc1
Jens Axboe <axboe@kernel.dk>
io_uring: pass in EPOLL_URING_WAKE for eventfd signaling and wakeups
Jens Axboe <axboe@kernel.dk>
eventfd: provide a eventfd_signal_mask() helper
Jens Axboe <axboe@kernel.dk>
eventpoll: add EPOLL_URING_WAKE poll wakeup flag
Jens Axboe <axboe@kernel.dk>
Revert "proc: don't allow async path resolution of /proc/self components"
Jens Axboe <axboe@kernel.dk>
Revert "proc: don't allow async path resolution of /proc/thread-self components"
Jens Axboe <axboe@kernel.dk>
net: remove cmsg restriction from io_uring based send/recvmsg calls
Jens Axboe <axboe@kernel.dk>
task_work: unconditionally run task_work from get_signal()
Jens Axboe <axboe@kernel.dk>
signal: kill JOBCTL_TASK_WORK
Jens Axboe <axboe@kernel.dk>
io_uring: import 5.15-stable io_uring
Jens Axboe <axboe@kernel.dk>
task_work: add helper for more targeted task_work canceling
Jens Axboe <axboe@kernel.dk>
kernel: don't call do_exit() for PF_IO_WORKER threads
Jens Axboe <axboe@kernel.dk>
kernel: stop masking signals in create_io_thread()
Stefan Metzmacher <metze@samba.org>
x86/process: setup io_threads more like normal user space threads
Jens Axboe <axboe@kernel.dk>
arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread()
Jens Axboe <axboe@kernel.dk>
arch: setup PF_IO_WORKER threads like PF_KTHREAD
Seth Forshee <sforshee@digitalocean.com>
entry/kvm: Exit to user mode when TIF_NOTIFY_SIGNAL is set
Jens Axboe <axboe@kernel.dk>
kernel: allow fork with TIF_NOTIFY_SIGNAL pending
Eric W. Biederman <ebiederm@xmission.com>
coredump: Limit what can interrupt coredumps
Jens Axboe <axboe@kernel.dk>
kernel: remove checking for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
task_work: remove legacy TWA_SIGNAL path
Al Viro <viro@zeniv.linux.org.uk>
alpha: fix TIF_NOTIFY_SIGNAL handling
Vineet Gupta <vgupta@synopsys.com>
ARC: unbork 5.11 bootup: fix snafu in _TIF_NOTIFY_SIGNAL handling
Jens Axboe <axboe@kernel.dk>
ia64: don't call handle_signal() unless there's actually a signal queued
Jens Axboe <axboe@kernel.dk>
sparc: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
riscv: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
nds32: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
ia64: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
h8300: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
c6x: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
alpha: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
xtensa: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
arm: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
microblaze: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
hexagon: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
csky: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
openrisc: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
sh: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
um: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
s390: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
mips: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
powerpc: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
parisc: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
nios32: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
m68k: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
arm64: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
arc: add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
x86: Wire up TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
task_work: Use TIF_NOTIFY_SIGNAL if available
Jens Axboe <axboe@kernel.dk>
entry: Add support for TIF_NOTIFY_SIGNAL
Jens Axboe <axboe@kernel.dk>
fs: provide locked helper variant of close_fd_get_file()
Eric W. Biederman <ebiederm@xmission.com>
file: Rename __close_fd_get_file close_fd_get_file
Jens Axboe <axboe@kernel.dk>
fs: make do_renameat2() take struct filename
Jens Axboe <axboe@kernel.dk>
signal: Add task_sigpending() helper
Pavel Begunkov <asml.silence@gmail.com>
net: add accept helper not installing fd
Jens Axboe <axboe@kernel.dk>
net: provide __sys_shutdown_sock() that takes a socket
Arnaldo Carvalho de Melo <acme@redhat.com>
tools headers UAPI: Sync openat2.h with the kernel sources
Jens Axboe <axboe@kernel.dk>
fs: expose LOOKUP_CACHED through openat2() RESOLVE_CACHED
Al Viro <viro@zeniv.linux.org.uk>
Make sure nd->path.mnt and nd->path.dentry are always valid pointers
Al Viro <viro@zeniv.linux.org.uk>
fix handling of nd->depth on LOOKUP_CACHED failures in try_to_unlazy*
Jens Axboe <axboe@kernel.dk>
fs: add support for LOOKUP_CACHED
Al Viro <viro@zeniv.linux.org.uk>
saner calling conventions for unlazy_child()
Jens Axboe <axboe@kernel.dk>
iov_iter: add helper to save iov_iter state
Jens Axboe <axboe@kernel.dk>
kernel: provide create_io_thread() helper
-------------
Diffstat:
Makefile | 6 +-
arch/alpha/include/asm/thread_info.h | 4 +-
arch/alpha/kernel/entry.S | 2 +-
arch/alpha/kernel/process.c | 2 +-
arch/alpha/kernel/signal.c | 2 +-
arch/arc/include/asm/thread_info.h | 4 +-
arch/arc/kernel/entry.S | 3 +-
arch/arc/kernel/process.c | 2 +-
arch/arc/kernel/signal.c | 2 +-
arch/arm/include/asm/thread_info.h | 7 +-
arch/arm/kernel/entry-common.S | 6 +-
arch/arm/kernel/entry-v7m.S | 2 +-
arch/arm/kernel/process.c | 2 +-
arch/arm/kernel/signal.c | 2 +-
arch/arm64/include/asm/thread_info.h | 5 +-
arch/arm64/kernel/process.c | 2 +-
arch/arm64/kernel/signal.c | 2 +-
arch/c6x/include/asm/thread_info.h | 1 +
arch/c6x/kernel/asm-offsets.c | 1 +
arch/c6x/kernel/signal.c | 3 +-
arch/csky/include/asm/thread_info.h | 5 +-
arch/csky/kernel/process.c | 2 +-
arch/csky/kernel/signal.c | 2 +-
arch/h8300/include/asm/thread_info.h | 4 +-
arch/h8300/kernel/process.c | 2 +-
arch/h8300/kernel/signal.c | 2 +-
arch/hexagon/include/asm/thread_info.h | 2 +
arch/hexagon/kernel/process.c | 4 +-
arch/ia64/include/asm/thread_info.h | 4 +-
arch/ia64/kernel/process.c | 5 +-
arch/ia64/kernel/signal.c | 3 +-
arch/m68k/include/asm/thread_info.h | 1 +
arch/m68k/kernel/process.c | 2 +-
arch/m68k/kernel/signal.c | 3 +-
arch/microblaze/include/asm/thread_info.h | 2 +
arch/microblaze/kernel/process.c | 2 +-
arch/microblaze/kernel/signal.c | 3 +-
arch/mips/include/asm/thread_info.h | 4 +-
arch/mips/kernel/process.c | 2 +-
arch/mips/kernel/signal.c | 2 +-
arch/nds32/include/asm/thread_info.h | 2 +
arch/nds32/kernel/ex-exit.S | 2 +-
arch/nds32/kernel/process.c | 2 +-
arch/nds32/kernel/signal.c | 2 +-
arch/nios2/include/asm/thread_info.h | 2 +
arch/nios2/kernel/process.c | 2 +-
arch/nios2/kernel/signal.c | 3 +-
arch/openrisc/include/asm/thread_info.h | 2 +
arch/openrisc/kernel/process.c | 2 +-
arch/openrisc/kernel/signal.c | 2 +-
arch/parisc/include/asm/thread_info.h | 4 +-
arch/parisc/kernel/process.c | 2 +-
arch/parisc/kernel/signal.c | 3 +-
arch/powerpc/include/asm/thread_info.h | 5 +-
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kernel/signal.c | 2 +-
arch/riscv/include/asm/thread_info.h | 5 +-
arch/riscv/kernel/process.c | 2 +-
arch/riscv/kernel/signal.c | 2 +-
arch/s390/include/asm/thread_info.h | 2 +
arch/s390/kernel/entry.S | 11 +-
arch/s390/kernel/process.c | 2 +-
arch/s390/kernel/signal.c | 2 +-
arch/sh/include/asm/thread_info.h | 4 +-
arch/sh/kernel/process_32.c | 2 +-
arch/sh/kernel/signal_32.c | 2 +-
arch/sparc/include/asm/thread_info_32.h | 4 +-
arch/sparc/include/asm/thread_info_64.h | 6 +-
arch/sparc/kernel/process_32.c | 2 +-
arch/sparc/kernel/process_64.c | 2 +-
arch/sparc/kernel/signal_32.c | 2 +-
arch/sparc/kernel/signal_64.c | 2 +-
arch/um/include/asm/thread_info.h | 2 +
arch/um/kernel/process.c | 5 +-
arch/x86/include/asm/thread_info.h | 2 +
arch/x86/kernel/process.c | 17 +
arch/x86/kernel/signal.c | 4 +-
arch/xtensa/include/asm/thread_info.h | 5 +-
arch/xtensa/kernel/entry.S | 4 +-
arch/xtensa/kernel/process.c | 2 +-
arch/xtensa/kernel/signal.c | 3 +-
drivers/android/binder.c | 2 +-
fs/Makefile | 2 -
fs/coredump.c | 2 +-
fs/eventfd.c | 37 +-
fs/eventpoll.c | 18 +-
fs/file.c | 34 +-
fs/internal.h | 3 +
fs/io-wq.c | 1242 ----
fs/namei.c | 84 +-
fs/open.c | 6 +
fs/proc/self.c | 7 -
fs/proc/thread_self.c | 7 -
include/linux/entry-common.h | 7 +-
include/linux/entry-kvm.h | 4 +-
include/linux/eventfd.h | 7 +
include/linux/fcntl.h | 2 +-
include/linux/fdtable.h | 2 +-
include/linux/io_uring.h | 46 +-
include/linux/namei.h | 1 +
include/linux/net.h | 3 -
include/linux/sched.h | 3 +
include/linux/sched/jobctl.h | 4 +-
include/linux/sched/signal.h | 18 +-
include/linux/sched/task.h | 2 +
include/linux/socket.h | 4 +
include/linux/syscalls.h | 2 +-
include/linux/task_work.h | 2 +
include/linux/tracehook.h | 23 +
include/linux/uio.h | 15 +
include/trace/events/io_uring.h | 121 +-
include/uapi/linux/eventpoll.h | 6 +
include/uapi/linux/io_uring.h | 115 +-
include/uapi/linux/openat2.h | 4 +
io_uring/Makefile | 6 +
io_uring/io-wq.c | 1398 +++++
{fs => io_uring}/io-wq.h | 47 +-
{fs => io_uring}/io_uring.c | 9209 ++++++++++++++++-------------
kernel/entry/common.c | 14 +-
kernel/entry/kvm.c | 2 +-
kernel/events/uprobes.c | 2 +-
kernel/exit.c | 2 +-
kernel/fork.c | 33 +-
kernel/sched/core.c | 2 +-
kernel/signal.c | 53 +-
kernel/task_work.c | 48 +-
lib/iov_iter.c | 52 +-
net/ipv4/af_inet.c | 1 -
net/ipv6/af_inet6.c | 1 -
net/socket.c | 92 +-
tools/include/uapi/linux/openat2.h | 4 +
131 files changed, 7279 insertions(+), 5773 deletions(-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 5.10 51/63] x86/process: setup io_threads more like normal user space threads
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
@ 2023-01-03 8:14 ` Greg Kroah-Hartman
2023-01-03 13:44 ` [PATCH 5.10 00/63] 5.10.162-rc1 review Pavel Machek
` (6 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2023-01-03 8:14 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Stefan Metzmacher, Linus Torvalds,
Jens Axboe, Andy Lutomirski, linux-kernel, io-uring, x86,
Thomas Gleixner
From: Stefan Metzmacher <metze@samba.org>
[ Upstream commit 50b7b6f29de3e18e9d6c09641256a0296361cfee ]
As io_threads are fully set up USER threads it's clearer to separate the
code path from the KTHREAD logic.
The only remaining difference to user space threads is that io_threads
never return to user space again. Instead they loop within the given
worker function.
The fact that they never return to user space means they don't have an
user space thread stack. In order to indicate that to tools like gdb we
reset the stack and instruction pointers to 0.
This allows gdb attach to user space processes using io-uring, which like
means that they have io_threads, without printing worrying message like
this:
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
warning: Architecture rejected target-supplied description
The output will be something like this:
(gdb) info threads
Id Target Id Frame
* 1 LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
2 LWP 4864 "iou-mgr-4863" 0x0000000000000000 in ?? ()
3 LWP 4865 "iou-wrk-4863" 0x0000000000000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (LWP 4865)]
#0 0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x0
Fixes: 4727dc20e042 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD")
Link: https://lore.kernel.org/io-uring/044d0bad-6888-a211-e1d3-159a4aeed52d@polymtl.ca/T/#m1bbf5727e3d4e839603f6ec7ed79c7eebfba6267
Signed-off-by: Stefan Metzmacher <metze@samba.org>
cc: Linus Torvalds <torvalds@linux-foundation.org>
cc: Jens Axboe <axboe@kernel.dk>
cc: Andy Lutomirski <luto@kernel.org>
cc: linux-kernel@vger.kernel.org
cc: io-uring@vger.kernel.org
cc: x86@kernel.org
Link: https://lore.kernel.org/r/20210505110310.237537-1-metze@samba.org
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/process.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -162,7 +162,7 @@ int copy_thread(unsigned long clone_flag
#endif
/* Kernel thread ? */
- if (unlikely(p->flags & (PF_KTHREAD | PF_IO_WORKER))) {
+ if (unlikely(p->flags & PF_KTHREAD)) {
memset(childregs, 0, sizeof(struct pt_regs));
kthread_frame_init(frame, sp, arg);
return 0;
@@ -178,6 +178,23 @@ int copy_thread(unsigned long clone_flag
task_user_gs(p) = get_user_gs(current_pt_regs());
#endif
+ if (unlikely(p->flags & PF_IO_WORKER)) {
+ /*
+ * An IO thread is a user space thread, but it doesn't
+ * return to ret_after_fork().
+ *
+ * In order to indicate that to tools like gdb,
+ * we reset the stack and instruction pointers.
+ *
+ * It does the same kernel frame setup to return to a kernel
+ * function that a kernel thread does.
+ */
+ childregs->sp = 0;
+ childregs->ip = 0;
+ kthread_frame_init(frame, sp, arg);
+ return 0;
+ }
+
/* Set a new TLS for the child thread? */
if (clone_flags & CLONE_SETTLS)
ret = set_new_tls(p, tls);
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
2023-01-03 8:14 ` [PATCH 5.10 51/63] x86/process: setup io_threads more like normal user space threads Greg Kroah-Hartman
@ 2023-01-03 13:44 ` Pavel Machek
2023-01-03 14:51 ` Guenter Roeck
` (5 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Pavel Machek @ 2023-01-03 13:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Hi!
> This is the start of the stable review cycle for the 5.10.162 release.
> There are 63 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.
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) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
2023-01-03 8:14 ` [PATCH 5.10 51/63] x86/process: setup io_threads more like normal user space threads Greg Kroah-Hartman
2023-01-03 13:44 ` [PATCH 5.10 00/63] 5.10.162-rc1 review Pavel Machek
@ 2023-01-03 14:51 ` Guenter Roeck
2023-01-03 15:32 ` Jon Hunter
` (4 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Guenter Roeck @ 2023-01-03 14:51 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow
On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.162 release.
> There are 63 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 Thu, 05 Jan 2023 08:12:47 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 162 pass: 162 fail: 0
Qemu test results:
total: 475 pass: 475 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2023-01-03 14:51 ` Guenter Roeck
@ 2023-01-03 15:32 ` Jon Hunter
2023-01-03 16:16 ` Joel Fernandes
` (3 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Jon Hunter @ 2023-01-03 15:32 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, linux-tegra
On Tue, 03 Jan 2023 09:13:30 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.162 release.
> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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
All tests passing for Tegra ...
Test results for stable-v5.10:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
75 tests: 75 pass, 0 fail
Linux version: 5.10.162-rc1-gc5bc645ae6f9
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2023-01-03 15:32 ` Jon Hunter
@ 2023-01-03 16:16 ` Joel Fernandes
2023-01-04 5:29 ` Greg Kroah-Hartman
2023-01-03 18:16 ` Naresh Kamboju
` (2 subsequent siblings)
7 siblings, 1 reply; 13+ messages in thread
From: Joel Fernandes @ 2023-01-03 16:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.162 release.
> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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,
Testing fails. Could you please pick these 2 up?
https://lore.kernel.org/r/20221230153215.1333921-1-joel@joelfernandes.org
https://lore.kernel.org/all/20221230153215.1333921-2-joel@joelfernandes.org/
Thank you,
- Joel
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Linux 5.10.162-rc1
>
> Jens Axboe <axboe@kernel.dk>
> io_uring: pass in EPOLL_URING_WAKE for eventfd signaling and wakeups
>
> Jens Axboe <axboe@kernel.dk>
> eventfd: provide a eventfd_signal_mask() helper
>
> Jens Axboe <axboe@kernel.dk>
> eventpoll: add EPOLL_URING_WAKE poll wakeup flag
>
> Jens Axboe <axboe@kernel.dk>
> Revert "proc: don't allow async path resolution of /proc/self components"
>
> Jens Axboe <axboe@kernel.dk>
> Revert "proc: don't allow async path resolution of /proc/thread-self components"
>
> Jens Axboe <axboe@kernel.dk>
> net: remove cmsg restriction from io_uring based send/recvmsg calls
>
> Jens Axboe <axboe@kernel.dk>
> task_work: unconditionally run task_work from get_signal()
>
> Jens Axboe <axboe@kernel.dk>
> signal: kill JOBCTL_TASK_WORK
>
> Jens Axboe <axboe@kernel.dk>
> io_uring: import 5.15-stable io_uring
>
> Jens Axboe <axboe@kernel.dk>
> task_work: add helper for more targeted task_work canceling
>
> Jens Axboe <axboe@kernel.dk>
> kernel: don't call do_exit() for PF_IO_WORKER threads
>
> Jens Axboe <axboe@kernel.dk>
> kernel: stop masking signals in create_io_thread()
>
> Stefan Metzmacher <metze@samba.org>
> x86/process: setup io_threads more like normal user space threads
>
> Jens Axboe <axboe@kernel.dk>
> arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread()
>
> Jens Axboe <axboe@kernel.dk>
> arch: setup PF_IO_WORKER threads like PF_KTHREAD
>
> Seth Forshee <sforshee@digitalocean.com>
> entry/kvm: Exit to user mode when TIF_NOTIFY_SIGNAL is set
>
> Jens Axboe <axboe@kernel.dk>
> kernel: allow fork with TIF_NOTIFY_SIGNAL pending
>
> Eric W. Biederman <ebiederm@xmission.com>
> coredump: Limit what can interrupt coredumps
>
> Jens Axboe <axboe@kernel.dk>
> kernel: remove checking for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> task_work: remove legacy TWA_SIGNAL path
>
> Al Viro <viro@zeniv.linux.org.uk>
> alpha: fix TIF_NOTIFY_SIGNAL handling
>
> Vineet Gupta <vgupta@synopsys.com>
> ARC: unbork 5.11 bootup: fix snafu in _TIF_NOTIFY_SIGNAL handling
>
> Jens Axboe <axboe@kernel.dk>
> ia64: don't call handle_signal() unless there's actually a signal queued
>
> Jens Axboe <axboe@kernel.dk>
> sparc: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> riscv: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> nds32: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> ia64: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> h8300: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> c6x: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> alpha: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> xtensa: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> arm: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> microblaze: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> hexagon: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> csky: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> openrisc: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> sh: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> um: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> s390: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> mips: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> powerpc: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> parisc: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> nios32: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> m68k: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> arm64: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> arc: add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> x86: Wire up TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> task_work: Use TIF_NOTIFY_SIGNAL if available
>
> Jens Axboe <axboe@kernel.dk>
> entry: Add support for TIF_NOTIFY_SIGNAL
>
> Jens Axboe <axboe@kernel.dk>
> fs: provide locked helper variant of close_fd_get_file()
>
> Eric W. Biederman <ebiederm@xmission.com>
> file: Rename __close_fd_get_file close_fd_get_file
>
> Jens Axboe <axboe@kernel.dk>
> fs: make do_renameat2() take struct filename
>
> Jens Axboe <axboe@kernel.dk>
> signal: Add task_sigpending() helper
>
> Pavel Begunkov <asml.silence@gmail.com>
> net: add accept helper not installing fd
>
> Jens Axboe <axboe@kernel.dk>
> net: provide __sys_shutdown_sock() that takes a socket
>
> Arnaldo Carvalho de Melo <acme@redhat.com>
> tools headers UAPI: Sync openat2.h with the kernel sources
>
> Jens Axboe <axboe@kernel.dk>
> fs: expose LOOKUP_CACHED through openat2() RESOLVE_CACHED
>
> Al Viro <viro@zeniv.linux.org.uk>
> Make sure nd->path.mnt and nd->path.dentry are always valid pointers
>
> Al Viro <viro@zeniv.linux.org.uk>
> fix handling of nd->depth on LOOKUP_CACHED failures in try_to_unlazy*
>
> Jens Axboe <axboe@kernel.dk>
> fs: add support for LOOKUP_CACHED
>
> Al Viro <viro@zeniv.linux.org.uk>
> saner calling conventions for unlazy_child()
>
> Jens Axboe <axboe@kernel.dk>
> iov_iter: add helper to save iov_iter state
>
> Jens Axboe <axboe@kernel.dk>
> kernel: provide create_io_thread() helper
>
>
> -------------
>
> Diffstat:
>
> Makefile | 6 +-
> arch/alpha/include/asm/thread_info.h | 4 +-
> arch/alpha/kernel/entry.S | 2 +-
> arch/alpha/kernel/process.c | 2 +-
> arch/alpha/kernel/signal.c | 2 +-
> arch/arc/include/asm/thread_info.h | 4 +-
> arch/arc/kernel/entry.S | 3 +-
> arch/arc/kernel/process.c | 2 +-
> arch/arc/kernel/signal.c | 2 +-
> arch/arm/include/asm/thread_info.h | 7 +-
> arch/arm/kernel/entry-common.S | 6 +-
> arch/arm/kernel/entry-v7m.S | 2 +-
> arch/arm/kernel/process.c | 2 +-
> arch/arm/kernel/signal.c | 2 +-
> arch/arm64/include/asm/thread_info.h | 5 +-
> arch/arm64/kernel/process.c | 2 +-
> arch/arm64/kernel/signal.c | 2 +-
> arch/c6x/include/asm/thread_info.h | 1 +
> arch/c6x/kernel/asm-offsets.c | 1 +
> arch/c6x/kernel/signal.c | 3 +-
> arch/csky/include/asm/thread_info.h | 5 +-
> arch/csky/kernel/process.c | 2 +-
> arch/csky/kernel/signal.c | 2 +-
> arch/h8300/include/asm/thread_info.h | 4 +-
> arch/h8300/kernel/process.c | 2 +-
> arch/h8300/kernel/signal.c | 2 +-
> arch/hexagon/include/asm/thread_info.h | 2 +
> arch/hexagon/kernel/process.c | 4 +-
> arch/ia64/include/asm/thread_info.h | 4 +-
> arch/ia64/kernel/process.c | 5 +-
> arch/ia64/kernel/signal.c | 3 +-
> arch/m68k/include/asm/thread_info.h | 1 +
> arch/m68k/kernel/process.c | 2 +-
> arch/m68k/kernel/signal.c | 3 +-
> arch/microblaze/include/asm/thread_info.h | 2 +
> arch/microblaze/kernel/process.c | 2 +-
> arch/microblaze/kernel/signal.c | 3 +-
> arch/mips/include/asm/thread_info.h | 4 +-
> arch/mips/kernel/process.c | 2 +-
> arch/mips/kernel/signal.c | 2 +-
> arch/nds32/include/asm/thread_info.h | 2 +
> arch/nds32/kernel/ex-exit.S | 2 +-
> arch/nds32/kernel/process.c | 2 +-
> arch/nds32/kernel/signal.c | 2 +-
> arch/nios2/include/asm/thread_info.h | 2 +
> arch/nios2/kernel/process.c | 2 +-
> arch/nios2/kernel/signal.c | 3 +-
> arch/openrisc/include/asm/thread_info.h | 2 +
> arch/openrisc/kernel/process.c | 2 +-
> arch/openrisc/kernel/signal.c | 2 +-
> arch/parisc/include/asm/thread_info.h | 4 +-
> arch/parisc/kernel/process.c | 2 +-
> arch/parisc/kernel/signal.c | 3 +-
> arch/powerpc/include/asm/thread_info.h | 5 +-
> arch/powerpc/kernel/process.c | 2 +-
> arch/powerpc/kernel/signal.c | 2 +-
> arch/riscv/include/asm/thread_info.h | 5 +-
> arch/riscv/kernel/process.c | 2 +-
> arch/riscv/kernel/signal.c | 2 +-
> arch/s390/include/asm/thread_info.h | 2 +
> arch/s390/kernel/entry.S | 11 +-
> arch/s390/kernel/process.c | 2 +-
> arch/s390/kernel/signal.c | 2 +-
> arch/sh/include/asm/thread_info.h | 4 +-
> arch/sh/kernel/process_32.c | 2 +-
> arch/sh/kernel/signal_32.c | 2 +-
> arch/sparc/include/asm/thread_info_32.h | 4 +-
> arch/sparc/include/asm/thread_info_64.h | 6 +-
> arch/sparc/kernel/process_32.c | 2 +-
> arch/sparc/kernel/process_64.c | 2 +-
> arch/sparc/kernel/signal_32.c | 2 +-
> arch/sparc/kernel/signal_64.c | 2 +-
> arch/um/include/asm/thread_info.h | 2 +
> arch/um/kernel/process.c | 5 +-
> arch/x86/include/asm/thread_info.h | 2 +
> arch/x86/kernel/process.c | 17 +
> arch/x86/kernel/signal.c | 4 +-
> arch/xtensa/include/asm/thread_info.h | 5 +-
> arch/xtensa/kernel/entry.S | 4 +-
> arch/xtensa/kernel/process.c | 2 +-
> arch/xtensa/kernel/signal.c | 3 +-
> drivers/android/binder.c | 2 +-
> fs/Makefile | 2 -
> fs/coredump.c | 2 +-
> fs/eventfd.c | 37 +-
> fs/eventpoll.c | 18 +-
> fs/file.c | 34 +-
> fs/internal.h | 3 +
> fs/io-wq.c | 1242 ----
> fs/namei.c | 84 +-
> fs/open.c | 6 +
> fs/proc/self.c | 7 -
> fs/proc/thread_self.c | 7 -
> include/linux/entry-common.h | 7 +-
> include/linux/entry-kvm.h | 4 +-
> include/linux/eventfd.h | 7 +
> include/linux/fcntl.h | 2 +-
> include/linux/fdtable.h | 2 +-
> include/linux/io_uring.h | 46 +-
> include/linux/namei.h | 1 +
> include/linux/net.h | 3 -
> include/linux/sched.h | 3 +
> include/linux/sched/jobctl.h | 4 +-
> include/linux/sched/signal.h | 18 +-
> include/linux/sched/task.h | 2 +
> include/linux/socket.h | 4 +
> include/linux/syscalls.h | 2 +-
> include/linux/task_work.h | 2 +
> include/linux/tracehook.h | 23 +
> include/linux/uio.h | 15 +
> include/trace/events/io_uring.h | 121 +-
> include/uapi/linux/eventpoll.h | 6 +
> include/uapi/linux/io_uring.h | 115 +-
> include/uapi/linux/openat2.h | 4 +
> io_uring/Makefile | 6 +
> io_uring/io-wq.c | 1398 +++++
> {fs => io_uring}/io-wq.h | 47 +-
> {fs => io_uring}/io_uring.c | 9209 ++++++++++++++++-------------
> kernel/entry/common.c | 14 +-
> kernel/entry/kvm.c | 2 +-
> kernel/events/uprobes.c | 2 +-
> kernel/exit.c | 2 +-
> kernel/fork.c | 33 +-
> kernel/sched/core.c | 2 +-
> kernel/signal.c | 53 +-
> kernel/task_work.c | 48 +-
> lib/iov_iter.c | 52 +-
> net/ipv4/af_inet.c | 1 -
> net/ipv6/af_inet6.c | 1 -
> net/socket.c | 92 +-
> tools/include/uapi/linux/openat2.h | 4 +
> 131 files changed, 7279 insertions(+), 5773 deletions(-)
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2023-01-03 16:16 ` Joel Fernandes
@ 2023-01-03 18:16 ` Naresh Kamboju
2023-01-03 18:27 ` Florian Fainelli
2023-01-03 18:59 ` Allen Pais
7 siblings, 0 replies; 13+ messages in thread
From: Naresh Kamboju @ 2023-01-03 18:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Tue, 3 Jan 2023 at 13:45, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.162 release.
> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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 <lkft@linaro.org>
## Build
* kernel: 5.10.162-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: c5bc645ae6f96d3949dcf1f0fb0a7c243fb525d1
* git describe: v5.10.161-64-gc5bc645ae6f9
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.161-64-gc5bc645ae6f9
## Test Regressions (compared to v5.10.160-19-gbc32b2c55e20)
## Metric Regressions (compared to v5.10.160-19-gbc32b2c55e20)
## Test Fixes (compared to v5.10.160-19-gbc32b2c55e20)
## Metric Fixes (compared to v5.10.160-19-gbc32b2c55e20)
## Test result summary
total: 138327, pass: 116359, fail: 3491, skip: 18160, xfail: 317
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 151 total, 148 passed, 3 failed
* arm64: 49 total, 46 passed, 3 failed
* i386: 39 total, 37 passed, 2 failed
* mips: 31 total, 29 passed, 2 failed
* parisc: 8 total, 8 passed, 0 failed
* powerpc: 32 total, 25 passed, 7 failed
* riscv: 16 total, 14 passed, 2 failed
* s390: 16 total, 16 passed, 0 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 42 total, 40 passed, 2 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* 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-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2023-01-03 18:16 ` Naresh Kamboju
@ 2023-01-03 18:27 ` Florian Fainelli
2023-01-03 18:59 ` Allen Pais
7 siblings, 0 replies; 13+ messages in thread
From: Florian Fainelli @ 2023-01-03 18:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow
On 1/3/23 00:13, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.162 release.
> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2023-01-03 18:27 ` Florian Fainelli
@ 2023-01-03 18:59 ` Allen Pais
7 siblings, 0 replies; 13+ messages in thread
From: Allen Pais @ 2023-01-03 18:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
> This is the start of the stable review cycle for the 5.10.162 release.
> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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 x86_64 and ARM64 test systems. No errors or
regressions.
Tested-by: Allen Pais <apais@linux.microsoft.com>
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-03 16:16 ` Joel Fernandes
@ 2023-01-04 5:29 ` Greg Kroah-Hartman
2023-01-04 21:56 ` Joel Fernandes
0 siblings, 1 reply; 13+ messages in thread
From: Greg Kroah-Hartman @ 2023-01-04 5:29 UTC (permalink / raw)
To: Joel Fernandes
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Tue, Jan 03, 2023 at 04:16:07PM +0000, Joel Fernandes wrote:
> On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.162 release.
> > There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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,
>
> Testing fails. Could you please pick these 2 up?
> https://lore.kernel.org/r/20221230153215.1333921-1-joel@joelfernandes.org
> https://lore.kernel.org/all/20221230153215.1333921-2-joel@joelfernandes.org/
That is not a regression from 5.10.161, right? This release is only for
the io_uring stuff to make sure that backport was done correctly.
The current "to apply" queue for the stable trees is very large right
now due to everyone waiting to get tiny things into -rc1 instead of
before then, so the above two are still not yet queued up, sorry.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-04 5:29 ` Greg Kroah-Hartman
@ 2023-01-04 21:56 ` Joel Fernandes
2023-01-05 11:43 ` Greg Kroah-Hartman
0 siblings, 1 reply; 13+ messages in thread
From: Joel Fernandes @ 2023-01-04 21:56 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
> On Jan 4, 2023, at 12:29 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jan 03, 2023 at 04:16:07PM +0000, Joel Fernandes wrote:
>>> On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.10.162 release.
>>> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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,
>>
>> Testing fails. Could you please pick these 2 up?
>> https://lore.kernel.org/r/20221230153215.1333921-1-joel@joelfernandes.org
>> https://lore.kernel.org/all/20221230153215.1333921-2-joel@joelfernandes.org/
>
> That is not a regression from 5.10.161, right?
Yes it is not.
> This release is only for
> the io_uring stuff to make sure that backport was done correctly.
>
> The current "to apply" queue for the stable trees is very large right
> now due to everyone waiting to get tiny things into -rc1 instead of
> before then, so the above two are still not yet queued up, sorry.
Sure not a problem, I can resend again later if it is still not queued.
Thanks,
- Joel
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
2023-01-04 21:56 ` Joel Fernandes
@ 2023-01-05 11:43 ` Greg Kroah-Hartman
0 siblings, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2023-01-05 11:43 UTC (permalink / raw)
To: Joel Fernandes
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
On Wed, Jan 04, 2023 at 04:56:31PM -0500, Joel Fernandes wrote:
>
>
> > On Jan 4, 2023, at 12:29 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jan 03, 2023 at 04:16:07PM +0000, Joel Fernandes wrote:
> >>> On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 5.10.162 release.
> >>> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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,
> >>
> >> Testing fails. Could you please pick these 2 up?
> >> https://lore.kernel.org/r/20221230153215.1333921-1-joel@joelfernandes.org
> >> https://lore.kernel.org/all/20221230153215.1333921-2-joel@joelfernandes.org/
> >
> > That is not a regression from 5.10.161, right?
>
> Yes it is not.
>
> > This release is only for
> > the io_uring stuff to make sure that backport was done correctly.
> >
> > The current "to apply" queue for the stable trees is very large right
> > now due to everyone waiting to get tiny things into -rc1 instead of
> > before then, so the above two are still not yet queued up, sorry.
>
> Sure not a problem, I can resend again later if it is still not queued.
You should have already received the email notices saying they were
queued :)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5.10 00/63] 5.10.162-rc1 review
@ 2023-01-05 15:28 Joel Fernandes
0 siblings, 0 replies; 13+ messages in thread
From: Joel Fernandes @ 2023-01-05 15:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow
> On Jan 5, 2023, at 6:43 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jan 04, 2023 at 04:56:31PM -0500, Joel Fernandes wrote:
>>
>>
>>>> On Jan 4, 2023, at 12:29 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Tue, Jan 03, 2023 at 04:16:07PM +0000, Joel Fernandes wrote:
>>>>> On Tue, Jan 03, 2023 at 09:13:30AM +0100, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.10.162 release.
>>>>> There are 63 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 Thu, 05 Jan 2023 08:12:47 +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.162-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,
>>>>
>>>> Testing fails. Could you please pick these 2 up?
>>>> https://lore.kernel.org/r/20221230153215.1333921-1-joel@joelfernandes.org
>>>> https://lore.kernel.org/all/20221230153215.1333921-2-joel@joelfernandes.org/
>>>
>>> That is not a regression from 5.10.161, right?
>>
>> Yes it is not.
>>
>>> This release is only for
>>> the io_uring stuff to make sure that backport was done correctly.
>>>
>>> The current "to apply" queue for the stable trees is very large right
>>> now due to everyone waiting to get tiny things into -rc1 instead of
>>> before then, so the above two are still not yet queued up, sorry.
>>
>> Sure not a problem, I can resend again later if it is still not queued.
>
> You should have already received the email notices saying they were
> queued :)
I happen to take messages from Skynet with a grain of salt ;-).
But thank you for the automated notification!
- Joel
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-01-05 15:28 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-03 8:13 [PATCH 5.10 00/63] 5.10.162-rc1 review Greg Kroah-Hartman
2023-01-03 8:14 ` [PATCH 5.10 51/63] x86/process: setup io_threads more like normal user space threads Greg Kroah-Hartman
2023-01-03 13:44 ` [PATCH 5.10 00/63] 5.10.162-rc1 review Pavel Machek
2023-01-03 14:51 ` Guenter Roeck
2023-01-03 15:32 ` Jon Hunter
2023-01-03 16:16 ` Joel Fernandes
2023-01-04 5:29 ` Greg Kroah-Hartman
2023-01-04 21:56 ` Joel Fernandes
2023-01-05 11:43 ` Greg Kroah-Hartman
2023-01-03 18:16 ` Naresh Kamboju
2023-01-03 18:27 ` Florian Fainelli
2023-01-03 18:59 ` Allen Pais
-- strict thread matches above, loose matches on Subject: below --
2023-01-05 15:28 Joel Fernandes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox