mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Alexey Izbyshev <>
Subject: Re: [musl] [PATCH] accept4: don't fall back to accept if we got unknown flags
Date: Tue, 28 Feb 2023 02:42:39 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2023-02-28 01:38, Rich Felker wrote:
> On Mon, Feb 27, 2023 at 10:46:54PM +0300, Alexey Izbyshev wrote:
>> accept4 emulation via accept ignores unknown flags, so it can 
>> spuriously
>> succeed instead of failing (or succeed without doing the action 
>> implied
>> by an unknown flag if it's added in a future kernel). Worse, unknown
>> flags trigger the fallback code even on modern kernels if the real
>> accept4 syscall returns EINVAL, because this is indistinguishable from
>> socketcall returning EINVAL due to lack of accept4 support. Fix this 
>> by
>> always propagating the syscall attempt failure if unknown flags are
>> present.
>> The behavior is still not ideal on old kernels lacking accept4 on 
>> arches
>> with socketcall, where failing with ENOSYS instead of EINVAL returned 
>> by
>> socketcall would be preferable, but at least modern kernels are now
>> fine.
> Can you clarify what you mean about ENOSYS vs EINVAL here? I'm not
> following.
Sorry for confusion, I meant the following. On arches with socketcall, 
if a program running on an old kernel that doesn't support accept4 in 
any form calls accept4 with unknown flags, musl's accept4 will fail with 
EINVAL after this patch. But the reason of failure remains unclear to 
the programmer: is it because some flag is not supported or because 
accept4 is not supported at all? So I thought it'd be better to fail 
with ENOSYS in this case instead, although I don't know a good way to do 
that: the EINVAL ambiguity exists at socketcall level too, so testing 
whether the kernel's socketcall supports __SC_accept4 or not would 
probably involve calling it with known-good arguments on a separately 
created socket, and I certainly don't propose to do that.

On the other hand, it could be argued that a function that can emulate a 
certain baseline feature set of another function shouldn't fail with 
ENOSYS at all because the real function would never do that. The two 
cleanest options for possibly-not-supported functions seem to be either 
always failing with ENOSYS if the kernel doesn't support the syscall or 
failing with a reasonable error if the caller requests something 
unsupported by the emulation. And I think accept4 satisfies the latter 
with this patch.

As an aside, note that dup3 and pipe2 currently also ignore unknown 
flags on old kernels, and for pipe2 there is a valid flag (O_DIRECT) 
that could be silently ignored because of that. But there is no issue on 
newer kernels supporting the syscalls, unlike for accept4.


  reply	other threads:[~2023-02-27 23:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 19:46 Alexey Izbyshev
2023-02-27 22:38 ` Rich Felker
2023-02-27 23:42   ` Alexey Izbyshev [this message]
2023-02-27 23:51     ` Alexey Izbyshev
2023-02-27 23:53       ` Rich Felker
2023-02-28 17:21     ` Rich Felker
2023-02-28 17:25       ` Rich Felker
2023-02-28 20:15         ` Alexey Izbyshev
2023-02-28 20:51           ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).