Thread (11 messages) 11 messages, 7 authors, 2020-11-19

Re: Is adding an argument to an existing syscall okay?

From: Aleksa Sarai <hidden>
Date: 2020-11-19 03:09:03

On 2020-11-16, Andy Lutomirski [off-list ref] wrote:
Linux 5.10 contains this patch:

commit 2a36ab717e8fe678d98f81c14a0b124712719840
Author: Peter Oskolkov [off-list ref]
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/>

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help