[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260724214423.GD27423@brightrain.aerifal.cx>
Date: Fri, 24 Jul 2026 17:44:23 -0400
From: Rich Felker <dalias@...c.org>
To: enh <enh@...gle.com>
Cc: musl@...ts.openwall.com, Jake Adamson <jakeadamson@...gle.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Peter Oskolkov <posk@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
mathieu.desnoyers@...icios.com
Subject: Re: Re: Question: number of arguments of musl's membarrier
does not match Linux syscall
On Fri, Jul 24, 2026 at 10:22:54AM -0400, enh wrote:
> On Fri, Jul 24, 2026 at 7:33 AM Szabolcs Nagy <nsz@...t70.net> wrote:
> >
> > * Jake Adamson <jakeadamson@...gle.com> [2026-07-23 15:27:57 -0700]:
> > > * Szabolcs Nagy <nsz@...t70.net> [Thu, 23 Jul 2026 23:34:51 +0200]:
> > > >https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a36ab717e8fe678d98f81c14a0b124712719840
> > > >good example why libc does not like wrapping new syscalls
> > > >(the contract is not documented and reasonable assumptions
> > > >get broken instead of using a new syscall number)
> > > >now it has to be var arg if we want backward compat.
> > >
> > > Ah, that makes sense then. Thanks for pointing out the kernel commit.
> > > It seems like musl has MEMBARRIER_CMD_FLAG_CPU defined won't that break musl's
> > > membarrier function? The Linux man page says it checks the third
> > > argument if that flag is passed.
> >
> > musl updates its headers to follow linux uapi, and
> > indeed the wrapper api issue was not noticed when
> > that flag was added:
> >
> > https://git.musl-libc.org/cgit/musl/commit/?id=54ca1cc7f1bce1c19593c0176aead964a2534933
> >
> > it would have been easier to catch at the man edit
> >
> > https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=d98b1454fc767b99e9e22f6240ace32c9474ee00
> >
> > at least now the man page uses SYS_membarrier.
> >
> > i think the options are: use 3 arg api (breaking
> > 2 arg callers if any), or use var arg function
> > (bwcompat with 2 arg callers) or tell users to
> > use syscall. either way it requires coordination
> > with glibc (and bionic and man-pages).
>
> there's a thread with glibc here:
> https://public-inbox.org/libc-alpha/CAJgzZoqtbwiN9-Oyb34GTHXB447DdvA8rEcbsEayBALK_d2qxQ@mail.gmail.com/
The solutions that require weird extensions don't make any sense to
me. How are they better rather than worse than a variadic function? If
there is an ABI problem replacing the existing 2-argument function
with a variadic one, we can just use an __asm__("...") label on the
new declaration with a new symbol name (aside: this is the way symbol
versioning should always have been done, so that it binds at
compile-time rather than link-time and works with static linking).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
