Re: [PATCH v4 12/12] mm/debug_vm_pgtable: Fix corrupted page flag

[Gavin Shan]

Hi Christophe and Anshuman,

On 7/28/21 8:05 PM, Anshuman Khandual wrote:
> On 7/28/21 1:23 PM, Christophe Leroy wrote:
> > Gavin Shan <gshan@xxxxxxxxxx> a écrit :
> > > In page table entry modifying tests, set_xxx_at() are used to populate
> > > the page table entries. On ARM64, PG_arch_1 (PG_dcache_clean) flag is
> > > set to the target page flag if execution permission is given. The logic
> > > exits since commit 4f04d8f00545 ("arm64: MMU definitions"). The page
> > > flag is kept when the page is free'd to buddy's free area list. However,
> > > it will trigger page checking failure when it's pulled from the buddy's
> > > free area list, as the following warning messages indicate.
> > >
> > >     BUG: Bad page state in process memhog  pfn:08000
> > >     page:0000000015c0a628 refcount:0 mapcount:0 \
> > >          mapping:0000000000000000 index:0x1 pfn:0x8000
> > >     flags: 0x7ffff8000000800(arch_1|node=0|zone=0|lastcpupid=0xfffff)
> > >     raw: 07ffff8000000800 dead000000000100 dead000000000122 0000000000000000
> > >     raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
> > >     page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag(s) set
> > >
> > > This fixes the issue by clearing PG_arch_1 through flush_dcache_page()
> > > after set_xxx_at() is called. For architectures other than ARM64, the
> > > unexpected overhead of cache flushing is acceptable.
> > >
> > > Signed-off-by: Gavin Shan <gshan@xxxxxxxxxx>
> >
> > Maybe a Fixes: tag would be good to have
>
> Agreed.
>
> Fixes: a5c3b9ffb0f4 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers")

Yep, I will add the tag in v5.

> > And would it be possible to have this fix as first patch of the series so that it can be applied to stable without applying the whole series ?
> Changing the allocation scheme does solve another problem (using non-owned pages)
> but is achieved via the entire series applied. But this particular patch could be
> moved to the beginning without much problem.

I prefer to keep current layout as explained before. Firstly, all
code changes included in this series are affecting only one source
file. It's hard to apply the whole series to stable kernel. I also
need apply this series to our downstream kernel once it hits upstream.
Secondly, applying PATCH[v4 12/12] can't resolve all issues we have.
It means we need to apply the whole series to resolve all issues.
Lastly, moving PATCH[v4 12/12] to PATCH[v4 01/12] will introduce
unnecessary code for subsequent patches. I don't think it's worthy
to do.

So lets keep current layout we have.

Thanks,
Gavin