On Thu, Aug 08, 2024 at 12:37:21AM +0200, Thomas Gleixner wrote:
> On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> > These new helpers will be needed for pud entry updates soon. Introduce
> > these helpers by referencing the pmd ones. Namely:
> >
> > - pudp_invalidate()
> > - pud_modify()
>
> Zero content about what these helpers do and why they are needed. That's
> not how it works, really.
I hope what Dave suggested to add "by referencing the pmd ones" would be
helpful, because they are exactly referencing those.
But sure.. I rewrote the commit message as following:
mm/x86: Add missing pud helpers
Some new helpers will be needed for pud entry updates soon. Introduce
these helpers by referencing the pmd ones. Namely:
- pudp_invalidate(): this helper invalidates a huge pud before a split
happens, so that the invalidated pud entry will make sure no race will
happen (either with software, like a concurrent zap, or hardware, like
a/d bit lost).
- pud_modify(): this helper applies a new pgprot to an existing huge pud
mapping.
For more information on why we need these two helpers, please refer to the
corresponding pmd helpers in the mprotect() code path.
When at it, simplify the pud_modify()/pmd_modify() comments on shadow stack
pgtable entries to reference pte_modify() to avoid duplicating the whole
paragraph three times.
Please let me know if this works for you.
>
>
> > +static inline pud_t pud_mkinvalid(pud_t pud)
> > +{
> > + return pfn_pud(pud_pfn(pud),
> > + __pgprot(pud_flags(pud) & ~(_PAGE_PRESENT|_PAGE_PROTNONE)));
>
> 100 characters...
Waiting for an answer on this one, so I'll ignore "100 char" comments for
now, and will address them when I get a clue on what is happening..
>
> > +}
> > +
> > static inline u64 flip_protnone_guard(u64 oldval, u64 val, u64 mask);
> >
> > static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
> > @@ -834,14 +840,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
> > pmd_result = __pmd(val);
> >
> > /*
> > - * To avoid creating Write=0,Dirty=1 PMDs, pte_modify() needs to avoid:
> > - * 1. Marking Write=0 PMDs Dirty=1
> > - * 2. Marking Dirty=1 PMDs Write=0
> > - *
> > - * The first case cannot happen because the _PAGE_CHG_MASK will filter
> > - * out any Dirty bit passed in newprot. Handle the second case by
> > - * going through the mksaveddirty exercise. Only do this if the old
> > - * value was Write=1 to avoid doing this on Shadow Stack PTEs.
> > + * Avoid creating shadow stack PMD by accident. See comment in
> > + * pte_modify().
>
> The changelog is utterly silent about this comment update.
Updated my commit message altogether above; I hope it works.
>
> > */
> > if (oldval & _PAGE_RW)
> > pmd_result = pmd_mksaveddirty(pmd_result);
> > @@ -851,6 +851,29 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
> > return pmd_result;
> > }
> >
> > +static inline pud_t pud_modify(pud_t pud, pgprot_t newprot)
> > +{
> > + pudval_t val = pud_val(pud), oldval = val;
> > + pud_t pud_result;
> > +
> > + val &= _HPAGE_CHG_MASK;
> > + val |= check_pgprot(newprot) & ~_HPAGE_CHG_MASK;
> > + val = flip_protnone_guard(oldval, val, PHYSICAL_PUD_PAGE_MASK);
> > +
> > + pud_result = __pud(val);
> > +
> > + /*
> > + * Avoid creating shadow stack PUD by accident. See comment in
> > + * pte_modify().
> > + */
> > + if (oldval & _PAGE_RW)
> > + pud_result = pud_mksaveddirty(pud_result);
> > + else
> > + pud_result = pud_clear_saveddirty(pud_result);
> > +
> > + return pud_result;
> > +}
> > +
> > /*
> > * mprotect needs to preserve PAT and encryption bits when updating
> > * vm_page_prot
> > @@ -1389,10 +1412,26 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma,
> > }
> > #endif
> >
> > +static inline pud_t pudp_establish(struct vm_area_struct *vma,
> > + unsigned long address, pud_t *pudp, pud_t pud)
>
> Random line break alignment.... See documentation.
This is exactly what we do with pmdp_establish() right above.
Would you be fine I keep this just to make pmd/pud look the same?
>
> > +{
> > + page_table_check_pud_set(vma->vm_mm, pudp, pud);
> > + if (IS_ENABLED(CONFIG_SMP)) {
> > + return xchg(pudp, pud);
> > + } else {
> > + pud_t old = *pudp;
> > + WRITE_ONCE(*pudp, pud);
>
> Lacks a newline between variable declaration and code.
>
> But seriously, why optimizing for !SMP? That's a pointless exercise and
> a guarantee for bitrot.
So far it looks still reasonable to me if it is there in pmd. If I remove
it, people can complain again on "hey, we have this /optimization/ in pmd,
why you removed it in pud?". No end..
So again.. it's the same to pmd ones. Either we change nothing, or we
change both. I don't want to expand this series to more than it wants to
do.. would you mind I keep it until someone justifies the change to modify
both?
>
> > + return old;
> > + }
> > +}
> > +
> > #define __HAVE_ARCH_PMDP_INVALIDATE_AD
> > extern pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma,
> > unsigned long address, pmd_t *pmdp);
> >
> > +pud_t pudp_invalidate(struct vm_area_struct *vma, unsigned long address,
> > + pud_t *pudp);
>
> While 'extern' is not required, please keep the file style consistent
> and use the 100 characters...
>
> > --- a/arch/x86/mm/pgtable.c
> > +++ b/arch/x86/mm/pgtable.c
> > @@ -641,6 +641,18 @@ pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address,
> > }
> > #endif
> >
> > +#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && \
> > + defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
> > +pud_t pudp_invalidate(struct vm_area_struct *vma, unsigned long address,
> > + pud_t *pudp)
> > +{
> > + VM_WARN_ON_ONCE(!pud_present(*pudp));
> > + pud_t old = pudp_establish(vma, address, pudp, pud_mkinvalid(*pudp));
> > + flush_pud_tlb_range(vma, address, address + HPAGE_PUD_SIZE);
> > + return old;
>
> Your keyboard clearly lacks a newline key ...
This is also the same, that pmdp_invalidate() coded it like exactly that.
In general, I prefer keeping the pmd/pud helpers look the same if you won't
disagree as of now, all over the places.
I know that it might even be better to clean up everything, get everything
reviewed first on pmd changes, then clone that to pud. That might be
cleaner indeed. But it adds much fuss all over the places, and even with
this series I got stuck for months.. and so far I haven't yet post what I
really wanted to post (huge pfnmaps). I sincerely hope we can move forward
with this and then clean things up later (none of them are major issues;
all trivial details so far, IMHO, so nothing I see go severely wrong yet),
and then the cleanup will need to be justified one by one on each spot.
Thanks,
--
Peter Xu
