On 13/01/2022 06:02, Petr Mladek wrote: > [...] > Is anyone really using this approach? kmsg_dump() looks like a better > choice when there are memory constrains. It does not need to reserve > memory for booting the crash kernel. > > I would not mind much but this change depends on a not fully reliable > assumption, see below. > > Also it will also complicate the solution for the kmsg_dump() code path. > It would be better to discuss this togeter with the other patch > https://lore.kernel.org/r/20220106212835.119409-1-gpiccoli@xxxxxxxxxx Hi Petr, thanks for your analysis here. Indeed, our use case benefits from both this and the other patch in the thread you mentioned above - see [0]. > [...] >> (b) We assume that the code path won't return from __crash_kexec() >> so we didn't guard against double execution of panic_print_sys_info(). > > This sounds suspiciously. There is small race window but it actually works. > __crash_kexec() really never returns when @kexec_crash_image is > loaded. Well, it might break in the future if the code is modified. > > Best Regards, > Petr OK, so since this patch is already on linux-next and is relevant for our use case, how about if we explicitly guard against the double print, as I suggested in [0]? Cheers, Guilherme [0] https://lore.kernel.org/lkml/ba0e29ba-0e08-df6e-ade5-eb58ae2495e3@xxxxxxxxxx/
