1. 12 4月, 2018 9 次提交
    • A
      ovl: consistent i_ino for non-samefs with xino · 12574a9f
      Amir Goldstein 提交于
      When overlay layers are not all on the same fs, but all inode numbers
      of underlying fs do not use the high 'xino' bits, overlay st_ino values
      are constant and persistent.
      
      In that case, set i_ino value to the same value as st_ino for nfsd
      readdirplus validator.
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      12574a9f
    • M
      ovl: add WARN_ON() for non-dir redirect cases · 3a291774
      Miklos Szeredi 提交于
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      3a291774
    • V
      ovl: cleanup setting OVL_INDEX · 0471a9cd
      Vivek Goyal 提交于
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      0471a9cd
    • V
      ovl: set d->is_dir and d->opaque for last path element · 102b0d11
      Vivek Goyal 提交于
      Certain properties in ovl_lookup_data should be set only for the last
      element of the path. IOW, if we are calling ovl_lookup_single() for an
      absolute redirect, then d->is_dir and d->opaque do not make much sense
      for intermediate path elements. Instead set them only if dentry being
      lookup is last path element.
      
      As of now we do not seem to be making use of d->opaque if it is set for
      a path/dentry in lower. But just define the semantics so that future code
      can make use of this assumption.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      102b0d11
    • V
      ovl: Do not check for redirect if this is last layer · e9b77f90
      Vivek Goyal 提交于
      If we are looking in last layer, then there should not be any need to
      process redirect. redirect information is used only for lookup in next
      lower layer and there is no more lower layer to look into. So no need
      to process redirects.
      
      IOW, ignore redirects on lowest layer.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      e9b77f90
    • A
      ovl: do not try to reconnect a disconnected origin dentry · 8a22efa1
      Amir Goldstein 提交于
      On lookup of non directory, we try to decode the origin file handle
      stored in upper inode. The origin file handle is supposed to be decoded
      to a disconnected non-dir dentry, which is fine, because we only need
      the lower inode of a copy up origin.
      
      However, if the origin file handle somehow turns out to be a directory
      we pay the expensive cost of reconnecting the directory dentry, only to
      get a mismatch file type and drop the dentry.
      
      Optimize this case by explicitly opting out of reconnecting the dentry.
      Opting-out of reconnect is done by passing a NULL acceptable callback
      to exportfs_decode_fh().
      
      While the case described above is a strange corner case that does not
      really need to be optimized, the API added for this optimization will
      be used by a following patch to optimize a more common case of decoding
      an overlayfs file handle.
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      8a22efa1
    • A
      ovl: disambiguate ovl_encode_fh() · 5b2cccd3
      Amir Goldstein 提交于
      Rename ovl_encode_fh() to ovl_encode_real_fh() to differentiate from the
      exportfs function ovl_encode_inode_fh() and change the latter to
      ovl_encode_fh() to match the exportfs method name.
      
      Rename ovl_decode_fh() to ovl_decode_real_fh() for consistency.
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      5b2cccd3
    • A
      ovl: fix lookup with middle layer opaque dir and absolute path redirects · 3ec9b3fa
      Amir Goldstein 提交于
      As of now if we encounter an opaque dir while looking for a dentry, we set
      d->last=true. This means that there is no need to look further in any of
      the lower layers. This works fine as long as there are no redirets or
      relative redircts. But what if there is an absolute redirect on the
      children dentry of opaque directory. We still need to continue to look into
      next lower layer. This patch fixes it.
      
      Here is an example to demonstrate the issue. Say you have following setup.
      
      upper:  /redirect (redirect=/a/b/c)
      lower1: /a/[b]/c       ([b] is opaque) (c has absolute redirect=/a/b/d/)
      lower0: /a/b/d/foo
      
      Now "redirect" dir should merge with lower1:/a/b/c/ and lower0:/a/b/d.
      Note, despite the fact lower1:/a/[b] is opaque, we need to continue to look
      into lower0 because children c has an absolute redirect.
      
      Following is a reproducer.
      
      Watch me make foo disappear:
      
       $ mkdir lower middle upper work work2 merged
       $ mkdir lower/origin
       $ touch lower/origin/foo
       $ mount -t overlay none merged/ \
               -olowerdir=lower,upperdir=middle,workdir=work2
       $ mkdir merged/pure
       $ mv merged/origin merged/pure/redirect
       $ umount merged
       $ mount -t overlay none merged/ \
               -olowerdir=middle:lower,upperdir=upper,workdir=work
       $ mv merged/pure/redirect merged/redirect
      
      Now you see foo inside a twice redirected merged dir:
      
       $ ls merged/redirect
       foo
       $ umount merged
       $ mount -t overlay none merged/ \
               -olowerdir=middle:lower,upperdir=upper,workdir=work
      
      After mount cycle you don't see foo inside the same dir:
      
       $ ls merged/redirect
      
      During middle layer lookup, the opaqueness of middle/pure is left in
      the lookup state and then middle/pure/redirect is wrongly treated as
      opaque.
      
      Fixes: 02b69b28 ("ovl: lookup redirects")
      Cc: <stable@vger.kernel.org> #v4.10
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      3ec9b3fa
    • V
      ovl: Set d->last properly during lookup · 452061fd
      Vivek Goyal 提交于
      d->last signifies that this is the last layer we are looking into and there
      is no more. And that means this allows for some optimzation opportunities
      during lookup. For example, in ovl_lookup_single() we don't have to check
      for opaque xattr of a directory is this is the last layer we are looking
      into (d->last = true).
      
      But knowing for sure whether we are looking into last layer can be very
      tricky. If redirects are not enabled, then we can look at poe->numlower and
      figure out if the lookup we are about to is last layer or not. But if
      redircts are enabled then it is possible poe->numlower suggests that we are
      looking in last layer, but there is an absolute redirect present in found
      element and that redirects us to a layer in root and that means lookup will
      continue in lower layers further.
      
      For example, consider following.
      
      /upperdir/pure (opaque=y)
      /upperdir/pure/foo (opaque=y,redirect=/bar)
      /lowerdir/bar
      
      In this case pure is "pure upper". When we look for "foo", that time
      poe->numlower=0. But that alone does not mean that we will not search for a
      merge candidate in /lowerdir. Absolute redirect changes that.
      
      IOW, d->last should not be set just based on poe->numlower if redirects are
      enabled. That can lead to setting d->last while it should not have and that
      means we will not check for opaque xattr while we should have.
      
      So do this.
      
       - If redirects are not enabled, then continue to rely on poe->numlower
         information to determine if it is last layer or not.
      
       - If redirects are enabled, then set d->last = true only if this is the
         last layer in root ovl_entry (roe).
      Suggested-by: NAmir Goldstein <amir73il@gmail.com>
      Reviewed-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 02b69b28 ("ovl: lookup redirects")
      Cc: <stable@vger.kernel.org> #v4.10
      452061fd
  2. 26 2月, 2018 1 次提交
    • V
      ovl: redirect_dir=nofollow should not follow redirect for opaque lower · d1fe96c0
      Vivek Goyal 提交于
      redirect_dir=nofollow should not follow a redirect. But in a specific
      configuration it can still follow it.  For example try this.
      
      $ mkdir -p lower0 lower1/foo upper work merged
      $ touch lower1/foo/lower-file.txt
      $ setfattr -n "trusted.overlay.opaque" -v "y" lower1/foo
      $ mount -t overlay -o lowerdir=lower1:lower0,workdir=work,upperdir=upper,redirect_dir=on none merged
      $ cd merged
      $ mv foo foo-renamed
      $ umount merged
      
      # mount again. This time with redirect_dir=nofollow
      $ mount -t overlay -o lowerdir=lower1:lower0,workdir=work,upperdir=upper,redirect_dir=nofollow none merged
      $ ls merged/foo-renamed/
      # This lists lower-file.txt, while it should not have.
      
      Basically, we are doing redirect check after we check for d.stop. And
      if this is not last lower, and we find an opaque lower, d.stop will be
      set.
      
      ovl_lookup_single()
              if (!d->last && ovl_is_opaquedir(this)) {
                      d->stop = d->opaque = true;
                      goto out;
              }
      
      To fix this, first check redirect is allowed. And after that check if
      d.stop has been set or not.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Fixes: 438c84c2 ("ovl: don't follow redirects if redirect_dir=off")
      Cc: <stable@vger.kernel.org> #v4.15
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      d1fe96c0
  3. 05 2月, 2018 1 次提交
    • A
      ovl: fix regression in fsnotify of overlay merge dir · 2aed489d
      Amir Goldstein 提交于
      A re-factoring patch in NFS export series has passed the wrong argument
      to ovl_get_inode() causing a regression in the very recent fix to
      fsnotify of overlay merge dir.
      
      The regression has caused merge directory inodes to be hashed by upper
      instead of lower real inode, when NFS export and directory indexing is
      disabled. That caused an inotify watch to become obsolete after directory
      copy up and drop caches.
      
      LTP test inotify07 was improved to catch this regression.
      The regression also caused multiple redirect dirs to same origin not to
      be detected on lookup with NFS export disabled. An xfstest was added to
      cover this case.
      
      Fixes: 0aceb53e ("ovl: do not pass overlay dentry to ovl_get_inode()")
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      2aed489d
  4. 24 1月, 2018 19 次提交
  5. 20 1月, 2018 2 次提交
    • A
      ovl: fix another overlay: warning prefix · f8167817
      Amir Goldstein 提交于
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      f8167817
    • A
      ovl: take lower dir inode mutex outside upper sb_writers lock · 6d0a8a90
      Amir Goldstein 提交于
      The functions ovl_lower_positive() and ovl_check_empty_dir() both take
      inode mutex on the real lower dir under ovl_want_write() which takes
      the upper_mnt sb_writers lock.
      
      While this is not a clear locking order or layering violation, it creates
      an undesired lock dependency between two unrelated layers for no good
      reason.
      
      This lock dependency materializes to a false(?) positive lockdep warning
      when calling rmdir() on a nested overlayfs, where both nested and
      underlying overlayfs both use the same fs type as upper layer.
      
      rmdir() on the nested overlayfs creates the lock chain:
        sb_writers of upper_mnt (e.g. tmpfs) in ovl_do_remove()
        ovl_i_mutex_dir_key[] of lower overlay dir in ovl_lower_positive()
      
      rmdir() on the underlying overlayfs creates the lock chain in
      reverse order:
        ovl_i_mutex_dir_key[] of lower overlay dir in vfs_rmdir()
        sb_writers of nested upper_mnt (e.g. tmpfs) in ovl_do_remove()
      
      To rid of the unneeded locking dependency, move both ovl_lower_positive()
      and ovl_check_empty_dir() to before ovl_want_write() in rmdir() and
      rename() implementation.
      
      This change spreads the pieces of ovl_check_empty_and_clear() directly
      inside the rmdir()/rename() implementations so the helper is no longer
      needed and removed.
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      6d0a8a90
  6. 11 12月, 2017 2 次提交
  7. 10 11月, 2017 2 次提交
  8. 09 11月, 2017 2 次提交
    • C
      ovl: re-structure overlay lower layers in-memory · b9343632
      Chandan Rajendra 提交于
      Define new structures to represent overlay instance lower layers and
      overlay merge dir lower layers to make room for storing more per layer
      information in-memory.
      
      Instead of keeping the fs instance lower layers in an array of struct
      vfsmount, keep them in an array of new struct ovl_layer, that has a
      pointer to struct vfsmount.
      
      Instead of keeping the dentry lower layers in an array of struct path,
      keep them in an array of new struct ovl_path, that has a pointer to
      struct dentry and to struct ovl_layer.
      
      Add a small helper to find the fs layer id that correspopnds to a lower
      struct ovl_path and use it in ovl_lookup().
      
      [amir: split re-structure from anonymous bdev patch]
      Signed-off-by: NChandan Rajendra <chandan@linux.vnet.ibm.com>
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      b9343632
    • A
      ovl: move include of ovl_entry.h into overlayfs.h · ee023c30
      Amir Goldstein 提交于
      Most overlayfs c files already explicitly include ovl_entry.h
      to use overlay entry struct definitions and upcoming changes
      are going to require even more c files to include this header.
      
      All overlayfs c files include overlayfs.h and overlayfs.h itself
      refers to some structs defined in ovl_entry.h, so it seems more
      logic to include ovl_entry.h from overlayfs.h than from c files.
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      ee023c30
  9. 24 10月, 2017 2 次提交
    • A
      ovl: do not cleanup unsupported index entries · fa0096e3
      Amir Goldstein 提交于
      With index=on, ovl_indexdir_cleanup() tries to cleanup invalid index
      entries (e.g. bad index name). This behavior could result in cleaning of
      entries created by newer kernels and is therefore undesirable.
      Instead, abort mount if such entries are encountered. We still cleanup
      'stale' entries and 'orphan' entries, both those cases can be a result
      of offline changes to lower and upper dirs.
      
      When encoutering an index entry of type directory or whiteout, kernel
      was supposed to fallback to read-only mount, but the fill_super()
      operation returns EROFS in this case instead of returning success with
      read-only mount flag, so mount fails when encoutering directory or
      whiteout index entries. Bless this behavior by returning -EINVAL on
      directory and whiteout index entries as we do for all unsupported index
      entries.
      
      Fixes: 61b67471 ("ovl: do not cleanup directory and whiteout index..")
      Cc: <stable@vger.kernel.org> # v4.13
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      fa0096e3
    • A
      ovl: handle ENOENT on index lookup · 7937a56f
      Amir Goldstein 提交于
      Treat ENOENT from index entry lookup the same way as treating a returned
      negative dentry. Apparently, either could be returned if file is not
      found, depending on the underlying file system.
      
      Fixes: 359f392c ("ovl: lookup index entry for copy up origin")
      Cc: <stable@vger.kernel.org> # v4.13
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      7937a56f