From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-190.mta1.migadu.com [95.215.58.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 732B243F8BF for ; Fri, 21 Aug 2026 09:30:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.190 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787304642; cv=none; b=YIcBv+YhYGhir3viDkKtaDvL4CELqH2kNvDVCdg1MWT1Mlcoajp02posxkWXXJulJTmgpwOR+eq37y7UMwbVe8B+fJV/jsrnDpbIG3nM8WYwwWSe2DDWZuq1Qbh9kY2vTDakp2nanDv96m2oXQ94NqQ6A8gJn8dZiyVUOhOXFSw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787304642; c=relaxed/simple; bh=MSK040sBBU8kGgBeKv9UupoXrEl2KRZD2AS7NSHKRMg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=h0mfuJIHffq9V0s3k6X99foWI7irOJETWhvU/JkcLDWe1uyoZPjERZz5wxJ3DSdD5P+q+C/atThdcSeXi+cBbZExqeTNbshKUoXT+qDPApDuIbuLkWGtoZ7xZOBJmDPv3LbqVcNdD26AP21uKPyLPaTlHOz3moK+7O9AOczrsG4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=E0GKCBAq; arc=none smtp.client-ip=95.215.58.190 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="E0GKCBAq" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=MSK040sBBU8kGgBeKv9UupoXrEl2KRZD2AS7NSHKRMg=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787304630; v=1; x=1787909430; b=E0GKCBAqiwbGtxef3NvQTA6webU0djEJEbmRMW3kJepwZO0K2vpnKYCpWnBCsVoC91lzIKKk luGJQ6qeneRzs7TI4DcD79zi2XAZOVm5rKgHYyWPNR11oM2w36F0kdCCeAUkxga4Q9JSRF7cUhq 6RHhASl/dwLrkPTwpbozZxS8= X-Envelope-To: linux-kernel@vger.kernel.org Received: from smtpclient.apple (114.251.196.85) by mta11.migadu.com with ESMTPS id de9d4864cbfbb597; Fri, 21 Aug 2026 09:30:20 +0000 X-Mizu-Trace-ID: de9d4864cbfbb597 X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset=us-ascii Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH 1/1] mm/hugetlb: do not dissolve gigantic pages without runtime support From: Muchun Song In-Reply-To: Date: Fri, 21 Aug 2026 17:30:00 +0800 Cc: Longlong Xia , osalvador@suse.de, akpm@linux-foundation.org, mike.kravetz@oracle.com, mhocko@suse.com, linmiaohe@huawei.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Longlong Xia Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260817162039.1511838-1-xialonglong2025@163.com> <206cb1f2-b66c-4b7b-b0ad-14cca9d8e0bd@kernel.org> To: "David Hildenbrand (Arm)" X-Mailer: Apple Mail (2.3864.600.51.1.1) > On Aug 21, 2026, at 01:33, David Hildenbrand (Arm) = wrote: >=20 > On 8/20/26 11:38, Muchun Song wrote: >>=20 >>=20 >>> On Aug 19, 2026, at 16:52, David Hildenbrand (Arm) = wrote: >>>=20 >>> On 8/17/26 18:20, Longlong Xia wrote: >>>> From: Longlong Xia >>>>=20 >>>> dissolve_free_hugetlb_folio() doesn't check = hstate_is_gigantic_no_runtime(h) >>>> though remove_hugetlb_folio()/update_and_free_hugetlb_folio() = silently >>>> bail for such folios >>>=20 >>> That's odd. Why do they silently skip such folios instead of warning = that >>> something unexpected is happening? >>>=20 >>> This screams for a cleanup unless I am missing something :) >>=20 >> Hi David, >>=20 >> Sashiko actually has a pretty detailed description [1]. So I think it = deserves a fix. >=20 > That's not what I meant. I agree that its a valid fix, but I think the = code > should possibly be reworked to not get silent rejection from these > functions--IOW, likely the callers should make sure to never call them = in this > scenario, and then VM_WARN_ON() instead of handling it silently. OK. Make sense. Muchun, Thanks. >=20 >=20 > --=20 > Cheers, >=20 > David