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: Tue, 12 Jul 2016 23:03:00 +0900 From: Sergey Senozhatsky <sergey.senozhatsky@...il.com> To: Petr Mladek <pmladek@...e.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Viresh Kumar <viresh.kumar@...aro.org>, Jan Kara <jack@...e.cz>, Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Tejun Heo <tj@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, vlevenetz@...sol.com, vaibhav.hiremath@...aro.org, alex.elder@...aro.org, johan@...nel.org, akpm@...ux-foundation.org, rostedt@...dmis.org Subject: Re: [Query] Preemption (hogging) of the work handler Hello, On (07/12/16 14:52), Petr Mladek wrote: [..] > > On (07/11/16 15:35), Viresh Kumar wrote: > > [..] > > > Sometimes, the platform doesn't come back after suspend. I have tried > > > enabling no-console-suspend and the last line it prints is: > > > > > > Disabling non-boot CPUs > > I guess that the printk() kthread is not longer scheduled when there > is only one CPU left. > > > > And nothing after that at all. We have to forcefully reboot the phone > > > after that. Moving the prints to they synchronous way (using > > > echo 1 > /sys/module/printk/parameters/synchronous), fixes that issue. > > > > hm... I'll take a look. > > We might try to explicitly flush the consoles in suspend_console(). > But I am not sure if we always want to do so because it might take > a while. Also it need not help if someone already owns the > console_sem. Note the console_unlock() calls the cond_resched() > when in safe context. Thanks, Petr. so, I'm looking at this thing now: : [ 12.874909] sched: RT throttling activated for rt_rq ffffffc0ac13fcd0 (cpu 0) : [ 12.874909] potential CPU hogs: : [ 12.874909] printk (292) so it's either cond_resched() does not reshed, keeping printk kthread active, which, however, upsets the sched and triggers throttling (umm, what); or we, somehow, have `console_may_schedule == 0' in this final console_unlock(), so cond_resched() never happens. I'm looking at mainline 3.10, tho. Viresh, can you verify if we can do cond_resched() from console_unlock() (console_may_schedule != 0) ? -ss > Well, we might do the best effort when no_console_suspend is enabled. > > > Best Regards, > Petr >
Powered by blists - more mailing lists