Re: fatfs locking

[Marcus Brinkmann]

At 29 Feb 2004 15:03:49 -0800,
Thomas Bushnell, BSG wrote:
> 
> Marcus Brinkmann <address@hidden> writes:
> 
> > The bonus question is if you also agree to do away with the .. special
> > case in name cache, leaving it to the filesystems to deal with it.
> > However, the answer to the above two questions should not depend on
> > the answer to the bonus question.
> 
> Diskfs should implement the normal thing for disk-based filesystems.
> The key thing that makes diskfs need to understand directory locking
> while netfs does not, is that diskfs is responsible for actually
> *rewriting* directories and allocating nodes, and netfs is not.
> 
> So what you have to show me is exactly how the race conditions I
> mention are going to be avoided without diskfs being guaranteed
> something about how the locks are managed.  The race is:

I am not suggesting that anything about the existing locking order or
locking strategy is changed.  The original problem which needs to be
solved is that the diskfs_cached_lookup callback can be called with
the directory node being locked and without it being locked, and the
filesystem has no way to know which of the two cases it has to deal
with at any time it is called.

This is a problem for fatfs, because unlike other filesystems, it
_always_ must lock the directory.  It will not release any locks held
by diskfs.  It just adds another lock: It will always lock the
directory, even if diskfs doesn't feel a need to do so.  However, it
can not do this unconditionally, because then it would deadlock (the
locks are not recursive, and you rejected recursive ways before, with
a good reason).

So, this is the main issue, and I don't feel that you have addressed
it at all.

> > > I will think about how to make fatfs work, but I don't think this kind
> > > of "solution" is at all right.
> 
> I stand by this.  The issue is *not* "who does the lock", but rather,
> how do you implement FATFS right?  That is, before changing the
> interface, tell me exactly when you think FAT should lock and what it
> should lock and when.  

Nobody talks about taking the lock in a different place from where it
is taken now.  We just want to _know_ that diskfs took the lock, so we
don't try to take it as well, resulting in a dead lock.

Now, what I just said might not be true for the .. case and Roland's
suggestion.  But as I said, this is a complete side issue.  The main
issue is that fatfs needs to lock the dir node, always, and under all
circumstances, and must know if diskfs also locked it already because
of its own requirements (as you described them).

In both types of callbacks, reading inodes from disk and writing
inodes to disk, fatfs must lock the directory.  In all those cases it
needs to know if diskfs already locked it by itself, to make some
guarantees about locking, and when it didn't do so.  In this latter
case, fatfs needs to do it itself because it has stricter requirements
than diskfs.

So, the answer to your question how to implement FATFS is, that FATFS
will always lock the dir node if it isn't locked already.  All other
filesystems do nothing differently from now.  Is that any clearer?

Thanks,
Marcus