Re: [PATCH RFC v1] m68k: signal.c: use signal frame gap to avoid stack corruption

[Finn Thain <fthain@linux-m68k.org>]

On Sun, 30 Apr 2023, Michael Schmitz wrote:

> Am 29.04.2023 um 21:49 schrieb Finn Thain:
> 
> >
> > That seems over-complicated to me... I must be missing something.
> >

If signals don't nest, a page fault on the signal stack should never 
produce a new signal frame there, so this bug should never show up there. 
I think that was the point I'd missed, because it means the signal stack 
may be exempted here. But is the extra complexity worth it?

> > What I had in mind was something like this (untested):
> >
> > unsigned long usp;
> >
> > if (CPU_IS_020_OR_030 && tregs->format == 0xb)
> >     /* USP is unreliable so use the worst-case value. */
> >     usp = sigsp(rdusp() - 256, ksig);
> > else
> >     usp = sigsp(rdusp(), ksig);
> >
> > return (void __user *)((usp - frame_size) & -8UL);
> 
> sigsp() may return an address from the alternate signal stack. In that 
> case, no adjustment to the signal stack address is advised.
> ...

It'd be ill advised as it would reduce data locality when it expanded the 
signal stack across a cache line or page boundary, and there may be a 
performance penalty for that. However, the signal stack seems to be prone 
to poor data locality anyway, compared to the normal user stack. So I 
wonder if this penalty could be measured. It seems like a premature 
optimization to me. Unfortunately, I don't think we get to measure cache 
misses on m68k.