On Thu, Mar 25, 2021 at 08:02:11AM -0600, Jens Axboe wrote:
On 3/25/21 7:56 AM, Stefan Metzmacher wrote:
Am 25.03.21 um 14:38 schrieb Jens Axboe:
On 3/25/21 6:11 AM, Stefan Metzmacher wrote:
Am 25.03.21 um 13:04 schrieb Eric W. Biederman:
Stefan Metzmacher <metze@xxxxxxxxx> writes:
Am 25.03.21 um 12:24 schrieb Sasha Levin:
From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
[ 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 stop either.
Longer term, we may want to look into allowing stop of these threads,
as it relates to eg process freezing. For now, this prevents a spin
issue if a SIGSTOP is delivered to the parent task.
Reported-by: Stefan Metzmacher <metze@xxxxxxxxx>
Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
kernel/signal.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 55526b941011..00a3840f6037 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -288,7 +288,8 @@ bool task_set_jobctl_pending(struct task_struct *task, unsigned long mask)
JOBCTL_STOP_SIGMASK | JOBCTL_TRAPPING));
BUG_ON((mask & JOBCTL_TRAPPING) && !(mask & JOBCTL_PENDING_MASK));
- if (unlikely(fatal_signal_pending(task) || (task->flags & PF_EXITING)))
+ if (unlikely(fatal_signal_pending(task) ||
+ (task->flags & (PF_EXITING | PF_IO_WORKER))))
return false;
if (mask & JOBCTL_STOP_SIGMASK)
Again, why is this proposed for 5.11 and 5.10 already?
Has the bit about the io worker kthreads been backported?
If so this isn't horrible. If not this is nonsense.
No not yet - my plan is to do that, but not until we're 100% satisfied
with it.
Do you understand why the patches where autoselected for 5.11 and 5.10?
As far as I know, selections like these (AUTOSEL) are done by some bot
that uses whatever criteria to see if they should be applied for earlier
revisions. I'm sure Sasha can expand on that :-)
Right, it's just heuristics that help catch commits that don't have a
stable tag but should have one.
Hence it's reasonable to expect that sometimes it'll pick patches that
should not go into stable, at least not just yet. It's important to
understand that this message is just a notice that it's queued up for
stable -rc, not that it's _in_ stable just yet. There's time to object.
Right, it's even more than that: this mail (tagged with "AUTOSEL") is a
notification that happens at least a week before the patch will go in
the stable queue.
If you think any AUTOSEL patches don't need to be backported, it's
usually enough to just quickly nack them.
--
Thanks,
Sasha
