[Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

Dave Anderson anderson at redhat.com
Tue Apr 26 14:57:48 UTC 2016



----- Original Message -----
> On 04/26, Dave Anderson wrote:
> >
> > > Ah. Yes, the usage of CRASHBUILTIN is ugly, and I tried to document this.
> > >
> > > We need the new (say) RAW_MEM_DUMP flag. We can't use RAMDUMP because it can
> > > be set along with KDUMP.
> > >
> > > And there is no room in pc->flags, so I decided to abuse CRASHBUILTIN for now.
> >
> > I understand.
> >
> > It's exceeding rare that a new dumpfile type, or a new live system accessor in
> > this case, gets introduced.  When that happens, we can move deprecated leftovers
> > from pc->flags to pc->flags2.   So for example, all of these can be moved to
> > pc->flags2 in one fell swoop:
> >
> >   REM_NETDUMP
> >   REM_MCLXCD
> >   REM_LKCD
> >   REM_S390D
> 
> Yes, yes, sure. But while this is trivial, this needs some tiresome changes.

One-time tiresome changes.  I should probably do it anyway.  They are a
waste of pc->flags space.

> and that is what this part of changelog
> 
> 	The usage of CRASHBUILTIN doesn't look nice, we need to cleanup
> 	this logic. I hope we can do this later, and it seems to me that
> 	the usage of MEMORY_SOURCES/DUMPFILE_TYPES needs some cleanups in
> 	any case.
> 
> in 9/10 tried to say ;)

CRASHBUILTIN is used to indicate the the Red Hat /dev/crash driver exists and
the kernel module was built into the kernel -- as opposed to having to load the
crash.ko driver.  I'm not sure how that is associated with this facility.

> 
> Say, memory_page_size(). It does "switch (pc->flags & MEMORY_SOURCES)" and it
> needs the update if we move (say) NETDUMP in pc->flags2. Trivial, but needs
> another patch/discussion/etc.

Who said to move NETDUMP?  I only suggested the REM_NETDUMP (and the other REM_xxx)
dumpfiles.
 
> 
> Another problem is that there is no simple/clear way to tell fd_init() paths that
> we do not need get_live_memory_source/memory_source_init. Unless we set
> REMOTE() == T but we should not do this.
> 
> So, if REMOTE() is false, fd_init() calls get_live_memory_source() if
> pc->dumpfile is NULL. This is not what RAMDUMP need, so 09/10 has to initialize
> pc->dumpfile. At the same time memory_source_init() assumes that if
> pc->dumpfile must at least exist if it is non-NULL. Perhaps this needs needs
> some cleanups too, but this is off-topic right now.

Right, presumably there would need to be a separate "if (QEMU_ACTIVE())" section 
in memory_source_init().

> Heh ;). and I think fd_init() is simply wrong. The problem is minor and off-topic
> too, I'll report it later (probably with simple fixes tomorrow). But in short,
> you can't use /dev/crash unless you are root, and if you root and /dev/crash
> is modular then /dev/crash will be removed and the module will be unloaded when
> the crash exits, even if it was not loaded/created by crash. Although I need
> to verify this, I can be wrong.

Correct.  When it's modular (and it isn't any more), the module is unloaded and
/dev/crash is purposely removed.  It works as intended.

Dave






More information about the Crash-utility mailing list