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: Fri, 30 Jun 2017 19:18:36 +0900 From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> To: sergey.senozhatsky.work@...il.com, pmladek@...e.com Cc: sergey.senozhatsky@...il.com, rostedt@...dmis.org, jack@...e.cz, akpm@...ux-foundation.org, peterz@...radead.org, rjw@...ysocki.net, ebiederm@...ssion.com, gregkh@...uxfoundation.org, jslaby@...e.com, pavel@....cz, andi@...as.de, linux-kernel@...r.kernel.org Subject: Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread Sergey Senozhatsky wrote: > if (!alloc_cpumask_var(&cpus_allowed, GFP_KERNEL)) { > wake_up_process(printk_kthread); > return true; > } Please avoid memory allocations when trying to print something. __GFP_DIRECT_RECLAIM allocations (e.g. GFP_KERNEL) can sleep for unpredictable duration. Allocations without __GFP_NOWARN will cause e.g. memory allocation failure messages. Even with __GFP_NOWARN, some messages might be still printed (e.g. serious problem). > I'm still thinking about Steven's proposals; but we will need offloading > anyways, so the bits we are talking about here are important regardless > the direction printk design will take, I think. Is there a chance that printk() waits for only data queued by that printk() call (exception will be printk() from NMI). If we carry penalty for printk() (charge delay according to amount of data queued by that printk()), users will stop doing stupid flooding with printk() based on an assumption that offloaded kernel thread will manage magically with guarantee of being printed out (i.e. users has to become careful).
Powered by blists - more mailing lists