cleanup submission path

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

  fs/io_uring.c | 116 ++++++++++++++------------------------------------
  1 file changed, 33 insertions(+), 83 deletions(-)

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 2 lines

  fs/io_uring.c | 116 ++++++++++++++------------------------------------
  1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

   fs/io_uring.c | 116 ++++++++++++++------------------------------------
   1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Do you prefer to return it back first?

Quoted 17 lines · Pavel Begunkov

Quoted 16 lines · Jens Axboe

Quoted 9 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

fs/io_uring.c | 116 ++++++++++++++------------------------------------ 1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

Quoted 4 lines

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Do you prefer to return it back first?

Ah I see, no I don't care about that.

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

    fs/io_uring.c | 116 ++++++++++++++------------------------------------
    1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

     fs/io_uring.c | 116 ++++++++++++++------------------------------------
     1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

Quoted 36 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

     fs/io_uring.c | 116 ++++++++++++++------------------------------------
     1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Quoted 1 line

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Quoted 31 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

     fs/io_uring.c | 116 ++++++++++++++------------------------------------
     1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 6 lines

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Quoted 44 lines · Jens Axboe

Quoted 31 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

      fs/io_uring.c | 116 ++++++++++++++------------------------------------
      1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 6 lines

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

Quoted 4 lines

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Hmm, what's the semantics? I think we should fail only those who need mm, but can't get it. The alternative is to fail all subsequent after the first mm_fault.

Quoted 45 lines · Pavel Begunkov

Quoted 44 lines · Jens Axboe

Quoted 31 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

      fs/io_uring.c | 116 ++++++++++++++------------------------------------
      1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 6 lines

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

Quoted 7 lines

Quoted 4 lines

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Hmm, what's the semantics? I think we should fail only those who need mm, but can't get it. The alternative is to fail all subsequent after the first mm_fault.

For the sqthread setup, there's no notion of "do this many". It just grabs whatever it can and issues it. This means that the mm assign is really per-sqe. What we did before, with the batching, just optimized it so we'd only grab it for one batch IFF at least one sqe in that batch needed the mm.

Since you've killed the batching, I think the logic should be something ala:

if (io_sqe_needs_user(sqe) && !cur_mm)) {
	if (already_attempted_mmget_and_failed_ {
		-EFAULT end sqe
	} else {
		do mm_get and mmuse dance
	}
}

Hence if the sqe doesn't need the mm, doesn't matter if we previously failed. If we need the mm and previously failed, -EFAULT.

Quoted 71 lines · Jens Axboe

Quoted 45 lines · Pavel Begunkov

Quoted 44 lines · Jens Axboe

Quoted 31 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

       fs/io_uring.c | 116 ++++++++++++++------------------------------------
       1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 6 lines

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

Quoted 7 lines

Quoted 4 lines

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Hmm, what's the semantics? I think we should fail only those who need mm, but can't get it. The alternative is to fail all subsequent after the first mm_fault.

For the sqthread setup, there's no notion of "do this many". It just grabs whatever it can and issues it. This means that the mm assign is really per-sqe. What we did before, with the batching, just optimized it so we'd only grab it for one batch IFF at least one sqe in that batch needed the mm.

Since you've killed the batching, I think the logic should be something ala:

if (io_sqe_needs_user(sqe) && !cur_mm)) {
	if (already_attempted_mmget_and_failed_ {
		-EFAULT end sqe
	} else {
		do mm_get and mmuse dance
	}
}

Quoted 3 lines

Hence if the sqe doesn't need the mm, doesn't matter if we previously failed. If we need the mm and previously failed, -EFAULT.

That makes sense, but a bit hard to implement honoring links and drains

Quoted 72 lines · Pavel Begunkov

Quoted 71 lines · Jens Axboe

Quoted 45 lines · Pavel Begunkov

Quoted 44 lines · Jens Axboe

Quoted 31 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

       fs/io_uring.c | 116 ++++++++++++++------------------------------------
       1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 6 lines

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

Quoted 7 lines

Quoted 4 lines

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Hmm, what's the semantics? I think we should fail only those who need mm, but can't get it. The alternative is to fail all subsequent after the first mm_fault.

For the sqthread setup, there's no notion of "do this many". It just grabs whatever it can and issues it. This means that the mm assign is really per-sqe. What we did before, with the batching, just optimized it so we'd only grab it for one batch IFF at least one sqe in that batch needed the mm.

Since you've killed the batching, I think the logic should be something ala:

if (io_sqe_needs_user(sqe) && !cur_mm)) {
	if (already_attempted_mmget_and_failed_ {
		-EFAULT end sqe
	} else {
		do mm_get and mmuse dance
	}
}

Quoted 4 lines

Quoted 3 lines

Hence if the sqe doesn't need the mm, doesn't matter if we previously failed. If we need the mm and previously failed, -EFAULT.

That makes sense, but a bit hard to implement honoring links and drains

If it becomes too complicated or convoluted, just drop it. It's not worth spending that much time on.

Quoted 76 lines · Jens Axboe

Quoted 75 lines · Pavel Begunkov

Quoted 74 lines · Jens Axboe

Quoted 45 lines · Pavel Begunkov

Quoted 44 lines · Jens Axboe

Quoted 31 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

        fs/io_uring.c | 116 ++++++++++++++------------------------------------
        1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 6 lines

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

Quoted 7 lines

Quoted 4 lines

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Hmm, what's the semantics? I think we should fail only those who need mm, but can't get it. The alternative is to fail all subsequent after the first mm_fault.

For the sqthread setup, there's no notion of "do this many". It just grabs whatever it can and issues it. This means that the mm assign is really per-sqe. What we did before, with the batching, just optimized it so we'd only grab it for one batch IFF at least one sqe in that batch needed the mm.

Since you've killed the batching, I think the logic should be something ala:

if (io_sqe_needs_user(sqe) && !cur_mm)) {
	if (already_attempted_mmget_and_failed_ {
		-EFAULT end sqe
	} else {
		do mm_get and mmuse dance
	}
}

Hence if the sqe doesn't need the mm, doesn't matter if we previously failed. If we need the mm and previously failed, -EFAULT.

Quoted 5 lines

Quoted 1 line

That makes sense, but a bit hard to implement honoring links and drains

If it becomes too complicated or convoluted, just drop it. It's not worth spending that much time on.

I've already done it more or less elegantly, just prefer to test commits before sending.

Quoted 82 lines · Pavel Begunkov

Quoted 81 lines · Jens Axboe

Quoted 72 lines · Pavel Begunkov

Quoted 71 lines · Jens Axboe

Quoted 45 lines · Pavel Begunkov

Quoted 44 lines · Jens Axboe

Quoted 31 lines · Pavel Begunkov

Quoted 22 lines · Jens Axboe

Quoted 21 lines · Jens Axboe

Quoted 20 lines · Pavel Begunkov

Quoted 8 lines · Jens Axboe

Quoted 7 lines · Pavel Begunkov

A small cleanup of very similar but diverged io_submit_sqes() and
io_ring_submit()

Pavel Begunkov (2):
io_uring: handle mm_fault outside of submission
io_uring: merge io_submit_sqes and io_ring_submit

Quoted 8 lines

Quoted 2 lines

fs/io_uring.c | 116 ++++++++++++++------------------------------------
1 file changed, 33 insertions(+), 83 deletions(-)

I like the cleanups here, but one thing that seems off is the assumption that io_sq_thread() always needs to grab the mm. If the sqes processed are just READ/WRITE_FIXED, then it never needs to grab the mm.
Yeah, we removed it to fix bugs. Personally, I think it would be

clearer to do lazy grabbing conditionally, rather than have two functions. And in this case it's easier to do after merging.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

Do you prefer to return it back first?

Ah I see, no I don't care about that.

OK, looked at the post-patches state. It's still not correct. You are grabbing the mm from io_sq_thread() unconditionally. We should not do that, only if the sqes we need to submit need mm context.

Quoted 6 lines

That's what my question to the fix was about :)
1. Then, what the case it could fail?
2. Is it ok to hold it while polling? It could keep it for quite a long time if host is swift, e.g. submit->poll->submit->poll-> ...

Anyway, I will add it back and resend the patchset.

If possible in a simple way, I'd prefer if we do it as a prep patch and then queue that up for 5.4 since we now lost that optimization. Then layer the other 2 on top of that, since I'll just rebase the 5.5 stuff on top of that.

Quoted 7 lines

Quoted 4 lines

If not trivially possible for 5.4, then we'll just have to leave with it in that release. For that case, you can fold the change in with these two patches.

Hmm, what's the semantics? I think we should fail only those who need mm, but can't get it. The alternative is to fail all subsequent after the first mm_fault.

For the sqthread setup, there's no notion of "do this many". It just grabs whatever it can and issues it. This means that the mm assign is really per-sqe. What we did before, with the batching, just optimized it so we'd only grab it for one batch IFF at least one sqe in that batch needed the mm.

Since you've killed the batching, I think the logic should be something ala:

if (io_sqe_needs_user(sqe) && !cur_mm)) {
	if (already_attempted_mmget_and_failed_ {
		-EFAULT end sqe
	} else {
		do mm_get and mmuse dance
	}
}

Quoted 4 lines

Quoted 3 lines

Hence if the sqe doesn't need the mm, doesn't matter if we previously failed. If we need the mm and previously failed, -EFAULT.

That makes sense, but a bit hard to implement honoring links and drains

If it becomes too complicated or convoluted, just drop it. It's not worth spending that much time on.

Quoted 2 lines

I've already done it more or less elegantly, just prefer to test commits before sending.

That's always appreciated!

It struck me that while I've added quite a few regression tests, we don't have any that just do basic read/write using the variety of settings we have for that. So I added that to liburing.