All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Stefan Metzmacher <metze@samba.org>, Jens Axboe <axboe@kernel.dk>,
	io-uring@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: [PATCHSET v2 0/6] io_uring: add support for open/close
Date: Mon, 20 Jan 2020 16:04:44 +0300	[thread overview]
Message-ID: <2fae1d5a-4dad-6435-04e9-e544c6c17f27@gmail.com> (raw)
In-Reply-To: <da05b8e8-4ef4-7527-36d5-511a192460f0@samba.org>

On 1/20/2020 3:15 PM, Stefan Metzmacher wrote:
> Hi Jens,
> 
>>> Thanks!
>>>
>>> Another great feature would the possibility to make use of the
>>> generated fd in the following request.
>>>
>>> This is a feature that's also available in the SMB3 protocol
>>> called compound related requests.
>>>
>>> The client can compound a chain with open, getinfo, read, close
>>> getinfo, read and close get an file handle of -1 and implicitly
>>> get the fd generated/used in the previous request.
>>
>> Right, the "plan" there is to utilize BPF to make this programmable.
>> We really need something more expressive to be able to pass information
>> between SQEs that are linked, or even to decide which link to run
>> depending on the outcome of the parent.
>>
>> There's a lot of potential there!
> 
> I guess so, but I don't yet understand how BPF works in real life.
> 
> Is it possible to do that as normal user without special privileges?
> 
> My naive way would be using some flags and get res and pass fd by reference.
> 
Just have been discussing related stuff. See the link if curious
https://github.com/axboe/liburing/issues/58

To summarise, there won't be enough flags to cover all use-cases and it
will slow down the common path. There should be something with
zero-overhead if the feature is not used, and that's not the case with
flags. That's why it'd be great to have a custom eBPF program
(in-kernel) controlling what and how to do next.

I don't much about eBPF internals, but probably we will be able to
attach an eBPF program to io_uring instance. Though, not sure whether it
could be done without privileges.

-- 
Pavel Begunkov

  reply	other threads:[~2020-01-20 13:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 17:00 [PATCHSET v2 0/6] io_uring: add support for open/close Jens Axboe
2020-01-07 17:00 ` [PATCH 1/6] fs: add namei support for doing a non-blocking path lookup Jens Axboe
2020-01-25 13:15   ` Jeff Layton
2020-01-07 17:00 ` [PATCH 2/6] fs: make build_open_flags() available internally Jens Axboe
2020-01-07 17:00 ` [PATCH 3/6] io_uring: add support for IORING_OP_OPENAT Jens Axboe
2020-01-08 13:05   ` Stefan Metzmacher
2020-01-08 16:20     ` Jens Axboe
2020-01-08 16:32       ` Stefan Metzmacher
2020-01-08 16:40         ` Jens Axboe
2020-01-08 17:04           ` Stefan Metzmacher
2020-01-08 22:53             ` Jens Axboe
2020-01-08 23:03               ` Stefan Metzmacher
2020-01-08 23:05                 ` Jens Axboe
2020-01-08 23:11                   ` Stefan Metzmacher
2020-01-08 23:22                     ` Jens Axboe
2020-01-09 10:40                       ` Stefan Metzmacher
2020-01-09 21:31                         ` Jens Axboe
2020-01-16 22:42                           ` Stefan Metzmacher
2020-01-17  0:16                             ` Jens Axboe
2020-01-07 17:00 ` [PATCH 4/6] fs: move filp_close() outside of __close_fd_get_file() Jens Axboe
2020-01-07 17:00 ` [PATCH 5/6] io-wq: add support for uncancellable work Jens Axboe
2020-01-07 17:00 ` [PATCH 6/6] io_uring: add support for IORING_OP_CLOSE Jens Axboe
2020-01-08 21:17 ` [PATCHSET v2 0/6] io_uring: add support for open/close Stefan Metzmacher
2020-01-08 22:57   ` Jens Axboe
2020-01-08 23:05     ` Stefan Metzmacher
2020-01-09  1:02       ` Jens Axboe
2020-01-09  2:03         ` Jens Axboe
2020-01-16 22:50           ` Stefan Metzmacher
2020-01-17  0:18             ` Jens Axboe
2020-01-20 12:15               ` Stefan Metzmacher
2020-01-20 13:04                 ` Pavel Begunkov [this message]
2020-01-17  0:44             ` Colin Walters
2020-01-17  0:51               ` Jens Axboe
2020-01-17  9:32               ` Pavel Begunkov
2020-01-17 15:21                 ` Jens Axboe
2020-01-17 22:27                   ` Pavel Begunkov
2020-01-17 22:36                     ` Jens Axboe

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=2fae1d5a-4dad-6435-04e9-e544c6c17f27@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=metze@samba.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.