Re: [RFC] atomic create+open

[Trond Myklebust <trond.myklebust@fys.uio.no>]

to den 06.10.2005 Klokka 20:49 (+0200) skreiv Miklos Szeredi:

> For simplicity case let's omit the creation of simlink, just say, the
> file is removed.
> 
> So NFS calls have_submounts(), which returns true.
> 
> Then the bind is umounted.  Nothing prevents this happening
> concurrently with the lookup.
> 
> Then the file is removed on the server.
> 
> When open_namei() gets around to following the mounts, it is not there
> any more, so the dentry for /mnt/foo (the NFS one is returned) and
> NFS's ->open is called on the file, which returns -ENOENT.  But
> open(..., O_CREAT, ...) should never return -ENOENT.

...and so the VFS can recognise the case, and be made to retry the
operation.
A more difficult race to deal with occurs if you allow a mount while
inside d_revalidate(). In that case NFS can end up opening the wrong
file.
Both these two races could, however, be fixed by moving the
__follow_mount() in open_namei() inside the section that is protected by
the parent directory i_sem.

In any case, all you are doing here is showing that the situation w.r.t.
mount races and lookup+create+open is difficult. I see nothing that
convinces me that a special atomic create+open will help to resolve
those races.
Nor do I see that adding a special atomic create+open will help me avoid
intents for the case of atomic lookup+open(). As far as I'm concerned,
the case of lookup+create+open is just a special case of lookup+open.

Cheers,
  Trond

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