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 272A5C54E67 for ; Tue, 26 Mar 2024 14:57:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFB816B00A0; Tue, 26 Mar 2024 10:57:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AABE46B00A1; Tue, 26 Mar 2024 10:57:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 973456B00A2; Tue, 26 Mar 2024 10:57:31 -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 8355C6B00A0 for ; Tue, 26 Mar 2024 10:57:31 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1491E140C93 for ; Tue, 26 Mar 2024 14:57:31 +0000 (UTC) X-FDA: 81939493902.10.5D89E98 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id B7BFA180013 for ; Tue, 26 Mar 2024 14:57:27 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="mkGbXX4/"; spf=pass (imf16.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711465047; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4uIJUGLkQRKUQyCGjAWUoWWKWykk3vu+aCljlwkTmV4=; b=LzMeJ36xSLs9mjjJTpUHTKomOvt02N54NrGRXH7LPyrqoDZTB2c8VKdoH+E4zGAjU7qxLc gs0IkM+kRDbEGMz9aac9xB14ldBBXEazCi0I2lZFG4nf1Af5FfEUi+pqRIqzyTnfsdpdYY zkiDVxuSqror7qKljGpV9hFOzW05oLk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711465047; a=rsa-sha256; cv=none; b=CkqgjCwiXoRCUD6GmujEdYHy/3CxJkU5bJPVGuubWKzVhm5tC7qEznqqOch8A0ZsLgR8yw FzGkRUut+oLh6xl+6aA+fnRlbWelPP/Vw99WJ8xngYL6ML5KZi5cENA3/SsSkxWYKbVaaF /dHlBSKRQESbV2A5LO/jsfF5VxAPbdg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="mkGbXX4/"; spf=pass (imf16.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B27B3611ED; Tue, 26 Mar 2024 14:57:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03F0CC433C7; Tue, 26 Mar 2024 14:57:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711465046; bh=sq1B4yPNkZWKh6th8vPtdVzhFb7i5RMJZN/k6yxDj2Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mkGbXX4/6d2pvS4gRiFkrP1zX6w2uIWEkJXcnLCgDB+QMZLLOth07HQf1k23UuxSK rKKgmefLXwFeqhX5uZVKYcTOq9908DNjPHTDDh93PD9urSfCDgf41GDQRzyA1xHBXI 6UzBC0H/zpeY0hXouZmJ63J1DkqU0eyIQB9Da2H7A8ghyBuDVUywavIK3htwwJk1ac ORIg24R2gqHTwfrzXF4Gz6p3nfgDY+Rw/bxyQ+gXPkrDVJzHjEJ+bAiG8DgMqiM9vc e6QONn1q9Vvh+L72URJnrKYQHzKnnz9gHOGO1QvF0FpCgGsQgjp/iUPaC3UePFgL+q xlh0j2gmDG9Gw== Date: Tue, 26 Mar 2024 16:56:44 +0200 From: Mike Rapoport To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Miklos Szeredi , Lorenzo Stoakes , xingwei lee , yue sun , Miklos Szeredi , stable@vger.kernel.org Subject: Re: [PATCH v2 1/3] mm/secretmem: fix GUP-fast succeeding on secretmem folios Message-ID: References: <20240326143210.291116-1-david@redhat.com> <20240326143210.291116-2-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240326143210.291116-2-david@redhat.com> X-Rspamd-Queue-Id: B7BFA180013 X-Rspam-User: X-Stat-Signature: 5d459uwjhw8csx5deu1m6crj1cxh1had X-Rspamd-Server: rspam03 X-HE-Tag: 1711465047-211248 X-HE-Meta: U2FsdGVkX19rNguC7OMVa4L94lOB3wli9rRlmNPDdkiPrNJ6Hpl7Igu92Hew8UTFQlgcoZDn2tKY7leK6Y0/7VLHgu5V3oFL/Fj9N3vNrrlrFeLsmkgsa4Se7VoJTdr+30TMl5s83z1an5Gma5Y+wWbdiFSoGpFlpYkp44l6HZT17lLCY5IfpQndeMdj7cgwembhIs2854HF3//jCd+EE02c0xDbkcGccWhipzmxDd0BkLkrd9rh6PHwdlFT3EmASbewSA3YKS7z3aDxA5nsjh1S8ST02cLBbtl9kLN0Hw9+Db+er6WlYwREZfGqHCZkzpS09vEJlVPWjRzz9LYAaBI+1NveckA9vlhlz4VDK+/NZjSEBHnEYOFpmWowZknlXqadiaQeP9sDBBkprhZHsijx1bWbsdSk3GKaEfrCIUpUJszupL7P9XZ5gyXH0vnJXFiSuc9fwtI4mvpmRqDuLUmFTQDV5cLKyXW5OyVe9s12/mVnRh9j5TzglIGmpnGZfhvY5bpbt+s9+zXvobh0ErtrDoI2f+gnceR5gplSSmlUZw76PKe/hKxHMfeghx47YT9U7D6/DDAKWdgDanWW4ZdMMnHBu+hHqIXbzkqafHu+6/d1jZdmsFSC41R2NwFLlWdHxP61U4uSWQXwj9IZ18WtZ9zBkKCvIbtX+CVBsOW60A95wA9I92plJ618ehEcVD8m9/L7d8h4rDdw/wP9G/m+oUQThO+qcwoQ6HSphvFebsj1mH/QJjsJYrH4xBg2eMJLQzR737sr/Hf8q4o6WSNZ9Bkk8luuWgJAD8+pF4xnFSGPO7orRyrsG8DYGGOFVn9jl3YOkq3hKICzZasNcAgwglj6w43PlTjOfV5P3FmmXzTu27XQw3Yb0vsSOJ5KwgzhOcYvjMK4jkKSLRD/7MxzsJdHT+zaIuafl0JVDokVTb/PeVK83qj4TZ7ekQRHe3XiM2LcsGCQrxxKoZR 4nMVXsv5 mmf+7ePRY6r+4mcLdVGg/cmu742hWB7Jss7OZ/r2Q/OGoplCOdzD7dQHCQ/BZZQVcziNTavVe/UOdtEpsluAwVnJl5w/vSVoa7xT3OTSqUhT2g5jADLf1bw48N7rxr8ROf1B5eisEqKsPdQgSN4sfiFkfsGMjmU4VNzptFxQFE76/Q9WuYEMbPmOlmcX2ROkKpF53jLciM7emTOebFLRpm6wyPhQTc6TmCJUy45YaG3MvXADzkXe7Y72FQOihrvmCZZ+oO/Hc5/58Mkf+8LiP9Rb++H0bwZ2NfxS77wmiGuxx/ZE= 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: List-Subscribe: List-Unsubscribe: On Tue, Mar 26, 2024 at 03:32:08PM +0100, David Hildenbrand wrote: > folio_is_secretmem() currently relies on secretmem folios being LRU folios, > to save some cycles. > > However, folios might reside in a folio batch without the LRU flag set, or > temporarily have their LRU flag cleared. Consequently, the LRU flag is > unreliable for this purpose. > > In particular, this is the case when secretmem_fault() allocates a > fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might > be added to the per-cpu folio batch and won't get the LRU flag set until > the batch was drained using e.g., lru_add_drain(). > > Consequently, folio_is_secretmem() might not detect secretmem folios > and GUP-fast can succeed in grabbing a secretmem folio, crashing the > kernel when we would later try reading/writing to the folio, because > the folio has been unmapped from the directmap. > > Fix it by removing that unreliable check. > > Reported-by: xingwei lee > Reported-by: yue sun > Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2rmz0HQ@mail.gmail.com/ > Debugged-by: Miklos Szeredi > Tested-by: Miklos Szeredi > Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") > Cc: > Signed-off-by: David Hildenbrand Reviewed-by: Mike Rapoport (IBM) > --- > include/linux/secretmem.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h > index 35f3a4a8ceb1..acf7e1a3f3de 100644 > --- a/include/linux/secretmem.h > +++ b/include/linux/secretmem.h > @@ -13,10 +13,10 @@ static inline bool folio_is_secretmem(struct folio *folio) > /* > * Using folio_mapping() is quite slow because of the actual call > * instruction. > - * We know that secretmem pages are not compound and LRU so we can > + * We know that secretmem pages are not compound, so we can > * save a couple of cycles here. > */ > - if (folio_test_large(folio) || !folio_test_lru(folio)) > + if (folio_test_large(folio)) > return false; > > mapping = (struct address_space *) > -- > 2.43.2 > -- Sincerely yours, Mike.