Files
linux/include/linux
Marco Elver 3ddb3fd8cd signal, perf: Fix siginfo_t by avoiding u64 on 32-bit architectures
The alignment of a structure is that of its largest member. On
architectures like 32-bit Arm (but not e.g. 32-bit x86) 64-bit integers
will require 64-bit alignment and not its natural word size.

This means that there is no portable way to add 64-bit integers to
siginfo_t on 32-bit architectures without breaking the ABI, because
siginfo_t does not yet (and therefore likely never will) contain 64-bit
fields on 32-bit architectures. Adding a 64-bit integer could change the
alignment of the union after the 3 initial int si_signo, si_errno,
si_code, thus introducing 4 bytes of padding shifting the entire union,
which would break the ABI.

One alternative would be to use the __packed attribute, however, it is
non-standard C. Given siginfo_t has definitions outside the Linux kernel
in various standard libraries that can be compiled with any number of
different compilers (not just those we rely on), using non-standard
attributes on siginfo_t should be avoided to ensure portability.

In the case of the si_perf field, word size is sufficient since there is
no exact requirement on size, given the data it contains is user-defined
via perf_event_attr::sig_data. On 32-bit architectures, any excess bits
of perf_event_attr::sig_data will therefore be truncated when copying
into si_perf.

Since si_perf is intended to disambiguate events (e.g. encoding relevant
information if there are more events of the same type), 32 bits should
provide enough entropy to do so on 32-bit architectures.

For 64-bit architectures, no change is intended.

Fixes: fb6cc127e0 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lkml.kernel.org/r/20210422191823.79012-1-elver@google.com
2021-04-23 09:03:16 +02:00
..
2021-02-02 00:16:57 +01:00
2020-12-09 19:26:02 -06:00
2021-01-23 14:57:21 +01:00
2021-01-24 14:27:17 +01:00
2021-02-26 09:41:03 -08:00
2021-02-17 14:07:48 +01:00
2021-01-21 14:06:00 -07:00
2021-01-16 15:12:06 -05:00
2021-01-18 14:26:51 +01:00
2021-02-08 12:28:07 +01:00
2020-12-10 12:42:59 -06:00
2021-02-11 13:24:44 -08:00
2021-01-27 12:27:36 +01:00
2020-12-15 16:19:31 +01:00
2021-02-26 09:41:03 -08:00
2020-12-15 16:19:31 +01:00
2021-02-17 14:12:42 +01:00
2021-01-21 16:16:10 +00:00
2021-02-26 09:41:02 -08:00
2021-02-26 09:41:03 -08:00
2021-01-22 15:09:42 +01:00
2021-01-14 11:20:17 +01:00
2021-02-26 09:41:03 -08:00
2021-03-13 11:27:30 -08:00
2021-02-08 12:28:07 +01:00
2021-01-04 11:42:21 -05:00
2021-02-16 16:11:14 -05:00
2021-02-02 10:26:12 +01:00
2021-02-17 13:17:49 -08:00
2021-02-26 09:40:59 -08:00
2021-01-21 14:06:00 -07:00
2021-02-03 19:05:50 +01:00
2021-01-24 14:27:17 +01:00
2021-01-24 14:27:20 +01:00
2021-02-26 09:41:03 -08:00
2021-01-16 23:19:26 +01:00
2020-12-10 16:17:15 +01:00
2021-01-28 00:35:03 +01:00
2020-12-10 10:45:36 +01:00
2021-03-02 17:25:46 -07:00
2021-02-20 10:13:32 -05:00
2021-01-06 16:24:59 -08:00
2021-02-09 12:27:29 -05:00
2021-02-13 17:17:53 +01:00
2021-01-21 16:16:10 +00:00
2021-02-01 13:20:07 -07:00
2021-01-18 10:52:41 +01:00
2021-02-09 12:15:07 +01:00
2021-01-21 14:06:00 -07:00
2021-01-24 14:27:17 +01:00
2021-02-08 22:58:55 +01:00