[Crash-utility] [PATCH 0/2] crash: warnings of excluded page structures

[Dave Anderson]

----- Original Message -----
> On Wed, Jan 08, 2014 at 03:32:01PM -0500, Dave Anderson wrote:
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > 
> > > I have proposed a patch to makedumpfile to (optionally) exclude from
> > > a dump the page structures representing excluded pages.
> > > The idea being that a system with terabytes of system memory has
> > > millions of pages of page structures.  And most of them are unneeded.
> > > 
> > > That patch thread begins here:
> > >   http://marc.info/?l=kexec&m=138853299130125&w=2
> > > 
> > > Dave [Anderson] raised these crash-related issues;
> > >   Although I'm sure you tested this, I find it amazing that
> > >   only the "kmem -[fF]" option is the only command option
> > >   that is affected?
> > >   If I'm not mistaken, this would be the first time that legitimate
> > >   kernel data would be excluded from the dump, and the user would
> > >   have no obvious way of knowing that it had been done, correct?
> > >   If it were encoded in the in the header somewhere, at least a
> > >   warning message could be printed during crash initialization.
> > >   ...
> > >   Right, but look at all of the other page struct offsets in addition to
> > >   page.lru that are used.  The page.flags usage comes to mind, and for
> > >   example, what would "kmem -p" display for the missing pages?
> > >   Or "kmem <address>"?  And would "kmem -i" display invalid data?
> > >   I'm just speculating off the top of my head, but the page structure is
> > >   such a fundamental data structure with several of its fields being
> > >   used,
> > >   just enter "help -o page_" to see all of its potential member usages.
> > > 
> > > So I am submitting two patches for your consideration, should the patch
> > > to exclude unused vmemmap pages be taken into makedumpfile.
> > > 
> > > - [PATCH 1/2] crash: initial note of excluded page structures
> > >   This one makes crash startup look like this:
> > >      This program has absolutely no warranty.  Enter "help warranty" for
> > >      details.
> > >  
> > >      NOTE: Unused vmemmap page structures are excluded from this dump.
> > >      GNU gdb (GDB) 7.6
> > >      Copyright (C) 2013 Free Software Foundation, Inc.
> > > 
> > > - [PATCH 1/2] crash: kmem warnings for excluded page structures
> > >    This patch modifies kmem options -f, -F, -s addr, -S addr, and -i.
> > >    Those are the only options that I could detect looking for excluded
> > >    pages.
> > > 
> > >    This patch applies on top of the first, and adds some warnings to the
> > >    output of these kmem options. For example:
> > > 
> > >     crash> kmem -f
> > >     Note: kmem -f may fail because unused page structures are excluded
> > >     from
> > >     this dump.
> > >     NODE
> > >       0
> > >     ZONE  NAME        SIZE    FREE      MEM_MAP       START_PADDR
> > >     START_MAPNR
> > >       0   DMA         4095    3934  ffffea0000000038      1000          0
> > >     AREA    SIZE  FREE_AREA_STRUCT  BLOCKS  PAGES
> > >       0       4k  ffff880000013068       2      2
> > >      ...
> > > 
> > >    crash> kmem -i
> > >                  PAGES        TOTAL      PERCENTAGE
> > >     TOTAL MEM  128008147     488.3 GB         ----
> > >          FREE  127599276     486.8 GB   99% of TOTAL MEM
> > >          USED   408871       1.6 GB    0% of TOTAL MEM
> > >        SHARED    11049      43.2 MB    0% of TOTAL MEM
> > >       BUFFERS     5722      22.4 MB    0% of TOTAL MEM
> > >        CACHED    44638     174.4 MB    0% of TOTAL MEM
> > >          SLAB    62139     242.7 MB    0% of TOTAL MEM
> > >    
> > >    TOTAL SWAP  4893032      18.7 GB         ----
> > >     SWAP USED        0            0    0% of TOTAL SWAP
> > >     SWAP FREE  4893032      18.7 GB  100% of TOTAL SWAP
> > >    
> > >    Note: 1970727 free pages not found (excluded); results are incomplete.
> > >    Unused page structures are excluded from this dump.
> > > 
> > > -Cliff Wickman
> > >  cpw at sgi.com
> > 
> > Cliff,
> > 
> > Can you make this patch far simpler?  I would prefer that an
> > error message *follows* the gdb banner, i.e., where a number of
> > current warnings get displayed?  You seem to be showing it just
> > above the gdb banner, where it kind of gets lost.
> 
> Okay I'll move the message.
>  
> > Secondly, I'm not sure where/how you are determining the 1970727
> > pages that are excluded.  Is it possible to put that in the
> > early warning message?
> 
> The 1970727 pages were counted by the second patch. That is, I
> put a counter in the readmem path that counted 'excluded' errors.
> So there were 1970727 such errors during the execution of the
> kmem -i.
> It is probably not worth it to make a place for a new number
> in the dump header.  Knowing how many million pages were
> excluded won't help if 'your' problem page was one of them.
> > 
> > Thirdly, I'm not convinced that the kmem locations where you
> > are adding per-option warning messages are going to be the only
> > place where problems may arise.  For that reason, I would
> > not even bother putting them in all those various locations,
> > but rather listing the "known" commands that may fail in the
> > early warning message.  So do something like:
> 
> Drop the 2nd patch then.  If you think it might be more misleading
> then helpful I'm fine with just the initialization warning.

OK -- I just don't want to clutter the code with a bunch of per-option
warning messages, but would rather have an ominous, as-wordy-as-you'd-like-it,
message delivered right up front.  

Take a look at "ERASEINFO_DATA" in the crash sources, and do a similar thing.
It's the same concept, where in that case, sensitive kernel data may have been
erased from the vmcore.

Thanks,
  Dave