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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 8 Nov 2017 22:29:05 -0500 From: Steven Rostedt <rostedt@...dmis.org> To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Cc: Tejun Heo <tj@...nel.org>, Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, linux-mm@...ck.org, xiyou.wangcong@...il.com, dave.hansen@...el.com, hannes@...xchg.org, mgorman@...e.de, mhocko@...nel.org, pmladek@...e.com, sergey.senozhatsky@...il.com, vbabka@...e.cz Subject: Re: [PATCH v3] printk: Add console owner and waiter logic to load balance console writes On Thu, 9 Nov 2017 09:56:35 +0900 Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> wrote: > Hello Steven, > > On (11/08/17 09:29), Steven Rostedt wrote: > > On Wed, 8 Nov 2017 14:19:55 +0900 > > Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> wrote: > > > > > the change goes further. I did express some of my concerns during the KS, > > > I'll just bring them to the list. > > > > > > > > > we now always shift printing from a save - scheduleable - context to > > > a potentially unsafe one - atomic. by example: > > > > And vice versa. We are now likely to go from a unscheduleable context > > to a schedule one, where before, that didn't exist. > > the existence of "and vice versa" is kinda alarming, isn't it? it's sort > of "yes, we can break some things, but we also can improve some things." Not really. Because the heuristic is that what calls printk will do the printk. > > > And my approach, makes it more likely that the task doing the printk > > prints its own message, and less likely to print someone else's. > > > > > > > > CPU0 CPU1~CPU10 CPU11 > > > > > > console_lock() > > > > > > printk(); > > > > > > console_unlock() IRQ > > > set console_owner printk() > > > sees console_owner > > > set console_waiter > > > sees console_waiter > > > break > > > console_unlock() > > > ^^^^ lockup [?] > > > > How? > > oh, yes, the missing part - assume CPU1~CPU10 did 5000 printk() calls, > while console_sem was locked on CPU0. then we console_unlock() from CPU0 > and shortly after IRQ->printk() from CPU11 forcibly takes over, so now > we are in console_unlock() from atomic, printing some 5000 messages. I'd say remove those 5000 printks ;-) -- Steve
Powered by blists - more mailing lists