[Crash-utility] makedumpfile: 4.5 kernel commit breaks page filtering

Laurence Oberman loberman at redhat.com
Fri Feb 26 16:46:47 UTC 2016


    
HelloYes sir. Happy to do that. will post back to the thread Monday.I am on PTO today.RegardsLaurence


Sent on the new Sprint Network from my Samsung Galaxy S®4

-------- Original message --------
From: Dave Anderson <anderson at redhat.com> 
Date: 02/26/2016  11:45  (GMT-05:00) 
To: Laurence Oberman <loberman at redhat.com>, Joe Lawrence <joe.lawrence at stratus.com> 
Cc: "Discussion list for crash utility usage, maintenance and development" <crash-utility at redhat.com>, ats-kumagai at wm.jp.nec.com 
Subject: Re: [Crash-utility] makedumpfile: 4.5 kernel commit breaks page	filtering 


Laurence and Joe,

Can you gents test Atsushi's fix in your environments?

Thanks,
  Dave


----- Original Message -----
> 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 at redhat.com
> >https://www.redhat.com/mailman/listinfo/crash-utility
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20160226/fc0a8c2f/attachment.htm>


More information about the Crash-utility mailing list