headers
rick | 1 Jan 1998 23:38
Picon

NFS server cache bug

I have no idea if this race condition problem still lives in any of the
current source code trees, but I bumped into it when testing V4 and
thought I'd let you know.

The basic problem is that nfsrv_getcache() does either a malloc or
gets the lru entry (with a potential to sleep in both cases). While
sleeping, it is possible for a retried copy of the same request to
get into the cache, resulting in duplicates and potential problems
later. My code base is now quite different, but I think the following
fixes the problem.

Basically, move the malloc to the top, before the search loop and change
the "else" case to look for an unlocked entry without sleeping and fall
back on using the newly malloc'd one, avoiding any sleeps after the
search loop.

Here is a "diff -c" for the nfs_srvcache.c that was in OpenBSD 2.6.
(If the entire file is more useful, you can get it via anonymous
ftp to snowhite.cis.uoguelph.ca in pub/nfs/nfs_srvcache.c.fixed.)

In case you are wondering, the V4 server did ok at the recent bakeoff
(although it still is missing some capabilities and needs more work) and
the CITI folks at the Univ. of Michigan are working on the client.
(I'll be putting an updated tarball on the ftp site soon, but unless you
 are really keen, it might be better to wait until the code is merged
 with the Univ. of Michigan work.)

Good luck with it, rick
--- diff -c nfs_srvcache.c ---
*** nfs_srvcache.c.sav	Fri Aug  9 22:20:43 2002
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Mondor | 2 Jan 1998 03:11
Picon

Re: AF_LOCAL, SOCK_STREAM and poll(2)

On Wed, 14 Aug 2002 16:52:08 +0200 (CEST)
Jaromir Dolecek <jdolecek <at> netbsd.org> wrote:

> When the other side of socket disconnects, you are supposed to get
> POLLIN from poll, and then get zero length read() == EOF. Is this
> not good enough?

For that particular project I could hack around it, but I am quite
surprised that POLLHUP event was not generated, as the general BSD sockets
API was generally followed by the UNIX domain. Not being able to know the
current connection state of the socket using select() or poll() alone has
some disadventages, especially for general event handler loops, and
threaded applications.

Installing a SIGPIPE signal handler for the whole process is not ideal for
a user-threaded application... without violating the thread API that
is. I know that better threads are to come for NetBSD eventually though,
which I am quite happy about. I would hope that kqueue interface if/when
implemented will have a unified interface for those events, independantly
of the domain type.

I have been reading about the nathan-sa branch work, and scheduler
activations paper, and have incidentally wondered: wouldn't kqueue be
capable of handling some of the required callbacks?

Matt

> Matthew Mondor wrote:
> > 
> > I recently noticed something which may or may not be of interest,
(Continue reading)

Permalink | Reply | 1 comment |

Gmane