Re: [PATCH] x86: uapi: ptrace: guard register offset macros with __ASSEMBLER__ or __FRAME_OFFSETS

[Nick Desaulniers <ndesaulniers@google.com>]

On Wed, Sep 2, 2026 at 10:29 AM Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 09/01, Nick Desaulniers wrote:
> >
> > On Fri, Aug 21, 2026 at 3:46 PM Nick Desaulniers
> > <ndesaulniers@google.com> wrote:
> > >
> > > The register offset macros in <asm/ptrace-abi.h> are guarded by
> > > `defined(__ASSEMBLER__) || defined(__FRAME_OFFSETS)` for 64-bit, but
> > > were left unguarded for 32-bit. This causes havoc for userspace that
> > > happens to use identifiers colliding with these short macro names
> > > (e.g., EBX, ECX, EAX, DS, ES, FS, GS, CS, SS). Without this guard,
> > > userspace is forced to be super extra careful with include ordering to
> > > minimize the chance of collision.
> > >
> > > Wrap both the 32-bit and 64-bit register definitions under
> > > `#if defined(__ASSEMBLER__) || defined(__FRAME_OFFSETS)`, and ensure
> > > User-Mode Linux (UML) defines `__FRAME_OFFSETS` for 32-bit as well.
> > >
> > > Assisted-by: Gemini
> > > Link: https://github.com/llvm/llvm-project/issues/217413
> > > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> >
> > + enh (who pulled this into android for testing)
> >
> > Oleg, can I get an ack/nack here?
>
> Oh... there is a little problem, I don't understand the usage of
> (magic to me) __FRAME_OFFSETS ;)

Yeah, my Assisted by tag is from asking Gemini to triple check my
patch before posting, and it pointing out to me from a local review:
"did you intend to break the arch/x86/um/ C uses of these macro
defines?"  So I'm just matching an existing pattern in arch/x86/um/
for 64b with the __FRAME_OFFSETS parts of this patch.

The patch started off as "why are the 64b macros behind the
__ASSEMBLER__ preprocessor guards, but not the 32b ones?"  I went back
through the pre-git history tree, and FWICT, those macros have always
been guarded for 64b, since the introduction of x86_64 support itself.
Dunno if anyone remembers anymore _why_ the 32b macro defines don't
have that guard (chesterton's fence?), but to me, IMO, it looks like a
mistake.

Hence this patch.  PTAL

>
> > Or someone who knows better the
> > history of UAPI headers?
>
> Certainly not me....
>
> OK. I'll try to read this patch tomorrow with the clear head after sleep.

Thanks for taking a look.
-- 
Thanks,
~Nick Desaulniers