lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 06 Dec 2020 23:14:56 +0106 From: John Ogness <john.ogness@...utronix.de> To: Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Petr Mladek <pmladek@...e.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Steven Rostedt <rostedt@...dmis.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org Subject: Re: recursion handling: Re: [PATCH next v2 3/3] printk: remove logbuf_lock, add syslog_lock On 2020-12-05, Sergey Senozhatsky <sergey.senozhatsky@...il.com> wrote: >> We should allow at least some level of recursion. Otherwise, we would >> not see warnings printed from vsprintf code. > > One level of recursion seems reasonable on one hand, but on the other > hand I also wonder if we can get useful info from recursion levels 2 > and higher. Would be great to maybe list possible scenarios. vsprintf() > still call re-enter printk() -- WARN_ONCE()-s in the code -- external > format specifiers handlers also can. Would we need to let two levels of > recursion printk->vsprintf->printk->???->printk or one is just enough? > > It also would make sense to add the lost messages counter to per-CPU > recursion counter struct, to count the number of times we bailout > of printk due to recursion limit. So that we'll at least have > "%d recursive printk messages lost" hints. We do not need such a counter to be per-cpu. A global atomic_long_t would suffice. Although I am not sure if that should be separate from the @fail member of the ringbuffer. > Overall... > I wonder where does the "limit printk recursion" come from? printk_safe > doesn't impose any strict limits (print_context is limited, but still) > and we've been running it for years now; have we ever seen any reports > of printk recursion overflows? The printk code is undergoing some major changes and we have already had bugs slip into the merge window. IMHO the additional code to track the recursion does not add significant complexity or runtime overhead. I would prefer to keep it until we are finished with this major rework. John Ogness
Powered by blists - more mailing lists