Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9106715pxu; Mon, 28 Dec 2020 06:48:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJy+Pkasa1x+R+ZKz/7dFcyEx/+kPqX2Es9Pucg201pBm+HNBd7u7xmGg4b2HhsRBUWJWgFe X-Received: by 2002:a17:906:edd2:: with SMTP id sb18mr43112763ejb.114.1609166930487; Mon, 28 Dec 2020 06:48:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609166930; cv=none; d=google.com; s=arc-20160816; b=yfx7ogq1pm6LXFT3xtcTVX6hB4NK0eLb+rH5wpsuvmphYQAwaNojVzzBj29fnBjKqQ boeU5M6kBnuxL6qt22iK/P1a6ZaVFW0AuD+UHeb8iE+glWevHMwN8sEndLW0qzYYSd/A 6UcDCgKIi1l6rm4jngbGlfQHgCmqkMh8roovuBc4EP21M8oIFFOrKvTej8h1b/U0Gr5Y ao3AIxy4yeRMhlbctKcwJf67RqPZxAkZyIEzsArWrNDPHE0IoWh7uml8IfbISw+vqiR2 19tsWXSx5hWoF8lBwagLw0i4Y9wPwNAFAYvXXyM7nCWgLhEYWzYOuR9AC1mpN1zcUnjR +6jw== 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:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=TH9GvXXbUqR2FRdsRT4DFytyD7iBWC1iwe+0rFKfhac=; b=WGbFX2uLX6yB0ugEczcU9bZmegI15Cspo0YIhFNaVO20zRmNEMHcVA6BUFc5yIApta tAggLH8sZkA7tWXpO6HeDbYOFPPEotpy3pslcsDes4vvkofuojK+xwGf5E4e7pWcaSVG j0h6IxH/H0EwKGE2dgX/ZVef57op+n/cK8te5WfhFyklIoG9pi2L/hFGSZVvdYXMbBMQ /PKxvbmSOGmfbDUMfhU4WMd8Fzs4KcRbozrQR9ELFUgHriJnr20QcMjTN/aPp1YFFkSM sdnUyygZgwT7EoVs2c2Ab0KfsEwgu35vq1Sk2lBq6CXGOUkVXnBhBu0Mj9oVdx59UIIh zQ6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=2JXJLno0; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o22si19278901ejg.205.2020.12.28.06.48.27; Mon, 28 Dec 2020 06:48:50 -0800 (PST) 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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=2JXJLno0; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439210AbgL1OXy (ORCPT + 99 others); Mon, 28 Dec 2020 09:23:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:59646 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2502813AbgL1OXe (ORCPT ); Mon, 28 Dec 2020 09:23:34 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9781B20731; Mon, 28 Dec 2020 14:22:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609165374; bh=WJeUAuTdeT5MrHYibK7LHhElDRROfb2vnw0VRIECb3k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2JXJLno0kLCntu6oHlM9AMoEmVMHRF95cNr2ubwTnwQgQLC0g0snxMlp/+8sEym2H 4D/sqzMwoPemb4hxTClv0e7+3Nzsmj83jaaYWLWGjNIFOwjheA4JK/LIemzDYnllb1 UlncPZsq4iekhxWBLRy6No3ybIL/7IFQJILo4OVo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Begunkov , Jens Axboe , Sasha Levin Subject: [PATCH 5.10 507/717] io_uring: cancel reqs shouldnt kill overflow list Date: Mon, 28 Dec 2020 13:48:25 +0100 Message-Id: <20201228125045.251872226@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228125020.963311703@linuxfoundation.org> References: <20201228125020.963311703@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Pavel Begunkov [ Upstream commit cda286f0715c82f8117e166afd42cca068876dde ] io_uring_cancel_task_requests() doesn't imply that the ring is going away, it may continue to work well after that. The problem is that it sets ->cq_overflow_flushed effectively disabling the CQ overflow feature Split setting cq_overflow_flushed from flush, and do the first one only on exit. It's ok in terms of cancellations because there is a io_uring->in_idle check in __io_cqring_fill_event(). It also fixes a race with setting ->cq_overflow_flushed in io_uring_cancel_task_requests, whuch's is not atomic and a part of a bitmask with other flags. Though, the only other flag that's not set during init is drain_next, so it's not as bad for sane architectures. Signed-off-by: Pavel Begunkov Fixes: 0f2122045b946 ("io_uring: don't rely on weak ->files references") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- fs/io_uring.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/io_uring.c b/fs/io_uring.c index b9d3209a5f9de..e9219841923cc 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -1641,10 +1641,6 @@ static bool io_cqring_overflow_flush(struct io_ring_ctx *ctx, bool force, spin_lock_irqsave(&ctx->completion_lock, flags); - /* if force is set, the ring is going away. always drop after that */ - if (force) - ctx->cq_overflow_flushed = 1; - cqe = NULL; list_for_each_entry_safe(req, tmp, &ctx->cq_overflow_list, compl.list) { if (tsk && req->task != tsk) @@ -8378,6 +8374,8 @@ static void io_ring_ctx_wait_and_kill(struct io_ring_ctx *ctx) { mutex_lock(&ctx->uring_lock); percpu_ref_kill(&ctx->refs); + /* if force is set, the ring is going away. always drop after that */ + ctx->cq_overflow_flushed = 1; if (ctx->rings) io_cqring_overflow_flush(ctx, true, NULL, NULL); mutex_unlock(&ctx->uring_lock); -- 2.27.0