On Thu, Aug 08, 2024 at 12:28:47AM +0200, Thomas Gleixner wrote:
> On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
>
> > Subject: mm/x86: arch_check_zapped_pud()
>
> Is not a proper subject line. It clearly lacks a verb.
>
> Subject: mm/x86: Implement arch_check_zapped_pud()
>
>
> > Introduce arch_check_zapped_pud() to sanity check shadow stack on PUD zaps.
> > It has the same logic of the PMD helper.
>
> s/of/as/
Will fix above two.
>
> > +
> > +void arch_check_zapped_pud(struct vm_area_struct *vma, pud_t pud)
> > +{
> > + /* See note in arch_check_zapped_pte() */
> > + VM_WARN_ON_ONCE(!(vma->vm_flags & VM_SHADOW_STACK) &&
> > + pud_shstk(pud));
>
> Please get rid of the line break. You have 100 characters.
Coding-style.rst still tells me 80 here:
The preferred limit on the length of a single line is 80 columns.
Statements longer than 80 columns should be broken into sensible chunks,
unless exceeding 80 columns significantly increases readability and does
not hide information.
Maybe this just changed very recently so even not in mm-unstable?
I'll fix the two line-wrap in this patch anyway, as I figured these two
cases even didn't hit 80.. probably because I used fill-column=75 locally..
But still I'll probably need to figure it out for other spots. Please help
me to justify.
>
> > +}
> > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> > index 2a6a3cccfc36..2289e9f7aa1b 100644
> > --- a/include/linux/pgtable.h
> > +++ b/include/linux/pgtable.h
> > @@ -447,6 +447,13 @@ static inline void arch_check_zapped_pmd(struct vm_area_struct *vma,
> > }
> > #endif
> >
> > +#ifndef arch_check_zapped_pud
> > +static inline void arch_check_zapped_pud(struct vm_area_struct *vma,
> > + pud_t pud)
> > +{
>
> Ditto..
>
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 0024266dea0a..81c5da0708ed 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
>
> Why is a mm change burried in a patch which is named mm/x86?
>
> It's clearly documented that core changes with the generic fallback come
> in one patch and the architecture override in a separate one afterwards.
>
> Do we write documentation just for the sake of writing it?
Hmm if that's the rule, in practise I bet many patches are violating that
rule that we merged and whatever patches I used to read.. but I see now,
I'll break this patch into two.
Personally I'd really still prefer it to be one patch especially when it's
only implemented in x86, then I copy x86+mm maintainers all here and it
explains why it's there. So please let me know if you think it may still
make sense to keep this patch as-is, or I'll split by default.
Thanks,
--
Peter Xu
