public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Pavel Begunkov <[email protected]>, [email protected]
Subject: Re: [PATCH for-5.10] io_uring: remove req cancel in ->flush()
Date: Tue, 20 Oct 2020 08:09:37 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 10/19/20 5:40 PM, Pavel Begunkov wrote:
> On 19/10/2020 21:08, Jens Axboe wrote:
>> On 10/19/20 9:45 AM, Pavel Begunkov wrote:
>>> Every close(io_uring) causes cancellation of all inflight requests
>>> carrying ->files. That's not nice but was neccessary up until recently.
>>> Now task->files removal is handled in the core code, so that part of
>>> flush can be removed.
>>
>> It does change the behavior, but I'd wager that's safe. One minor
>> comment:
> 
> Right, but I would think that users are not happy that every close
> kills requests without apparent reasons.

To be fair, closing the ring fd is kind of unexpected and I would not
expect any real applications to do that. If they did, I would have
expected queries on why file table requests get canceled on close. Hence
I'm not too worried about anyone hitting any issues related to this
change, as the change is certainly one for the better.

>>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>>> index 95d2bb7069c6..6536e24eb44e 100644
>>> --- a/fs/io_uring.c
>>> +++ b/fs/io_uring.c
>>> @@ -8748,16 +8748,12 @@ void __io_uring_task_cancel(void)
>>>  
>>>  static int io_uring_flush(struct file *file, void *data)
>>>  {
>>> -	struct io_ring_ctx *ctx = file->private_data;
>>> +	bool exiting = !data;
>>>  
>>> -	/*
>>> -	 * If the task is going away, cancel work it may have pending
>>> -	 */
>>>  	if (fatal_signal_pending(current) || (current->flags & PF_EXITING))
>>> -		data = NULL;
>>> +		exiting = true;
>>>  
>>> -	io_uring_cancel_task_requests(ctx, data);
>>> -	io_uring_attempt_task_drop(file, !data);
>>> +	io_uring_attempt_task_drop(file, exiting);
>>>  	return 0;
>>>  }
>>
>> Why not just keep the !data for task_drop? Would make the diff take
>> away just the hunk we're interested in. Even adding a comment would be
>> better, imho.
> 
> That would look cleaner, but I just left what already was there. TBH,
> I don't even entirely understand why exiting=!data. Looking up how
> exit_files() works, it passes down non-NULL files to
> put_files_struct() -> ... filp_close() -> f_op->flush().
> 
> I'm curious how does this filp_close(file, files=NULL) happens?

It doesn't, we just clear it internall to match all requests, not just
files backed ones.

> Moreover, if that's exit_files() which is interesting, then first
> it calls io_uring_cancel_task_requests(), which should remove all
> struct file from tctx->xa. I haven't tested it though.

Yep, further cleanups are certainly possible there.

I've queued this up, thanks.

-- 
Jens Axboe


  reply	other threads:[~2020-10-20 14:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19 15:45 [PATCH for-5.10] io_uring: remove req cancel in ->flush() Pavel Begunkov
2020-10-19 20:08 ` Jens Axboe
2020-10-19 23:40   ` Pavel Begunkov
2020-10-20 14:09     ` Jens Axboe [this message]
2020-10-20 16:29       ` Pavel Begunkov
2020-10-20 16:59         ` Jens Axboe
2020-10-22  6:42 ` Xiaoguang Wang
2020-10-22 11:44   ` Pavel Begunkov
2020-10-23  3:33     ` Xiaoguang Wang

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] \
    /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