----- Original Message ----- > 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 > > > 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? Yes. The whole /dev/crash driver bullshit was put in place because of CONFIG_STRICT_DEVMEM. So we pretty much had to work around it by creating the read-only /dev/crash driver. Anyway, in the original discussions, the security folks didn't want /dev/crash hanging around unless it was actively being used by a root-only live crash session. Later on it was decided that the driver should be built into the kernel. Please, just leave it be... ;-) Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
