Re: [PATCH] remove BKL from drivers' release functions

[David C. Hansen]

Alexander Viro wrote:
 > ->release() is not serialized AT ALL.  It is serialized for given
 > struct file, but call open(2) twice and you've got two struct file
 > for the same device. close() both and you've got two calls of
 > ->release(), quite possibly - simultaneous.
OK, that clears some things up.  So, the file->fcount is only used in 
cases where the file descriptor was dup'd, right?

As Rick Lindsley pointed out to me:
 > In cases where we removed BKL from release() and left obvious locking
 > issues as "an exercise to the reader", we MAY have broken things
 > because the BKL (we now know) may have been serializing opens and
 > closes.
 > In cases where we replaced it with atomic locking or a spinlock, we've
 > done nothing but replace one lock with another (unless there are
 > subtleties

back to Alexander  Viro:
 > In other words, patch is completely bogus.
No, not completely.  In a lot of cases we just replaced some regular 
arithmetic with atomic instructions of some sort.  These changes are 
still completely valid.  But, in the cases where we added locking, we 
need to reevaluate them for potential problem.  In the cases where we 
just removed the BKL, we really need to check them to make sure that we 
didn't introduce anything.
Thanks for the feedback, Al!  This has been very helpful!

--
Dave Hansen
[e-mail]