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 dave@sr71.net- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:40 EST