From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A306DC433EF for ; Fri, 15 Jul 2022 15:21:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E239B9401FC; Fri, 15 Jul 2022 11:21:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAC109401FB; Fri, 15 Jul 2022 11:21:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4DF59401FC; Fri, 15 Jul 2022 11:21:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B1C049401FB for ; Fri, 15 Jul 2022 11:21:47 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 82796152A for ; Fri, 15 Jul 2022 15:21:47 +0000 (UTC) X-FDA: 79689699054.13.2B387AB Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf29.hostedemail.com (Postfix) with ESMTP id 122BC12007D for ; Fri, 15 Jul 2022 15:21:45 +0000 (UTC) Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oCN8H-00060Z-T4; Fri, 15 Jul 2022 11:21:33 -0400 Message-ID: Subject: Re: [PATCH] mm: fix page leak with multiple threads mapping the same page From: Rik van Riel To: Andrew Morton Cc: "Kirill A. Shutemov" , Josef Bacik , linux-mm@kvack.org, Matthew Wilcox , Chris Mason Date: Fri, 15 Jul 2022 11:21:32 -0400 In-Reply-To: <20220707175803.3c30c6ea64843f4bd8b64908@linux-foundation.org> References: <2b798acfd95c9ab9395fe85e8d5a835e2e10a920.1657051137.git.josef@toxicpanda.com> <20220706224657.3xbhbkflernezlxy@black.fi.intel.com> <20220707175803.3c30c6ea64843f4bd8b64908@linux-foundation.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-u9T57SpqAp83XcrE1F4Q" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657898507; a=rsa-sha256; cv=none; b=Yl8oidwqVqCTOXhzWRfHCiKL2pjVO+ircfNzzBLH+aQgTXarlvUMtEv7LtxK8VlW8CNcv3 1oSlmT0USQZPcubuAGQjFgLLwfgEwngCouF3PYOU5H4D4HgKaAhCUXdKBw5tOG/bRSxVbj HUtNpMj5dTJq/6tbiFB9ShI8xF4lPzM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=none; spf=none (imf29.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657898507; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ugacKsOMcODBiBlhrLEHlYfQNKuKL7eRB14o40k+gkA=; b=2u2yPeX1tSnNa5vh0MSHKWaVe2LX4lQ6daz08CEeSDkbSUSTZWHSUTERHOOVMoU8OjzdTr 8HeTK4d9Pxrupd56ZXVsGGaYlxEOzHBz+qr9wV+ty5FLSL3wuDdTY1qgRn/4qAgLTgQSLH Vy6UhNPQg/JjjUjYce27CqGJuSw28fQ= X-Stat-Signature: x814hb9ow7pzq8yfxwbkcb7nh7dyoatn X-Rspamd-Queue-Id: 122BC12007D Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=none; spf=none (imf29.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1657898505-902199 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --=-u9T57SpqAp83XcrE1F4Q Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2022-07-07 at 17:58 -0700, Andrew Morton wrote: > On Wed, 06 Jul 2022 20:42:56 -0400 Rik van Riel > wrote: > > >=20 > > The explanation is that by the time we get to > > finish_fault, we already have a reference on a > > page, and we need to ensure that reference > > gets released by the caller. > >=20 > > VM_FAULT_NOPAGE is one of the ways to indicate > > that the page should be freed. >=20 > I think Kirill meant this should be added to the code comment! OK, I finally got around to looking at that today, and it seems like the comment at the top of finish_fault() already has everything I wanted to write down. Is there anything else we should add here? /** * finish_fault - finish page fault once we have prepared the page to fault * * @vmf: structure describing the fault * * This function handles all that is needed to finish a page fault once the * page to fault in is prepared. It handles locking of PTEs, inserts PTE for * given page, adds reverse page mapping, handles memcg charges and LRU * addition. * * The function expects the page to be locked and on success it consumes a * reference of a page being mapped (for the PTE which maps it). * * Return: %0 on success, %VM_FAULT_ code in case of error. */ vm_fault_t finish_fault(struct vm_fault *vmf) { --=20 All Rights Reversed. --=-u9T57SpqAp83XcrE1F4Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAmLRhfwACgkQznnekoTE 3oNfSgf/d5uTfKagE+rJZWRLAvCFc+Yn5s0QWo8eCve5g3sHvr1Ih0CnqTp5RqU1 xAqT93sOJxo5d1ff0h7HFc9DnrwroDqFvjEyfy40SXdolbZvxEdS0Tuurg15FYRO CyX4cPdcvXVAsW9OetI8DpkM1T7ARDpPJUI6e/bEMlLGTDRVJHb5jp5JuSyqelXE 9xuZMawqMDo5A5zHHbhToVGQMc2blwoiPCsP5gXJVfbluJ2g4+DNAifIzTfiBVUy UR886qMkE6SuWLc/x2A8+m0O+VWd04qroJLE2nF1+evrdlxgVlefols86ZWz97wL Etc8L6OsMzxaeW6hvrwE26EBs6vDOg== =JQYc -----END PGP SIGNATURE----- --=-u9T57SpqAp83XcrE1F4Q--