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 E35C3C54E90 for ; Thu, 22 May 2025 12:40:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E3396B0082; Thu, 22 May 2025 08:40:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7936A6B0083; Thu, 22 May 2025 08:40:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A9896B0085; Thu, 22 May 2025 08:40:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 519A06B0082 for ; Thu, 22 May 2025 08:40:23 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EAABD12141E for ; Thu, 22 May 2025 12:40:22 +0000 (UTC) X-FDA: 83470501884.20.AF4294F Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) by imf23.hostedemail.com (Postfix) with ESMTP id 2EA9214000D for ; Thu, 22 May 2025 12:40:18 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=q1kXA6V4; spf=pass (imf23.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.189 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=1747917621; 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=o/jJvwOkURxtxoRnJBvK627eN5WNgntlDWEx9DwDX9c=; b=BdbjULKIafGFHuSD2V2MMEuYlWMN4vgjYMOlJLeZ/8nqUOh2Wcb/w6+UHxyTmKAVFTipzz YS3SP/2eITGW4UGITz++mm+4HwgwRRzze3YCdJHimJ26drEEVka3uv3yHTvDy1cBPcbH25 mDDjtSzzFErTOFs4hnUyCKpLEk10I1I= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=q1kXA6V4; spf=pass (imf23.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747917621; a=rsa-sha256; cv=none; b=s3rhGWGyM1QMpuV8V1zC73UcQ6wQNu8Kr2BUhO6mHGCMqQ1OUbi21McqEDR5bNFi7hn3Qr +dREvTH/5Ip8ZdXKaFocSes8+WjIaF1ngcduRiioC78phKbRmAjZg0IYSNWWg1QkA2tk8F q+xDCmlzPfzEpiBsohhp5BvQuX5X62k= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747917615; 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=o/jJvwOkURxtxoRnJBvK627eN5WNgntlDWEx9DwDX9c=; b=q1kXA6V4zfGfrNy51OHqH8rO7FuEZmHb/i59g2jWLmszj+qNGOE9AN2vqsptKOXl5iHjaU fnvY86wo+qJ/P/NcfiS2H2yfXi36ba+5ZxJYamSbRxJ2FH31ymZTUnb1jiAeQalUXgczhM 7OWlVUU/AI78YSia2VIR8bVvUdZPKwg= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: [PATCH] mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Thu, 22 May 2025 20:39:39 +0800 Cc: Ge Yang , 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 Content-Transfer-Encoding: quoted-printable Message-Id: <3B8641A1-5345-44A5-B610-9BCBC980493D@linux.dev> References: <1747884137-26685-1-git-send-email-yangge1116@126.com> <644FF836-9DC7-42B4-BACE-C433E637B885@linux.dev> To: Oscar Salvador X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 2EA9214000D X-Stat-Signature: oo57spp9jia31rhmbc3c18j5etoyurp1 X-Rspam-User: X-HE-Tag: 1747917618-816656 X-HE-Meta: U2FsdGVkX1//QAPXQ9vgrykPtIA8OblAV7iFdZhcyDFx5tQ752auhwJ9UzQ11vBM7anl16LCtu+ey8DghtHWU+nYOQi6BLPt2c8+JARogPYaYwMmBgsHLNqEiYF3BnjsEfF0LYP3lDeMzxGMUwXH47f6MKz90FjAcNtcofwP2ABoHGsWBvDAbVgOYstIhtAeIhpjw6sW9LxSvOk8KliuOx7SCyYQbso2MjtDUmSrAyCw0kqPN6fBqQJJ70esiZGEfe33mGNak4Md6pQrgpyaS8nsXTs+CA+Mtlssg47rb34g8ayOKN10an761Dl8jp6EbNvfnYJq9ynUKd0SHmq07dhBo921t5EY/ix1eCTxXii6fx9ELc4dM+zAS5O+KNyeEP6LWJkZYMXwlZZotVOcboMZB5Bo4rLJ59YEbwhN9BsoZCuv5Uwjrj4Sup8AbqXT4DBTUAd1dmrb/MhIW0Y9+d21KYfoSuii+WZj6UGAhZVxuFO3WW1yTKVDAxdN3h/kg0kxG+MW+OzKff+6k+JOI8IbFtQSDDBd1kq3CpZtMjREqXpRxGVxEnLbLr15OsP2/2K5oHVp8Yd/3VogE5pI5znjqY3URgcUINCh0peyzkr49+Nc0UgouDov0yyLYQTv2oCi4Dw5ZiwtnoXsTcj+rkMtH4b+1VXV7cdd/63wb13oVuZcH3kgRsx8Wk5DOcIqSF63YguYB3WaCyU6+MJ19k1cX7rfFh/Yg+qAh+xsS9GJQjEYJsNt8KIg9Up2C8WzcEmgK5AsxVs2489DF+gZ1Zoqu6SLYHo9gDgOLB5GlCKv/BX9ypqkCtnzzWTA/R+jXVpB7e6dH63b6ivAYQ6IJb9caf+mqoGKwZ9FuSG4przuL2ZIUl0bGmsZ7TaCrg68VCM37pnCw2ptGdsJI8Dt2YFNVrdwhCrzfEmovo9rk/rBsnM3jURHDtCjjPLPypjQIWGB1BZklHmDCR8/1vH 5TBoR83q g4yXnnkfghoiCdaiFowbR6e2xBAD6h/teByADT0o1k5HUrIztTNfIL5BKa35MiP9A52pY9bVOg8iV/9Kf2g7HW7wGizN3TGF1UHOP3ygTzOrWGWwR/Dn+Ba3DwpM1M8gctzdhsvRA7YfKOadzdIVJXDWshN4TvgGsFHZexcVPDoWe2ybZfrvsGX5qwJmRALVqhq0Elf0AqMTZ8kp8SnyM0JzI4f16QIDKw8BA9GxjqBtSuVs6GjX/JHFc3Q== 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 May 22, 2025, at 19:49, Oscar Salvador wrote: >=20 > On Thu, May 22, 2025 at 07:34:56PM +0800, Ge Yang wrote: >> It seems that we cannot simply remove the folio_test_hugetlb() check. = The >> reasons are as follows: >=20 > Yeah, my thought was whether we could move the folio_hstate within > alloc_and_dissolve_hugetlb_folio(), since the latter really needs to = take the > lock. > But isolate_or_dissolve_huge_page() also needs the 'hstate' not only = to > pass it onto alloc_and_dissolve_hugetlb_folio() but to check whether > hstate is gigantic. But I think we could use "folio_order() > MAX_PAGE_ORDER" to replace the = check of hstate_is_gigantic(), right? Then ee could remove the first parameter = of hstate from alloc_and_dissolve_hugetlb_folio() and obtain hstate in it. >=20 > Umh, kinda hate sparkling the locks all around. >=20 >=20 > --=20 > Oscar Salvador > SUSE Labs