Atomic context and kernel API design

LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

An API should refrain from making promises that it cannot keep. A recent episode involving the kernel's in_atomic() macro demonstrates how things can go wrong when a function does not really do what it appears to do. It is also a good excuse to look at an under-documented (but fundamental) aspect of kernel code design.

Kernel code generally runs in one of two fundamental contexts. Process context reigns when the kernel is running directly on behalf of a (usually) user-space process; the code which implements system calls is one example. When the kernel is running in process context, it is allowed to go to sleep if necessary. But when the kernel is running in atomic context, things like sleeping are not allowed. Code which handles hardware and software interrupts is one obvious example of atomic context.

There is more to it than that, though: any kernel function moves into atomic context the moment it acquires a spinlock. Given the way spinlocks are implemented, going to sleep while holding one would be a fatal error; if some other kernel function tried to acquire the same lock, the system would almost certainly deadlock forever.

"Deadlocking forever" tends not to appear on users' wishlists for the kernel, so the kernel developers go out of their way to avoid that situation. To that end, code which is running in atomic context carefully follows a number of rules, including (1) no access to user space, and, crucially, (2) no sleeping. Problems can result, though, when a particular kernel function does not know which context it might be invoked in. The classic example is kmalloc() and friends, which take an explicit argument (GFP_KERNEL or GFP_ATOMIC) specifying whether sleeping is possible or not.

The wish to write code which can work optimally in either context is common, though. Some developers, while trying to write such code, may well stumble across the following definitions from <linux/hardirq.h>:

    /*
     * Are we doing bottom half or hardware interrupt processing?
     * Are we in a softirq context? Interrupt context?
     */
    #define in_irq()	   (hardirq_count())
    #define in_softirq()   (softirq_count())
    #define in_interrupt() (irq_count())

    #define in_atomic()	   ((preempt_count() & ~PREEMPT_ACTIVE) != 0)

It would seem that in_atomic() would fit the bill for any developer trying to decide whether a given bit of code needs to act in an atomic manner at any specific time. A quick grep through the kernel sources shows that, in fact, in_atomic() has been used in quite a few different places for just that purpose. There is only one problem: those uses are almost certainly all wrong.

The in_atomic() macro works by checking whether preemption is disabled, which seems like the right thing to do. Handlers for events like hardware interrupts will disable preemption, but so will the acquisition of a spinlock. So this test appears to catch all of the cases where sleeping would be a bad idea. Certainly a number of people who have looked at this macro have come to that conclusion.

But if preemption has not been configured into the kernel in the first place, the kernel does not raise the "preemption count" when spinlocks are acquired. So, in this situation (which is common - many distributors still do not enable preemption in their kernels), in_atomic() has no way to know if the calling code holds any spinlocks or not. So it will return zero (indicating process context) even when spinlocks are held. And that could lead to kernel code thinking that it is running in process context (and acting accordingly) when, in fact, it is not.

Given this problem, one might well wonder why the function exists in the first place, why people are using it, and what developers can really do to get a handle on whether they can sleep or not. Andrew Morton answered the first question in a relatively cryptic way:

In other words, in_atomic() works in a specific low-level situation, but it was never meant to be used in a wider context. Its placement in hardirq.h next to macros which can be used elsewhere was, thus, almost certainly a mistake. As Alan Stern pointed out, the fact that Linux Device Drivers recommends the use of in_atomic() will not have helped the situation. Your editor recommends that the authors of that book be immediately sacked.

Once these mistakes are cleared up, there is still the question of just how kernel code should decide whether it is running in an atomic context or not. The real answer is that it just can't do that. Quoting Andrew Morton again:

This pattern is consistent through the kernel - once again, the GFP_ flags example stands out in this regard. But it's also clear that this practice has not been documented to the point that kernel developers understand that things should be done this way. Consider this recent posting from Rusty Russell, who understands these issues better than most:

In fact, kmalloc() cannot figure out on its own whether sleeping is allowable or not. It has to be told by the caller. This rule is unlikely to change, so expect a series of in_atomic() removal patches starting with 2.6.26. Once that work is done, the in_atomic() macro can be moved to a safer place where it will not create further confusion.

Index entries for this article
Kernel	in_atomic()
Kernel	Spinlocks

---

(Log in to post comments)

Hmm... if in_atomic only has one or two narrow, valid uses, perhaps it shouldn't be a macro at
all?  Either a small, static function in the one source file that uses it?  GCC will still
inline it, but the static declaration would send the signal "not for outside consumption."

Indeed, you might ask why use macros at all for this kind of thing, when compiler-inlined
functions are just as efficient?

Perhaps that "one or two narrow, valid uses" are in different files?

Hmmm... it looks like something to be called by a "per-arch" files, so even "one use" actually
lives in multiple files. :-)

I guess it belongs in a header, but I still wonder if it shouldn't have a different name.

If you follow Andrew Morton's reasoning, "am I in atomic" is something a caller should never
ask.  It should be told explicitly, as in the case of kmalloc().

The case where "in_atomic" is getting used "legitimately" is in a fault handler (which should
not be a fastpath pretty much by definition).  It sounds like they're abusing preempt_count to
coax a particular behavior out of the fault handler, rather than just stating the intended
behavior directly.  That doesn't necessarily sound like clean design to me, but rather an
overly clever hack.

I'm sure someone more familiar with this mechanism can explain why it is or is not a good
mechanism.

I guess this argues for building your kernels with pre-emption enabled, at least until 2.4.26.

2.4.26 has been out for a while :p

what you are missing is that I remember correctly our editor is one of the authors.

There are many cases where admitting you are wrong and suggesting a punishment preempts
someone else suggesting a more suitable punishment. I'm suggesting flogging is a suitable
punishment. Well, not really, I was just caught up in the entertainment value of a good
flogging. 

In reality, writing is a severe form of self-flagellation and I am grateful our editor
subjected himself to it. I first bought the Second Edition of Lunux Device Drivers, bought the
Third Edition as soon as I saw it was out, and will buy the Fourth Edition as soon as I learn
of its existence.

Bring in the wonder llama consultants.

Paging Jeff Minter...

What the hell does GFP stand for?

http://lwn.net/Articles/23042/

Oops. But that is the guy who wrote about that in_atomic ref. Perhaps we need another opinion
;-)

Just kidding. Keep up the good work corbet.

Well on Windows you get General Protection Faults, in Linux it must therefore be General Fault
Protection :-)

> In fact, kmalloc() cannot figure out on its own whether sleeping is
> allowable or not...

You are (of course) correct.  Damn, but it was such a beautiful example; 
the same one I used in 2003 in my OLS keynote, and noone spotted it then 
either.

Thanks,
Rusty.

Couldn't this be problematic in the case of systems that use intrusion detection? One
technique that I am familar with is the use of MD5 sums of system binaries, to check if they
have been tampered with. Directly modifying binaries would make this prefetch technique
incompatible with systems that do MD5 checking.