All of lore.kernel.org
 help / color / mirror / Atom feed
From: lizetao <lizetao1@huawei.com>
To: Pavel Begunkov <asml.silence@gmail.com>,
	Bui Quang Minh <minhquangbui99@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	"io-uring@vger.kernel.org" <io-uring@vger.kernel.org>,
	"syzbot+3c750be01dab672c513d@syzkaller.appspotmail.com"
	<syzbot+3c750be01dab672c513d@syzkaller.appspotmail.com>
Subject: RE: [PATCH] io_uring: simplify the SQPOLL thread check when cancelling requests
Date: Mon, 13 Jan 2025 04:40:49 +0000	[thread overview]
Message-ID: <7a3696740cd546cd95cd821a7a7be03c@huawei.com> (raw)
In-Reply-To: <75e12d85-9c2e-4b06-99d1-bc29c5422b69@gmail.com>

Hi,

> -----Original Message-----
> From: Pavel Begunkov <asml.silence@gmail.com>
> Sent: Monday, January 13, 2025 5:16 AM
> To: Bui Quang Minh <minhquangbui99@gmail.com>; lizetao
> <lizetao1@huawei.com>; linux-kernel@vger.kernel.org
> Cc: Jens Axboe <axboe@kernel.dk>; io-uring@vger.kernel.org;
> syzbot+3c750be01dab672c513d@syzkaller.appspotmail.com
> Subject: Re: [PATCH] io_uring: simplify the SQPOLL thread check when
> cancelling requests
> 
> On 1/12/25 16:14, Bui Quang Minh wrote:
> ...
> >>> @@ -2898,7 +2899,12 @@ static __cold void io_ring_exit_work(struct
> >>> work_struct *work)
> >>>           if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
> >>>               io_move_task_work_from_local(ctx);
> >>>
> >>> -        while (io_uring_try_cancel_requests(ctx, NULL, true))
> >>> +        /*
> >>> +         * Even if SQPOLL thread reaches this path, don't force
> >>> +         * iopoll here, let the io_uring_cancel_generic handle
> >>> +         * it.
> >>
> >> Just curious, will sq_thread enter this io_ring_exit_work path?
> >
> > AFAIK, yes. The SQPOLL thread is created with create_io_thread, this function
> creates a new task with CLONE_FILES. So all the open files is shared. There will
> be case that the parent closes its io_uring file and SQPOLL thread become the
> only owner of that file. So it can reach this path when terminating.
> 
> The function is run by a separate kthread, the sqpoll task doesn't call it directly.

I also think so, the sqpoll task may not call io_ring_exit_work().
> 
> [...]
> >>>> io_uring,
> >>> -                                     cancel_all);
> >>> +                                     cancel_all,
> >>> +                                     true);
> >>>           }
> >>>
> >>>           if (loop) {
> >>> --
> >>> 2.43.0
> >>>
> >>
> >> Maybe you miss something, just like Begunkov mentioned in your last
> version patch:
> >>
> >>    io_uring_cancel_generic
> >>      WARN_ON_ONCE(sqd && sqd->thread != current);
> >>
> >> This WARN_ON_ONCE will never be triggered, so you could remove it.
> >
> > He meant that we don't need to annotate sqd->thread access in this debug
> check. The io_uring_cancel_generic function has assumption that the sgd is not
> NULL only when it's called by a SQPOLL thread. So the check means to ensure
> this assumption. A data race happens only when this function is called by other
> tasks than the SQPOLL thread, so it can race with the SQPOLL termination.
> However, the sgd is not NULL only when this function is called by SQPOLL
> thread. In normal situation following the io_uring_cancel_generic's assumption,
> the data race cannot happen. And in case the assumption is broken, the
> warning almost always is triggered even if data race happens. So we can ignore
> the race here.
> 
> Right. And that's the point of warnings, they're supposed to be untriggerable,
> otherwise there is a problem with the code that needs to be fixed.

Okay, I understand the meaning of this WARN.
> 
> --
> Pavel Begunkov

---
Li Zetao


  reply	other threads:[~2025-01-13  4:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-12 14:33 [PATCH] io_uring: simplify the SQPOLL thread check when cancelling requests Bui Quang Minh
2025-01-12 15:45 ` lizetao
2025-01-12 16:14   ` Bui Quang Minh
2025-01-12 21:15     ` Pavel Begunkov
2025-01-13  4:40       ` lizetao [this message]
2025-01-13 15:33       ` Bui Quang Minh
2025-01-13  7:49 ` lizetao

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=7a3696740cd546cd95cd821a7a7be03c@huawei.com \
    --to=lizetao1@huawei.com \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minhquangbui99@gmail.com \
    --cc=syzbot+3c750be01dab672c513d@syzkaller.appspotmail.com \
    /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.