[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YI/wJSwQitisM8Xf@hirez.programming.kicks-ass.net>
Date: Mon, 3 May 2021 14:44:21 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Marco Elver <elver@...gle.com>, Arnd Bergmann <arnd@...db.de>,
Florian Weimer <fweimer@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Collingbourne <pcc@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
sparclinux <sparclinux@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: [PATCH 7/3] signal: Deliver all of the perf_data in si_perf
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.
Powered by blists - more mailing lists