Messages in this thread | | | From | Marco Elver <> | Date | Mon, 3 May 2021 21:53:39 +0200 | Subject | Re: [PATCH 7/3] signal: Deliver all of the perf_data in si_perf |
| |
On Mon, 3 May 2021 at 21:38, Eric W. Biederman <ebiederm@xmission.com> wrote: > Peter Zijlstra <peterz@infradead.org> 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
| |