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

[Dave Anderson]

----- Original Message -----
> On 04/26, Dave Anderson wrote:
> >
> > > But all the LOCAL_ACTIVE changes in 1-7 do not care about the details of "live"
> > > mechanism at all. So I still think we need a generic helper which should be true
> > > if local-and-active. Or, vice versa, remote-and-active, this doesn't matter.
> ...
> > > So you suggest to change this patch to do
> > >
> > > 		if (ACTIVE() && !ACTIVE_QEMU() && !INSTACK(...))
> > >
> > > To me this simply looks worse, but I won't insist. But note that if we ever have
> > > another ACTIVE_SOMETHING() source, we will need to modify this code again.  While
> > > this code do not care about qemu/something at all. So I still think we need a new
> > > helper which doesn't depend on qemu or whatever else.
> >
> > Right, but this is definitely the outlier with respect to "live" systems.
> 
> Can't understand...

I mean that it's a special case of a "live" system.  For the most part it is, but
there are a number of gotcha's that would need to be caught and addressed.

> 
> > > > > Or perhaps you mean that ACTIVE_QEMU() should be defined as
> > > > >
> > > > > 	#define ACTIVE_QEMU()	(pc->flags2 & QEMU_LIVE)
> > > > >
> > > > > ? iow, it should not imply ACTIVE() ? This would be even worse, in this case we
> > > > > would neet to replace almost every ACTIVE() with "ACTIVE() || ACTIVE_QEMU()".
> >
> > QEMU_LIVE should be in pc->flags, and appear as part of MEMORY_SOURCES.  And LIVE_SYSTEM
> > should also be set so that the facility falls under both ACTIVE() and ACTIVE_QEMU().
> > And then in the subset of cases where ACTIVE() is too broad, ACTIVE_QEMU() can be added
> > as a restriction.
> 
> OK. But not in the case above? This particular /proc/$tc->pid doesn't need to
> know if this (remote) live system is ACTIVE_QEMU() or ACTIVE_SOMETHING_ELSE()?
> All it needs to know if we debug the (live) kernel on the same machine or not.

I think we're still talking about the code segment in back_trace()?  All that
is doing is recognizing that the "current" task no longer exists, and the backtrace
attempt should fail.  Then there's some other code that runs before the next "crash> "
prompt that resets it to the live "crash" task that's running.  In the live QEMU 
session, that will have to handled differently in both places.  I don't know how
you're going to easily determine whether task still exists.

Dave