Hello Dave,
>Note that PAGE_MAPPING_ANON is now only set in the compound_head
page,
>so when makedumpfile walks though the pages, it will have to look
>at each page's head page for the bit setting.
Thanks for your report.
As you said, it seems checking the head page like kernel does is necessary.
I'll try to work it out, please give me some time.
Reading head page's page->mapping for each tail page will take extra time,
so I contrived another way.
It's just skipping compound tail pages for filtering.
If makedumpfile excludes compound pages, it will be done at a time by
exclude_range() at the time of checking the compound head page. We don't
need to check compound tail pages individually.
I made the patch, could you test the *compound* branch below ?
This version requires a new unexported symbol, you need to specify
-x vmlinux for now.
https://sourceforge.net/p/makedumpfile/code/ci/compound/tree/
Thanks,
Atsushi Kumagai
>As it is now, makedumpfile runs amok filtering pages that still
have
>stuff left in page->mapping. For example, all of the addresses in
>my "filtered.list" input file are those of legitimate kernel data
>structures that have been incorrectly filtered because PAGE_MAPPING_ANON
>(bit 1) has been left set:
>
>crash> kmem -p < filtered.list
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>ffffea0011b29040 46ca41000 dead0000ffffffff 0 0 3ffff800000000
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>ffffea0011b29040 46ca41000 dead0000ffffffff 0 0 3ffff800000000
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>ffffea0011b29640 46ca59000 dead0000ffffffff 0 0 3ffff800000000
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>ffffea0011b29640 46ca59000 dead0000ffffffff 0 0 3ffff800000000
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>ffffea0001d51640 75459000 dead0000ffffffff 0 0 1ffff800000000
>...
>
>In earlier kernels, the page->mapping fields above would not have
>their PAGE_MAPPING_ANON set.
>
>Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility