Hi Sergey,
On Fri, 15 May 2020 at 16:03, Sergey Senozhatsky
<sergey.senozhat...@gmail.com> wrote:
>
> On (20/05/15 10:50), Petr Mladek wrote:
> > kdb is able to stop kernel even in NMI context where printk() is redirected
> > to the printk_safe() lockless variant. Move the check and redirect to kdb
> > even in this case.
>
> Can I please have some context what problem does this solve?
You can find the problem description here [1] which leads to this fix.
> I can see that vkdb_printf() calls into console drivers:
>
> for_each_console(c) {
> c->write(c, cp, retlen - (cp - kdb_buffer));
> touch_nmi_watchdog();
> }
>
> Is this guaranteed that we never execute this path from NMI?
Yes the above code could run in NMI context but it will only run after
we stop the kernel (drop into debugger) and on a single CPU at a time.
AFAIK, we drop into the debugger either via sysrq or during
oops_in_progress. So I think it should be a lockless entry into the
console driver for write operations.
TBH, it's very much possible that I may miss some aspect. So please
feel free to correct me.
[1] https://lkml.org/lkml/2020/5/12/213
-Sumit
> If so, can this please be added to the commit message? A more
> detailed commit message will help a lot.
>
> -ss
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
