io_uring: add support for open/close

If the fast lookup fails, then return -EAGAIN to have the caller retry the path lookup. Assume that a dentry having any of:

->d_revalidate()
->d_automount()
->d_manage()

could block in those callbacks. Preemptively return -EAGAIN if any of these are present.

This is in preparation for supporting non-blocking open.

Signed-off-by Jens Axboe <[email protected]>

---
 fs/namei.c            | 21 ++++++++++++++++++++-
 include/linux/namei.h |  2 ++
 2 files changed, 22 insertions(+), 1 deletion(-)

fs/namei.c +1 -0

index b367fdb91682..ed108a41634f 100644
@@ -1641,6 +1641,17 @@ static struct dentry *__lookup_hash(const struct qstr *name,
 	return dentry;
 }
 
+static inline bool lookup_could_block(struct dentry *dentry, unsigned int flags)

fs/namei.c +9 -1

 static int lookup_fast(struct nameidata *nd,
 		       struct path *path, struct inode **inode,
 		       unsigned *seqp)

@@ -1665,6 +1676,9 @@ static int lookup_fast(struct nameidata *nd,
 			return 0;
 		}
 
+		if (unlikely(lookup_could_block(dentry, nd->flags)))
+			return -EAGAIN;
+
 		/*
 		 * This sequence count validates that the inode matches
 		 * the dentry name information from lookup.

@@ -1707,7 +1721,10 @@ static int lookup_fast(struct nameidata *nd,
 		dentry = __d_lookup(parent, &nd->last);
 		if (unlikely(!dentry))
 			return 0;
-		status = d_revalidate(dentry, nd->flags);
+		if (unlikely(lookup_could_block(dentry, nd->flags)))
+			status = -EAGAIN;
+		else
+			status = d_revalidate(dentry, nd->flags);
 	}
 	if (unlikely(status <= 0)) {
 		if (!status)

@@ -1912,6 +1929,8 @@ static int walk_component(struct nameidata *nd, int flags)
 	if (unlikely(err <= 0)) {
 		if (err < 0)
 			return err;
+		if (nd->flags & LOOKUP_NONBLOCK)
+			return -EAGAIN;
 		path.dentry = lookup_slow(&nd->last, nd->path.dentry,
 					  nd->flags);
 		if (IS_ERR(path.dentry))

include/linux/namei.h +2 -0

index 4e77068f7a1a..392eb439f88b 100644
@@ -49,6 +49,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
 /* LOOKUP_* flags which do scope-related checks based on the dirfd. */
 #define LOOKUP_IS_SCOPED (LOOKUP_BENEATH | LOOKUP_IN_ROOT)
 
+#define LOOKUP_NONBLOCK		0x200000 /* don't block for lookup */
+
 extern int path_pts(struct path *path);
 
 extern int user_path_at_empty(int, const char __user *, unsigned, struct path *, int *empty);

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Do you have comments on this?

Quoted 17 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Quoted 1 line

Do you have comments on this?

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Sounds like you'd like an option for having multiple personalities within a single ring?

I think it would be better to have a ring per personality instead.

One thing we could do to make this more lightweight
is to have rings that are associated, so that we can share a lot of the backend processing between them.

Am 08.01.20 um 17:20 schrieb Jens Axboe:

Quoted 20 lines · Stefan Metzmacher

Quoted 18 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Do you have comments on this?

Quoted 4 lines

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Ah, it's user = get_uid(current_user()); and ctx->user = user in io_uring_create(), right?

Quoted 2 lines

Sounds like you'd like an option for having multiple personalities within a single ring?

I'm not sure anymore, I wasn't aware of the above.

Quoted 1 line

I think it would be better to have a ring per personality instead.

We could do that. I guess we could use per user rings for path based operations and a single ring for fd based operations.

Quoted 3 lines

One thing we could do to make this more lightweight
is to have rings that are associated, so that we can share a lot of the backend processing between them.

My current idea is to use the ring fd and pass it to our main epoll loop.

Can you be more specific about how an api for associated rings could look like?

Quoted 26 lines

Am 08.01.20 um 17:20 schrieb Jens Axboe:

Quoted 24 lines · Stefan Metzmacher

Quoted 14 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

Quoted 4 lines

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Do you have comments on this?

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Quoted 2 lines

Ah, it's user = get_uid(current_user()); and ctx->user = user in io_uring_create(), right?

That's just for the accounting, it's the:

ctx->creds = get_current_cred();

Quoted 16 lines

Quoted 2 lines

Sounds like you'd like an option for having multiple personalities within a single ring?

I'm not sure anymore, I wasn't aware of the above.

Quoted 1 line

I think it would be better to have a ring per personality instead.

We could do that. I guess we could use per user rings for path based operations and a single ring for fd based operations.

Quoted 3 lines

One thing we could do to make this more lightweight
is to have rings that are associated, so that we can share a lot of the backend processing between them.

My current idea is to use the ring fd and pass it to our main epoll loop.

Quoted 2 lines

Can you be more specific about how an api for associated rings could look like?

The API would be the exact same, there would just be some way to associate rings when you create them. Probably a new field in struct io_uring_params (and an associated flag), which would tell io_uring that two separate rings are really the same "user". This would allow io_uring to use the same io-wq workqueues, for example, etc.

This depends on the fact that you can setup the rings with the right personalities, that they would be known upfront. From your description, I'm not so sure that's the case? If not, then we would indeed need something that can pass in the credentials on a per-command basis. Not sure what that would look like.

Am 08.01.20 um 17:40 schrieb Jens Axboe:

Quoted 30 lines · Stefan Metzmacher

Quoted 28 lines

Am 08.01.20 um 17:20 schrieb Jens Axboe:

Quoted 18 lines · Stefan Metzmacher

Quoted 17 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Quoted 6 lines

Quoted 1 line

Do you have comments on this?

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Ah, it's user = get_uid(current_user()); and ctx->user = user in io_uring_create(), right?

Quoted 3 lines

That's just for the accounting, it's the:

ctx->creds = get_current_cred();

Ok, I just looked at an old checkout.

In kernel-dk-block/for-5.6/io_uring-vfs I see this only used in the async processing. Does a non-blocking openat also use ctx->creds?

Quoted 19 lines

Quoted 18 lines

Quoted 2 lines

Sounds like you'd like an option for having multiple personalities within a single ring?

I'm not sure anymore, I wasn't aware of the above.

Quoted 1 line

I think it would be better to have a ring per personality instead.

We could do that. I guess we could use per user rings for path based operations and a single ring for fd based operations.

Quoted 3 lines

One thing we could do to make this more lightweight
is to have rings that are associated, so that we can share a lot of the backend processing between them.

My current idea is to use the ring fd and pass it to our main epoll loop.

Can you be more specific about how an api for associated rings could look like?

Quoted 5 lines

The API would be the exact same, there would just be some way to associate rings when you create them. Probably a new field in struct io_uring_params (and an associated flag), which would tell io_uring that two separate rings are really the same "user". This would allow io_uring to use the same io-wq workqueues, for example, etc.

Ok, this would be just for better performance / better usage of resources, right?

Quoted 5 lines

This depends on the fact that you can setup the rings with the right personalities, that they would be known upfront. From your description, I'm not so sure that's the case? If not, then we would indeed need something that can pass in the credentials on a per-command basis. Not sure what that would look like.

We know the credentials and using a ring per user should be ok.

Quoted 37 lines

Am 08.01.20 um 17:40 schrieb Jens Axboe:

Quoted 27 lines · Stefan Metzmacher

Quoted 26 lines

Am 08.01.20 um 17:20 schrieb Jens Axboe:

Quoted 24 lines · Stefan Metzmacher

Quoted 14 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

Quoted 4 lines

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Do you have comments on this?

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Quoted 6 lines

Quoted 2 lines

Ah, it's user = get_uid(current_user()); and ctx->user = user in io_uring_create(), right?

That's just for the accounting, it's the:

ctx->creds = get_current_cred();

Ok, I just looked at an old checkout.

Quoted 2 lines

In kernel-dk-block/for-5.6/io_uring-vfs I see this only used in the async processing. Does a non-blocking openat also use ctx->creds?

There's basically two sets here - one set is in the ring, and the other is the identity that the async thread (briefly) assumes if we have to go async. Right now they are the same thing, and hence we don't need to play any tricks off the system call submitting SQEs to assume any other identity than the one we have.

Am 08.01.20 um 23:53 schrieb Jens Axboe:

Quoted 38 lines · Stefan Metzmacher

Quoted 37 lines

Am 08.01.20 um 17:40 schrieb Jens Axboe:

Quoted 27 lines · Stefan Metzmacher

Quoted 26 lines

Am 08.01.20 um 17:20 schrieb Jens Axboe:

Quoted 24 lines · Stefan Metzmacher

Quoted 14 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

Quoted 4 lines

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Do you have comments on this?

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Quoted 6 lines

Quoted 2 lines

Ah, it's user = get_uid(current_user()); and ctx->user = user in io_uring_create(), right?

That's just for the accounting, it's the:

ctx->creds = get_current_cred();

Ok, I just looked at an old checkout.

Quoted 8 lines

Quoted 2 lines

In kernel-dk-block/for-5.6/io_uring-vfs I see this only used in the async processing. Does a non-blocking openat also use ctx->creds?

There's basically two sets here - one set is in the ring, and the other is the identity that the async thread (briefly) assumes if we have to go async. Right now they are the same thing, and hence we don't need to play any tricks off the system call submitting SQEs to assume any other identity than the one we have.

I see two cases using it io_sq_thread() and io_wq_create()->io_worker_handle_work() call override_creds().

But aren't non-blocking syscall executed in the context of the thread calling io_uring_enter()->io_submit_sqes()?
In only see some magic around ctx->sqo_mm for that case, but ctx->creds doesn't seem to be used in that case. And my design would require that.

Quoted 48 lines

Am 08.01.20 um 23:53 schrieb Jens Axboe:

Quoted 38 lines · Stefan Metzmacher

Quoted 37 lines

Am 08.01.20 um 17:40 schrieb Jens Axboe:

Quoted 27 lines · Stefan Metzmacher

Quoted 26 lines

Am 08.01.20 um 17:20 schrieb Jens Axboe:

Quoted 24 lines · Stefan Metzmacher

Quoted 14 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

Quoted 4 lines

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Do you have comments on this?

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Quoted 6 lines

Quoted 2 lines

Ah, it's user = get_uid(current_user()); and ctx->user = user in io_uring_create(), right?

That's just for the accounting, it's the:

ctx->creds = get_current_cred();

Ok, I just looked at an old checkout.

Quoted 8 lines

Quoted 2 lines

In kernel-dk-block/for-5.6/io_uring-vfs I see this only used in the async processing. Does a non-blocking openat also use ctx->creds?

There's basically two sets here - one set is in the ring, and the other is the identity that the async thread (briefly) assumes if we have to go async. Right now they are the same thing, and hence we don't need to play any tricks off the system call submitting SQEs to assume any other identity than the one we have.

Quoted 7 lines

I see two cases using it io_sq_thread() and io_wq_create()->io_worker_handle_work() call override_creds().

But aren't non-blocking syscall executed in the context of the thread calling io_uring_enter()->io_submit_sqes()?
In only see some magic around ctx->sqo_mm for that case, but ctx->creds doesn't seem to be used in that case. And my design would require that.

For now, the sq thread (which is used if you use IORING_SETUP_SQPOLL) currently requires fixed files, so it can't be used with open at the moment anyway. But if/when enabled, it'll assume the same credentials as the async context and syscall path.

Am 09.01.20 um 00:05 schrieb Jens Axboe:

Quoted 57 lines · Stefan Metzmacher

Quoted 48 lines

Am 08.01.20 um 23:53 schrieb Jens Axboe:

Quoted 38 lines · Stefan Metzmacher

Quoted 37 lines

Am 08.01.20 um 17:40 schrieb Jens Axboe:

Quoted 27 lines · Stefan Metzmacher

Quoted 26 lines

Am 08.01.20 um 17:20 schrieb Jens Axboe:

Quoted 24 lines · Stefan Metzmacher

Quoted 14 lines

Hi Jens,

Quoted 4 lines

This works just like openat(2), except it can be performed async. For the normal case of a non-blocking path lookup this will complete inline. If we have to do IO to perform the open, it'll be done from async context.

Did you already thought about the credentials being used for the async open? The application could call setuid() and similar calls to change the credentials of the userspace process/threads. In order for applications like samba to use this async openat, it would be required to specify the credentials for each open, as we have to multiplex requests from multiple user sessions in one process.

Quoted 4 lines

This applies to non-fd based syscall. Also for an async connect to a unix domain socket.

Do you have comments on this?

The open works like any of the other commands, it inherits the credentials that the ring was setup with. Same with the memory context, file table, etc. There's currently no way to have multiple personalities within a single ring.

Quoted 6 lines

Quoted 2 lines

Ah, it's user = get_uid(current_user()); and ctx->user = user in io_uring_create(), right?

That's just for the accounting, it's the:

ctx->creds = get_current_cred();

Ok, I just looked at an old checkout.

Quoted 8 lines

Quoted 2 lines

In kernel-dk-block/for-5.6/io_uring-vfs I see this only used in the async processing. Does a non-blocking openat also use ctx->creds?

There's basically two sets here - one set is in the ring, and the other is the identity that the async thread (briefly) assumes if we have to go async. Right now they are the same thing, and hence we don't need to play any tricks off the system call submitting SQEs to assume any other identity than the one we have.

Quoted 7 lines

I see two cases using it io_sq_thread() and io_wq_create()->io_worker_handle_work() call override_creds().

But aren't non-blocking syscall executed in the context of the thread calling io_uring_enter()->io_submit_sqes()?
In only see some magic around ctx->sqo_mm for that case, but ctx->creds doesn't seem to be used in that case. And my design would require that.

Quoted 4 lines

For now, the sq thread (which is used if you use IORING_SETUP_SQPOLL) currently requires fixed files, so it can't be used with open at the moment anyway. But if/when enabled, it'll assume the same credentials as the async context and syscall path.

I'm sorry, but I'm still unsure we're talking about the same thing (or maybe I'm missing some basics here).

My understanding of the io_uring_enter() is that it will execute as much non-blocking calls as it can without switching to any other kernel thread.

And my fear is that openat will use get_current_cred() instead of ctx->creds.

I'm I missing something?

Quoted 5 lines

I'm sorry, but I'm still unsure we're talking about the same thing (or maybe I'm missing some basics here).

My understanding of the io_uring_enter() is that it will execute as much non-blocking calls as it can without switching to any other kernel thread.

Correct, any SQE that we can do without switching, we will.

Quoted 2 lines

And my fear is that openat will use get_current_cred() instead of ctx->creds.

OK, I think I follow your concern. So you'd like to setup the rings from a _different_ user, and then later on use it for submission for SQEs that a specific user. So sort of the same as our initial discussion, except the mapping would be static. The difference being that you might setup the ring from a different user than the user that would be submitting IO on it?

If so, then we do need something to support that, probably an IORING_REGISTER_CREDS or similar. This would allow you to replace the creds you currently have in ctx->creds with whatever new one.

Quoted 1 line

I'm I missing something?

I think we're talking about the same thing, just different views of it :-)

Quoted 11 lines

Quoted 5 lines

I'm sorry, but I'm still unsure we're talking about the same thing (or maybe I'm missing some basics here).

My understanding of the io_uring_enter() is that it will execute as much non-blocking calls as it can without switching to any other kernel thread.

Correct, any SQE that we can do without switching, we will.

Quoted 2 lines

And my fear is that openat will use get_current_cred() instead of ctx->creds.

Quoted 6 lines

OK, I think I follow your concern. So you'd like to setup the rings from a _different_ user, and then later on use it for submission for SQEs that a specific user. So sort of the same as our initial discussion, except the mapping would be static. The difference being that you might setup the ring from a different user than the user that would be submitting IO on it?

Our current (much simplified here) flow is this:

  # we start as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # we become the user555 and
  # create our desired credential token
  seteuid(555); seteguid(555); setgroups()...
  # Start an openat2 on behalf of user555
  openat2()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0); setgroups()...
  ...
  # we become the user444 and
  # create our desired credential token
  seteuid(444); seteguid(444); setgroups()...
  # Start an openat2 on behalf of user444
  openat2()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0); setgroups()...
  ...
  # we become the user555 and
  # create our desired credential token
  seteuid(555); seteguid(555); setgroups()...
  # Start an openat2 on behalf of user555
  openat2()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0); setgroups()...

It means we have to do about 7 syscalls in order to open a file on behalf of a user.
(In reality we cache things and avoid set*id() calls most of the time, but I want to demonstrate the simplified design here)

With io_uring I'd like to use a flow like this:

  # we start as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # we become the user444 and
  # create our desired credential token
  seteuid(444); seteguid(444); setgroups()...
  # we snapshot the credentials to the new ring for user444
  ring444 = io_uring_setup()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # we become the user555 and
  # create our desired credential token
  seteuid(555); seteguid(555); setgroups()...
  # we snapshot the credentials to the new ring for user555
  ring555 = io_uring_setup()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # Start an openat2 on behalf of user555
  io_uring_enter(ring555, OP_OPENAT2...)
  ...
  # Start an openat2 on behalf of user444
  io_uring_enter(ring444, OP_OPENAT2...)
  ...
  # Start an openat2 on behalf of user555
  io_uring_enter(ring555, OP_OPENAT2...)

So instead of constantly doing 7 syscalls per open, we would be down to just at most one. And I would assume that io_uring_enter() would do the temporary credential switch for me also in the non-blocking case.

Quoted 3 lines

If so, then we do need something to support that, probably an IORING_REGISTER_CREDS or similar. This would allow you to replace the creds you currently have in ctx->creds with whatever new one.

I don't want to change ctx->creds, but I want it to be used consistently.

What I think is missing is something like this:

fs/io_uring.c +5 -0

index 32aee149f652..55dbb154915a 100644
@@ -6359,10 +6359,27 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int,
 fd, u32, to_submit,
                struct mm_struct *cur_mm;
 
                mutex_lock(&ctx->uring_lock);
+               if (current->mm != ctx->sqo_mm) {
+                       // TODO: somthing like this...
+                       restore_mm = current->mm;
+                       use_mm(ctx->sqo_mm);
+               }
                /* already have mm, so io_submit_sqes() won't try to

grab it */

                cur_mm = ctx->sqo_mm;

fs/io_uring.c +12 -0

+               if (current_cred() != ctx->creds) {
+                       // TODO: somthing like this...
+                       restore_cred = override_creds(ctx->creds);
+               }
                submitted = io_submit_sqes(ctx, to_submit, f.file, fd,
                                           &cur_mm, false);
+               if (restore_cred != NULL) {
+                       revert_creds(restore_cred);
+               }
+               if (restore_mm != NULL) {
+                       // TODO: something like this...
+                       unuse_mm(ctx->sqo_mm);
+                       use_mm(restore_mm);
+               }
                mutex_unlock(&ctx->uring_lock);
 
                if (submitted != to_submit)

I'm not sure if current->mm is needed, I just added it for completeness and as hint that io_op_defs[req->opcode].needs_mm is there and a needs_creds could also be added (if it helps with performance)

Is it possible to trigger a change of current->mm from userspace?

An IORING_REGISTER_CREDS would only be useful if it's possible to register a set of credentials and then use per io_uring_sqe credentials. That would also be fine for me, but I'm not sure it's needed for now.

Quoted 83 lines

Quoted 11 lines

Quoted 5 lines

I'm sorry, but I'm still unsure we're talking about the same thing (or maybe I'm missing some basics here).

My understanding of the io_uring_enter() is that it will execute as much non-blocking calls as it can without switching to any other kernel thread.

Correct, any SQE that we can do without switching, we will.

Quoted 2 lines

And my fear is that openat will use get_current_cred() instead of ctx->creds.

Quoted 6 lines

OK, I think I follow your concern. So you'd like to setup the rings from a _different_ user, and then later on use it for submission for SQEs that a specific user. So sort of the same as our initial discussion, except the mapping would be static. The difference being that you might setup the ring from a different user than the user that would be submitting IO on it?

Our current (much simplified here) flow is this:

  # we start as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # we become the user555 and
  # create our desired credential token
  seteuid(555); seteguid(555); setgroups()...
  # Start an openat2 on behalf of user555
  openat2()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0); setgroups()...
  ...
  # we become the user444 and
  # create our desired credential token
  seteuid(444); seteguid(444); setgroups()...
  # Start an openat2 on behalf of user444
  openat2()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0); setgroups()...
  ...
  # we become the user555 and
  # create our desired credential token
  seteuid(555); seteguid(555); setgroups()...
  # Start an openat2 on behalf of user555
  openat2()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0); setgroups()...

It means we have to do about 7 syscalls in order to open a file on behalf of a user.
(In reality we cache things and avoid set*id() calls most of the time, but I want to demonstrate the simplified design here)

With io_uring I'd like to use a flow like this:

  # we start as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # we become the user444 and
  # create our desired credential token
  seteuid(444); seteguid(444); setgroups()...
  # we snapshot the credentials to the new ring for user444
  ring444 = io_uring_setup()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # we become the user555 and
  # create our desired credential token
  seteuid(555); seteguid(555); setgroups()...
  # we snapshot the credentials to the new ring for user555
  ring555 = io_uring_setup()
  # we unbecome the user again and run as root
  seteuid(0);setegid(0);setgroups()...
  ...
  # Start an openat2 on behalf of user555
  io_uring_enter(ring555, OP_OPENAT2...)
  ...
  # Start an openat2 on behalf of user444
  io_uring_enter(ring444, OP_OPENAT2...)
  ...
  # Start an openat2 on behalf of user555
  io_uring_enter(ring555, OP_OPENAT2...)

Quoted 4 lines

So instead of constantly doing 7 syscalls per open, we would be down to just at most one. And I would assume that io_uring_enter() would do the temporary credential switch for me also in the non-blocking case.

OK, thanks for spelling the use case out, makes it easier to understand what you need in terms of what we currently can't do.

Quoted 47 lines

Quoted 3 lines

If so, then we do need something to support that, probably an IORING_REGISTER_CREDS or similar. This would allow you to replace the creds you currently have in ctx->creds with whatever new one.

I don't want to change ctx->creds, but I want it to be used consistently.

What I think is missing is something like this:

fs/io_uring.c +5 -0

index 32aee149f652..55dbb154915a 100644
@@ -6359,10 +6359,27 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int,
 fd, u32, to_submit,
                struct mm_struct *cur_mm;
 
                mutex_lock(&ctx->uring_lock);
+               if (current->mm != ctx->sqo_mm) {
+                       // TODO: somthing like this...
+                       restore_mm = current->mm;
+                       use_mm(ctx->sqo_mm);
+               }
                /* already have mm, so io_submit_sqes() won't try to

grab it */

                cur_mm = ctx->sqo_mm;

fs/io_uring.c +12 -0

+               if (current_cred() != ctx->creds) {
+                       // TODO: somthing like this...
+                       restore_cred = override_creds(ctx->creds);
+               }
                submitted = io_submit_sqes(ctx, to_submit, f.file, fd,
                                           &cur_mm, false);
+               if (restore_cred != NULL) {
+                       revert_creds(restore_cred);
+               }
+               if (restore_mm != NULL) {
+                       // TODO: something like this...
+                       unuse_mm(ctx->sqo_mm);
+                       use_mm(restore_mm);
+               }
                mutex_unlock(&ctx->uring_lock);
 
                if (submitted != to_submit)

I'm not sure if current->mm is needed, I just added it for completeness and as hint that io_op_defs[req->opcode].needs_mm is there and a needs_creds could also be added (if it helps with performance)

Quoted 5 lines

Is it possible to trigger a change of current->mm from userspace?

An IORING_REGISTER_CREDS would only be useful if it's possible to register a set of credentials and then use per io_uring_sqe credentials. That would also be fine for me, but I'm not sure it's needed for now.

I think it'd be a cleaner way of doing the same thing as your patch does. It seems a little odd to do this by default (having the ring change personalities depending on who's using it), but from an opt-in point of view, I think it makes more sense.

That would make the IORING_REGISTER_ call something like IORING_REGISTER_ADOPT_OWNER or something like that, meaning that the ring would just assume the identify of the task that's calling io_uring_enter().

Note that this also has to be passed through to the io-wq handler, as the mappings there are currently static as well.

Quoted 20 lines

Quoted 9 lines

I'm not sure if current->mm is needed, I just added it for completeness and as hint that io_op_defs[req->opcode].needs_mm is there and a needs_creds could also be added (if it helps with performance)

Is it possible to trigger a change of current->mm from userspace?

An IORING_REGISTER_CREDS would only be useful if it's possible to register a set of credentials and then use per io_uring_sqe credentials. That would also be fine for me, but I'm not sure it's needed for now.

I think it'd be a cleaner way of doing the same thing as your patch does. It seems a little odd to do this by default (having the ring change personalities depending on who's using it), but from an opt-in point of view, I think it makes more sense.

That would make the IORING_REGISTER_ call something like IORING_REGISTER_ADOPT_OWNER or something like that, meaning that the ring would just assume the identify of the task that's calling io_uring_enter().

Quoted 2 lines

Note that this also has to be passed through to the io-wq handler, as the mappings there are currently static as well.

What's the next step here?

I think the current state is a security problem!

The inline execution either needs to change the creds temporary or io_uring_enter() needs a general check that the current creds match the creds of the ring and return -EPERM or something similar.

Sending this out separately, as I rebased it on top of the work.openat2 branch from Al to resolve some of the conflicts with the differences in how open flags are built.

Am 07.01.20 um 18:00 schrieb Jens Axboe:

Quoted 3 lines

Sending this out separately, as I rebased it on top of the work.openat2 branch from Al to resolve some of the conflicts with the differences in how open flags are built.

Now that you rebased on top of openat2, wouldn't it be better to add openat2 that to io_uring instead of the old openat call?

Quoted 5 lines

Am 07.01.20 um 18:00 schrieb Jens Axboe:

Quoted 3 lines

Sending this out separately, as I rebased it on top of the work.openat2 branch from Al to resolve some of the conflicts with the differences in how open flags are built.

Quoted 2 lines

Now that you rebased on top of openat2, wouldn't it be better to add openat2 that to io_uring instead of the old openat call?

The IORING_OP_OPENAT already exists, so it would probably make more sense to add IORING_OP_OPENAT2 alongside that. Or I could just change it. Don't really feel that strongly about it, I'll probably just add openat2 and leave openat alone, openat will just be a wrapper around openat2 anyway.

Am 08.01.20 um 23:57 schrieb Jens Axboe:

Quoted 9 lines · Stefan Metzmacher

Quoted 7 lines

Am 07.01.20 um 18:00 schrieb Jens Axboe:

Quoted 3 lines

Sending this out separately, as I rebased it on top of the work.openat2 branch from Al to resolve some of the conflicts with the differences in how open flags are built.

Now that you rebased on top of openat2, wouldn't it be better to add openat2 that to io_uring instead of the old openat call?

Quoted 4 lines

The IORING_OP_OPENAT already exists, so it would probably make more sense to add IORING_OP_OPENAT2 alongside that. Or I could just change it. Don't really feel that strongly about it, I'll probably just add openat2 and leave openat alone, openat will just be a wrapper around openat2 anyway.

Great, thanks!

Quoted 15 lines · Stefan Metzmacher

Am 08.01.20 um 23:57 schrieb Jens Axboe:

Quoted 13 lines · Stefan Metzmacher

Quoted 7 lines

Am 07.01.20 um 18:00 schrieb Jens Axboe:

Quoted 3 lines

Sending this out separately, as I rebased it on top of the work.openat2 branch from Al to resolve some of the conflicts with the differences in how open flags are built.

Now that you rebased on top of openat2, wouldn't it be better to add openat2 that to io_uring instead of the old openat call?

The IORING_OP_OPENAT already exists, so it would probably make more sense to add IORING_OP_OPENAT2 alongside that. Or I could just change it. Don't really feel that strongly about it, I'll probably just add openat2 and leave openat alone, openat will just be a wrapper around openat2 anyway.

Quoted 1 line

Great, thanks!

Here:

https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs

Not tested yet, will wire this up in liburing and write a test case as well.

Quoted 20 lines · Stefan Metzmacher

Quoted 10 lines

Am 08.01.20 um 23:57 schrieb Jens Axboe:

Quoted 9 lines · Stefan Metzmacher

Quoted 7 lines

Am 07.01.20 um 18:00 schrieb Jens Axboe:

Quoted 3 lines

Sending this out separately, as I rebased it on top of the work.openat2 branch from Al to resolve some of the conflicts with the differences in how open flags are built.

Now that you rebased on top of openat2, wouldn't it be better to add openat2 that to io_uring instead of the old openat call?

Quoted 6 lines

Quoted 4 lines

The IORING_OP_OPENAT already exists, so it would probably make more sense to add IORING_OP_OPENAT2 alongside that. Or I could just change it. Don't really feel that strongly about it, I'll probably just add openat2 and leave openat alone, openat will just be a wrapper around openat2 anyway.

Great, thanks!

Here:

Quoted 4 lines

https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs

Not tested yet, will wire this up in liburing and write a test case as well.

Wrote a basic test case, and used my openbench as well. Seems to work fine for me. Pushed prep etc support to liburing.

Am 09.01.20 um 03:03 schrieb Jens Axboe:

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Stefan Metzmacher

Quoted 10 lines

Am 08.01.20 um 23:57 schrieb Jens Axboe:

Quoted 9 lines · Stefan Metzmacher

Quoted 7 lines

Am 07.01.20 um 18:00 schrieb Jens Axboe:

Quoted 3 lines

Sending this out separately, as I rebased it on top of the work.openat2 branch from Al to resolve some of the conflicts with the differences in how open flags are built.

Now that you rebased on top of openat2, wouldn't it be better to add openat2 that to io_uring instead of the old openat call?

Quoted 6 lines

Quoted 4 lines

The IORING_OP_OPENAT already exists, so it would probably make more sense to add IORING_OP_OPENAT2 alongside that. Or I could just change it. Don't really feel that strongly about it, I'll probably just add openat2 and leave openat alone, openat will just be a wrapper around openat2 anyway.

Great, thanks!

Here:

Quoted 7 lines

Quoted 4 lines

https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs

Not tested yet, will wire this up in liburing and write a test case as well.

Wrote a basic test case, and used my openbench as well. Seems to work fine for me. Pushed prep etc support to liburing.

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.

Quoted 11 lines

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!

Hi Jens,

Quoted 17 lines

Quoted 11 lines

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.

Quoted 1 line

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.

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.

Quoted 4 lines · Stefan Metzmacher

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.

Sounds similar to https://capnproto.org/rpc.html too.

But that seems most valuable in a situation with nontrivial latency.

Quoted 3 lines · Stefan Metzmacher

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.

Sounds similar to https://capnproto.org/rpc.html too.

Quoted 7 lines · Colin Walters

Quoted 3 lines · Stefan Metzmacher

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.

Sounds similar to https://capnproto.org/rpc.html too.

Looks like just grouping a pack of operations for RPC.
With io_uring we could implement more interesting stuff. I've been thinking about eBPF in io_uring for a while as well, and apparently it could be _really_ powerful, and would allow almost zero-context-switches for some usecases.

1. full flow control with eBPF
- dropping requests (links)
- emitting reqs/links (e.g. after completions of another req)
- chaining/redirecting
of course, all of that with fast intermediate computations in between

2. do long eBPF programs by introducing a new opcode (punted to async). (though, there would be problems with that)

Could even allow to dynamically register new opcodes within the kernel and extend it to eBPF, if there will be demand for such things.

Quoted 20 lines · Pavel Begunkov

Quoted 7 lines · Colin Walters

Quoted 3 lines · Stefan Metzmacher

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.

Sounds similar to https://capnproto.org/rpc.html too.

Looks like just grouping a pack of operations for RPC.
With io_uring we could implement more interesting stuff. I've been thinking about eBPF in io_uring for a while as well, and apparently it could be _really_ powerful, and would allow almost zero-context-switches for some usecases.

1. full flow control with eBPF
- dropping requests (links)
- emitting reqs/links (e.g. after completions of another req)
- chaining/redirecting
of course, all of that with fast intermediate computations in between

Quoted 5 lines

2. do long eBPF programs by introducing a new opcode (punted to async). (though, there would be problems with that)

Could even allow to dynamically register new opcodes within the kernel and extend it to eBPF, if there will be demand for such things.

We're also looking into exactly that at Facebook, nothing concrete yet though. But it's clear we need it to take full advantage of links at least, and it's also clear that it would unlock a lot of really cool functionality once we do.

Pavel, I'd strongly urge you to submit a talk to LSF/MM/BPF about this. It's the perfect venue to have some concrete planning around this topic and get things rolling.

https://lore.kernel.org/bpf/20191122172502.vffyfxlqejthjib6@macbook-pro-91.dhcp.thefacebook.com/

Quoted 32 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 7 lines · Colin Walters

Quoted 3 lines · Stefan Metzmacher

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.

Sounds similar to https://capnproto.org/rpc.html too.

Looks like just grouping a pack of operations for RPC.
With io_uring we could implement more interesting stuff. I've been thinking about eBPF in io_uring for a while as well, and apparently it could be _really_ powerful, and would allow almost zero-context-switches for some usecases.

1. full flow control with eBPF
- dropping requests (links)
- emitting reqs/links (e.g. after completions of another req)
- chaining/redirecting
of course, all of that with fast intermediate computations in between

Quoted 5 lines

2. do long eBPF programs by introducing a new opcode (punted to async). (though, there would be problems with that)

Could even allow to dynamically register new opcodes within the kernel and extend it to eBPF, if there will be demand for such things.

We're also looking into exactly that at Facebook, nothing concrete yet though. But it's clear we need it to take full advantage of links at least, and it's also clear that it would unlock a lot of really cool functionality once we do.

Quoted 3 lines

Pavel, I'd strongly urge you to submit a talk to LSF/MM/BPF about this. It's the perfect venue to have some concrete planning around this topic and get things rolling.

Sounds interesting, I'll try this, but didn't you intend to do it yourself? And thanks for the tip!