From: Wei Liu
Sent: 08 September 2021 16:24
On Wed, Sep 08, 2021 at 02:51:21PM +0000, David Laight wrote:
From: Wei Liu
Sent: 08 September 2021 11:03
...
However calling into the allocator from that IPI path seems very heavy weight. I will discuss with fellow engineers on how to fix it properly.
Isn't the IPI code something that is likely to get called when a lot of stack has already been used?
So you really shouldn't be using much stack at all??
I don't follow your questions. I don't dispute there is a problem. I just think calling into the allocator is not a good idea in that particular piece of code we need to fix.
Hopefully we can come up with a solution to remove need for a cpumask in that code -- discussion is on-going.
I'm pretty sure the IPI interrupt is high priority so can nest with another interrupt. (You certainly want it to be that way.)
So the kernel may already be running on the interrupt stack. If the interrupted ISR code has used a lot of stack then there may not be as much left as you might expect.
Many years ago (nearly 40!) I wrote something that did static stack depth analysis for an embedded system. Since there were no (interesting) indirect calls an no recursion it wasn't completely impossible. What it showed was that the deepest stack use was in error trace paths that probably never happened. I suspect the same is true for Linux - the deepest points will be inside printk() in obscure error paths. Get an IPI while in a printk() from deep inside an ISR and you may not have the amount of stack you expect.
It might be possible to use the clang 'control flow integrity' information to determine the actual maximum stack use even for indirectly called functions. I suspect that would be an eye-opener....
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)