Date: Sun, 15 Aug 2004 12:58:06 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: Robert Watson <rwatson@freebsd.org> Cc: threads@freebsd.org Subject: RE: thread-unsafe syslog code in libc? Message-ID: <XFMail.20040815125806.jdp@polstra.com> In-Reply-To: <Pine.NEB.3.96L.1040815125617.30898L-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20040815125806.jdp>