Re: Security issues with local filesystem caching

[David Howells <dhowells@redhat.com>]

Trond Myklebust <trond.myklebust@fys.uio.no> wrote:

> It is not as if we care about an extra context switch here,

Avoiding context switches aren't the main problem; avoiding serialisation is.

> and we really don't want to do that file i/o in the context of the rpciod
> process if we can avoid it.

We aren't doing file I/O in the context of the rpciod process, at least not to
the cache.  It's either done in the context of the process that issued the
read, write or pagefault.  keventd handles the copying of data from the backing
file pages to the netfs pages when we satisfy a read from the cache.

> It might be nice to be able to do those calls that only involve lookup+read
> in the context of the user's process in order to avoid the context switch
> when paging in data from the cache,

We do most of both in the user's process's context already.

The security problems come from the lookups, creates, xattr ops that we have to
do when acquiring a cookie.  All of these are done in the context of the
process that called iget5 for NFS.  We could farm them out to another process
to avoid the security, but that would then cause serialisation and context
switches.

> but writing to it both can and should be done as a write-behind process.
> 
> IOW: we should rather set up a separate workqueue to write data to disk,
> and just concentrate on working out a way to lookup and read data with
> no fsuid/fsgid changes and preferably a minimum of selinux magic.

Writing data to the cache is done by the pagecache at the moment.  I'd really
like to use direct I/O instead as that'd mean I wouldn't need shadow pages in
the page cache and I'd also be able to avoid the page-to-page copy I'm
currently doing.

David