Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5113536pxj; Tue, 22 Jun 2021 15:38:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGYUpFEFvMG7sApQIXUlSNdsl8zivUV/yh6oFNgQPWWMEIZteX24cWGjx75Z7C+Ci452ii X-Received: by 2002:a5d:89d0:: with SMTP id a16mr4667465iot.76.1624401483393; Tue, 22 Jun 2021 15:38:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624401483; cv=none; d=google.com; s=arc-20160816; b=PHApxHmSBQjG0x72l+STNpCH+j9Kf0rRYpGoEoEUbzLJqjUXaAIPjRQQYhWYf/eJit iM7DsBMO1MRGAA7yzAc1BNikV05KFA7m2hU9EeaIJjtGXnswJVwzJnfhtklMxnKAPF1K I9foX900WOypUHRWSzuAAdpGVUDdssSmcEXNDgse6Pl8n+mMSaQFQKAnE0zl8WE7+zcw HQEjKRBz0TLFnRJ2J/7n8dPFFsbvkcsUU3m5d6wUbzbgiZQYtjMUGcRAvLY456as/fmj XgWm1l8axZMEyBzIbKgKeGoIFr7lPBnBHbWfsq93xaFNZ0l9SolyUjQ5p7DO0Zc2n0Nr sTMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:to:from:subject :message-id; bh=CIncmydXS8JWuvCS/hSrBtM+J+laCDGsV2lnZ669phE=; b=cqFfQ/0zDwia7hOpuWsZ7NmB2McXbwzM0LNgOhc7OdsGtB294JLydZ2sT7FV7rKAMP M0gavcc/skricjm0DqFGks/QxBK3pCme4H5vT1QrggPsieBBZVe5HeSngDTekwOffzJw lkwRrETFA3tC2hHYBz61UZgYvqjbApsbi+bz45zm0mSfzpi1yVZZ1OReN+8mKTcag8n4 rjUytwuqLaqrCSKnXGlblisCTAbVgaa0FFY+5K5YXdYilQ0GCD3DKJ9mCdU6xFAjMNd1 dOH0utvjn7ArX5jbrbvlPsELbyp81KKba9OjczJmc3BpY2PHq+KgVymZW6q7ZDjNmTvQ 93ow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l16si7560190ilo.155.2021.06.22.15.37.50; Tue, 22 Jun 2021 15:38:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230249AbhFVWjd (ORCPT + 99 others); Tue, 22 Jun 2021 18:39:33 -0400 Received: from cloud48395.mywhc.ca ([173.209.37.211]:36352 "EHLO cloud48395.mywhc.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229800AbhFVWjd (ORCPT ); Tue, 22 Jun 2021 18:39:33 -0400 Received: from modemcable064.203-130-66.mc.videotron.ca ([66.130.203.64]:33484 helo=[192.168.1.179]) by cloud48395.mywhc.ca with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lvp19-0002q8-Ul; Tue, 22 Jun 2021 18:37:15 -0400 Message-ID: Subject: Re: [PATCH 1/2 v2] io_uring: Fix race condition when sqp thread goes to sleep From: Olivier Langlois To: Pavel Begunkov , Jens Axboe , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 22 Jun 2021 18:37:15 -0400 In-Reply-To: References: <67c806d0bcf2e096c1b0c7e87bd5926c37231b87.1624387080.git.olivier@trillion01.com> <60d23218.1c69fb81.79e86.f345SMTPIN_ADDED_MISSING@mx.google.com> Organization: Trillion01 Inc Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.40.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud48395.mywhc.ca X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trillion01.com X-Get-Message-Sender-Via: cloud48395.mywhc.ca: authenticated_id: olivier@trillion01.com X-Authenticated-Sender: cloud48395.mywhc.ca: olivier@trillion01.com X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2021-06-22 at 21:45 +0100, Pavel Begunkov wrote: > On 6/22/21 7:55 PM, Olivier Langlois wrote: > > If an asynchronous completion happens before the task is preparing > > itself to wait and set its state to TASK_INTERRUPTIBLE, the > > completion > > will not wake up the sqp thread. > > > > Signed-off-by: Olivier Langlois > > --- > > ?fs/io_uring.c | 2 +- > > ?1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/io_uring.c b/fs/io_uring.c > > index fc8637f591a6..02f789e07d4c 100644 > > --- a/fs/io_uring.c > > +++ b/fs/io_uring.c > > @@ -6902,7 +6902,7 @@ static int io_sq_thread(void *data) > > ????????????????} > > ? > > ????????????????prepare_to_wait(&sqd->wait, &wait, > > TASK_INTERRUPTIBLE); > > -???????????????if (!io_sqd_events_pending(sqd)) { > > +???????????????if (!io_sqd_events_pending(sqd) && !current- > > >task_works) { > > Agree that it should be here, but we also lack a good enough > task_work_run() around, and that may send the task burn CPU > for a while in some cases. Let's do > > if (!io_sqd_events_pending(sqd) && !io_run_task_work()) > ?? ... I can do that if you want but considering that the function is inline and the race condition is a relatively rare occurence, is the cost coming with inline expansion really worth it in this case? > > fwiw, no need to worry about TASK_INTERRUPTIBLE as > io_run_task_work() sets it to TASK_RUNNING. I wasn't worried about that as I believe that finish_wait() is taking care the state as well. What I wasn't sure about was if the patch was sufficient to totally eliminate the race condition. I had to educate myself about how schedule() works to appreciate its design and convince myself that the patch was good. > > > ????????????????????????needs_sched = true; > > ????????????????????????list_for_each_entry(ctx, &sqd->ctx_list, > > sqd_list) { > > ????????????????????????????????io_ring_set_wakeup_flag(ctx); > > >