All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Dev Jain <dev.jain@arm.com>, Andrew Morton <akpm@linux-foundation.org>
Cc: muchun.song@linux.dev, osalvador@suse.de, ljs@kernel.org,
	liam@infradead.org, riel@surriel.com, vbabka@kernel.org,
	harry@kernel.org, jannh@google.com, lance.yang@linux.dev,
	kas@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	apopple@nvidia.com, rcampbell@nvidia.com, ziy@nvidia.com,
	matthew.brost@intel.com, joshua.hahnjy@gmail.com,
	rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net,
	ying.huang@linux.alibaba.com, ak@linux.intel.com,
	nao.horiguchi@gmail.com, mel@csn.ul.ie, j-nomura@ce.jp.nec.com,
	pfalcato@suse.de, tglx@kernel.org, dave.hansen@intel.com,
	jpoimboe@kernel.org, catalin.marinas@arm.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, ryan.roberts@arm.com,
	anshuman.khandual@arm.com, stable@vger.kernel.org
Subject: Re: [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses
Date: Mon, 6 Jul 2026 10:45:47 +0200	[thread overview]
Message-ID: <4b4e8007-3747-457a-85cc-d1003e1c8fe2@kernel.org> (raw)
In-Reply-To: <8fdbe0d6-87fd-441c-b6d2-baac380f6fb3@arm.com>

On 7/5/26 10:08, Dev Jain wrote:
> 
> 
> On 05/07/26 1:05 pm, Andrew Morton wrote:
>> On Fri,  3 Jul 2026 11:41:54 +0000 Dev Jain <dev.jain@arm.com> wrote:
>>
>>> huge_ptep_get() can be handed a virtual address pointing to the middle of
>>> a contpmd/contpte mapped hugetlb folio (examples of callers are
>>> pagemap_hugetlb_range, page_mapped_in_vma).
>>>
>>> The arm64 helper rewalks the pgtables in find_num_contig to answer whether
>>> the huge pte we have maps a contpmd or a contpte hugetlb folio, and
>>> returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the
>>> contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS
>>> if the addr is not aligned.
>>>
>>> Fix this by aligning the pmdp pointer down to a contpmd base before
>>> checking equality with the passed huge pte pointer, to correctly answer
>>> whether the huge pte is the base of a contpmd block.
>>>
>>> Fixes: 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
>>> Cc: stable@vger.kernel.org
>>
>> Please describe the userspace-visible effects of bugs when fixing them.
>> Particularly when cc:stable is proposed.  Thanks.
> 
> Forgot for this one. It should be, on systems where CONT_PTES != CONT_PMDS
> (meaning page size is 16K) we could collect excess a/d bit state, meaning
> extra work for the kernel.

Even worse, right? We could walk 128 entries, when we really should just walk 16
(IIRC) entries, possibly reading garbage or even worse, into a memory hole at
the end of memory?

-- 
Cheers,

David


  reply	other threads:[~2026-07-06  8:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 11:41 [PATCH v3 0/6] Fix incorrect access of hugetlb pte entries Dev Jain
2026-07-03 11:41 ` [PATCH v3 1/6] arm64: make huge_ptep_get handled unaligned addresses Dev Jain
2026-07-04  2:42   ` Muchun Song
2026-07-05  7:35   ` Andrew Morton
2026-07-05  8:08     ` Dev Jain
2026-07-06  8:45       ` David Hildenbrand (Arm) [this message]
2026-07-06 10:52         ` Dev Jain
2026-07-06 10:54           ` Dev Jain
2026-07-06 14:04             ` David Hildenbrand (Arm)
2026-07-03 11:41 ` [PATCH v3 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one() Dev Jain
2026-07-04  2:44   ` Muchun Song
2026-07-06  8:46   ` David Hildenbrand (Arm)
2026-07-03 11:41 ` [PATCH v3 3/6] mm/rmap: use huge_ptep_get() in try_to_migrate_one() Dev Jain
2026-07-06  8:46   ` David Hildenbrand (Arm)
2026-07-03 11:41 ` [PATCH v3 4/6] mm/migrate: use huge_ptep_get() in remove_migration_pte() Dev Jain
2026-07-03 11:41 ` [PATCH v3 5/6] mm/page_vma_mapped: use huge_ptep_get() for hugetlb Dev Jain
2026-07-03 11:41 ` [PATCH v3 6/6] mm/mprotect: " Dev Jain
2026-07-05  8:33   ` Andrew Morton
2026-07-05  8:47     ` Dev Jain
2026-07-06  8:48   ` David Hildenbrand (Arm)
2026-07-05  7:45 ` [PATCH v3 0/6] Fix incorrect access of hugetlb pte entries Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b4e8007-3747-457a-85cc-d1003e1c8fe2@kernel.org \
    --to=david@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@intel.com \
    --cc=dev.jain@arm.com \
    --cc=gourry@gourry.net \
    --cc=harry@kernel.org \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=jannh@google.com \
    --cc=joshua.hahnjy@gmail.com \
    --cc=jpoimboe@kernel.org \
    --cc=kas@kernel.org \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=mel@csn.ul.ie \
    --cc=muchun.song@linux.dev \
    --cc=nao.horiguchi@gmail.com \
    --cc=osalvador@suse.de \
    --cc=pfalcato@suse.de \
    --cc=rakie.kim@sk.com \
    --cc=rcampbell@nvidia.com \
    --cc=riel@surriel.com \
    --cc=ryan.roberts@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@kernel.org \
    --cc=vbabka@kernel.org \
    --cc=will@kernel.org \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.