From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (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 DC33238A29A for ; Wed, 24 Jun 2026 06:58:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782284321; cv=none; b=Lcq3wJVLq4TWmK3M9vZwoS4TyBE1tcbmq0vRXoKcHdCz0mcpWHtcpOm6osStBhWXMSJK1jmr+wJRJmLZkFKvn292BXuERmpiBQGXdDSpE3LdBo2PgXKU9kT3J6kzvQg8pS6QxoRCJW5OVSZ/v67Wn1ik1903JZtu9bSGG4MtGrU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782284321; c=relaxed/simple; bh=9eFUNVh7/EBt/uXy5hk3JHu88+WXUNUpsGmIpAMLkbc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jmCat5lFeDzi+Pdcqr/LizVSZDk3lNkLSz32yr+n/Iih1GFWNj8wvw/PP+In1X201SoI5Jj+FIbk13pwwZERroR/6JLGFKjIsxqzhlnTzKKQJMU754VN2gLyzCq/lr9Y3o3o2/YZaEgSm9BWzsl+H/2+PE/0msBBCFA2rRPCdTY= 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=QtudLKBG; arc=none smtp.client-ip=91.218.175.174 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="QtudLKBG" Message-ID: <5d11c940-a8b9-40d4-9b8f-aa2a9909724c@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782284317; 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=zGLKldePx7r1dzWhJ9pzygXxiTVGhPttEMwGKkjBnek=; b=QtudLKBGcSAIiYOhfSuYwYXrE7BrFJxaCaxmHI66MGPiLwTzNCdy6rqPqA/Gc6gSFyI1sV XaRqukOxZmUafB0N7JgptoH+y3hZuWMdeEq+bCVoyV9EB8jhqIBEloxzHYQeyFIAaSQtDr NwzmO1eYu3cGLE7L//TwrDdw8UjY3bo= Date: Wed, 24 Jun 2026 14:58:17 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one To: Dev Jain , "David Hildenbrand (Arm)" Cc: akpm@linux-foundation.org, ljs@kernel.org, chrisl@kernel.org, kasong@tencent.com, hughd@google.com, liam@infradead.org, riel@surriel.com, vbabka@kernel.org, harry@kernel.org, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, baolin.wang@linux.alibaba.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260618074449.24974-1-lance.yang@linux.dev> <0fe2a584-c633-4f82-8c47-d204e3b39a57@linux.dev> <22613c23-612b-4de0-8731-00ad2da63eae@linux.dev> <0368128c-664a-40aa-9b37-27768d403795@kernel.org> <82474473-ff96-4ee5-bbe4-3d92c2f8cefa@arm.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <82474473-ff96-4ee5-bbe4-3d92c2f8cefa@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/6/24 13:50, Dev Jain wrote: > > > On 22/06/26 1:47 pm, David Hildenbrand (Arm) wrote: >> On 6/22/26 10:14, Dev Jain wrote: >>> >>> >>> On 22/06/26 1:43 pm, Dev Jain wrote: >>>> >>>> >>>> On 18/06/26 3:31 pm, Lance Yang wrote: >>>>> >>>>> >>>>> >>>>> Yeah, looks like this was already there before the split. Should this >>>>> be fixed separately? >>>> >>>> Same bug is there in try_to_migrate_one(), check_pte(), remove_migration_pte() >>>> and prot_none_hugetlb_entry() :) >>>> >>> >>> Lemme send a series for them. Main thing is identifying the fixes tag really. >> >> Thanks! > > I am confused w.r.t backport. So currently we just have to do this: > > - /* > - * Handle PFN swap PTEs, such as device-exclusive ones, that > - * actually map pages. > - */ > - pteval = ptep_get(pvmw.pte); > + address = pvmw.address; > + if (folio_test_hugetlb(folio)) { > + pteval = huge_ptep_get(mm, address, pvmw.pte); > + } else { > + /* > + * Handle PFN swap PTEs, such as device-exclusive ones, > + * that actually map pages. > + */ > + pteval = ptep_get(pvmw.pte); > + } > > > At commit c7ab0d2fdc84, try_to_unmap_one() was converted to use the pvmw API. The > code was: > > while (page_vma_mapped_walk(&pvmw)) { > subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte); > > Doing a plain dereference. Before this commit, the code was: > > > pte_t *__page_check_address(struct page *page, struct mm_struct *mm, > unsigned long address, spinlock_t **ptlp, int sync) > { > pmd_t *pmd; > pte_t *pte; > spinlock_t *ptl; > > if (unlikely(PageHuge(page))) { > /* when pud is not present, pte will be NULL */ > pte = huge_pte_offset(mm, address); > if (!pte) > return NULL; > > ptl = huge_pte_lockptr(page_hstate(page), mm, pte); > goto check; > } > > pmd = mm_find_pmd(mm, address); > if (!pmd) > return NULL; > > pte = pte_offset_map(pmd, address); > /* Make a quick check before getting the lock */ > if (!sync && !pte_present(*pte)) { > pte_unmap(pte); > return NULL; > } > > ptl = pte_lockptr(mm, pmd); > check: > spin_lock(ptl); > if (pte_present(*pte) && page_to_pfn(page) == pte_pfn(*pte)) { > *ptlp = ptl; > return pte; > } > pte_unmap_unlock(pte, ptl); > return NULL; > } > > > This does pte_pfn(*pte), a plain dereference. I am not sure how back I need > to go for the backport and do I need to post multiple patches for different > stable versions. Yeah ... looks old old old, not just c7ab0d2fdc84. Stable backport looks kinda messy though. Mainline can probably stay as one clean series, but stable might needs separate review per tree. Going to be a pain ... > And, it is crazy that the bug has stayed for this long and testing didn't find this. > Perhaps no one bothered running hugetlb-read-hwpoison on PPC or s390. And for some > reason those tests are in a category of "destructive" in run_vmtests.sh, requiring > a command line option - and even that option was fixed just now in 3432cbb291aa! Sigh ...