On Mon, 11 Sept 2023 at 15:20, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > Going out on a crazy idea, I wonder if we could get the compiler to help us > here. As all preempt disabled locations are static, and as for functions, > they can be called with preemption enabled or disabled. Would it be > possible for the compiler to mark all locations that need preemption disabled? Definitely not. Those preempt-disabled areas aren't static, for one thing. Any time you take any exception in kernel space, your exception handles is all dynamically preemtible or not, possibly depending on architecture details) Yes, most exception handlers then have magic rules: page faults won't get past a particular point if they happened while not preemptible, for example. And interrupts will disable preemption themselves. But we have a ton of code that runs lots of subtle code in exception handlers that is very architecture-dependent, whether it is things like unaligned fixups, or instruction rewriting things for dynamic calls, or a lot of very grotty code. Most (all?) of it could probably be made to be non-preemptible, but it's a lot of code for a lot of architectures, and it's not the trivial kind. And that's ignoring all the code that is run in just regular process context with no exceptions that is sometimes run under spinlocks, and sometimes not. There's a *lot* of it. Think something as trivial as memcpy(), but also kmalloc() or any number of stuff that is just random support code that can be used from atomic (non-preemtible) context. So even if we could rely on magic compiler support that doesn't exist - which we can't - it's not evenb *remotely* as static as you seem to think it is. Linus