Re: fatfs locking

Marcus Brinkmann <[email protected]> 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:

lock dir
look up name, record inode number N
unlock dir

  other thread now unlinks inode N, which then gets allocated as some
  new node

lock inode N: but whoops, that's the wrong inode!

So one must lock the looked-up node *before* unlocking the directory.
And this works, because directory trees must be a DAG (except for ..).

Now the alternative is to have the filesystem-specific implementation
of lookup do the right locking.  But it must do it, and it basically
has to do it the same way always.

Which means that the FATFS problem is *not* solved.  You can move the
requirement from diskfs to filesystem-specific code, but you can't
just move it to filesystem-specific code and then ignore it for FATFS.

> It occurs to me that without this change, if a directory in a ufs or ext2fs
> filesystem contains a link to itself by a name other than "..", then a
> lookup of that name will deadlock the directory node.  (That is probably an
> invalid state that fsck would fix, but still.)  Am I right about that?

Roland is right about this.  It is assumed entirely that ".." links
are the only back-pointers in the directory hierarchy.  This is why
link of directories is historically restricted to root, and the old
Unix manpages contain a mention of the potential deadlock between
competing back-pointing links.

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

Thomas