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 D9812CDB47E for ; Fri, 13 Oct 2023 12:59:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3EC346B02C7; Fri, 13 Oct 2023 08:59:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 39BD26B02C8; Fri, 13 Oct 2023 08:59:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28B346B02C9; Fri, 13 Oct 2023 08:59:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 163986B02C7 for ; Fri, 13 Oct 2023 08:59:12 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DF0B812029F for ; Fri, 13 Oct 2023 12:59:11 +0000 (UTC) X-FDA: 81340443702.19.EB921BB Received: from out-203.mta0.migadu.com (out-203.mta0.migadu.com [91.218.175.203]) by imf26.hostedemail.com (Postfix) with ESMTP id CF69514001F for ; Fri, 13 Oct 2023 12:59:09 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=WoxhJtdd; spf=pass (imf26.hostedemail.com: domain of naoya.horiguchi@linux.dev designates 91.218.175.203 as permitted sender) smtp.mailfrom=naoya.horiguchi@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=1697201950; 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=9/wTbhHU5rbrI+BeEut+pKSzv8F9ZWvt0d/dEa4I7XI=; b=KyoWalWubZUMhpUshwaz7A+EkgKigvmFevWwDf0zrF6s0o6kMaRZ93rn4DbrPC2rLKwDfu PIARf5ZspG/T0T//jtoEieAQowgHpRgOVY/xjg6XJ0Wa300t8yiHzRtPTDI2pN+YywmlX8 FNLCGacZzpOOZyMc7POFm0tiHGgfkeM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697201950; a=rsa-sha256; cv=none; b=P7itlsuzgMtufUEmo2fQv88Hi5/hsD+TVzfyGAezbgKkaeKpXhTIOp25yT1OPjW2kwytWr JWYvTYxrUoO9YKMMHA8pOpMybJg92KgHqGXfcaSKdncIopISKT7u2p3SfK8YkHty4eeZam mU1mXZAZDSOEBDgranlevHlJWrjXSXk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=WoxhJtdd; spf=pass (imf26.hostedemail.com: domain of naoya.horiguchi@linux.dev designates 91.218.175.203 as permitted sender) smtp.mailfrom=naoya.horiguchi@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Fri, 13 Oct 2023 21:58:56 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1697201947; 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: in-reply-to:in-reply-to:references:references; bh=9/wTbhHU5rbrI+BeEut+pKSzv8F9ZWvt0d/dEa4I7XI=; b=WoxhJtddxX73sqPzb0Zn/12n8Qcqhnh/ZjGuuwy193Kt2MdYfPUvQmJDU8Z7sR6XtWqK0P NJ9mvs8lRCcNMCXT59gAD2k3Spx23QlowL41fp5dADWzY8kmxXDyrySilBuSlagtik8/wA RxUUXD2/RVQ3NNwOkl/qAbNpycce5Rg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Naoya Horiguchi To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Muchun Song , Joao Martins , Oscar Salvador , David Hildenbrand , Miaohe Lin , David Rientjes , Anshuman Khandual , Barry Song , Michal Hocko , Matthew Wilcox , Xiongchun Duan , Andrew Morton Subject: Re: [PATCH v2 01/11] hugetlb: set hugetlb page flag before optimizing vmemmap Message-ID: <20231013125856.GA636971@u2004> References: <20230905214412.89152-1-mike.kravetz@oracle.com> <20230905214412.89152-2-mike.kravetz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230905214412.89152-2-mike.kravetz@oracle.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: CF69514001F X-Rspam-User: X-Stat-Signature: 87kcnmk16ta9sp7zrmcpyr7bbkoe379c X-Rspamd-Server: rspam03 X-HE-Tag: 1697201949-244564 X-HE-Meta: U2FsdGVkX19tgdd/iS7Bv0aWaom+w6hWrnlotHCr82PlINgkA2q8ImJv+uJNhkM9KHs6b9f9t9adyklBeJU4mubehmF/x6a4hEVwAoYkdhUyhmUvybi91CrdKT3F/qFAhTadE+Mq4ElX42Ogj8FWNEDeI4qwBrusKY0ksHKkd7M6Myl0njHUGb+arr5W0I8DtCOEUTVyEUqE7GFXIO8agIRd8bukycXyjIKLJPAUThgTap1VV61YaA/QuMP2yfybURS7DxoaPQrX4mHPpItaTw0zK1YNdv/8x2uowjXKL1uvw4MyfQ05HOhOu1G7IKNHdSqXPZUUdmC/HX7emKH0ZhnKc5pSrCEbXHKqDBOpHGVbd7osaXrVhoPfMU92a/Bn6LS8be1pSCGhXmvHnlooHStN1Sxo3ay8YtRTqsioY5YTb4wb4oAe6vvimYfZUSBFQPbi5Wz/uy7voprnbL5aheGwNwHKgix1rWVPO9x06hJIDprDTlM9sEGscM9M/AZPQDxkWdntu7Vn0IuH079m7hNUJ6BcJm1Sd7r57NGWuHt9DyKP8JZj+q9w6WEXZ+NSJ8Ja5mLZAf3nEVPGx6isJkeSRWVOlOv1X8uotSEIQ+BslHfOPTHdp7XDnjwInh9ErqQZyv4jzx+E76MbRWlIxxBqXTzENr22xn/5By6WgxGB7eBYJiu5C/r3UP30vhVEUvr/1JSJVPTr6QYB21OnrTbKi3rGZOdYpY4JVRYPI6f8hKwg6IpxeEeOy1NlqW2sQwwwUiUCTyPCJlzwF5vRo6lZM6g2o/xPvjOlrv7fEYy5ieC7AijA5/79USfZkUcGjcIpS3ebZPfWx3xnYtGBVzpzr47LR9I5nOJHgXIEpDaHa6HXY4qB99zQESemdwWkjUW4NNzo71IV7AwIcXWWrsPCUzcQkVUPS7qy13WEcNHxjpDVaeOSQzUyTTdNWFm+TRuiPthAr6R8SK61g+p ChNGQGRx ftm5GcY8emLQFJpEGhee37+Wv4s6xQQbg/n+Mc/AdXoESFjcPZ1viAQ5l/Q1lY0wFLXRc9E3E+woUqIsT1DIrMBnM+up5TQEiy+KJUHy1v0qrbXSkA4VfqQHdkQ== 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 Tue, Sep 05, 2023 at 02:44:00PM -0700, Mike Kravetz wrote: > Currently, vmemmap optimization of hugetlb pages is performed before the > hugetlb flag (previously hugetlb destructor) is set identifying it as a > hugetlb folio. This means there is a window of time where an ordinary > folio does not have all associated vmemmap present. The core mm only > expects vmemmap to be potentially optimized for hugetlb and device dax. > This can cause problems in code such as memory error handling that may > want to write to tail struct pages. > > There is only one call to perform hugetlb vmemmap optimization today. > To fix this issue, simply set the hugetlb flag before that call. > > There was a similar issue in the free hugetlb path that was previously > addressed. The two routines that optimize or restore hugetlb vmemmap > should only be passed hugetlb folios/pages. To catch any callers not > following this rule, add VM_WARN_ON calls to the routines. In the > hugetlb free code paths, some calls could be made to restore vmemmap > after clearing the hugetlb flag. This was 'safe' as in these cases > vmemmap was already present and the call was a NOOP. However, for > consistency these calls where eliminated so that we can add the > VM_WARN_ON checks. > > Fixes: f41f2ed43ca5 ("mm: hugetlb: free the vmemmap pages associated with each HugeTLB page") > Signed-off-by: Mike Kravetz I saw that VM_WARN_ON_ONCE() in hugetlb_vmemmap_restore is triggered when memory_failure() is called on a free hugetlb page with vmemmap optimization disabled (the warning is not triggered if vmemmap optimization is enabled). I think that we need check folio_test_hugetlb() before dissolve_free_huge_page() calls hugetlb_vmemmap_restore_folio(). Could you consider adding some diff like below? diff --git a/mm/hugetlb.c b/mm/hugetlb.c --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2312,15 +2312,16 @@ int dissolve_free_huge_page(struct page *page) * Attempt to allocate vmemmmap here so that we can take * appropriate action on failure. */ - rc = hugetlb_vmemmap_restore_folio(h, folio); - if (!rc) { - update_and_free_hugetlb_folio(h, folio, false); - } else { - spin_lock_irq(&hugetlb_lock); - add_hugetlb_folio(h, folio, false); - h->max_huge_pages++; - spin_unlock_irq(&hugetlb_lock); + if (folio_test_hugetlb(folio)) { + rc = hugetlb_vmemmap_restore_folio(h, folio); + if (rc) { + spin_lock_irq(&hugetlb_lock); + add_hugetlb_folio(h, folio, false); + h->max_huge_pages++; + goto out; + } } + update_and_free_hugetlb_folio(h, folio, false); return rc; } Thanks, Naoya Horiguchi