> 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.
