1. 09 Mar, 2019 12 commits
    • J. R. Okajima's avatar
      aufs: ioctl, mvdown 2/2, callers · ca3bca20
      J. R. Okajima authored
      
      
      Support for the options of MVDOWN feature, which allows to overwrite the
      existing entry, and writing to the branch even if its permission is RO.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      ca3bca20
    • J. R. Okajima's avatar
      aufs: ioctl, wbr_fd · de0ee5c9
      J. R. Okajima authored
      
      
      Provide a file descriptor corresponding the specified writable branch.
      The file descriptor will be used from user-space such as FHSM and
      libau.so. For details, see aufs-util.git.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      de0ee5c9
    • J. R. Okajima's avatar
      aufs: branch management, delete 1/3, file list · b6f19f4f
      J. R. Okajima authored
      
      
      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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      b6f19f4f
    • J. R. Okajima's avatar
      aufs: atomic_open 3/5, pass h_file to au_do_open() · 51a7f431
      J. R. Okajima authored
      
      
      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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      51a7f431
    • J. R. Okajima's avatar
      aufs: file op · a3387b95
      J. R. Okajima authored
      
      
      Implement several f_op functions for non-dir.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      a3387b95
    • J. R. Okajima's avatar
      aufs: file op, mmap · 8d319094
      J. R. Okajima authored
      
      
      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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      8d319094
    • J. R. Okajima's avatar
      aufs: file op, internal re-open when write · beeeb01e
      J. R. Okajima authored
      
      
      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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      beeeb01e
    • J. R. Okajima's avatar
      aufs: file op, open non-dir · b5bd8ebf
      J. R. Okajima authored
      
      
      Implement f_op->open() for non-directory.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      b5bd8ebf
    • J. R. Okajima's avatar
      aufs: remount 3/5, refresh the opened files · 97be350d
      J. R. Okajima authored
      
      
      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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      97be350d
    • J. R. Okajima's avatar
      aufs: finfo for directory · 4dcf89d5
      J. R. Okajima authored
      
      
      Expand finfo to support for a directory.
      For readdir(3), see VDIR and RDU in later commits.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      4dcf89d5
    • J. R. Okajima's avatar
      aufs: DIO and dynamically customize address_space_operations · 5b336293
      J. R. Okajima authored
      
      
      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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      5b336293
    • J. R. Okajima's avatar
      aufs: copy-up 3/7, internal file I/O · e989fe7b
      J. R. Okajima authored
      
      
      The internal file read/write for copy-up in kernelspace.
      Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
      e989fe7b