----- Original Message -----
> Hi Dave,
>
> On s390 we will have a dump method that creates live dumps, similar to
> the snap.so crash plugin. Because Linux is not stopped while the dump
> is created, the resulting dump is not consistent. Therefore it is
> important that the crash tool informs the user about this issue.
>
> The dump tool writes a magic number (ASCII "LIVEDUMP") into the first 8
> bytes of the dump memory. With this patch this is checked in POST_INIT
> by the s390x backend crash code. If the magic is found, the LIVE_SYSTEM
> flag is set. This ensures that commands that do not work with /dev/mem
> also will fail with s390x live dumps.
>
> Example:
>
> crash> bt -a
> bt: -a option not supported on a live system
>
> In addition to that with this patch crash prints a "[LIVE DUMP]" info
> tag for live dump files at startup (similar to [PARTIAL DUMP]):
>
> $ crash livedump vmlinux
> KERNEL: /boot/vmlinux
> DUMPFILE: dump.s390 [LIVE DUMP]
>
> Michael
Interesting -- I'm amazed that even doing such a thing works!
Anyway, if you look at all the places where ACTIVE() is called,
this patch, at a minimum, would be kind of inefficient.
For example, consider that -- after each command -- the complete
task table would get re-initialized (as opposed to doing a single
invocation-time initialization from a dumpfile). That's not a big
deal when reading RAM, but it could be costly when having to
read from the dumpfile each time. But there are numerous places
where a similar tact is taken to avoid unnecessary dumpfile accesses
if the data can be cached.
I would have no problem with adding a new LIVE_DUMP flag to
pc->flags2, and just checking it in display_sys_stats() and
non_matching_kernel() as you've done below. In dealing with
dumpfiles generated from snap.so, the "bt" command is pretty
much the only command that probably should be restricted.
However, I don't restrict "bt" with snap.so vmcores because
currently there's no magic/signature/whatever that indicates
what kind of dump it is. But if you implement a new LIVE_DUMP
flag, I might do it there as well so we've got some consistency.
What do you think about that?
Dave
> ---
> kernel.c | 8 ++++++--
> s390x.c | 12 ++++++++++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> --- a/kernel.c
> +++ b/kernel.c
> @@ -975,7 +975,9 @@ non_matching_kernel(void)
> else
> fprintf(fp, " DUMPFILE: ");
> if (ACTIVE()) {
> - if (REMOTE_ACTIVE())
> + if (pc->dumpfile)
> + fprintf(fp, "%s [LIVE DUMP]\n", pc->dumpfile);
> + else if (REMOTE_ACTIVE())
> fprintf(fp, "%s@%s (remote live system)\n",
> pc->server_memsrc, pc->server);
> else
> @@ -4080,7 +4082,9 @@ display_sys_stats(void)
> else
> fprintf(fp, " DUMPFILE: ");
> if (ACTIVE()) {
> - if (REMOTE_ACTIVE())
> + if (pc->dumpfile)
> + fprintf(fp, "%s [LIVE DUMP]\n", pc->dumpfile);
> + else if (REMOTE_ACTIVE())
> fprintf(fp, "%s@%s (remote live system)\n",
> pc->server_memsrc, pc->server);
> else
> --- a/s390x.c
> +++ b/s390x.c
> @@ -328,6 +328,17 @@ static void s390x_process_elf_notes(void
> }
> }
>
> +static void s390x_check_live(void)
>j +{
> + unsigned long long live_magic;
> +
> + readmem(0, KVADDR, &live_magic, sizeof(live_magic),
> "live_magic",
> + RETURN_ON_ERROR | QUIET);
> +
> + if (live_magic == 0x4c49564544554d50ULL)
> + pc->flags |= LIVE_SYSTEM;
> +}
> +
> /*
> * Do all necessary machine-specific setup here. This is called
> several
> * times during initialization.
> @@ -402,6 +413,7 @@ s390x_init(int when)
> break;
>
> case POST_INIT:
> + s390x_check_live();
> break;
> }
> }
>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
