From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6885039A812 for ; Thu, 19 Mar 2026 07:00:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773903628; cv=none; b=jlYiFF3lY5hyO4V8OErjHisZ+8wtvPi0IhuE3xVo8pMT8bpazK5kt8YW6A28m0nhRXHKevYQwt6U+YHAEw99dBwyDMrYZPTpKvalUs7xnlBgl5WEA4dMsB8FY/lEfL6nN1qn/oQvFS6URtsi2TUHbZyPKQ92dGZFvgi8PBMt7pA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773903628; c=relaxed/simple; bh=NF2egJeivfYfznBkhWOk4tdQ3UKNJRZm9PQLsBsElTg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FuJz/eigQLNzHYH7yeEQeSw17aO3DbF2qjnlkRdbf5vQz6RM4mLqWJTxD3pvjcrdgKyYcqEPSHA2HbVXLUKzzc5iqtAZd4V+K4Hr/U7H5Kb0EnncMYdtJUa28GG+8bdD9fbIJKJSi+urCvzUv+0Hsn2JwU4fJDW5JXlK6TF/z68= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=MWv1JOHy; arc=none smtp.client-ip=115.124.30.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="MWv1JOHy" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1773903621; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=/Tf/vnCCMR7csoiq+BQVcLU+w/pmlReZtybYZJ5pONw=; b=MWv1JOHykstAwSjNKpMk7xi8s9J/eKltQb+8fvBrcKP6/1GMOz4FD7cuUrVZtFVAxuYreD8bT8frU5cI0Qks2HEr60doelpQ61nk7KOE0lJdN2nDOzrdC35TSedtYGlD/SjyTW0TXYcqwp+GNVTxaOBHVDM3VY0RFtb0GAsBrow= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_---0X.HWASq_1773903618; Received: from 30.74.144.123(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X.HWASq_1773903618 cluster:ay36) by smtp.aliyun-inc.com; Thu, 19 Mar 2026 15:00:18 +0800 Message-ID: Date: Thu, 19 Mar 2026 15:00:17 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/8] mm/huge_memory: handle buggy PMD entry in zap_huge_pmd() To: "Lorenzo Stoakes (Oracle)" , Andrew Morton Cc: David Hildenbrand , Zi Yan , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <8ffa393ad86b9b0ecd9b001ca88706ce2f9fe003.1773865827.git.ljs@kernel.org> From: Baolin Wang In-Reply-To: <8ffa393ad86b9b0ecd9b001ca88706ce2f9fe003.1773865827.git.ljs@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/19/26 4:39 AM, Lorenzo Stoakes (Oracle) wrote: > A recent bug I analysed [0] managed to, through a bug in the userfaultfd > implementation, reach an invalid point in the zap_huge_pmd() code where the > PMD was none of: > > - A non-DAX, PFN or mixed map. > - The huge zero folio > - A present PMD entry > - A softleaf entry > > The code at this point calls folio_test_anon() on a known-NULL > folio. Having logic like this explicitly NULL dereference in the code is > hard to understand, and makes debugging potentially more difficult. > > Add an else branch to handle this case and WARN() and exit indicating > failure. > > [0]:https://lore.kernel.org/all/6b3d7ad7-49e1-407a-903d-3103704160d8@lucifer.local/ > > Signed-off-by: Lorenzo Stoakes (Oracle) > --- > mm/huge_memory.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index bba1ba1f6b67..8e6b7ba11448 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2478,6 +2478,10 @@ bool zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, > > if (!thp_migration_supported()) > WARN_ONCE(1, "Non present huge pmd without pmd migration enabled!"); > + } else { > + WARN_ON_ONCE(true); > + spin_unlock(ptl); The warning looks reasonable to me, but ... > + return false; IIUC, if we return false here, the caller zap_pmd_range() will fall back to call zap_pte_range(). Since pmd_trans_huge(pmd) returns true, zap_pte_range() will simply return 'addr', causing an infinite loop in zap_pmd_range(), right?