so the transition
> to using a mutex possibly is not such a big step any longer.
>
> To avoid creating problems with lock order, the code does not take
> new locks when the log mutex is held. This is visible in logwakeup()
> and logread(). It looks that selrecord() does not acquire
lock order, the code does not take
new locks when the log mutex is held. This is visible in logwakeup()
and logread(). It looks that selrecord() does not acquire new locks,
so no extra steps are needed in logpoll().
In logread(), the code assumes that there is only one reader. This keeps
the data
On Thu, Oct 20, 2016 at 09:26:16PM +0200, Mark Kettenis wrote:
> I don't think putting a lock in msgbuf_putchar us a good idea. We
> deliberately did not put a lock in kprintf() to make sure it can still
> be used when we're in ddb without hitting a deadlock. Instead we put
> the lock (kprintf_mu
> Date: Thu, 20 Oct 2016 15:42:32 +0200
> From: Alexander Bluhm
>
> Hi,
>
> A while ago I made kernel logging interrupt safe by adding a
> splhigh(). When we are going MP this is not sufficient, so replace
> it with a mutex. The idea is to hold the mutex every time msgbufp
> is dereferenced.
Hi,
A while ago I made kernel logging interrupt safe by adding a
splhigh(). When we are going MP this is not sufficient, so replace
it with a mutex. The idea is to hold the mutex every time msgbufp
is dereferenced. This allows to print to dmesg without kernel lock.
Note that we take the mutex
