Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

[Ingo Molnar]

* Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:

> > >> But what about the register state when delivering a signal?  Don't we
> > >> set the registers to the init state?  Do we need to preserve PKRU state
> > >> instead of init'ing it?  The init state _is_ nice here because it is
> > >> permissive allows us to do something useful no matter what PKRU gets set to.
> > >
> > > I think we leave the extended regs alone.  Don't we?
> > >
> > > I think that, for most signals, we want to leave PKRU as is,
> > > especially for things that aren't SIGSEGV.  For SIGSEGV, maybe we want
> > > an option to reset PKRU on delivery (and then set the flag to restore
> > > on return?).
> >
> > Is there some precedent for doing the state differently for different
> > signals?
> 
> Yes, to a very limited extent: SA_ONSTACK.
> 
> >
> > >> Well, the signal handler isn't necessarily going to clobber it, but the
> > >> delivery code already clobbers it when going to the init state.
> > >
> > > Can you point to that code?
> >
> > handle_signal() -> fpu__clear()
> >
> > The comment around it says:
> >
> > "Ensure the signal handler starts with the new fpu state."
> >
> 
> You win this round :)
> 
> So maybe we should have a mask of xfeatures that aren't cleared on
> signal delivery (e.g. PKRU, perhaps) and that are, by default,
> preserved across signal returns.

So the principle is this: signals are conceptually like creating a new thread of 
execution, and that's a very powerful programming concept, like fork() or 
pthread_create() are powerful concepts. So we definitely want to keep that default 
behavior, and I don't think we want to deviate from that for typical new extended 
CPU context features, even if signal delivery slows down as a result.

But we've been arguing about 'lightweight signals' for up to two decades that I 
can remember. (The first such suggestion was to not save the FPU state, back when 
FPU saves were ridiculously slow compared to other parts of saving/restoring a 
context.)

So having a well-enumerated, extensible opt-in mask (which defaults to 'all state 
saved') that allows smart signal handlers to skip the save/restore of certain CPU 
context components would be acceptable I think.

But I'd still expect this to be limited to closely coded, specialistic signal 
handlers - as the trend goes against such type of specialization: compilers and 
runtime environments do take advantage of new CPU features so if you want to have 
an 'easy to use' signal handler, you should use the default one.

I'd not be surprised if large-scale signal users like Valgrind could benefit.

> > I'm sure we can preserve it, we just need to be _careful_.
> 
> Right.
> 
> How much does XSAVEOPT help here?  IOW if we're careful to save to the same 
> place we restored from and we don't modify the state in the mean time, how much 
> of the time do we save?  In the best case, I guess we save the memory writes but 
> not the reads?

So I'd not design new signal interfaces around current behavior, I'd design them 
for the existing patterns (which center around programming ease of use) - with 
opt-in, performance-enhancing specializations.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/