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 42ACFC43334 for ; Fri, 8 Jul 2022 00:58:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A42F66B0072; Thu, 7 Jul 2022 20:58:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CADD6B0073; Thu, 7 Jul 2022 20:58:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86BA16B0074; Thu, 7 Jul 2022 20:58:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 718A56B0072 for ; Thu, 7 Jul 2022 20:58:06 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4750D20516 for ; Fri, 8 Jul 2022 00:58:06 +0000 (UTC) X-FDA: 79662120972.08.9B74713 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id C40128005B for ; Fri, 8 Jul 2022 00:58:05 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A0B5F61672; Fri, 8 Jul 2022 00:58:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5C65C3411E; Fri, 8 Jul 2022 00:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1657241884; bh=kz+sjS1jFeh8hmONUnaA1qHQSeXeSgEjdjUHP9bpnnk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tcoqnfG+iZBbGN8zKSvMzImIv6SEDxhJywlEtFWkPKmrnIUlNrrEgrGFmzJd3cKZX Y7dO4DItbbfosuk7R97F0fYvPUE9tlnGbzhgUaUhMLY+gR9sYHcFsE52hpCyTrndW5 LBCAyM69c/zCxP+IjKp75piOqqM5XW47FFYH+nrc= Date: Thu, 7 Jul 2022 17:58:03 -0700 From: Andrew Morton To: Rik van Riel Cc: "Kirill A. Shutemov" , Josef Bacik , linux-mm@kvack.org, Matthew Wilcox , Chris Mason Subject: Re: [PATCH] mm: fix page leak with multiple threads mapping the same page Message-Id: <20220707175803.3c30c6ea64843f4bd8b64908@linux-foundation.org> In-Reply-To: References: <2b798acfd95c9ab9395fe85e8d5a835e2e10a920.1657051137.git.josef@toxicpanda.com> <20220706224657.3xbhbkflernezlxy@black.fi.intel.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657241885; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uNmLkJFjspoPWTMirl3DTGlCY6pxKUa0XynTwZmRfw0=; b=vRS59XFEwDXXaDhnkzcSn2ncOF58Zp2yAvIk1/2jCE04E9BGEsDME624Jg7GJ7xM21ZWJP eVRAx11dNC3XSg2+TVMo7QD4/Zn01zEUCjVv8ssut1uSAttb36Yr8dxydiKa4gOZF720ZS /x7bxA+hqi36drk99IhniF5nlziV8nI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657241885; a=rsa-sha256; cv=none; b=n74/ynVS8jVt0o1dqBVan9kW3DTQPJHQavNpC9vchL/sy0ByXixmyLx9yeFbv0aI5vtWcT K0TfwbGmja0NUTfAgH72897ji0xYgloE0Szs9fsyVPTuIrrR/Vcas80XxPYshGlUK2U2Xi DHWHNXq5kbzLZ188apOc3lBki6QiIeg= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=tcoqnfG+; dmarc=none; spf=pass (imf30.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=tcoqnfG+; dmarc=none; spf=pass (imf30.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Stat-Signature: d8ts418dm64qfu9csyw7a84c1q4er7aa X-Rspamd-Queue-Id: C40128005B X-Rspamd-Server: rspam07 X-Rspam-User: X-HE-Tag: 1657241885-308044 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: On Wed, 06 Jul 2022 20:42:56 -0400 Rik van Riel wrote: > On Thu, 2022-07-07 at 01:46 +0300, Kirill A. Shutemov wrote: > > On Tue, Jul 05, 2022 at 04:00:36PM -0400, Josef Bacik wrote: > > >=20 > > > Fix this by returning VM_FAULT_NOPAGE in the > > > pmd_devmap_trans_unstable() > > > case, this makes us drop the ref on the page properly, and now my > > > reproducer no longer leaks the huge pages. > > >=20 > > > Fixes: f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() > > > codepaths") > > > Cc: Kirill A. Shutemov > > > Cc: Matthew Wilcox (Oracle) > > > Signed-off-by: Josef Bacik > > > Signed-off-by: Rik van Riel > > > Signed-off-by: Chris Mason > >=20 > > Cc: stable@=A0 >=20 > Yes, it should. How do we send a patch to stable@ > after the start of the thread? cc'ing the stable list doesn't have much affect, afaik. What Kirill means is that we should add cc:stable to this patch's changelog. I did that yesterday. >=20 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@ -4371,7 +4371,7 @@ vm_fault_t finish_fault(struct vm_fault *vmf) > > > =A0 > > > =A0=A0=A0=A0=A0=A0=A0=A0/* See comment in handle_pte_fault() */ > > > =A0=A0=A0=A0=A0=A0=A0=A0if (pmd_devmap_trans_unstable(vmf->pmd)) > > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return 0; > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return VM_FAULT_NOPAGE; > >=20 > > Comment update would be nice. > >=20 > > Other instances of pmd_devmap_trans_unstable() return 0 in the fault > > path. > > Explanation would be helpful. > >=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. I think Kirill meant this should be added to the code comment!