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 18E20CD128A for ; Sun, 7 Apr 2024 07:15:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A3FD6B0083; Sun, 7 Apr 2024 03:15:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 553DF6B0085; Sun, 7 Apr 2024 03:15:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 442206B0087; Sun, 7 Apr 2024 03:15:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 26FE06B0083 for ; Sun, 7 Apr 2024 03:15:20 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CE2D01208DF for ; Sun, 7 Apr 2024 07:15:19 +0000 (UTC) X-FDA: 81981874758.27.420C42F Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) by imf13.hostedemail.com (Postfix) with ESMTP id 040F320015 for ; Sun, 7 Apr 2024 07:15:17 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=epnnCVW8; spf=pass (imf13.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.178 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712474118; 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=izG0H7d0XKCwBq0rwb80s1K6r+EFzHAQWeJRLY377NM=; b=NX17GvLhMRIweSVtZADeiOsRXunTdgc2+jwv4xD8zNaaylZBhL4Ldb1w/kzLwz4phZOePj YZANdjCBLAoOaWiLLo3IUo1VSEi+U620QEHx9VGu9DXMt9+txrntP6aJXhil/RGXC0Zfvv H5iDdGxyoOs6RYizEDSgxhPhzwEw9js= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712474118; a=rsa-sha256; cv=none; b=d1eZx0zBoT75KyM9hLuVHot8U67rpO6lZv/csEz/2kipuOJLu9ByCnH2b/Ip/dxC0bBSh4 cwdFHTeEPdhYjHwUvrzl5IO2ndyXsypRDwdXuKZMd9TGEcvYvk3VudwvcBtL3ptw01jAa2 TCuabbEw8HADUdtCHt0/EnVXOhagzwM= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=epnnCVW8; spf=pass (imf13.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.178 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1712474115; h=from:from: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; bh=izG0H7d0XKCwBq0rwb80s1K6r+EFzHAQWeJRLY377NM=; b=epnnCVW8YEOXahW2gj8Pz3tiWwPXSkD+H8LLFOh5Gb/wDuMZC37dsPG67BeXj8BS9HidGX p7LowTcLJZWOZSNbSaOfNmFK8yyBc2oMynwqxBOYZLICgbeeUHtioVKWHekd/aVmYL3gUC d7hKVJiqp1Vzr+bYwWCZ2eUEXCfPmng= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: [PATCH] hugetlb: Convert alloc_buddy_hugetlb_folio to use a folio X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Sun, 7 Apr 2024 15:14:37 +0800 Cc: Matthew Wilcox , Andrew Morton , linux-mm@kvack.org Content-Transfer-Encoding: 7bit Message-Id: References: <20240402200656.913841-1-willy@infradead.org> To: Oscar Salvador X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 040F320015 X-Rspam-User: X-Stat-Signature: hcgu93edaenhbdttnz7m4iopaq6zoara X-Rspamd-Server: rspam03 X-HE-Tag: 1712474117-637405 X-HE-Meta: U2FsdGVkX18sZSC0fYrgacLcuyvmN7Bva6k/iLneHymvKQiK5rCz9Z4L75SxiVznROsqFJ91aH7LkPaJ9SXpbZ+frnzUM2pogUgrTnN2DpbUz726RM9PU6AbSXk1v1RGQpHqxYBAa/r2O8QcLv1+hvICZ/H7BOW/h4XlBVse5YUowQeym0+ZdBevghBSYNGIBDOYRoouAbrAGQtf4zlrJLz849U5E5gBdZYeGuMyZhbOHeCg2FL6fz4W6OAXHgl+8pWE3YvkCurCJJHMh7iGIkETIlU3EyTUosn5dTppVqVvcwraT1UfQAfZNVohmh40GceZRLx5WqDsVQAteHssIF0C3F3VYt5RPg/LXz5UUrEHRhbzmCcp4j2OsXX9JnwDppiqHE+EXKixGS4tM5ctMdbr112n22yINWscuc1fgDfl9G4Np5gKww98mf+FKvUh+1YT4i4iNnxCjyxV+NVmWJF9z1ImQIzpfeKJQZKZDe4CvhfvdZmcf/8ZEUpTI1fWF268Gck95dK8A+u6+q+DzZcBwTRJ6IzeLvvSaHOg39bR4BNUefxEwENlMB1ZWLn4huDu8GI4fJB/8wA2t0BONUdXSdSirZ0Or07fO//6kJU65k2ZlU6uPmzuzlWjrEWvAjCARbaXgoBZCQnNxDZIS7fwtxMUriPH2gRpJH8jF042vHVLixg8bPT83axcYAyiWNJReed1jLcDWM2KL8mIpeaGbgjq8bius2+eW/r8Wpp450pyLqN6vQbb5DHuFRPojCKxs9qYTV/WCVK1huyaHN/JQBsOCVqqeq8GvQsoSzoME6AM9ZMsKSwh8JGSje4lNSGq8r/86lmCuhJfilCzSJz1FRg+/lqGYlrsC343A8uljqEfnrkFoQ== 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 Apr 4, 2024, at 19:13, Oscar Salvador wrote: > > On Wed, Apr 03, 2024 at 10:17:45PM +0100, Matthew Wilcox wrote: >> I think hugetlb is being unnecessarily paranoid here, tbh. Or maybe >> this part is just badly structured; if we're allocating a hugetlb folio, >> it should be fine for its refcount to be temporarily elevated by someone >> else. Not sure I can figure out what's going on in >> alloc_and_dissolve_hugetlb_folio() though. > > AFAICR, the problem comes when we need to remap the pages for vmemmap > optimization [1]. > So, IIUC: > > 1) if someone comes around and grabs a refcount (say something doing > speculative stuff) > 2) we do the remapping > 3) that someone who took the refcount, now does a put_page() > 4) vmemmap no longer points to the old page but the new one, meaning > that that 'put_page()' is done on the wrong page. > > @Munchun: Did I get this right? Right. But let me clarify this again. We need to keep the content of the physical page constant throughout the processing of HVO (i.g. between the copying of head vmemmap page and remapping of it). Zero-referenced page could prevent others from updating the content of the page structs. > > [1] https://lore.kernel.org/linux-mm/YupRjWRiz4lPo+y7@FVFYT0MHHV2J/ Yes, I've also pointed it out here. Thanks. > > > -- > Oscar Salvador > SUSE Labs