nullfs stabilization I

[Csaba Henk]

On 2006-01-11, Simon 'corecode' Schubert <corecode at xxxxxxxxxxxx> wrote:
> Matthew Dillon wrote:
>>     cache_lock would create the namecache record in the lower layer
>>     (recursively), and then operate in the same manner as if it exited in
>>     the first place.
>
> The problem in this case is that you just don't know which lower 
> namecache records to create.  I don't want to guess the name of the 
> lower layer from the name of the upper layer, because some filesystem 
> might want to remap filenames or files and directories.
>
> dumb idea, but think of a filesystem which sorts files alphabetically in 
> directories..., or a filesystem which maps filenames to ones which are 
> case-insensitive-safe (so that windows can access fOO and Foo, because 
> one is mapped to fo_o_ and one to f_oo...
>
> So at the very moment we do a lock action in the upper layer (i.e. every 
> time we do a cache_lookup()), we already have to have the association 
> ready.  Which means we need a callback into the vfs;  I just can't think 
> of something else.

So, that's what I've been meditating on recently.

Say we want our upper f_oo entry to shadow Foo which doens'nt yet exist.

As you suggest, the event chain is as follows, IIRC:

 * Userspace asks for f_oo (open("f_oo", O_CREAT | ...)).
 * f_oo namecache entry gets locked, but we also want to lock the lower one
   for the sake of coherency.
 * Alas, cache layer can't divine whom to lock down there, hence calls into
   the vfs to dig up that entry.
 ...

but why not:

 * Userspace asks for f_oo.
 * With f_oo namecache entry locked, our vfs is asked to resolve it;
   at this stage the the cache layer doesn't know of shadowing.
 * 
   a) The vfs does know that it wants to shadow Foo. Now if the vfs would start
   to resolve in the wild, then locking is not present in the lower layer and
   the bad guys can sneak in. So it performs a cache layer callback
   (cache_getshadow("Foo", ...) ?), which would inform the cache layer
   about the shadowing intent.
,-->
|  b) After returning from the callback, the vfs could do the resolution as it
|  feels like, happily ignorant of ncp locking issues as ever.
|
`* Under the hood the cache layer gets the post about shadowing intent.
   It locks down Foo, and ensures coherency before giving the control back to
   the vfs.
   ...

The usual, "core" part of the resolution would take place with all
relevant parties having their respective locks set up, since it would
happen in stage b). The difference from your scheme is that the callback would
go from the vfs to the cache layer, not from the cache layer to the vfs
(so then it would be a systemwide function, not just a locally
available/relevant method).

Do you think it would be feasible?

Csaba