[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201603062354.CHD52187.HMFVOJSFFOLtOQ@I-love.SAKURA.ne.jp>
Date: Sun, 6 Mar 2016 23:54:57 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: sergey.senozhatsky.work@...il.com
Cc: akpm@...ux-foundation.org, jack@...e.com, pmladek@...e.com,
tj@...nel.org, linux-kernel@...r.kernel.org,
sergey.senozhatsky@...il.com, jack@...e.cz
Subject: Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async
Sergey Senozhatsky wrote:
> such usage is quite possible.
>
> problems that I have with console_lock()/console_unlock() is that
> these functions serve a double purpose: exclusive printk() lock and a
> console_drivers list lock.
Yes, I don't like it too.
>
> **** I haven't really thought about it yet, but I want to split it. ****
>
Since writing to console does not call schedule(), I think
rcu_read_lock()/rcu_read_unlock()/synchronize_rcu() (or synchronize_rcu_*() ?)
can manage it without using
read_lock_console()/read_unlock_console()/write_lock_console()/write_unlock_console().
Replacing console_lock()/console_unlock() for protecting console_drivers list
with RCU might be helpful.
Powered by blists - more mailing lists