LWN: Comments on "TASK_KILLABLE"

w00t for exception-throwing languages

NachoGomez — Fri, 08 Jul 2022 13:55:27 +0000

> If people could start writing their *kernels* in the first kind of language, we would have even fewer problems (but there are a bunch of things that have to be resolved before this happens).

Well, 14 years later Linus Torvalds hinted the use of Rust in the Linux kernel by 2023, so it seems the bunch of things are going to be resolved soon ;-)

https://thenewstack.io/rust-in-the-linux-kernel-by-2023-l...

TASK_KILLABLE

nix — Fri, 25 Jul 2008 20:28:05 +0000

If it's in KILLABLE state, it *does* know how to deal with signals within 
the kernel, and its in-kernel state can be cleanly unwound. The reason 
that this doesn't propagate up to userspace as an EINTR is simply that 
there is in effect a Unix guarantee that filesystem operations cannot be 
interrupted, and the vast majority of userspace code relies on this 
guarantee and will malfunction if it starts getting EINTRs from tasks. 
(This is what the old 'intr' option did, and boy were the results messy.)

That's why it only responds to SIGKILL: because SIGKILL, by definition, 
doesn't get propagated to userspace, because the process's userspace 
component is killed by the SIGKILL.

TASK_KILLABLE

mcortese — Thu, 24 Jul 2008 17:49:53 +0000

If it's holding a lock (which it generally is, or the sleep would be interruptible) it's probably doing that because some data structure protected by that lock is in an inconsistent state.
...whereas a KILLABLE task, despite having data in inconsistent state and not knowing how to deal with most incoming signals (and in that being much like the UNINTERRUPTIBLE variety), despite all that, it still knows how to deal with just one type of signal, kill.

Are there a lot of such tasks out there? (irony not intended, I really want to understand how much this change can improve the kernel)

TASK_KILLABLE

nix — Mon, 21 Jul 2008 21:09:23 +0000

How can you tell what queues it's on? If it's holding a lock (which it 
generally is, or the sleep would be interruptible) it's probably doing 
that because some data structure protected by that lock is in an 
inconsistent state. That data structure may very well not be per-process. 
How do you clean it up?

(And the answer is not always 'discard it': it may hold an inode lock and 
the inode in question has dirty data associated with it. Discarding that 
would not be a good idea!)

I suspect that uninterruptible sleep will always be with us in *some* form 
(at least until every single data structure in the kernel, and every 
single code flow path, gains cleanup handlers: and we know from C++ 
exceptions just how very easy that is to make work right and how very easy 
it is to trap all code flow paths that may need cleanups of some kind. Oh, 
sorry, did I say 'easy'? That should be 'difficult'.)

TASK_KILLABLE

mcortese — Mon, 21 Jul 2008 18:06:01 +0000

Is it really impossible to get rid of a process stuck in an UNINTERRUPTIBLE wait? What prevents the kernel from just removing it from any queue and freeing its allocated memory?

w00t for exception-throwing languages

renox — Thu, 10 Jul 2008 11:02:48 +0000

That's *very* different: catching all possible case is difficult for C programmers so it's
difficult also for code review to find those missing case.

It's much more easy to catch those guilty of wrapping their code with empy catch{} and sending
them to do other things than programming.

w00t for exception-throwing languages

leoc — Tue, 08 Jul 2008 17:56:52 +0000

Some languages throw exceptions when bad stuff (like an interrupted file write) happens.

Yes, but bad programmers use those languages too, and seem to actively enjoy doing things like wrapping large amounts of logic with empty or otherwise useless exception handlers.

Don't forget the ten commandments...

walles — Mon, 07 Jul 2008 05:14:27 +0000

... for C programmers. Let me quote the sixth commandment for you:

"
If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ``it cannot happen to me'', the gods shall surely punish thee for thy arrogance.
"

Writing broken code for yourself is OK. Writing broken code for others is not.

w00t for exception-throwing languages

giraffedata — Sat, 05 Jul 2008 23:39:35 +0000

Things are getting better though. So maybe 10 years from now the uninterruptible sleeps can be removed from the kernel.

There will have to be advances on other fronts for us to go that far. The article covers one of the major reasons for uninterruptible sleep today: that your client can't deal with a half-finished operation. But the other reason programs do uninterruptible sleep is that they themselves lack the intelligence to finish a partially done operation -- i.e. there's nowhere to get off the highway before the destination.

I have found it takes some very hard work to make it possible to get out of something in the middle. You have to carefully decide whether to spend time and bug tolerance for that or use it for something else.

w00t for exception-throwing languages

walles — Fri, 04 Jul 2008 11:35:09 +0000

Some languages throw exceptions when bad stuff (like an interrupted file write) happens.  They
are easy to write in and is what most things should be written in.

Some languages (like C, assembler, C++) return error codes when bad stuff happens.  These
error codes often get ignored.  And programs written in these languages often have bugs of the
kind that are mentioned in this article.  These languages are good for writing kernels and not
that much else.

Now, if people could just stick to the first kind of language for their user-space apps we
wouldn't be having these problems.  If people could start writing their *kernels* in the first
kind of language, we would have even fewer problems (but there are a bunch of things that have
to be resolved before this happens).

Unfortunately, in practice, many people tend to go with the second kind of language for no
particular reason.

Things are getting better though.  So maybe 10 years from now the uninterruptible sleeps can
be removed from the kernel.

Anyway, w00t for exception-throwing (and bounds-checking and garbage-collecting) languages!

signalfd

i3839 — Thu, 03 Jul 2008 13:43:22 +0000

Assuming the signalfd manpage can be trusted, RTFM. ;-)

> signalfd()  is available on Linux since kernel 2.6.22.  Working support
> is provided in glibc since version 2.8.

agree

alex — Thu, 03 Jul 2008 13:27:30 +0000

I can only nod in agreement having spent many-many hours trying to get signal handling behave
in an above-the-os DBT. The number of corner cases is quite surprising.

TASK_KILLABLE

zlynx — Thu, 03 Jul 2008 05:17:44 +0000

signalfd is what you're looking for, although I'm not clear on its merge status.

TASK_KILLABLE

jwb — Thu, 03 Jul 2008 03:55:57 +0000

This is a great idea.  Signals are the worst, stupidest part of Unix (yes, they are even more
stupid than creat) and EINTR has a long history of exposing errors in programs.  I have never
seen any program which I could confidently claim handles all signals correctly.  The nature of
the asynchronous delivery and the completely undefined state of the program which takes the
signal makes it impossible to prove or even convincingly demonstrate that Unix programs are
correct in this regard.

I'd be very happy to see Linux moving over to the BSD kqueue API, where signals are handled in
a program's main i/o loop instead of being delivered to magical handlers.  This greatly
simplifies the programming and makes it possible to have confidence in the correctness of a
program.