RE: [PATCH v2 1/1] Simplify the generation of man pages
-Original Message- > Use `sed` to simplify the man pages generation. Keep the .in files > intact during make and generate the actual man pages with sed. > Additionally package tools already gz the man pages during install so it > doesn't really need to do that during make and it breaks reproducibility > of the package due to timestamps on files. > > Motivation: https://reproducible-builds.org > > Signed-off-by: Leonidas Spyropoulos Thank you for the good improvement! Applied with adding the man files to .gitignore: https://github.com/makedumpfile/makedumpfile/commit/2169de66ecd4504a3e69e0be0330f492f966ce5e (and thank you Guilherme for your review and test.) Kazu ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/3] makedumpfile: harden parsing of old prink buffer
On Mon, Mar 7, 2022 at 12:23 PM Philipp Rudo wrote: > > Hi, > > dumping the dmesg can cause an endless loop for the old prink mechanism (> > v3.5.0 and < v5.10.0) when the log_buf got corrupted. This series fixes those > cases by adding a cycle detection. The cycle detection is implemented in a > generic way so that it can be reused in other parts of makedumpfile. > > Thanks > Philipp > > Philipp Rudo (3): > makedumpfile: add generic cycle detection > makedumpfile: use pointer arithmetics for dump_dmesg > makedumpfile: use cycle detection when parsing the prink log_buf > > Makefile | 2 +- > detect_cycle.c | 99 ++ > detect_cycle.h | 40 > makedumpfile.c | 65 + > 4 files changed, 190 insertions(+), 16 deletions(-) > create mode 100644 detect_cycle.c > create mode 100644 detect_cycle.h > > -- > 2.35.1 > You can add Tested-by: Dave Wysochanski As I mentioned in the Red Hat bug, for my testing, I ran over 1,000 vmcores as a test set comparing "makedumpfile --dump-dmesg" output and saw no difference. Then I ran the one vmcore we found the loop on, and with these patches the loop was correctly detected and makedumpfile terminated rather than running forever. I'm still reviewing code a bit and may have a few minor bits of feedback in a few days. However, I don't offhand see anything that sticks out as wrong so far the code looks good. Thanks for doing this patchset. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V4] notifier/panic: Introduce panic_notifier_filter
On 08/03/2022 09:54, Petr Mladek wrote: > [...] > Honestly, I am not that keen about enforcing the priorities. > > It would make sense only when the ordering is really important. > Then there should be some rules. It should be obvious why > something has to be done earlier than something else. > > From my POV, it is just another complexity. Someone will need to > assign the priority to the existing notifiers. People will wonder > about it for newly added notifiers. > > Reproducibility seems to be the only motivation. Is it really a > problem? Do the notifiers affect each other? > > Also the notifiers are typically registered by some early boot > code. It will define some ordering out of box. > > Best Regards, > Petr OK Petr, makes sense. I feel that one the pros of the approach would be to document all the notifiers in the header, but I guess nothing prevents me to do that heh I don't need enforcing the priorities for this. I liked the idea of having everything "reproducible" as you said, but we could face the problem of how to order some independent notifiers... would be something "ad-hoc". I'll progress here without priorities for now, if somebody see an advantage for that, we can use it. Thanks for your points, Guilherme ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V4] notifier/panic: Introduce panic_notifier_filter
On Mon 2022-03-07 11:25:30, Guilherme G. Piccoli wrote: > On 07/03/2022 11:04, b...@redhat.com wrote: > > [...] > > Ah, sorry, I even didn't notice that. That's awesome if we can make use > > of that. While I still have concerns: > > > > Thanks, nice that you liked the idea. > > > 1) about those we have decided to take out from panic notifier list and > > put before kdump, e.g the Hypver-V notifier, how will we do with it? Are > > we going to handle them as we have discussed? > > > > While implementing that I will think of something, but if > understood/remember correctly Hyper-V gonna be one of the first to run > in the first notifier list proposed by Petr - so we might still use > ordering by priority there, having Hyper-V being the first heh My understanding is that the problem is not a priority but an ordering against other operations. Namely, Hyper-V must be called even before crash dump. Some others before kmsg_dump(). And the rest only when the crash dump is not called at all. > > 2) Combing and settling priority for all existing panic notifier looks > > great, even though it will take some effort. How about the later newly > > added one? How can we guarantee that those new notifiers are getting > > appropriate priority to mark their order? Sometime we even don't know > > a new panic notifier is added since code change may be made in any > > component or driver. > > > > This is a great point! How to do it? One idea is to have a special > registering function for panic notifiers that checks for priority field > missing, and good documentation is a good idea as well, always. > > But if you / others have other suggestions, let me know - appreciate that. > Cheers, Honestly, I am not that keen about enforcing the priorities. It would make sense only when the ordering is really important. Then there should be some rules. It should be obvious why something has to be done earlier than something else. >From my POV, it is just another complexity. Someone will need to assign the priority to the existing notifiers. People will wonder about it for newly added notifiers. Reproducibility seems to be the only motivation. Is it really a problem? Do the notifiers affect each other? Also the notifiers are typically registered by some early boot code. It will define some ordering out of box. Best Regards, Petr ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
