On Mon, 3 May 2021 at 21:38, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes: > > > On Sun, May 02, 2021 at 01:39:16PM -0500, Eric W. Biederman wrote: > > > >> The one thing that this doesn't do is give you a 64bit field > >> on 32bit architectures. > >> > >> On 32bit builds the layout is: > >> > >> int si_signo; > >> int si_errno; > >> int si_code; > >> void __user *_addr; > >> > >> So I believe if the first 3 fields were moved into the _sifields union > >> si_perf could define a 64bit field as it's first member and it would not > >> break anything else. > >> > >> Given that the data field is 64bit that seems desirable. > > > > The data field is fundamentally an address, it is internally a u64 > > because the perf ring buffer has u64 alignment and it saves on compat > > crap etc. > > > > So for the 32bit/compat case the high bits will always be 0 and > > truncating into an unsigned long is fine. > > I see why it is fine to truncate the data field into an unsigned long. > > Other than technical difficulties in extending siginfo_t is there any > reason not to define data as a __u64? No -- like I pointed at earlier, si_perf used to be __u64, but we can't because of the siginfo_t limitation. What we have now is fine, and not worth dwelling over given siginfo limitations. Thanks, -- Marco
