Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp13952905pxu; Mon, 4 Jan 2021 08:51:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJw7LSla9JJXG6iGU0sDPkgcEbJnypFnEq6xBBoqhsrdZORuX5IzidkBhBn7tTVGMBlzC/h1 X-Received: by 2002:a17:906:941a:: with SMTP id q26mr67765459ejx.227.1609779077431; Mon, 04 Jan 2021 08:51:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609779077; cv=none; d=google.com; s=arc-20160816; b=WWG+5+pKciBnoeNBepq7Jj2XNvx4YVi/dz9QvTV5Ta6sGGOOvqUZZD9s84DZVOAtKu LGR4FzsGEzn48UE+BzLLI/emkAC5Yfb6q0u2bQgAuaAFJVkVSCudbvOi75+BNYrO2H0S 8l+jHCNNE6KkI1P7ExaeDDgJ96rISX5/ukZ5o0MxxuyJu+A2SJrFEI1fdw0hWTK0Cu0o NDchBUI7S8D0uKo98ra8HwCsHFaR41sYcY+UrayC6KIFRBcVYb5L43/CyPdJr9fpUHrs mT0neisdl9m50SVZN1eCUcNLTfumsr/k1o3w6PQEgfBr+1TNw9kS/Lg0DoZA7Qj+Fn9b MRsg== 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=uisP94bgjvXpoLmCzeymbKCxzHxMhiiig7z6mWVQUTs=; b=0WfXZjjiDwCW1AJhFN7bdRGIcA/LyiwqLc78nNapWibBxZoSRDLktz/YUvxyTPSVQC VrG6NipZi8F+IZEsMJyrYj0GmElbIuYUlkX+3lUGLDhqOSlGN4S2SALdYRVhwsf2M+ME lq5J+EcTx5FgICGu5etNQ40+1ea9zdklex8HJ51fIc2fSeVK9QwUbyCv2zotQRL0aIgF tIJFvtQE+ul/enGFVGzgaY/M4M24Msc+Dg/RZ31tUtKACI6qHWVV07e2zvy/iA8rEZm1 oqHAXtrt727p+Zp6csPkC8Semhu4YN8xA1bkiZhjUDdgaej8kLaouKTobZdgfE1kJqeE 0U6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=N5DYcnrk; 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 hk16si28932202ejb.8.2021.01.04.08.50.54; Mon, 04 Jan 2021 08:51:17 -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=N5DYcnrk; 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 S1728778AbhADQCO (ORCPT + 99 others); Mon, 4 Jan 2021 11:02:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:39414 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728748AbhADQCJ (ORCPT ); Mon, 4 Jan 2021 11:02:09 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C466022519; Mon, 4 Jan 2021 16:01:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609776089; bh=waRQhcYKE8DOL1wuAwegN+jbUsvrLSohcSjKxKE+tn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N5DYcnrklATj6xZbUBR3SGvaeaNaU+qt9NSW7BTEQCwhOOkTAzMuzPaZ5+4oivhmx kVRz6FpHp4MYb2cW6S9KYoIHE7Qels4k+AMaBm08S4uilw855lZYTc70tZqm7ZnV08 w02vLJhqQbvLyPpBvB7Srxhyvv/26fYsM+CdDE+s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jens Axboe , Christian Brauner Subject: [PATCH 5.10 17/63] io_uring: dont assume mm is constant across submits Date: Mon, 4 Jan 2021 16:57:10 +0100 Message-Id: <20210104155709.650714386@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210104155708.800470590@linuxfoundation.org> References: <20210104155708.800470590@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: Jens Axboe commit 77788775c7132a8d93c6930ab1bd84fc743c7cb7 upstream. If we COW the identity, we assume that ->mm never changes. But this isn't true of multiple processes end up sharing the ring. Hence treat id->mm like like any other process compontent when it comes to the identity mapping. This is pretty trivial, just moving the existing grab into io_grab_identity(), and including a check for the match. Cc: stable@vger.kernel.org # 5.10 Fixes: 1e6fa5216a0e ("io_uring: COW io_identity on mismatch") Reported-by: Christian Brauner : Tested-by: Christian Brauner : Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- fs/io_uring.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -1369,6 +1369,13 @@ static bool io_grab_identity(struct io_k spin_unlock_irq(&ctx->inflight_lock); req->work.flags |= IO_WQ_WORK_FILES; } + if (!(req->work.flags & IO_WQ_WORK_MM) && + (def->work_flags & IO_WQ_WORK_MM)) { + if (id->mm != current->mm) + return false; + mmgrab(id->mm); + req->work.flags |= IO_WQ_WORK_MM; + } return true; } @@ -1393,13 +1400,6 @@ static void io_prep_async_work(struct io req->work.flags |= IO_WQ_WORK_UNBOUND; } - /* ->mm can never change on us */ - if (!(req->work.flags & IO_WQ_WORK_MM) && - (def->work_flags & IO_WQ_WORK_MM)) { - mmgrab(id->mm); - req->work.flags |= IO_WQ_WORK_MM; - } - /* if we fail grabbing identity, we must COW, regrab, and retry */ if (io_grab_identity(req)) return;