[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260724124310.GB27423@brightrain.aerifal.cx>
Date: Fri, 24 Jul 2026 08:43:11 -0400
From: Rich Felker <dalias@...c.org>
To: Jake Adamson <jakeadamson@...gle.com>,
Nick Desaulniers <ndesaulniers@...gle.com>, musl@...ts.openwall.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 01:32:58PM +0200, Szabolcs Nagy 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).
Perhaps we should remove the macro unless/until we make a way to use
it, so that applications don't see it available and assume they can
use it. It looks like very niche functionality that could be relegated
to making a raw syscall using the kernel header instead of
sys/membarrier.h.
I'm not strongly opposed to the variadic solution though we'd have to
check if it's ABI-compatible with existing code on all archs. I'm not
entirely sure that's the case. If not we'd need a macro or asm-label
redirect for the new version. And it doesn't make sense to do this
until the issue has been considered in more depth.
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.
