> Date: Tue, 19 Jun 2018 15:38:01 +0200
> From: Martin Pieuchot <m...@openbsd.org>
> 
> On 19/06/18(Tue) 14:55, Mark Kettenis wrote:
> > > To avoid races with another thread that might be clearing our pointer
> > > in `fd_ofiles', we need more than atomic operations.  For that we need
> > > to serialize the threads.  The most simple way to do so is with a mutex
> > > on a different data structure.  Either global, like in my diff, or as
> > > visa@ suggested in the corresponding `fdp'.
> > 
> > Right.  Another case of trying to take a reference without holding one
> > already.  The trick here is to use the fact that as long as there is a
> > file descriptor allocated for this open file the reference count is at
> > least 1.  So in that case taking a reference is safe.  Your global
> > mutex does indeed do the trick.  But why aren't you using the file
> > descriptor table rwlock for this purpose?  Is that because there is a
> > lock ordering problem between the kernel lock and that rwlock?
> 
> I have two reasons.  First I don't want to introduce new sleeping points,
> secondly I want this mutex to disappear.  IMHO extending the scope of a
> lock is going in the wrong direction because then we'll want to split it.
> That's why I'm happy that our discussion made visa@ look at improving this.

I wouldn't call this extending the scope of the lock.  But yes, it
might cause unnecessary sleeps if a write lock is held for the purpose
of opening a file.  The mutex that visa@ proposes trades that in for
potential contion in the multiple-readers case.

Reply via email to