[Crash-utility] [RFC/PATCH] s390x: Add live dump detection

[Dave Anderson]

----- 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;
>  	}
>  }
>