GitLab

Implement an internal list of opened files to allow deleting a branch
which has an opened dir. Obviously I don't like such list.

There was such list in linux as sb->s_files, but in linux-3.12 s_files
became containing just a part of the opened files, and in linux-3.13 it
was totally gone.
Aufs still needs the file list, particularly for re-setting the branch
attribute from RW to RO.
After resetting to RO, aufs should return EROFS for write. In order to
support such case, aufs keeps the late s_files and mark_files_ro()
approach.

See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Extend do_open_dir(), au_do_open_nondir() and au_do_open() to receive an
additional parameter h_file, which is an opened file object by branch
fs's ->atomic_open(). By this design/commit, aufs doesn't have to
duplicate many codes into a new aufs_atomic_open() (in later commit),
and can simply share them.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Implement several f_op functions for non-dir.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

For details, read the document in this commit.
I don't like this approach, but there is no other way currently. But it
seems that UnionMount is trying add siblings of f_dentry and d_inode for
linux-4.0 or later. It may become another light for aufs too.

The finfo object which has ever mmapped is excluded from
refreshing (based upon fi_mmapped). Otherwise we may corrupt the process
memory space.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

By default, aufs doesn't copy-up the file in open(2).
The file write operation is one of the trigger of the copy-up.
Although I understand that O_RDWR or O_WRONLY should trigger the
copy-up, it is not a good idea for the case of open(O_RDWR) +
mmap(MAP_PRIVATE). In this case, all changes are not written-back to the
file on disk, and the copy-up is meaningless entirely.
In other words, aufs postpone the copy-up as possible.

This design also applies to the file operation after branch management.
Some of the opened file need to be refreshed after add/del/mod
branches. Eg. detect the revealed same named one, open it, close the old
one internally while the virtual file is kept opened.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Implement f_op->open() for non-directory.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

As a part of branch-management, aufs maintains all cached inodes,
dentries, and opened files in remounting.
This commits handles the opened files by counting the number of them,
generating an array of their pointers. I don't like such array
approach, but I don't have another idea.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

This is the hardest test to support UDBA (users' direct branch access).
It uses 'fsnotify' internally.  Detecting UDBA, decrements the
generation of the cached aufs objects.  In the next access to the file,
aufs detects the generation is obsoleted and tries refreshing it.
Eventually aufs cache will be updated to latest status.

The fsnotify is set on the cached dirs on the non-RR branches.
The RR (real readonly) branches will never be modified and it is
unnecessary to set fsnotify for them.

This commit is for the declarations mainly, and the body parts will be
in succeeding commits.

This feature is compiled only when CONFIG_AUFS_HNOTIFY is enabled.
See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The main part is in previous commit.
This commit handles the generation of aufs objects, to make sure the
inode in the file handle is still valid.
In order not to confuse NFSD, the various operation returns ESTALE for
NFSD where it used to return EBUSY.

See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

As a result of branch management, the virtual inode may point a
different real inode from it used to. And aufs has to maintain its
address_space_operations, since its definition may affect the
behaviour.
I know some people (including grsec-patch) doesn't like a non-const
address_space_operations, but in order to keep the consistency of the
behaviour, the correct address_space_operations is important.

See also the document in this commit.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

The internal file read/write for copy-up in kernelspace.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>