On Wed, Aug 05, 2026 at 07:58:02AM +0200, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 04/08/2026 à 21:22, Pedro Falcato a écrit :
> > On Tue, Aug 04, 2026 at 12:22:19PM +0100, Lorenzo Stoakes (ARM) wrote:
> >
> > >
> > > > if (!pte) {
> > > > mmap_read_unlock(mm);
> > > > result = SCAN_NO_PTE_TABLE;
> > > > diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> > > > index b91b1a98029c..2cfc6e608ef4 100644
> > > > --- a/mm/pgtable-generic.c
> > > > +++ b/mm/pgtable-generic.c
> > > > @@ -308,8 +308,8 @@ pte_t *__pte_offset_map(pmd_t *pmd, unsigned long
> > > > addr, pmd_t *pmdvalp)
> > > > return NULL;
> > > > }
> > > >
> > > > -pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd,
> > > > - unsigned long addr, spinlock_t **ptlp)
> > > > +const pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd,
> > >
> > > Can pmd be const too?
> >
> > I was going to say "yes but then pmdp_get() also needs to be constfified"
> > but
> > actually no, it can't:
> >
> > pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) {
> > if (unlikely(pmd_bad(pmdval))) {
> > pmd_clear_bad(pmd);
> > goto nomap;
> > }
> > }
> >
> > so PTE mapping actually needs to write to the pmdp if the pmd looks bad.
> > Tricky stuff :)
>
> But if pmd is const, can it be bad at all ?
Yes, you just need a stray write or a bit of memory corruption and it can
go bad. And then we need to do clear_bad() :)
(it's unclear to me whether this is actually common or useful enough these
days; the way this was explained to me, page tables can be best-effort
redundant; but it's not like we know clearing the whole range is ok, and
the way pmd_ERROR, etc work they don't even communicate to userspace what
happened, unlike normal hwpoison mechanisms)
--
Pedro