Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Feb 2012 00:53:33 -0800
From:      Julian Elischer <julian@freebsd.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Eitan Adler <eadler@freebsd.org>
Subject:   Re: svn commit: r231814 - in head/sys: kern sys
Message-ID:  <4F3CC40D.4000307@freebsd.org>
In-Reply-To: <20120216181210.K1423@besplex.bde.org>
References:  <201202160511.q1G5BZNk099785@svn.freebsd.org> <20120216181210.K1423@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2/16/12 12:39 AM, Bruce Evans wrote:
> On Thu, 16 Feb 2012, Eitan Adler wrote:
>
>> Log:
>>  Add a timestamp to the msgbuf output in order to determine when when
>>  messages were printed.
>>
>>  This can be enabled with the kern.msgbuf_show_timestamp sysctl
>
> Apart from being fundamentally broken, this adds lots of bloat and
> style bugs.  The msgbuf is a very low-level interface, and was
> careful not to do stuff like this.  I'm still waiting for the previous
> round of breakage of it, that replaces careful atomic ops by spinlocks,
> to be backed out.  Code at this level cannot use any normal locking,
> and used to be carefully written to not do so.  The spinlocks break it,
> for example, if there is a trap while holding the lock and the trap
> handler wants to use the message buffer.  Interrupts are possible
> too, but they are disabled on the same CPU for technical reasons, so
> they cannot cause deadlock here.  The main possiblities for traps are
> NMIs.  The NMI handler shouldn't call printf, but perhaps it does.
> It might cause a panic.  Then panic can only print by blowing open
> the locks.  It might be a STOP IPI.  The stop function uses printf
> to diagnose other blockages, at least with certain options.  Anyway
> printf must never block endlessly, so msgbuf functions must not never
> block endlessly either, so neither can use any normal locking, since
> normal locking can easily block endlessly in deadlock conditions, by
> the definition of deadlock.

Bruce, this is a good example of a legitimate gripe going un-noticed 
because
you didn't shout loud enough at the right time, at the right people.
It's been about 20 years since we started working on this but I've finally
come to the point of saying that we need you to do more when you see 
problems.
object officially if you think things should be backed out!

your reasons here seem sound, so it's hard to see why you haven't been 
more
public about it.

Julian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3CC40D.4000307>