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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 12 Jul 2016 17:59:18 +0200
From:	Petr Mladek <pmladek@...e.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jan Kara <jack@...e.com>, Tejun Heo <tj@...nel.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Byungchul Park <byungchul.park@....com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH v12 0/3] printk: Make printk() completely async

On Mon 2016-07-11 12:25:11, Viresh Kumar wrote:
> On Fri, May 13, 2016 at 6:18 AM, Sergey Senozhatsky
> <sergey.senozhatsky@...il.com> wrote:
> > Hello,
> >
> > no code changes, just refreshing the series so it'll be easier to
> > pick up. added Reviwed-by-s and corrected a typo spotted by Petr.
> >
> > This patch permits to change printk() to operate in completely
> > asynchronous mode: new messages are getting upended to the kernel
> > printk buffer, but instead of 'direct' printing the actual print
> > job is performed by a dedicated kthread. This has the advantage
> > that printing always happens from a schedulable context and thus
> > we don't lockup any particular CPU or even interrupts.
> >
> > against next-20160513
> >
> >
> > v12:
> > -- rename printk_kthread_can_run bool flag
> > -- update printk_kthread_can_run comment (Petr)
> > -- drop mutex from printk_sync_set(), sysfs writes are synchronised (Petr)
> 
> We were also screwed because of the problem this thread is trying to solve,
> which I posted last week [1].
> 
> And then I found this thread which fixed my issue, thanks a lot guys :)
> 
> Tested-by: Viresh Kumar <viresh.kumar@...aro.org>
> 
> Though, I would also like to mention one unwanted thing that happened on
> my setup :)
> 
> [   12.874909] sched: RT throttling activated for rt_rq ffffffc0ac13fcd0 (cpu 0)
> [   12.874909] potential CPU hogs:
> [   12.874909]  printk (292)
> 
> On my system, the excessive printing happens during suspend/resume and this
> happened after all the non-boot CPUs were offlined. So, only CPU 0 was left and
> that was doing printing for a long time and so these errors :)
> 
> It resulted in missing some print messages eventually as the scheduler probably
> didn't schedule this thread for sometime after that.
> 
> Will it be fine to get the priority of this kthread to a somewhat lower value,
> etc ?

I think that this patch helped only by chance. It causes that any
message without a new line will force printk to the sync mode.
Then it will print even the buffered messages immediately. It
causes printk to behave more or less in the sync mode all the time.

I am still scratching my head about the problem fixed by this patch
and also about suspend problems.

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ