linux-kernel - Re: [PATCH v10 1/2] printk: Make printk() completely async

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:	Thu, 7 Apr 2016 21:08:26 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Jan Kara <jack@...e.com>, Petr Mladek <pmladek@...e.com>,
	Tejun Heo <tj@...nel.org>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	linux-kernel@...r.kernel.org,
	Byungchul Park <byungchul.park@....com>
Subject: Re: [PATCH v10 1/2] printk: Make printk() completely async

Hello,

On (04/07/16 18:48), Sergey Senozhatsky wrote:
> On (04/06/16 10:27), Jan Kara wrote:
> [..]
> > > Well, it's good that we have this.
> > > 
> > > It would be better if it was runtime-controllable - changing boot
> > > parameters is a bit of a pain.  In fact with this approach, your
> > > zillions-of-scsi-disks scenario becomes less problematic: do the async
> > > offloading during the boot process then switch back to the more
> > > reliable sync printing late in boot.
> > 
> > Doing this should be relatively easy. It would be userspace's decision
> > whether they want more reliable or faster printk. Sounds fine with me.

ok, after some thinking -- it makes a lot of sense to have it. good old
sync printk is potentially more reliable after all. I think I also now
want to meke the 'default' for printk_sync being 'true'. so we won't
spoil printk on the systems that never had any problems with it. at
least for one release cycle, may be. thus, people would need to request
async printk via boot param and switch back to sync printk once the booting
process is done [or keep async printk].

how does that sound?

	-ss

> > > This gets normal scheduling policy, so a spinning userspace SCHED_FIFO
> > > task will block printk for ever.  This seems bad.
> > 
> > I have to research this a bit but won't the SCHED_FIFO task that has
> > potentially unbounded amount of work lockup the CPU even though it does
> > occasional cond_resched()?
> 
> depending on `watchdog_thresh' value, it can take something like 20+
> seconds before watchdog will notice softlockup.
> so I'm setting printk kthread prio to `MAX_RT_PRIO - 1' as of now,
> just in case.
> 
> I think I'll leave printk kthread init as a late_initcall. probably
> would prefer core/arch/device init calls to happen in sync printk mode.