Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

"Steven J. Magnani" <steve@digidescorp.com> writes:

>> You mean the unhashed inode is created by ->get_parent()? If so, the
>> root cause sounds like ->get_parent() itself. If not, I'm not
>> understanding the meaning of the temporary/unofficial inode here.
>
> Maybe "private" is a better word than "unofficial". Private inodes are
> created anywhere fat_new_inode (nee fat_build_unhashed_inode) is called
> directly, instead of through fat_build_inode. So yes, this is on the
> get_parent paths (via fat_lookup_dir), and also on the fh_to_dentry path
> when inode reconstruction is necessary.
>
> With private inodes, I don't see how anyone but the code that created
> them could find them to lock them. The reason they're private is that
> they're temporary aliases; at the time they're created, we don't have
> enough information to register them in a way that others could find
> them. A lookup, etc. operation will look for the inode of the "drivers"
> directory, not the ".." of the "usb" directory. We do need these private
> inodes in order to walk directory entries. I don't think they're a
> problem that needs solving; if we didn't use private inodes, we'd still
> need a way to walk directory entries in the context of these NFS
> operations, and there would still be potential races between that and
> other operations on the filesystem.

How do you prevent to modify or free the those inode/blocks from other
path?  Yeah, it is racy. And if races is not solved, that's simply wrong
and not solution.

Although I'm not thinking deeply about NFS support on FAT. Just a idea,
the one of possible solutions would be register it to hash, and find it
on all path. So, all path will use same inode and lock.

We need the key, possible key is - if it is only directory, FAT may be
able to use i_start as additional search key.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>