Re: fcntl(F_GETPATH) support

[Mateusz Guzik <mjguzik%gmail.com@localhost>]

On 9/15/19, Jason Thorpe <thorpej%me.com@localhost> wrote:
>
>
>> On Sep 15, 2019, at 11:03 AM, Christos Zoulas <christos%zoulas.com@localhost>
>> wrote:
>>
>> I think it is quite reliable because all the file descriptors would be
>> recently
>> opened and therefore be in the cache.  One would need to DoS the cache
>> cause eviction. If that turns out to be false, we can make the namecache
>> reliable, or withdraw it.
>
> If we had a way to ask the file system for the / a name+parent in the event
> we don't find an entry in the name cache, then we don't have to make the
> name cache "reliable".

See my other e-mail about turning realpath into a syscall. Then you have
everything to work with and the code should be trivial unless you want
to handle hardlinks. In the most simplistic implementation you do the
lookup and then do the reverse lookup of what you found. Things still
can get evicted in the time window in-between but that's probably
tolerable.

>
> FWIW, I don't think making the name cache "reliable" is necessarily a good
> idea -- it could be abused to consume kernel memory by creating lots of
> long-named files / directories.
>

I don't think it's a material change in terms of memory use. You can
already force this scenario by creating files and stating them.
Getting rid of namecache entries is not going to save you much compared
to all the vnodes which need to be dropped/recycled (which will also
remove the nc entries).

> In the event that the name really can't be determined (perhaps it's an
> open-unlinked file?), then I think it's perfectly reasonable to return
> ENOENT for F_GETPATH; callers need to be capable of handling that.
>

Corner case of the sort is probably not accounted for either and not
expected to be ran into -- if you remove the files from under the compiler
you are tampering with the build and it is free to fail.

On the other hand name eviction is not a problem you expect to run
into.

I can't easily test right now for sure, but historically BSDs have not
been adding newly created files to the namecache and perhaps
NetBSD is not doing it either. In which case F_GETPATH on newly
created files is guaranteed to fail unless someone looked them up
separately. Whether this should be modified is imho a separate
discussion, but is relevant to points made earlier about memory
use and DoSability. Imho it should be fine to change the kernel
to always add these.

-- 
Mateusz Guzik <mjguzik gmail.com>