linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sbaugh@catern.com
To: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linuxppc-dev@ozlabs.org, linux-alpha@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
Date: Mon, 26 Aug 2019 19:50:50 +0000	[thread overview]
Message-ID: <854l2366zp.fsf@catern.com> (raw)
In-Reply-To: 20190820033406.29796-8-cyphar@cyphar.com

Aleksa Sarai <cyphar@cyphar.com> writes:
> To this end, we introduce the openat2(2) syscall. It provides all of the
> features of openat(2) through the @how->flags argument, but also
> also provides a new @how->resolve argument which exposes RESOLVE_* flags
> that map to our new LOOKUP_* flags. It also eliminates the long-standing
> ugliness of variadic-open(2) by embedding it in a struct.

I don't like this usage of a structure in memory to pass arguments that
would fit in registers. This would be quite inconvenient for me as a
userspace developer.

Others have brought up issues with this: the issue of seccomp, and the
issue of mismatch between the userspace interface and the kernel
interface, are the most important for me. I want to add another,
admittedly somewhat niche, concern.

This interfaces requires a program to allocate memory (even on the
stack) just to pass arguments to the kernel which could be passed
without allocating that memory. That makes it more difficult and less
efficient to use this syscall in any case where memory is not so easily
allocatable: such as early program startup or assembly, where the stack
may be limited in size or not even available yet, or when injecting a
syscall while ptracing.

A struct-passing interface was needed for clone, since we ran out of
registers; but we have not run out of registers yet for openat, so it
would be nice to avoid this if we can. We can always expand later...


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-08-26 20:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20  3:33 [PATCH RESEND v11 0/8] openat2(2) Aleksa Sarai
2019-08-20  3:33 ` [PATCH RESEND v11 1/8] namei: obey trailing magic-link DAC permissions Aleksa Sarai
2019-08-20  3:34 ` [PATCH RESEND v11 2/8] procfs: switch magic-link modes to be more sane Aleksa Sarai
2019-08-20  3:34 ` [PATCH RESEND v11 3/8] open: O_EMPTYPATH: procfs-less file descriptor re-opening Aleksa Sarai
2019-08-20  3:34 ` [PATCH RESEND v11 4/8] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-08-20  3:34 ` [PATCH RESEND v11 5/8] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-08-20  3:34 ` [PATCH RESEND v11 6/8] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-08-20  3:34 ` [PATCH RESEND v11 7/8] open: openat2(2) syscall Aleksa Sarai
2019-08-24 20:17   ` Daniel Colascione
2019-08-29 12:15     ` Aleksa Sarai
2019-08-29 13:05       ` Rasmus Villemoes
2019-08-29 13:19         ` Aleksa Sarai
2019-08-26 19:50   ` sbaugh [this message]
2019-08-28 15:55     ` Jeff Layton
2019-08-28 20:17       ` Spencer Baugh
2019-08-20  3:34 ` [PATCH RESEND v11 8/8] selftests: add openat2(2) selftests Aleksa Sarai

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=854l2366zp.fsf@catern.com \
    --to=sbaugh@catern.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
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).