From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 18B4686341 for ; Wed, 24 Jun 2026 05:51:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782280272; cv=none; b=JmIR5j+XgRn07uU/d7NATr9RW/lcN1IgpnKYkwRFasRWIrqwuKYy1McE79NCwvy1hYEujWzKkMNFVnDeH+kdy9DzkIDaOxYWaqqe6X8WznA0W4/Q3lpu1cfVlWWNyLMzTCPMQ+h2t0y+L0OiDZ4RYYuN5d6NhqEAAQ0pWV0Qn1w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782280272; c=relaxed/simple; bh=G1DrRGj/pcW4vuRHrevEY0fnEtN/QDNsQ4085ytGVGQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bkGRvPCfWhWB48CTwpkQ3ZYhKB5ZfHQ0EONOIPIDKPUAlZYi/PYY3gMS8fyEIdjpkB1s1kxsY1InBxyjvNrkEY7ZBTecD1WCcBW1i71UuF9w251/BqlDWpSJPGA3QHlQds3BaFnyJFTTazSfYPmL5ZesCn6g72/wOctqtsREkag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=WrRo5tSb; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="WrRo5tSb" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A6361756; Tue, 23 Jun 2026 22:50:58 -0700 (PDT) Received: from [10.164.148.38] (unknown [10.164.148.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CC4073F632; Tue, 23 Jun 2026 22:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782280262; bh=G1DrRGj/pcW4vuRHrevEY0fnEtN/QDNsQ4085ytGVGQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=WrRo5tSb18qXkWRcfh2IoO9hFlLgZhmoXMwlBCf69YPCvHeAUAFJynTnDmGemQXG4 JCIiHk6LHeeFMiueSPF9DDQdTvWfnl/dNfE8ii1MIb0UK2AI69LV2NyTp3fAsHdrSy Wd7Rh66LXFKSsnIuYvvW3+Yk2njHqOUVo9P+3cq8= Message-ID: <82474473-ff96-4ee5-bbe4-3d92c2f8cefa@arm.com> Date: Wed, 24 Jun 2026 11:20:44 +0530 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 v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one To: "David Hildenbrand (Arm)" , Lance Yang 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> Content-Language: en-US From: Dev Jain In-Reply-To: <0368128c-664a-40aa-9b37-27768d403795@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. 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! >