Marco Elver <elver@xxxxxxxxxx> writes: > On Sat, 1 May 2021 at 00:50, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> >> It turns out that linux uses si_trapno very sparingly, and as such it >> can be considered extra information for a very narrow selection of >> signals, rather than information that is present with every fault >> reported in siginfo. >> >> As such move si_trapno inside the union inside of _si_fault. This >> results in no change in placement, and makes it eaiser to extend >> _si_fault in the future as this reduces the number of special cases. >> In particular with si_trapno included in the union it is no longer a >> concern that the union must be pointer alligned on most architectures >> because the union followes immediately after si_addr which is a >> pointer. >> > > Maybe add "Link: > https://lkml.kernel.org/r/CAK8P3a0+uKYwL1NhY6Hvtieghba2hKYGD6hcKx5n8=4Gtt+pHA@xxxxxxxxxxxxxx"; > >> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > > Acked-by: Marco Elver <elver@xxxxxxxxxx> > > By no longer guarding it with __ARCH_SI_TRAPNO we run the risk that it > will be used by something else at some point. Is that intentional? The motivation was letting the code be tested on other architectures. But once si_trapno falls inside the union instead of being present for every signal reporting a fault it doesn't really matter. I think it would be poor taste but harmless to use si_trapno, mostly because defining a new entry in the union could be more specific and well defined. Eric
