Re: printk badness with VMAP_STACK

[Sergey Senozhatsky <sergey.senozhatsky@gmail.com>]

Hello,

thanks for Cc-ing.

On (10/27/16 11:19), Petr Mladek wrote:
[..]
> Yeah, logbuf_lock is taken on many locations but logbuf_cpu is set
> only in vprintk_emit(). It means that the other locations, including
> console_unlock() are not protected against this type of recursion.
> 
> There is actually a whole bunch of possible printk-related deadlocks.
> There are several approaches how to handle some of them, for example:
> 
>  + printk_save(), see
>    https://lkml.kernel.org/r/20161018154045.7364-1-sergey.senozhatsky@gmail.com
> 
>  + async printk, see
>    https://lkml.kernel.org/r/1459789048-1337-1-git-send-email-sergey.senozhatsky@gmail.com
> 
>  + early console, see
>    https://lkml.kernel.org/r/20161018170830.405990950@infradead.org
> 
> 
> The more we try to fix them, the more problems we see. Sergey probably
> has the best overview about it at the moment.

yep. I think I'll re-fresh my printk_safe patch set tonight. it will
conflict with Linus' pr_cont() rework, so I'll keep my patch set as a
RFC.


> We are going to discuss a possible progress on Plumbers next week.

yep. I'll prepare some PDF slides :)


I'm afraid due to the lack of experience/time/"anything else that is
crucially important" I have no idea at the moment if my KS tech-topic
proposal [1][2] has been approved or rejected (is KS schedule available
somewhere online already? I can't find it) and I absolutely forgot to
submit it as a LPC micro-conference as a back-up plan (hm, can people
actually do this?). so in the worst case (printk tech-topic is out of KS
schedule) we will have to find an empty room on our own (I'm available
*any* time). my apologies for any incontinence in advance.

[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-July/002740.html
[2] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-September/004006.html

	-ss