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

[Oleg Nesterov]

On 04/26, Dave Anderson wrote:
>
>
> > 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.

Yes, yes, I see how it is used now. Damn, but now I also see that my changelog
looks very confusing!

"The usage of CRASHBUILTIN doesn't look nice" above means "The usage of CRASHBUILTIN
IN THIS PATCH doesn't look nice", and I even added the FIXME comment. Sorry for
confusion Dave.

> > 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.

Ah, yes.

> > 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().

Well, I still disagree, see the previous email... I still think we need some
generic macro.

> > 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.

Even if this module was loaded and /dev/crash existed before I start /bin/crash?

	# ll /dev/crash
	cr--r--r--. 1 root root 10, 57 Apr 26 12:33 /dev/crash
	# crash ../VMLINUX
	...
	 WARNING: ../VMLINUX and /proc/version do not match!

(just in case, this is correct)

	# ll /dev/crash
	ls: cannot access /dev/crash: No such file or directory

doesn't look friendly.

And I can't use /bin/crash without root even if I do "chmod a+r /dev/crash" on my
machine.

Is it all intentional?

Oleg.