Reconsidering exportable UBIFS

[NeilBrown]

On Mon, May 09 2016, Al Viro wrote:

> On Mon, May 09, 2016 at 08:18:22AM +1000, NeilBrown wrote:
>
>> Not puppies, just kittens.
>> 
>> If you don't provide these functions, then exporting with
>> "subtree_check" won't work.  That is no great loss except that people
>> might find the failure confusing.
>
> 	OK, a client sends you a RENAME.  With fhandles of both parents +
> old and new names in those.  Your task, should you choose to accept it, is
> to figure out whether we should fail with nfserr_inval due to an attempt
> to make a directory its own descendent.  Without being able to locate all
> ancestors of a directory.

You are right, sorry.  I was thinking that get_parent() was for finding
the parent of a non-directory, but it is for directories.  It does the
equivalent of lookup("..").  So if you have a ".." link or something
like it, it should be easy.  If you don't, it won't be easy at all.

Thanks,
NeilBrown


>
> 	You are fond of complaining about the checks that could've been left
> to server not getting skipped on the client.  Now you want to skip them on
> the server side as well?  Can't have it both ways...
>
> 	Seriously, it really doesn't work.  You can't do directory
> modifications without having found the chain of ancestors.  No ->get_parent()
> is OK _only_ for something like tmpfs, where we have the full chains of
> ancestors towards root all the time.  For UBIFS it's obviously not true.
> Not unless you suck the entire directory tree in memory at the mount time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20160509/ee959586/attachment-0001.sig>