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 7E20CD10C11 for ; Mon, 28 Oct 2024 12:52:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 036E16B007B; Mon, 28 Oct 2024 08:52:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F291E6B0083; Mon, 28 Oct 2024 08:52:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF1556B0088; Mon, 28 Oct 2024 08:52:38 -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 BD6576B007B for ; Mon, 28 Oct 2024 08:52:38 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2FA98120AB0 for ; Mon, 28 Oct 2024 12:52:38 +0000 (UTC) X-FDA: 82722998736.09.73D15D8 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf20.hostedemail.com (Postfix) with ESMTP id DFE151C0006 for ; Mon, 28 Oct 2024 12:52:05 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730119902; 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; bh=hxqJ9h+umbzxLcDhIMNT7Pm677swoD4kTsMd73G81+4=; b=wTnWzd/zSL4pnPe/DVE05MdlXCISagWJyk/nikUDXfNaNYJ/7qjeGgIOqyVO04QFAU2xvk an8fL/9LsH0q6rdFAP3pACU+nHDXxVblB2S90e2ioUuqUx9wX83oiMo0rTR88UUegzHTpn KvmtHtivk8zEYisfzyMJhxonILvSrnA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730119902; a=rsa-sha256; cv=none; b=t1cA9Eet96JC1+XHtViiVyoPCmsVfdWdL1UBZlxgeVKPoNccSh9s+zwErwWF2cMeIPDWuv 6dlDLPyKne6YugEBpv+0s0VUXmA8s9QkxrUDFp7MuKXMS6w4EIXdCDcgHIU3+iU7TDeqnU K2yIRQqENACx9Yxo26B1DfzBaY2T5XQ= Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4XcYDL3fFCz20r2X; Mon, 28 Oct 2024 20:51:30 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id C2BCE18002B; Mon, 28 Oct 2024 20:52:27 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 28 Oct 2024 20:52:27 +0800 Message-ID: <54f5f3ee-8442-4c49-ab4e-c46e8db73576@huawei.com> Date: Mon, 28 Oct 2024 20:52:26 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] mm: use aligned address in clear_gigantic_page() To: David Hildenbrand , Andrew Morton CC: Matthew Wilcox , Muchun Song , "Huang, Ying" , References: <20241026054307.3896926-1-wangkefeng.wang@huawei.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspam-User: X-Stat-Signature: t6xf48k8j1zjp34bbhjzsjm4j19ey8de X-Rspamd-Queue-Id: DFE151C0006 X-Rspamd-Server: rspam11 X-HE-Tag: 1730119925-794789 X-HE-Meta: U2FsdGVkX1+Q1t6YNfXR4wrU+KJ1d8TQ96SgjtIWhuTzrXiY7OBaaFuVS1NIfY14YrHQZ5ylTHN9nK9Lez2YmkSl+k+YcGqJ0IQGVmsPabhxyEHBEe+rkHVc3FXt2fN/4BX9WaXt+7u656slJoynuGjMSmXNQ6O1SZNblMGh8onJB8BgaKvJHzvN+pYofIIr+mb88Pd1j6RdWl08r5ZpCbhH98SdZPd5fF2RWPygowyzUGfGeNFE0Br8gMRY/6vc7iYL3Sqvuixz4WHL+vUSHLxeMmYAir3BLbjzgLO6S6JS8oqjxP0Q0UK2k67LFs4lbyP+Q6B878lKJleaJo5zvNYuRqNPP1rxlVjrLvb4+hiJPekyya4M0wL+MOXasQGI/+OGgfZQ/10q4NPeintmbkjhSd8E6fHhjXVz7QeqAXx80fkLztp7zPoH5NKnMKfW/AZmIV3qm95FC6XcbxnnsCk67pSsD3Sl+13HUpPSpOjgxwPyuO5k/xqAVYTxL2M2PmkCeu2TypTnK+tZYCs8zhfP8iP/6jvp9nyG/C0LvDAqdcWVZncon2yzVbsMYUGXRQuXgcOHSPEb7BFmaFY8eKq6rlAIGRPRp7yODfdriG8XtXq/0E6+XylJrBAUeodwiQ2RCOljwk64jOP2Qb6qLK9q9GUVWjYB3Z02HIZK8vOf7QTaQutn7HXb2MOQZ5t5Qr2rUVtbLaQsZlKu+7CFswQKssyNhZBK8jipttjvGRDahV82P7zubAVFNwzjcVwSAYYkVwzA3Czk/W6mbN4d6zAL3XRjU6ciFN1NOi0bJlYKuzLh7SvY1frJ7Ffi+Cjrqln3wdtqfg70hkV/1vKuk9KAYC1NFGsYn5eJNfoxI3X9QEVKn6ZpmizT95eBqNV9rw65clbAM/lBfNzAiaqwEWAX+rogjiZq/H+rxpRRoxEihsOROalWpz/4GrnXjPJ3DCEN9R5Z1WmO6OXWieS UqI3UveG xMqbofVW2/9uh0ZVN3ui14+cYU3zn/PydDjMpDJerfx3Mi6QZsf88moWDuqIXBmcD7wd3gknY9gXXf/+uEAUzrzCKkXS5w+2HVo9lMtY27iIy2rTI3zheJwpBAuZ1NUwKz+wBMiK+aqiPMqhV6iJgPaP14e21ymZihYcp5kQT3FqcyVSbZBVbckQnFwCg0TCTp/m0dDgDfpzmTddndyoENAfP9nb3KeUPuvXRnJKszfORHXlqN2Ubh7t6oOT/ExR86RazKJYWNeICzi0= 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 2024/10/28 18:00, David Hildenbrand wrote: > On 26.10.24 07:43, Kefeng Wang wrote: >> When clearing gigantic page, it zeros page from the first page to the >> last page, if directly passing addr_hint which maybe not the address >> of the first page of folio, then some archs could flush the wrong cache >> if it does use the addr_hint as a hint. For non-gigantic page, it >> calculates the base address inside, even passed the wrong addr_hint, it >> only has performance impact as the process_huge_page() wants to process >> target page last to keep its cache lines hot), no functional impact. >> >> Let's pass the real accessed address to folio_zero_user() and use the >> aligned address in clear_gigantic_page() to fix it. >> >> Fixes: 78fefd04c123 ("mm: memory: convert clear_huge_page() to >> folio_zero_user()") >> Signed-off-by: Kefeng Wang >> --- >> v2: >> - update changelog to clarify the impact, per Andrew >> >>   fs/hugetlbfs/inode.c | 2 +- >>   mm/memory.c          | 1 + >>   2 files changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c >> index a4441fb77f7c..a5ea006f403e 100644 >> --- a/fs/hugetlbfs/inode.c >> +++ b/fs/hugetlbfs/inode.c >> @@ -825,7 +825,7 @@ static long hugetlbfs_fallocate(struct file *file, >> int mode, loff_t offset, >>               error = PTR_ERR(folio); >>               goto out; >>           } >> -        folio_zero_user(folio, ALIGN_DOWN(addr, hpage_size)); >> +        folio_zero_user(folio, addr); >>           __folio_mark_uptodate(folio); >>           error = hugetlb_add_to_page_cache(folio, mapping, index); >>           if (unlikely(error)) { >> diff --git a/mm/memory.c b/mm/memory.c >> index 75c2dfd04f72..ef47b7ea5ddd 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -6821,6 +6821,7 @@ static void clear_gigantic_page(struct folio >> *folio, unsigned long addr, >>       int i; >>       might_sleep(); >> +    addr = ALIGN_DOWN(addr, folio_size(folio)); > > Right, that's what's effectively done in a very bad way in > process_huge_page() > > unsigned long addr = addr_hint & >              ~(((unsigned long)nr_pages << PAGE_SHIFT) - 1); > > > That should all be cleaned up ... process_huge_page() likely shouldn't Yes, let's fix the bug firstly, > be even consuming "nr_pages". No sure about this part, it uses nr_pages as the end and calculate the 'base'. > > > In clear_gigantic_page(), can you please rename the "unsigned long addr" > parameter to unsigned long "addr_hint" and use an additional "unsigned > long addr" ? > Sure.