coda's use of file->f_mapping and inode->i_mapping

coda's use of file->f_mapping and inode->i_mapping

[Jeff Layton]

I've been slowly crawling through filesystems to convert them to
errseq_t based error handling for ->fsync operations. I started looking
at coda, but it does some strange things with the f_mapping that I don't
quite understand.

When a file is opened on coda, we call down to userland daemon, which
opens the file and passes the fd back to the kernel. The kernel then
converts that to a struct file pointer and stores that in the
coda_file_info->cfi_container. So far, so good...

The weird bit is that in coda_file_mmap, we then do this:

        coda_file->f_mapping = host_file->f_mapping;
        if (coda_inode->i_mapping == &coda_inode->i_data)
                coda_inode->i_mapping = host_inode->i_mapping;


What is the significance of mmap on coda files? If you want to monkey
around with the i_mapping and f_mapping, wouldn't it make more sense to
do so at open() time?

-- 
Jeff Layton <jlayton@redhat.com>

Re: coda's use of file->f_mapping and inode->i_mapping

[Jan Harkes]

On Wed, Aug 02, 2017 at 11:05:31AM -0400, Jeff Layton wrote:
> The weird bit is that in coda_file_mmap, we then do this:
> 
>         coda_file->f_mapping = host_file->f_mapping;
>         if (coda_inode->i_mapping == &coda_inode->i_data)
>                 coda_inode->i_mapping = host_inode->i_mapping;
> 
> 
> What is the significance of mmap on coda files? If you want to monkey
> around with the i_mapping and f_mapping, wouldn't it make more sense to
> do so at open() time?

Normal read and write calls go through the Coda kernel module and are
passed along to the underlying 'host / container' file. However with
mmap you only get told that the mapping is created and the following
page faults are handled directly by following the file's
f_mapping/i_mapping pointer.  We don't need to set up this pointer if
the user never calls mmap.

It is possible that when different users open the same file object they
are given a different container file. Although Coda's userspace as far
as I know doesn't actually do this, this case was 'anticipated' as a
possibility.

By delaying the monkeying around to the point of mmap, open/read/write
for files works reliably and only if a second mmap is attempted where
the second coda_file handle for the same coda_inode happens to have a
different host_file associated with it do we return EBUSY.

Jan