public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Christian Brauner <[email protected]>,
	Al Viro <[email protected]>
Cc: Stefan Roesch <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected]
Subject: Re: [PATCH v10 4/5] io_uring: add fsetxattr and setxattr support
Date: Thu, 30 Dec 2021 11:09:12 -0800	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <20211230180114.vuum3zorhafd2zta@wittgenstein>

On 12/30/21 10:01 AM, Christian Brauner wrote:
>> However, what I really want to see is the answer to my question re control
>> flow and the place where we do copy the arguments from userland.  Including
>> the pathname.
>>
>> *IF* there's a subtle reason that has to be done from prep phase (and there
>> might very well be - figuring out the control flow in io_uring is bloody
>> painful), I would really like to see it spelled out, along with the explanation
>> of the reasons why statx() doesn't need anything of that sort.
>>
>> If there's no such reasons, I would bloody well leave marshalling to the
> 
> That's really something the io_uring folks should explain to us. I can't
> help much there either apart from what I can gather from looking through
> the io_req_prep() switch.
> 
> Where it's clear that nearly all syscall-operations immediately do a
> getname() and/or copy their arguments in the *_prep() phase as, not in
> the actual "do-the-work" phase. For example, io_epoll_ctl_prep() which
> copies struct epoll_event via copy_from_user(). It doesn't do it in
> io_epoll_ctl(). So as such io_statx_prep() is the outlier...

For each command, there are two steps:

- The prep of it, this happens inline from the system call where the
  request, or requests, are submitted. The prep phase should ensure that
  argument structs are stable. Hence a caller can prep a request and
  have memory on stack, as long as it submits before it becomes invalid.
  An example of that are iovecs for readv/writev. The caller does not
  need to have them stable for the duration of the request, just across
  submit. That's the io_${cmd}_prep() helpers.

- The execution of it. May be separate from prep and from an async
  worker. Where the lower layers don't support a nonblocking attempt,
  they are always done async. The statx stuff is an example of that.

Hence prep needs to copy from userland on the prep side always for the
statx family, as execution will happen out-of-line from the submission.

Does that explain it?

-- 
Jens Axboe


  reply	other threads:[~2021-12-30 19:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-29 20:29 [PATCH v10 0/5] io_uring: add xattr support Stefan Roesch
2021-12-29 20:29 ` [PATCH v10 1/5] fs: split off do_user_path_at_empty from user_path_at_empty() Stefan Roesch
2021-12-30  0:49   ` Al Viro
2021-12-30 19:57     ` Stefan Roesch
2021-12-29 20:29 ` [PATCH v10 2/5] fs: split off setxattr_copy and do_setxattr function from setxattr Stefan Roesch
2021-12-30  1:15   ` Al Viro
2021-12-30  9:41     ` Christian Brauner
2021-12-30 19:57     ` Stefan Roesch
2021-12-29 20:30 ` [PATCH v10 3/5] fs: split off do_getxattr from getxattr Stefan Roesch
2021-12-29 20:30 ` [PATCH v10 4/5] io_uring: add fsetxattr and setxattr support Stefan Roesch
2021-12-30  1:58   ` Al Viro
2021-12-30  2:17   ` Al Viro
2021-12-30  2:19     ` Al Viro
2021-12-30  3:04     ` Al Viro
2021-12-30 10:12       ` Christian Brauner
2021-12-30 16:16         ` Al Viro
2021-12-30 18:01           ` Christian Brauner
2021-12-30 19:09             ` Jens Axboe [this message]
2021-12-30 22:24               ` Al Viro
2021-12-30 22:46                 ` Jens Axboe
2021-12-30 23:02                   ` Al Viro
2021-12-30 20:18     ` Stefan Roesch
2021-12-29 20:30 ` [PATCH v10 5/5] io_uring: add fgetxattr and getxattr support Stefan Roesch
2021-12-30  1:41   ` Al Viro
2021-12-30  1:46     ` Al Viro
2021-12-30 20:01     ` Stefan Roesch

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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