[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170116134328.GB23242@tigerII.localdomain>
Date: Mon, 16 Jan 2017 22:43:28 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc: Petr Mladek <pmladek@...e.com>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.cz>, linux-fbdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] printk: Correctly handle preemption in console_unlock()
On (01/16/17 22:26), Sergey Senozhatsky wrote:
> On (01/16/17 13:48), Petr Mladek wrote:
> [..]
> > The async printk code looks like this:
> >
> > vprintk_emit(...)
> > {
> >
> >
> > if (can_printk_async()) {
> > /* Offload printing to a schedulable context. */
> > printk_kthread_need_flush_console = true;
> > wake_up_process(printk_kthread);
> > } else {
> > /*
> > * Try to acquire and then immediately release the
> > * console semaphore. The release will print out
> > * buffers and wake up /dev/kmsg and syslog() users.
> > */
> > if (console_trylock())
> > console_unlock();
> > }
> >
> > So, there is still the console_trylock() for the sync mode. Or do I
> > see an outdated variant?
>
> no, it doesn't.
I meant that none of this is happening in vprintk_emit(). there is no
console_sem in vprintk_emit() at all. eveything is done in deferred printk.
-ss
Powered by blists - more mailing lists