Re: [RFC PATCH 02/15] rseq: Remove broken uapi field layout on 32-bit little endian

----- On Jan 25, 2022, at 9:41 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

----- On Jan 25, 2022, at 7:21 AM, Christian Brauner brauner@kernel.org wrote:

[...]

quoted

quoted

 include/uapi/linux/rseq.h | 17 ++++-------------

[...]

quoted

quoted

 	union {

A bit unfortunate we seem to have to keep the union around even though
it's just one field now.

Well, as far as the user-space projects that I know of which use rseq
are concerned (glibc, librseq, tcmalloc), those end up with their own
copy of the uapi header anyway to deal with the big/little endian field
on 32-bit. So I'm very much open to remove the union if we accept that
this uapi header is really just meant to express the ABI and is not
expected to be used as an API by user-space.

That would mean we also bring a uapi header copy into the kernel
rseq selftests as well to minimize the gap between librseq and
the kernel sefltests (the kernel sefltests pretty much include a
copy of librseq for convenience. librseq is maintained out of tree).

Thoughts ?

Actually, if we go ahead and remove the union, and replace:

struct rseq {
  union {
    __u64 ptr64;
  } rseq_cs;
[...]
} v;

by:

struct rseq {
  __u64 rseq_cs;
} v;

expressions such as these are unchanged:

- sizeof(v.rseq_cs),
- &v.rseq_cs,
- __alignof__(v.rseq_cs),
- offsetof(struct rseq, rseq_cs).

So users of the uapi rseq.h (as an API) can still use rseq_abi->rseq_cs before
and after the change.

Based on this, I am inclined to remove the union, and just make the rseq_cs field
a __u64.

Any objections ?

Thanks,

Mathieu

Thanks,

Mathieu


--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com