Re: Log mutex for msgbuf concurrency control

, 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 acqu

Log mutex for msgbuf concurrency control

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 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

Re: log mutex

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

Re: log mutex

> 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

log mutex

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