Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
----- 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