On 10/21/24 14:13, Lorenzo Stoakes wrote: >> Do you think there's enough value int his to warrant digging in? And indeed >> I imagine bits are in short supply for this and would need a strong >> argument to get... so yeah I don't think too worthwhile most likely! >> >> Thanks for the suggestion though! > To put it on list - Dave Hansen commented on IRC that it would be safer to > avoid this for now due to this being an ABI change, and reasonable to > perhaps add it later if required, so that seems a sensible way forward. We added SEGV_PKUERR because we really did expect signal handlers to want to do something new and special, including consuming si_pkey. Old signal handlers would probably be pretty confused. So, yeah, if it's not crystal clear that new signal handler code is needed, than I'd punt on adding a new SEGV_* code for now. BTW, SEGV_* codes are sequentially assigned. It isn't a bitfield and there are no space constraints. We've only used a dozen or so of them and ->si_code is an int.
