Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED

[Linus Torvalds]

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