On Tue, Sep 15 2020 at 10:35, Linus Torvalds wrote:
On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner tglx@linutronix.de wrote:
OTOH, having a working 'preemptible()' or maybe better named 'can_schedule()' check makes tons of sense to make decisions about allocation modes or other things.
No. I think that those kinds of decisions about actual behavior are always simply fundamentally wrong.
Note that this is very different from having warnings about invalid use. THAT is correct. It may not warn in all configurations, but that doesn't matter: what matters is that it warns in common enough configurations that developers will catch it.
You wish. I just found a 7 year old bug in a 10G network driver which surely would have been found if people would enable debug configs and not just run the crap on their PREEMPT_NONE, all debug off kernel. And that driver is not subject to bitrot, it gets regular bug fixes from people who seem to care (distro folks).
So having a warning in "might_sleep()" that doesn't always trigger, because you have a limited configuration that can't even detect the situation, that's fine and dandy and intentional.
and lets people get away with their crap.
But having code like
if (can_schedule()) .. do something different ..is fundamentally complete and utter garbage.
It's one thing if you test for "am I in hardware interrupt context". Those tests aren't great either, but at least they make sense.
They make sense in limited situations like exception handlers and such which really have to know from which context an exception was raised.
But with the above reasoning such checks do not make sense in any other general code. 'in hard interrupt context' is just another context where you can't do stuff which you can do when in preemptible task context.
Most tests are way broader than a single context. in_interrupt() is true for hard interrupt, soft interrupt delivery and all BH disabled contexts, which is completely ill defined.
But a driver - or some library routine - making a difference based on some nebulous "can I schedule" is fundamentally and basically WRONG.
If some code changes behavior, it needs to be explicit to the *caller* of that code.
I'm fine with that, but then we have to be consequent and ban _all_ of these and not just declare can_schedule() to be a bad one.
Thanks,
tglx