Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 17 Jan 2022 17:44:08 +0200 | Subject | Re: [GIT PULL] signal/exit/ptrace changes for v5.17 |
| |
On Mon, Jan 17, 2022 at 5:32 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > I would like to have a version of pipe_write that sleeps in > TASK_KILLABLE.
That would actually be horrible for another reason - now it would count towards the load average. That's another difference between interruptible waits and non-interruptible ones.
Admittedly it's an entirely arbitrary one, but it's part of the whole semantic difference between TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE.
You can play with TASK_NOLOAD of course, so it's something that can be worked around, but it gets a bit ugly.
> I want the I/O wake-ups and I want the SIGKILL wake ups > but I don't want any other wake-ups. Unfortunately the I/O wake-ups in > the pipe code are sent with wake_up_interruptible. So a task sleeping > in TASK_KILLABLE won't get them.
Yeah. The code *could* use the non-interruptible 'wake_up()', and everything should work - because waking things up too much doesn't change semantics, it's just a slight pessimization. Plus the whole "nested waitqueues" isn't actually any remotely normal case, so it doesn't really matter for performance either.
But I really think it's wrong.
You're trying to work around a problem the wrong way around. If a task is dead, and is dumping core, then signals just shouldn't matter in the first place, and thus the whole "TASK_INTERRUPTIBLE vs TASK_UNINTERRUPTIBLE" really shouldn't be an issue. The fact that it is an issue means there's something wrong in signaling, not in the pipe code.
So I really think that's where the fix should be - on the signal delivery side.
Linus
| |