thread-unsafe syslog code in libc?

[Robert Watson]

On Sun, 15 Aug 2004, John Polstra wrote:

> On 15-Aug-2004 Robert Watson wrote:
> > On Sun, 15 Aug 2004, John Polstra wrote:
> > 
> >> 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. 
> > 
> > So maybe we're dealing with a user space race where multiple threads
> > attempt to do a first syslog in parallel?
> 
> Probably not that.  You said it was a simultaneous connect() and
> close(), right?  The close is only done in disconnectlog() and
> closelog().  The former is only called in unusual error cases, and the
> latter is called by applications.  So I guess one culprit could be a
> first syslog call in one thread and a closelog call in another thread. 
> 
> Or, maybe the system ran out of mbufs and the send() did fail, causing
> disconnectlog to be used and exercising the race.  An out of mbufs
> condition might also contribute to the kernel panic you mentioned. 

The race in question was one where we failed to protect against namei() in
connect() possibly sleeping during a lookup and a close() on the file
descriptor during that period disconnecting the PCB from the socket.  When
connect() woke up again, it would try to dereference the PCB and cause a
page fault.  The problem is a larger issue concerning how we want to
handle file descriptors, etc, but it was triggered by odd use of a file
descriptor in user space that is also suggestive of a user space race.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research