On 15-Aug-2004 Robert Watson wrote:
>
> I recently resolved a kernel race reported by Martin Blapp in which a file
> descriptor had connect() called on it by one thread, and was
> simultaenously close()'d by another. The bug resulted in a kernel crash,
> which is certainly not the right response, and I'm working on a number of
> aspects of that problem. However, this also speaks to a race in user
> space. The socket in question was being connected to /var/run/log, so I
> believe it was made from the libc syslog code. A glance at
> src/lib/libc/gen/syslog.c suggests that things are indeed a bit
> un-threadsafe, especially in vsyslog(), where things get connected and
> disconnected a fair amount.
I don't see any repeated connecting and disconnecting in vsyslog
except under error conditions. Here's the relevant code, with my
commentary non-indented:
/* Get connected, output the message to the local logger. */
if (!opened)
openlog(LogTag, LogStat | LOG_NDELAY, 0);
connectlog();
Note that connectlog() is a no-op if we are already connected (the
expected case after the first call).
if (send(LogFile, tbuf, cnt, 0) >= 0)
return;
If the send succeeds (the normal case) we return here and don't
disconnect.
/*
* If the send() failed, the odds are syslogd was restarted.
* Make one (only) attempt to reconnect to /dev/log.
*/
disconnectlog();
connectlog();
if (send(LogFile, tbuf, cnt, 0) >= 0)
return;
The above is only to handle an unusual error case.
There is some thread-unsafeness here, but it doesn't look like it
would matter under normal conditions.
John