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 C49C2C54E90 for ; Thu, 22 May 2025 11:35:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4840A6B0085; Thu, 22 May 2025 07:35:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 434AF6B0088; Thu, 22 May 2025 07:35:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 371856B0089; Thu, 22 May 2025 07:35:07 -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 184986B0085 for ; Thu, 22 May 2025 07:35:07 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4E7DF1611C8 for ; Thu, 22 May 2025 11:35:06 +0000 (UTC) X-FDA: 83470337412.06.2752A0B Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.7]) by imf03.hostedemail.com (Postfix) with ESMTP id 4EFD820007 for ; Thu, 22 May 2025 11:35:02 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=TP1WDE6e; spf=pass (imf03.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.7 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747913704; 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=+2YR3SBQV4q9Lx7C2ALD+oH2dckWuf9RbQ/n1pINFmI=; b=TNcHYA/1QWGUsEFT8mxTfjqvtA8YQ9XPHrEeF+BzFN8mV72dUA5Qm3WpNCAQPQEVtWERMA uafSmoYKdsn0Ir/GGTv94/Z3adMEZO0Z3wVHO1r64rXX/Kz9JoW7Wx+7rkcDcAp8dMOtAh 1DtL/inVBHc+yZSemdXVymOxSJ8DwLU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=TP1WDE6e; spf=pass (imf03.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.7 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747913704; a=rsa-sha256; cv=none; b=UyYHCJ3otA3Le6xqPcYYJ6kdyKMOcIxNOzAv6ciryIYyBgJldCPL9Bmx8+05YYaqN7IISr LpjeOOYauDUpKTNOw0OGdfcFJPVLnk3MIQNoQcbYIRTUO/H8TB3RHb2vHHRacXACpbHfhu in9d4lmjqZtp14plKE1gW734IO52Fm8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From: Content-Type; bh=+2YR3SBQV4q9Lx7C2ALD+oH2dckWuf9RbQ/n1pINFmI=; b=TP1WDE6e5efu4PqMX/PdpVITZahk/W7M6eIoxd2qOJybqRliUO7zGy77BHQR9k uCXjhdX7wWnS/HJVhDPkuC7JGrq/iAYyrk5X7gOt+6q4cKB0/3hjTV8H4PDYr953 ngZNEsMf7WplyzT+zZmwEs2txoK8QOtyg2um5GjdkGHl8= Received: from [172.19.20.199] (unknown []) by gzsmtp2 (Coremail) with SMTP id PSkvCgD3R1vgCy9o0ZusAQ--.12490S2; Thu, 22 May 2025 19:34:57 +0800 (CST) Message-ID: Date: Thu, 22 May 2025 19:34:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios To: Oscar Salvador , Muchun Song Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, liuzixing@hygon.cn References: <1747884137-26685-1-git-send-email-yangge1116@126.com> <644FF836-9DC7-42B4-BACE-C433E637B885@linux.dev> From: Ge Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:PSkvCgD3R1vgCy9o0ZusAQ--.12490S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7uF15AFyruFWUZr4UZrW3trb_yoW8AF1kpF W7KrnxXF4DJas8ur4Iyw1kJr15ArWUXa45GFWxGr43ZF43XasrKr1jqws0qayfCrn3Ja1I vF4IgF4vgF1qkaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jbmiiUUUUU= X-Originating-IP: [112.64.138.194] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbiih9VG2gvBbqcNwAAsI X-Rspam-User: X-Rspamd-Queue-Id: 4EFD820007 X-Rspamd-Server: rspam09 X-Stat-Signature: e8g4fpteuatnobzpmkyu4yx69ewhjtpe X-HE-Tag: 1747913702-651686 X-HE-Meta: U2FsdGVkX185LBuTC/8sjAnAqPzj8X8vtwYg2LA6YQR5jSrMOiORaICCN8sxY/yMGzKwgZNkzyuhkpMeMRcQxGGtcNuck0vcgNvrmHUyFkXyIjBKOy7/DnN3mVprmWzjQ6ThzqWyqnrCuLa+RMgDZ0cktmiqnAusgiRRdqa0oZd+tlb/kn5i0FtOLQRgyicJMBZJGjjKqqHMCmg2eF5zUIbgJfhIz6WXmDAbXe+ovkIAezX5uD/x8sDnLm5sroz0oNRyVN70JXC2jW0RW6HuFHu0smLhuSdwuL2j5LZcs6dkBcLYJ+COsAkZwDdsao7Y5VUrOehC940aN7IwEbiKbT5SfOG9aDe9I4TyvVH0TBqTmKxzBGJZE5BYO+F1eAbP8i1Yu9pcVSTMZ8JMcmieTxJYDbhe8plaqh+S3Gy9g4eujm+G22PeyeTrmLM8KyTrJFjSOOMYZEbEqA6z3goXVIS1VbYAQ1A/SmK11Rn34Hpp2ktBRHnp4bFV6SBSNqPSeDkgk1zpS4rzgbVhPEkUjH9cgUSHOFZT0/pqsaiVwncXJQl4f1Igu4+dzv8/a+nJz/4BbbQachgC+WN4NuYA0qtsR8rjox3DxxIRhIVOPOTcmq0K9166gyVJkA55R4q/c8FTQMTdbcwKJz4FBIeWEb70JUyz532Sq70yk3y8xl2bhc2bxs3ZjW+II+7Ji6KWgMgQGuwwKc3rkIQDk6uKLfegieQ0W8+EUGRJkOUg1La+A341rX4OwkzBykWXntqbrWGu6KkZN08JzyrvHO6RqAHavojy27QFwSgkV40EFQGHDVOzq8hKDmrYRcAcit9zlAHYcECAIQ0SgpjsuXJXdug2TFotZwrm93+0n6LsMnb5cdGF1/sv8AFGCnkbvjrbKnM3dB9k0wXr0Aaa4E4Bk5mumdlENdD1dqyJw/qU1GmACBLD3tOifEkoMit2chncNMeEya2EbPubSR6H9rp fBAjOvjZ pSjPW9xr+7AlD4GBbf8weQHAlWHrzHBB8A+nxwO0V193NsC0Bs4lxioDsHBTVe79RnttBjt4L6h+Fvp9OpYYecPRIU6yIBLzDoNIjAH6nnJUYzNSlrV3o95KTUamu55bEXhRHNLSzflyMWyRLx/TkA8ylNPqMiMh/XWuzyfAYJ++RHZNs8mjnHUMCPC4etatYaT82A54a8M57aT6BNBQE43cDd1rMB6yPgRZlW8xA8Ipc1vnMjwcsg/O8XkfWyL4hXRnxDQPZ0Khw5/Q/3kAJD1KqIAi5fw+0M/VumZOTL1CzV8/ftJILFSROuINlNBGEGUWNZBlo3jbXMKah7ElS/MrDbBhfGD5QoNmILLHwJMohGnlrxYdujVuklg== 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: 在 2025/5/22 13:34, Oscar Salvador 写道: > On Thu, May 22, 2025 at 11:47:05AM +0800, Muchun Song wrote: >> Thanks for fixing this problem. BTW, in order to catch future similar problem, >> it is better to add WARN_ON into folio_hstate() to assert if hugetlb_lock >> is not held when folio's reference count is zero. For this fix, LGTM. > > Why cannot we put all the burden in alloc_and_dissolve_hugetlb_folio(), > which will again check things under the lock? > I mean, I would be ok to save cycles and check upfront in > replace_free_hugepage_folios(), but the latter has only one user which > is alloc_contig_range(), which is not really an expected-to-be optimized > function. > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index bd8971388236..b4d937732256 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2924,13 +2924,6 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn) > > while (start_pfn < end_pfn) { > folio = pfn_folio(start_pfn); > - if (folio_test_hugetlb(folio)) { > - h = folio_hstate(folio); > - } else { > - start_pfn++; > - continue; > - } > - > if (!folio_ref_count(folio)) { > ret = alloc_and_dissolve_hugetlb_folio(h, folio, > &isolate_list); > > > It seems that we cannot simply remove the folio_test_hugetlb() check. The reasons are as follows: 1）If we remove it, we will be unable to obtain the hstat corresponding to the folio, and consequently, we won't be able to call alloc_and_dissolve_hugetlb_folio(). 2）The alloc_and_dissolve_hugetlb_folio() function is also called within the isolate_or_dissolve_huge_folio() function. However, the folio_test_hugetlb() check within the isolate_or_dissolve_huge_folio() function cannot be removed.