[PATCH 3/5] openrisc: traps: Don't send signals to kernel mode threads

OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

dividual kworker > > > can potentially have CPU share equal to the entire UX cgroup. > > > > > > -kworker/0:0 > > > -kworker/1:0 > > > - UX > > > Task-A > > > Task-B > > > - background > > > Task-X > > >

Re: [PATCH v4 08/12] perf record: introduce --threads= command line option

Hello, On Tue, Apr 6, 2021 at 5:49 PM Bayduraev, Alexey V wrote: > > > Provide --threads option in perf record command line interface. > The option can have a value in the form of masks that specify > cpus to be monitored with data streaming threads and its layout > in system t

[tip: sched/core] sched/fair: Ignore percpu threads for imbalance pulls

:00 Committer: Peter Zijlstra CommitterDate: Fri, 09 Apr 2021 18:02:20 +02:00 sched/fair: Ignore percpu threads for imbalance pulls During load balance, LBF_SOME_PINNED will be set if any candidate task cannot be detached due to CPU affinity constraints. This can result in setting env->

[tip: sched/core] sched/fair: Ignore percpu threads for imbalance pulls

:00 Committer: Peter Zijlstra CommitterDate: Fri, 09 Apr 2021 13:52:10 +02:00 sched/fair: Ignore percpu threads for imbalance pulls During load balance, LBF_SOME_PINNED will be set if any candidate task cannot be detached due to CPU affinity constraints. This can result in setting env->

[tip: sched/core] sched/fair: Ignore percpu threads for imbalance pulls

:00 Committer: Peter Zijlstra CommitterDate: Thu, 08 Apr 2021 23:09:44 +02:00 sched/fair: Ignore percpu threads for imbalance pulls During load balance, LBF_SOME_PINNED will be set if any candidate task cannot be detached due to CPU affinity constraints. This can result in setting env->

Re: [PATCH v4 08/12] perf record: introduce --threads= command line option

On Tue, Apr 06, 2021 at 11:49:06AM +0300, Bayduraev, Alexey V wrote: SNIP > Suggested-by: Jiri Olsa > Suggested-by: Namhyung Kim > Signed-off-by: Alexey Bayduraev > --- > tools/include/linux/bitmap.h | 11 ++ > tools/lib/bitmap.c | 14 ++ > tools/perf/builtin-record.c | 317

Re: [PATCH v4 05/12] perf record: start threads in the beginning of trace streaming

> + err = write(thread->pipes.ack[1], , sizeof(msg)); > + if (err == -1) > + pr_err("threads[%d]: failed to notify on start. Error %m", > thread->tid); It might be safer to not use %m. I'm not sure if all the non glibc libcs that people use support it.

[PATCH v5 1/3] sched/fair: Ignore percpu threads for imbalance pulls

From: Lingutla Chandrasekhar During load balance, LBF_SOME_PINNED will be set if any candidate task cannot be detached due to CPU affinity constraints. This can result in setting env->sd->parent->sgc->group_imbalance, which can lead to a group being classified as group_imbalanced (rather than

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

ps in prioritizing > > Task-A and Task-B over Task-X and Task-Y. However, each individual kworker > > can potentially have CPU share equal to the entire UX cgroup. > > > > -kworker/0:0 > > -kworker/1:0 > > - UX > > ----Task-A > > Task-B > > - ba

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

However, each individual kworker > can potentially have CPU share equal to the entire UX cgroup. > > -kworker/0:0 > -kworker/1:0 > - UX > Task-A > Task-B > - background > Task-X > Task-Y > Hence we want to move all kernel threads to another cgr

Re: [PATCH v4 1/3] sched/fair: Ignore percpu threads for imbalance pulls

On 06/04/21 17:35, Dietmar Eggemann wrote: > On 01/04/2021 21:30, Valentin Schneider wrote: >> From: Lingutla Chandrasekhar >> >> During load balance, LBF_SOME_PINNED will bet set if any candidate task > > nitpick; s/bet/be ? > Yes indeed... > [...] > > Reviewed-by: Dietmar Eggemann

Re: [PATCH v4 1/3] sched/fair: Ignore percpu threads for imbalance pulls

On 01/04/2021 21:30, Valentin Schneider wrote: > From: Lingutla Chandrasekhar > > During load balance, LBF_SOME_PINNED will bet set if any candidate task nitpick; s/bet/be ? [...] Reviewed-by: Dietmar Eggemann

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

d. However, there are many kernel tasks stuck in the > > root cgroup after the boot. > > > > We see all kworker threads are in the root cpu cgroup. This is because, > > tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration. > > This restriction is in place t

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

her share > compared to the other tasks inside important cgroups. This is mitigated > by moving all tasks inside root cgroup to a different cgroup after > Android is booted. However, there are many kernel tasks stuck in the > root cgroup after the boot. > > We see all kworker threads

[PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

tasks inside root cgroup to a different cgroup after Android is booted. However, there are many kernel tasks stuck in the root cgroup after the boot. We see all kworker threads are in the root cpu cgroup. This is because, tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

d. However, there are many kernel tasks stuck in the > > root cgroup after the boot. > > > > We see all kworker threads are in the root cpu cgroup. This is because, > > tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration. > > This restriction

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

her share > compared to the other tasks inside important cgroups. This is mitigated > by moving all tasks inside root cgroup to a different cgroup after > Android is booted. However, there are many kernel tasks stuck in the > root cgroup after the boot. > > We see all kworker

[PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

tasks inside root cgroup to a different cgroup after Android is booted. However, there are many kernel tasks stuck in the root cgroup after the boot. We see all kworker threads are in the root cpu cgroup. This is because, tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration

[PATCH v4 08/12] perf record: introduce --threads= command line option

Provide --threads option in perf record command line interface. The option can have a value in the form of masks that specify cpus to be monitored with data streaming threads and its layout in system topology. The masks can be filtered using cpu mask provided via -C option. The specification

[PATCH v4 05/12] perf record: start threads in the beginning of trace streaming

== -1) + pr_err("threads[%d]: failed to notify on start. Error %m", thread->tid); + + pr_debug("threads[%d]: started on cpu=%d\n", thread->tid, sched_getcpu()); + + pollfd = >pollfd; + ctlfd_pos = thread->ctlfd_pos; + + for (;;) { +

[PATCH v4 04/12] perf record: stop threads in the end of trace streaming

Signal thread to terminate by closing write fd of msg pipe. Receive THREAD_MSG__READY message as the confirmation of the thread's termination. Stop threads created for parallel trace streaming prior their stats processing. Signed-off-by: Alexey Bayduraev --- tools/perf/builtin-record.c | 30

Re: [PATCH 0/6] Allow signals for IO threads

Am 01.04.21 um 18:24 schrieb Linus Torvalds: > On Thu, Apr 1, 2021 at 9:00 AM Stefan Metzmacher wrote: >> >> I haven't tried it, but it seems gdb tries to use PTRACE_PEEKUSR >> against the last thread tid listed under /proc//tasks/ in order to >> get the architecture for the userspace application

Re: [PATCH v4 1/3] sched/fair: Ignore percpu threads for imbalance pulls

On Thu, 1 Apr 2021 at 21:30, Valentin Schneider wrote: > > From: Lingutla Chandrasekhar > > During load balance, LBF_SOME_PINNED will bet set if any candidate task > cannot be detached due to CPU affinity constraints. This can result in > setting env->sd->parent->sgc->group_imbalance, which can

[PATCH v4 1/3] sched/fair: Ignore percpu threads for imbalance pulls

From: Lingutla Chandrasekhar During load balance, LBF_SOME_PINNED will bet set if any candidate task cannot be detached due to CPU affinity constraints. This can result in setting env->sd->parent->sgc->group_imbalance, which can lead to a group being classified as group_imbalanced (rather than

[PATCH v14 5/6] locking/qspinlock: Avoid moving certain threads between waiting queues in CNA

Prohibit moving certain threads (e.g., in irq and nmi contexts) to the secondary queue. Those prioritized threads will always stay in the primary queue, and so will have a shorter wait time for the lock. Signed-off-by: Alex Kogan Reviewed-by: Steve Sistare Reviewed-by: Waiman Long --- kernel

Re: [PATCH 0/6] Allow signals for IO threads

On Thu, Apr 1, 2021 at 9:00 AM Stefan Metzmacher wrote: > > I haven't tried it, but it seems gdb tries to use PTRACE_PEEKUSR > against the last thread tid listed under /proc//tasks/ in order to > get the architecture for the userspace application Christ, what an odd hack. Why wouldn't it just do

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

Hi Jens, >>> I don't assume signals wanted by userspace should potentially handled in an >>> io_thread... >>> e.g. things set with fcntl(fd, F_SETSIG,) used together with F_SETLEASE? >> >> I guess we do actually need it, if we're not fiddling with >> wants_signal() for them. To quell Oleg's

Re: [PATCH 0/6] Allow signals for IO threads

On Thu, Apr 1, 2021 at 7:58 AM Stefan Metzmacher wrote: > > > > > Ok, the following makes gdb happy again: > > > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -163,6 +163,8 @@ int copy_thread(unsigned long clone_flags, unsigned > > long sp, unsigned long arg, > >

Re: [PATCH 0/6] Allow signals for IO threads

Am 01.04.21 um 17:39 schrieb Linus Torvalds: > On Thu, Apr 1, 2021 at 7:58 AM Stefan Metzmacher wrote: >> >>> >>> Ok, the following makes gdb happy again: >>> >>> --- a/arch/x86/kernel/process.c >>> +++ b/arch/x86/kernel/process.c >>> @@ -163,6 +163,8 @@ int copy_thread(unsigned long

Re: [PATCH 0/6] Allow signals for IO threads

Hi Jens, >> For help, type "help". >> Type "apropos word" to search for commands related to "word". >> Attaching to process 1320 >> [New LWP 1321] >> [New LWP 1322] >> >> warning: Selected architecture i386:x86-64 is not compatible with reported >> target architecture i386 >> >> warning:

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

On 3/27/21 11:40 AM, Eric W. Biederman wrote: > Jens Axboe writes: > >> On 3/26/21 4:38 PM, Jens Axboe wrote: >>> OK good point, and follows the same logic even if it won't make a >>> difference in my case. I'll make the change. >> >> Made the suggested edits and ran the quick tests and the

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

index 5b75fbe3d2d6..f2718350bf4b 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2752,15 +2752,6 @@ bool get_signal(struct ksignal *ksig) >*/ > current->flags |= PF_SIGNALED; > > - /* > - * PF_IO

Re: [PATCH 0/6] Allow signals for IO threads

; > kthread_frame_init(frame, sp, arg); > return 0; > } Confirmed, it stops complaining about the arch at that point. > I'm wondering if we should decouple the PF_KTHREAD and PF_IO_WORKER > cases even more and keep as much of a userspace-like copy_thread as > possible. Probably makes sense, the only thing they really share is the func+arg setup. Hence PF_IO_WORKER threads likely just use the rest of the init, where it doesn't conflict with the frame setup. -- Jens Axboe

Re: [PATCH 0/6] Allow signals for IO threads

Hi Jens, > root@ub1704-166:~# LANG=C gdb --pid 1320 > GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it.

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

wrote: >>>>>> Jens Axboe writes: >>>>>> >>>>>>> We go through various hoops to disallow signals for the IO threads, but >>>>>>> there's really no reason why we cannot just allow them. The IO threads >>>>&g

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

t;> >>>>>> We go through various hoops to disallow signals for the IO threads, but >>>>>> there's really no reason why we cannot just allow them. The IO threads >>>>>> never return to userspace like a normal thread, and hence don't go >>>

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

Jens Axboe writes: > On 3/26/21 4:23 PM, Eric W. Biederman wrote: >> Jens Axboe writes: >> >>> On 3/26/21 2:29 PM, Eric W. Biederman wrote: >>>> Jens Axboe writes: >>>> >>>>> We go through various hoops to disallow signals for t

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

On 3/26/21 4:23 PM, Eric W. Biederman wrote: > Jens Axboe writes: > >> On 3/26/21 2:29 PM, Eric W. Biederman wrote: >>> Jens Axboe writes: >>> >>>> We go through various hoops to disallow signals for the IO threads, but >>>> there's really n

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

Jens Axboe writes: > On 3/26/21 2:29 PM, Eric W. Biederman wrote: >> Jens Axboe writes: >> >>> We go through various hoops to disallow signals for the IO threads, but >>> there's really no reason why we cannot just allow them. The IO threads >>> neve

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

On 3/26/21 2:29 PM, Eric W. Biederman wrote: > Jens Axboe writes: > >> We go through various hoops to disallow signals for the IO threads, but >> there's really no reason why we cannot just allow them. The IO threads >> never return to userspace like a normal thread, an

Re: [PATCH 1/7] kernel: don't call do_exit() for PF_IO_WORKER threads

On 3/26/21 2:43 PM, Eric W. Biederman wrote: > Jens Axboe writes: > >> Right now we're never calling get_signal() from PF_IO_WORKER threads, but >> in preparation for doing so, don't handle a fatal signal for them. The >> workers have state they need to cleanup when ex

Re: [PATCH 1/7] kernel: don't call do_exit() for PF_IO_WORKER threads

Jens Axboe writes: > Right now we're never calling get_signal() from PF_IO_WORKER threads, but > in preparation for doing so, don't handle a fatal signal for them. The > workers have state they need to cleanup when exiting, and they don't do > coredumps, so just return instead o

Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

Jens Axboe writes: > We go through various hoops to disallow signals for the IO threads, but > there's really no reason why we cannot just allow them. The IO threads > never return to userspace like a normal thread, and hence don't go through > normal signal processing. Instead

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

I got lost :/ >>>> >>>> Let's bring you back in :-) >>>> >>>>> On 03/25, Jens Axboe wrote: >>>>>> >>>>>> With IO threads accepting signals, including SIGSTOP, >>>>> >>>>> wher

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

back in :-) >>> >>>> On 03/25, Jens Axboe wrote: >>>>> >>>>> With IO threads accepting signals, including SIGSTOP, >>>> >>>> where can I find this change? Looks like I wasn't cc'ed... >>> >>> It's this very series. >&

Re: [PATCHSET v2 0/7] Allow signals for IO threads

On 3/26/21 9:51 AM, Jens Axboe wrote: > Hi, > > For the v1 posting, see here: Sigh, just ignore the last 4 patches (07...10/10) in this series, there are sitting on top of this series and I messed up the git send-email. This patch series ends in the 4 reverts. -- Jens Axboe

[PATCH 06/10] Revert "signal: don't allow STOP on PF_IO_WORKER threads"

This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597. The IO threads allow and handle SIGSTOP now, so don't special case them anymore in task_set_jobctl_pending(). Signed-off-by: Jens Axboe --- kernel/signal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel

[PATCH 4/7] Revert "signal: don't allow sending any signals to PF_IO_WORKER threads"

This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5. IO threads now take signals just fine, so there's no reason to limit them specifically. Revert the change that prevented that from happening. Signed-off-by: Jens Axboe --- kernel/signal.c | 3 --- 1 file changed, 3 deletions

[PATCH 7/7] Revert "signal: don't allow STOP on PF_IO_WORKER threads"

This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597. The IO threads allow and handle SIGSTOP now, so don't special case them anymore in task_set_jobctl_pending(). Signed-off-by: Jens Axboe --- kernel/signal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel

[PATCH 2/7] io_uring: handle signals for IO threads like a normal thread

We go through various hoops to disallow signals for the IO threads, but there's really no reason why we cannot just allow them. The IO threads never return to userspace like a normal thread, and hence don't go through normal signal processing. Instead, just check for a pending signal as part

[PATCH 03/10] Revert "signal: don't allow sending any signals to PF_IO_WORKER threads"

This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5. IO threads now take signals just fine, so there's no reason to limit them specifically. Revert the change that prevented that from happening. Signed-off-by: Jens Axboe --- kernel/signal.c | 3 --- 1 file changed, 3 deletions

[PATCH 1/7] kernel: don't call do_exit() for PF_IO_WORKER threads

Right now we're never calling get_signal() from PF_IO_WORKER threads, but in preparation for doing so, don't handle a fatal signal for them. The workers have state they need to cleanup when exiting, and they don't do coredumps, so just return instead of performing either a dump or calling do_exit

[PATCHSET v2 0/7] Allow signals for IO threads

in get_signal() for PF_IO_WORKER. This is only a problem for nested signals, like SIGSTOP followed by SIGKILL. We can't have get_signal() calling do_exit() on behalf of the IO threads, they have cleanups to do. Thanks Stefan. - Move signal masking to when the PF_IO_WORKER thread is created

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

On 3/26/21 9:23 AM, Stefan Metzmacher wrote: > Am 26.03.21 um 16:01 schrieb Jens Axboe: >> On 3/26/21 7:48 AM, Oleg Nesterov wrote: >>> Jens, sorry, I got lost :/ >> >> Let's bring you back in :-) >> >>> On 03/25, Jens Axboe wrote: >>>>

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

Am 26.03.21 um 16:01 schrieb Jens Axboe: > On 3/26/21 7:48 AM, Oleg Nesterov wrote: >> Jens, sorry, I got lost :/ > > Let's bring you back in :-) > >> On 03/25, Jens Axboe wrote: >>> >>> With IO threads accepting signals, including SIGSTOP, >> >

Re: [PATCH 0/6] Allow signals for IO threads

I'll try your stop + kill, I just >>>>>>>>>> tested both of them separately and didn't observe anything. I also >>>>>>>>>> ran >>>>>>>>>> your io_uring-cp example (and found a bug in the example, fixed and

Re: [PATCH 0/6] Allow signals for IO threads

serve anything. I also ran >>>>>>>>> your io_uring-cp example (and found a bug in the example, fixed and >>>>>>>>> pushed), fwiw. >>>>>>>> >>>>>>>> I can reproduce this one! I'll take a closer look.

Re: [PATCH 0/6] Allow signals for IO threads

xample, fixed and >>>>>>>> pushed), fwiw. >>>>>>> >>>>>>> I can reproduce this one! I'll take a closer look. >>>>>> >>>>>> OK, that one is actually pretty straight forward - we rely on cleaning >&g

Re: [PATCH 0/6] Allow signals for IO threads

t;> I can reproduce this one! I'll take a closer look. >>>>> >>>>> OK, that one is actually pretty straight forward - we rely on cleaning >>>>> up on exit, but for fatal cases, get_signal() will call do_exit() for us >>>>> and never r

Re: [PATCH 0/6] Allow signals for IO threads

gt; I can reproduce this one! I'll take a closer look. >>>>> >>>>> OK, that one is actually pretty straight forward - we rely on cleaning >>>>> up on exit, but for fatal cases, get_signal() will call do_exit() for us >>>>> and never return. So

Re: [PATCH 0/6] Allow signals for IO threads

I also ran >>>>>> your io_uring-cp example (and found a bug in the example, fixed and >>>>>> pushed), fwiw. >>>>> >>>>> I can reproduce this one! I'll take a closer look. >>>> >>>> OK, that one is actually p

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

On 3/26/21 7:48 AM, Oleg Nesterov wrote: > Jens, sorry, I got lost :/ Let's bring you back in :-) > On 03/25, Jens Axboe wrote: >> >> With IO threads accepting signals, including SIGSTOP, > > where can I find this change? Looks like I wasn't cc'ed... It's this

Re: [PATCH 0/6] Allow signals for IO threads

an >>>>>> your io_uring-cp example (and found a bug in the example, fixed and >>>>>> pushed), fwiw. >>>>> >>>>> I can reproduce this one! I'll take a closer look. >>>> >>>> OK, that one is actually p

Re: [PATCH 0/6] Allow signals for IO threads

>>>> pushed), fwiw. >>>> >>>> I can reproduce this one! I'll take a closer look. >>> >>> OK, that one is actually pretty straight forward - we rely on cleaning >>> up on exit, but for fatal cases, get_signal() will call do_exit() for u

Re: [PATCH 0/6] Allow signals for IO threads

. >> >> OK, that one is actually pretty straight forward - we rely on cleaning >> up on exit, but for fatal cases, get_signal() will call do_exit() for us >> and never return. So we might need a special case in there to deal with >> that, or some other way of ensuring th

Re: [PATCH 0/6] Allow signals for IO threads

. >> >> OK, that one is actually pretty straight forward - we rely on cleaning >> up on exit, but for fatal cases, get_signal() will call do_exit() for us >> and never return. So we might need a special case in there to deal with >> that, or some other way of ensuring

Re: [PATCH 0/6] Allow signals for IO threads

exit, but for fatal cases, get_signal() will call do_exit() for us > and never return. So we might need a special case in there to deal with > that, or some other way of ensuring that fatal signal gets processed > correctly for IO threads. And if (fatal_signal_pending(current)) doesn't prevent get_signal() from being called? metze

Re: [PATCH 0/6] Allow signals for IO threads

to deal with that, or some other way of ensuring that fatal signal gets processed correctly for IO threads. -- Jens Axboe

Re: [PATCH 0/6] Allow signals for IO threads

On 3/26/21 7:54 AM, Jens Axboe wrote: >> The KILL after STOP deadlock still exists. > > In which tree? Sounds like you're still on the old one with that > incremental you sent, which wasn't complete. > >> Does io_wq_manager() exits without cleaning up on SIGKILL? > > No, it should kill up in

Re: [PATCH 0/6] Allow signals for IO threads

us thread today, the seemingly much saner approach >>>> is just to allow signals (including SIGSTOP) for the PF_IO_WORKER IO >>>> threads. If we just have the threads call get_signal() for >>>> signal_pending(), then everything just falls out naturally with how >

Re: [PATCH 2/8] kernel: unmask SIGSTOP for IO threads

Jens, sorry, I got lost :/ On 03/25, Jens Axboe wrote: > > With IO threads accepting signals, including SIGSTOP, where can I find this change? Looks like I wasn't cc'ed... > unmask the > SIGSTOP signal from the default blocked mask. > > Signed-off-by: Jens Axboe > ---

Re: [PATCH 0/6] Allow signals for IO threads

signals (including SIGSTOP) for the PF_IO_WORKER IO >>> threads. If we just have the threads call get_signal() for >>> signal_pending(), then everything just falls out naturally with how >>> we receive and handle signals. >>> >>> Patch 1 adds support fo

Re: [PATCH 0/6] Allow signals for IO threads

On 3/26/21 5:48 AM, Stefan Metzmacher wrote: > > Am 26.03.21 um 01:39 schrieb Jens Axboe: >> Hi, >> >> As discussed in a previous thread today, the seemingly much saner approach >> is just to allow signals (including SIGSTOP) for the PF_IO_WORKER IO >> threa

[PATCH 6/8] Revert "signal: don't allow STOP on PF_IO_WORKER threads"

This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597. The IO threads allow and handle SIGSTOP now, so don't special case them anymore in task_set_jobctl_pending(). Signed-off-by: Jens Axboe --- kernel/signal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel

[PATCH 3/8] Revert "signal: don't allow sending any signals to PF_IO_WORKER threads"

This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5. IO threads now take signals just fine, so there's no reason to limit them specifically. Revert the change that prevented that from happening. Signed-off-by: Jens Axboe --- kernel/signal.c | 3 --- 1 file changed, 3 deletions

[PATCH 1/8] io_uring: handle signals for IO threads like a normal thread

We go through various hoops to disallow signals for the IO threads, but there's really no reason why we cannot just allow them. The IO threads never return to userspace like a normal thread, and hence don't go through normal signal processing. Instead, just check for a pending signal as part

[PATCH 0/6] Allow signals for IO threads

Hi, As discussed in a previous thread today, the seemingly much saner approach is just to allow signals (including SIGSTOP) for the PF_IO_WORKER IO threads. If we just have the threads call get_signal() for signal_pending(), then everything just falls out naturally with how we receive and handle

[PATCH 2/8] kernel: unmask SIGSTOP for IO threads

With IO threads accepting signals, including SIGSTOP, unmask the SIGSTOP signal from the default blocked mask. Signed-off-by: Jens Axboe --- kernel/fork.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/fork.c b/kernel/fork.c index d3171e8e88e5..d5a40552910f 100644

[PATCH 2/2] proc: don't show PF_IO_WORKER threads as threads in /proc//task/

We don't allow SIGSTOP and ptrace attach to these threads, and that confuses applications like gdb that assume they can attach to any thread listed in /proc//task/. gdb then enters an infinite loop of retrying attach, even though it fails with the same error (-EPERM) every time. Skip over

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

t; Stefan Metzmacher writes: >>>>> >>>>>> Am 25.03.21 um 12:24 schrieb Sasha Levin: >>>>>>> From: "Eric W. Biederman" >>>>>>> >>>>>>> [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ]

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

schrieb Sasha Levin: From: "Eric W. Biederman" [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] Just like we don't allow normal signals to IO threads, don't deliver a STOP to a task that has PF_IO_WORKER set. The IO threads don't take signals in general, and have no means o

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

gt; Am 25.03.21 um 12:24 schrieb Sasha Levin: >>>>>> From: "Eric W. Biederman" >>>>>> >>>>>> [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] >>>>>> >>>>>> Just like we don't allow

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

gt; From: "Eric W. Biederman" >>>>> >>>>> [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] >>>>> >>>>> Just like we don't allow normal signals to IO threads, don't deliver a >>>>> STOP to a task that has PF_IO_WORK

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] >>>> >>>> Just like we don't allow normal signals to IO threads, don't deliver a >>>> STOP to a task that has PF_IO_WORKER set. The IO threads don't take >>>> signals in general, and ha

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

Am 25.03.21 um 13:04 schrieb Eric W. Biederman: > Stefan Metzmacher writes: > >> Am 25.03.21 um 12:24 schrieb Sasha Levin: >>> From: "Eric W. Biederman" >>> >>> [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] >>> >&g

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

Stefan Metzmacher writes: > Am 25.03.21 um 12:24 schrieb Sasha Levin: >> From: "Eric W. Biederman" >> >> [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] >> >> Just like we don't allow normal signals to IO threads, don't deliver a

Re: [PATCH AUTOSEL 5.11 42/44] signal: don't allow sending any signals to PF_IO_WORKER threads

t; thread. Linux does allow this kind of behavior for regular threads, but > it's really a compatability thing that we need not care about for the IO > threads. > > Reported-by: Stefan Metzmacher > Signed-off-by: Jens Axboe > Signed-off-by: Sasha Levin > --- > kernel/sig

Re: [PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

Am 25.03.21 um 12:24 schrieb Sasha Levin: > From: "Eric W. Biederman" > > [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] > > Just like we don't allow normal signals to IO threads, don't deliver a > STOP to a task that has PF_IO_WORKER set. The IO

[PATCH AUTOSEL 5.10 38/39] signal: don't allow STOP on PF_IO_WORKER threads

From: "Eric W. Biederman" [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] Just like we don't allow normal signals to IO threads, don't deliver a STOP to a task that has PF_IO_WORKER set. The IO threads don't take signals in general, and have no means of flushing out a s

[PATCH AUTOSEL 5.10 37/39] signal: don't allow sending any signals to PF_IO_WORKER threads

From: Jens Axboe [ Upstream commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5 ] They don't take signals individually, and even if they share signals with the parent task, don't allow them to be delivered through the worker thread. Linux does allow this kind of behavior for regular threads

[PATCH AUTOSEL 5.11 43/44] signal: don't allow STOP on PF_IO_WORKER threads

From: "Eric W. Biederman" [ Upstream commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597 ] Just like we don't allow normal signals to IO threads, don't deliver a STOP to a task that has PF_IO_WORKER set. The IO threads don't take signals in general, and have no means of flushing out a s

[PATCH AUTOSEL 5.11 42/44] signal: don't allow sending any signals to PF_IO_WORKER threads

From: Jens Axboe [ Upstream commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5 ] They don't take signals individually, and even if they share signals with the parent task, don't allow them to be delivered through the worker thread. Linux does allow this kind of behavior for regular threads

Re: [PATCH 2/2] signal: don't allow STOP on PF_IO_WORKER threads

On 03/20, Eric W. Biederman wrote: > > But please tell me why is it not the right thing to have the io_uring > helper threads stop? Why is it ok for that process to go on consuming > cpu resources in a non-stoppable way. Yes, I have the same question ;) Oleg.

Re: [PATCH 2/2] signal: don't allow STOP on PF_IO_WORKER threads

On 03/20, Jens Axboe wrote: > > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2349,6 +2349,10 @@ static bool do_signal_stop(int signr) > > t = current; > while_each_thread(current, t) { > + /* don't S

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

On 3/21/21 8:54 AM, Eric W. Biederman wrote: > Jens Axboe writes: > >> On 3/20/21 3:38 PM, Eric W. Biederman wrote: >>> Linus Torvalds writes: >>> >>>> On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman >>>> wrote: >>>>> >

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

Jens Axboe writes: > On 3/20/21 3:38 PM, Eric W. Biederman wrote: >> Linus Torvalds writes: >> >>> On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman >>> wrote: >>>> >>>> The creds should be reasonably in-sync with the rest of

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

On 3/20/21 3:38 PM, Eric W. Biederman wrote: > Linus Torvalds writes: > >> On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman >> wrote: >>> >>> The creds should be reasonably in-sync with the rest of the threads. >> >> It's not about credentials

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

Linus Torvalds writes: > On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman > wrote: >> >> The creds should be reasonably in-sync with the rest of the threads. > > It's not about credentials (despite the -EPERM). > > It's about the fact that kernel threads cannot

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman wrote: > > The creds should be reasonably in-sync with the rest of the threads. It's not about credentials (despite the -EPERM). It's about the fact that kernel threads cannot handle signals, and then get caught in endless

  1   2   3   4   5   6   7   8   9   10   >