Messages in this thread | | | From | "Eric W. Biederman" <> | Date | Mon, 17 Jan 2022 10:31:36 -0600 | Subject | Re: [GIT PULL] signal/exit/ptrace changes for v5.17 |
| |
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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.
Yes. I don't want to make a change that changes the load average.
>> 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.
The actual signaling is shutdown, (except for the special case of SIGKILL being able to terminate the coredump). It is io_uring and anything else that is not a signal that causes signal_pending() to return true.
I have not found any solution I am happy with yet, I am just brainstorming.
Part of the problem is that I really don't want to perform process shutdown and remove evidence of why the process crashed. So maybe shutting down io_uring is fine in that case but I don't like that either.
The more I look at all of the interesting corner cases the more I wonder if the solution isn't to have the coredump code fork a kernel-only userspace process (like the io_uring threads are kernel-only userspace threads). That would at least allow kernel functionality to work like normal and greatly reduce the chance of weird feature interactions.
Hmm. A special kernel-only thread might even be enough as io_uring would not be directing task_work at it.
You have been me some good information and I think I just need to sleep on this problem a bit more to come up with a non-hacky solution.
Eric
| |