On 2020-11-16, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > Linux 5.10 contains this patch: > > commit 2a36ab717e8fe678d98f81c14a0b124712719840 > Author: Peter Oskolkov <posk@xxxxxxxxxx> > Date: Wed Sep 23 16:36:16 2020 -0700 > > rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ > > This adds an argument to an existing syscall. Before the patch, > membarrier had 2 parameters; now it has 3. Is this really okay? At > least the patch is careful and ignores the third parameter unless a > previously unused flag bit is set. This change is not wrong from a correctness perspective but this kind of pattern is (in my view at least) an anti-pattern -- as Florian has mentioned, adding new arguments to an existing syscall can lead to libc complications for wrappers, as well as more explicit issues like the O_TMPFILE example. This all harkens back to the whole "what extensibility system we want to have" question Christian and I discussed at LPC this year[1]. This setup (add a new flag to enable the new argument) is one of the approaches we listed, but the only question is whether it's one we want to encourage. In fairness, we can't retro-fit extensible structs to membarrier(2) so there isn't a nice way to do this other than adding membarrier2(2). And it seems to me the real issue is that membarrier(2) is a multiplexer which inevitably means it has its own host of extensibility issues (which we covered in the talk as well). *shrug* [1]: https://lwn.net/Articles/830666/ -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
