13 Mar, 2020

2 commits

  • Lockdep reports "WARNING: lock held when returning to user space!" due to
    async write holding freeze lock over the write. Apparently aio.c already
    deals with this by lying to lockdep about the state of the lock.

    Do the same here. No need to check for S_IFREG() here since these file ops
    are regular-only.

    Reported-by: syzbot+9331a354f4f624a52a55@syzkaller.appspotmail.com
    Fixes: 2406a307ac7d ("ovl: implement async IO routines")
    Signed-off-by: Miklos Szeredi

    Miklos Szeredi
     
  • Fix up two bugs in the coversion to xino_mode:
    1. xino=off does not always end up in disabled mode
    2. xino=auto on 32bit arch should end up in disabled mode

    Take a proactive approach to disabling xino on 32bit kernel:
    1. Disable XINO_AUTO config during build time
    2. Disable xino with a warning on mount time

    As a by product, xino=on on 32bit arch also ends up in disabled mode.
    We never intended to enable xino on 32bit arch and this will make the
    rest of the logic simpler.

    Fixes: 0f831ec85eda ("ovl: simplify ovl_same_sb() helper")
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

12 Mar, 2020

1 commit

  • ovl_inode_lock() is interruptible. When inode_lock() in ovl_llseek()
    was replaced with ovl_inode_lock(), we did not add a check for error.

    Fix this by making ovl_inode_lock() uninterruptible and change the
    existing call sites to use an _interruptible variant.

    Reported-by: syzbot+66a9752fa927f745385e@syzkaller.appspotmail.com
    Fixes: b1f9d3858f72 ("ovl: use ovl_inode_lock in ovl_llseek()")
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

03 Feb, 2020

1 commit

  • ovl_lseek() is using ssize_t to return the value from vfs_llseek(). On a
    32-bit kernel ssize_t is a 32-bit signed int, which overflows above 2 GB.

    Assign the return value of vfs_llseek() to loff_t to fix this.

    Reported-by: Boris Gjenero
    Fixes: 9e46b840c705 ("ovl: support stacked SEEK_HOLE/SEEK_DATA")
    Cc: # v4.19
    Signed-off-by: Miklos Szeredi

    Miklos Szeredi
     

24 Jan, 2020

7 commits

  • Now overlayfs falls back to use default file splice read
    and write, which is not compatiple with overlayfs, returning
    EFAULT. xfstests generic/591 can reproduce part of this.

    Tested this patch with xfstests auto group tests.

    Signed-off-by: Murphy Zhou
    Signed-off-by: Miklos Szeredi

    Murphy Zhou
     
  • A performance regression was observed since linux v4.19 with aio test using
    fio with iodepth 128 on overlayfs. The queue depth of the device was
    always 1 which is unexpected.

    After investigation, it was found that commit 16914e6fc7e1 ("ovl: add
    ovl_read_iter()") and commit 2a92e07edc5e ("ovl: add ovl_write_iter()")
    resulted in vfs_iter_{read,write} being called on underlying filesystem,
    which always results in syncronous IO.

    Implement async IO for stacked reading and writing. This resolves the
    performance regresion.

    This is implemented by allocating a new kiocb for submitting the AIO
    request on the underlying filesystem. When the request is completed, the
    new kiocb is freed and the completion callback is called on the original
    iocb.

    Signed-off-by: Jiufei Xue
    Signed-off-by: Miklos Szeredi

    Jiufei Xue
     
  • The ovl_layer struct is never modified except at initialization.

    Signed-off-by: Miklos Szeredi

    Miklos Szeredi
     
  • On non-samefs overlay without xino, non pure upper inodes should use a
    pseudo_dev assigned to each unique lower fs, but if lower layer is on the
    same fs and upper layer, it has no pseudo_dev assigned.

    In this overlay layers setup:
    - two filesystems, A and B
    - upper layer is on A
    - lower layer 1 is also on A
    - lower layer 2 is on B

    Non pure upper overlay inode, whose origin is in layer 1 will have the
    st_dev;st_ino values of the real lower inode before copy up and the
    st_dev;st_ino values of the real upper inode after copy up.

    Fix this inconsitency by assigning a unique pseudo_dev also for upper fs,
    that will be used as st_dev value along with the lower inode st_dev for
    overlay inodes in the case above.

    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • This fixes ovl_lower_uuid_ok() to correctly detect the corner case:
    - two filesystems, A and B, both have null uuid
    - upper layer is on A
    - lower layer 1 is also on A
    - lower layer 2 is on B

    In this case, bad_uuid would not have been set for B, because the check
    only involved the list of lower fs. Hence we'll try to decode a layer 2
    origin on layer 1 and fail.

    We check for conflicting (and null) uuid among all lower layers, including
    those layers that are on the same fs as the upper layer.

    Reported-by: Miklos Szeredi
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • Rename lower_fs[] array to fs[], extend its size by one and use index fsid
    (instead of fsid-1) to access the fs[] array.

    Initialize fs[0] with upper fs values. fsid 0 is reserved even with lower
    only overlay, so fs[0] remains null in this case.

    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • No code uses the sb returned from this helper, so make it retrun a boolean
    and rename it to ovl_same_fs().

    The xino mode is irrelevant when all layers are on same fs, so instead of
    describing samefs with mode OVL_XINO_OFF, use a new xino_mode state, which
    is 0 in the case of samefs, -1 in the case of xino=off and > 0 with xino
    enabled.

    Create a new helper ovl_same_dev(), to use instead of the common check for
    (ovl_same_fs() || xinobits).

    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

23 Jan, 2020

5 commits

  • Rename lower_layers[] array to layers[], extend its size by one and
    initialize layers[0] with upper layer values. Lower layers are now
    addressed with index 1..numlower. layers[0] is reserved even with lower
    only overlay.

    [SzM: replace ofs->numlower with ofs->numlayer, the latter's value is
    incremented by one]

    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • Current copy-up is not efficient for big sparse file,
    It's not only slow but also wasting more disk space
    when the target lower file has huge hole inside.
    This patch tries to recognize file hole and skip it
    during copy-up.

    Detail logic of hole detection as below:
    When we detect next data position is larger than current
    position we will skip that hole, otherwise we copy
    data in the size of OVL_COPY_UP_CHUNK_SIZE. Actually,
    it may not recognize all kind of holes and sometimes
    only skips partial of hole area. However, it will be
    enough for most of the use cases.

    Additionally, this optimization relies on lseek(2)
    SEEK_DATA implementation, so for some specific
    filesystems which do not support this feature
    will behave as before on copy-up.

    Reviewed-by: Amir Goldstein
    Signed-off-by: Chengguang Xu
    Signed-off-by: Miklos Szeredi

    Chengguang Xu
     
  • In ovl_llseek() we use the overlay inode rwsem to protect against
    concurrent modifications to real file f_pos, because we copy the overlay
    file f_pos to/from the real file f_pos.

    This caused a lockdep warning of locking order violation when the
    ovl_llseek() operation was called on a lower nested overlay layer while the
    upper layer fs sb_writers is held (with patch improving copy-up efficiency
    for big sparse file).

    Use the internal ovl_inode_lock() instead of the overlay inode rwsem in
    those cases. It is meant to be used for protecting against concurrent
    changes to overlay inode internal state changes.

    The locking order rules are documented to explain this case.

    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • Use pr_fmt auto generate "overlayfs: " prefix.

    Signed-off-by: lijiazi
    Signed-off-by: Miklos Szeredi

    lijiazi
     
  • The WARN_ON() that child entry is always on overlay st_dev became wrong
    when we allowed this function to update d_ino in non-samefs setup with xino
    enabled.

    It is not true in case of xino bits overflow on a non-dir inode. Leave the
    WARN_ON() only for directories, where assertion is still true.

    Fixes: adbf4f7ea834 ("ovl: consistent d_ino for non-samefs with xino")
    Cc: # v4.17+
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

15 Dec, 2019

1 commit

  • Pull overlayfs fixes from Miklos Szeredi:
    "Fix some bugs and documentation"

    * tag 'ovl-fixes-5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
    docs: filesystems: overlayfs: Fix restview warnings
    docs: filesystems: overlayfs: Rename overlayfs.txt to .rst
    ovl: relax WARN_ON() on rename to self
    ovl: fix corner case of non-unique st_dev;st_ino
    ovl: don't use a temp buf for encoding real fh
    ovl: make sure that real fid is 32bit aligned in memory
    ovl: fix lookup failure on multi lower squashfs

    Linus Torvalds
     

10 Dec, 2019

5 commits

  • In ovl_rename(), if new upper is hardlinked to old upper underneath
    overlayfs before upper dirs are locked, user will get an ESTALE error
    and a WARN_ON will be printed.

    Changes to underlying layers while overlayfs is mounted may result in
    unexpected behavior, but it shouldn't crash the kernel and it shouldn't
    trigger WARN_ON() either, so relax this WARN_ON().

    Reported-by: syzbot+bb1836a212e69f8e201a@syzkaller.appspotmail.com
    Fixes: 804032fabb3b ("ovl: don't check rename to self")
    Cc: # v4.9+
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • On non-samefs overlay without xino, non pure upper inodes should use a
    pseudo_dev assigned to each unique lower fs and pure upper inodes use the
    real upper st_dev.

    It is fine for an overlay pure upper inode to use the same st_dev;st_ino
    values as the real upper inode, because the content of those two different
    filesystem objects is always the same.

    In this case, however:
    - two filesystems, A and B
    - upper layer is on A
    - lower layer 1 is also on A
    - lower layer 2 is on B

    Non pure upper overlay inode, whose origin is in layer 1 will have the same
    st_dev;st_ino values as the real lower inode. This may result with a false
    positive results of 'diff' between the real lower and copied up overlay
    inode.

    Fix this by using the upper st_dev;st_ino values in this case. This breaks
    the property of constant st_dev;st_ino across copy up of this case. This
    breakage will be fixed by a later patch.

    Fixes: 5148626b806a ("ovl: allocate anon bdev per unique lower fs")
    Cc: stable@vger.kernel.org # v4.17+
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • We can allocate maximum fh size and encode into it directly.

    Suggested-by: Al Viro
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • Seprate on-disk encoding from in-memory and on-wire resresentation
    of overlay file handle.

    In-memory and on-wire we only ever pass around pointers to struct
    ovl_fh, which encapsulates at offset 3 the on-disk format struct
    ovl_fb. struct ovl_fb encapsulates at offset 21 the real file handle.
    That makes sure that the real file handle is always 32bit aligned
    in-memory when passed down to the underlying filesystem.

    On-disk format remains the same and store/load are done into
    correctly aligned buffer.

    New nfs exported file handles are exported with aligned real fid.
    Old nfs file handles are copied to an aligned buffer before being
    decoded.

    Reported-by: Al Viro
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • In the past, overlayfs required that lower fs have non null uuid in
    order to support nfs export and decode copy up origin file handles.

    Commit 9df085f3c9a2 ("ovl: relax requirement for non null uuid of
    lower fs") relaxed this requirement for nfs export support, as long
    as uuid (even if null) is unique among all lower fs.

    However, said commit unintentionally also relaxed the non null uuid
    requirement for decoding copy up origin file handles, regardless of
    the unique uuid requirement.

    Amend this mistake by disabling decoding of copy up origin file handle
    from lower fs with a conflicting uuid.

    We still encode copy up origin file handles from those fs, because
    file handles like those already exist in the wild and because they
    might provide useful information in the future.

    There is an unhandled corner case described by Miklos this way:
    - two filesystems, A and B, both have null uuid
    - upper layer is on A
    - lower layer 1 is also on A
    - lower layer 2 is on B

    In this case bad_uuid won't be set for B, because the check only
    involves the list of lower fs. Hence we'll try to decode a layer 2
    origin on layer 1 and fail.

    We will deal with this corner case later.

    Reported-by: Colin Ian King
    Tested-by: Colin Ian King
    Link: https://lore.kernel.org/lkml/20191106234301.283006-1-colin.king@canonical.com/
    Fixes: 9df085f3c9a2 ("ovl: relax requirement for non null uuid ...")
    Cc: stable@vger.kernel.org # v4.20+
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

16 Nov, 2019

1 commit

  • Most of the callers of lookup_one_len_unlocked() treat negatives are
    ERR_PTR(-ENOENT). Provide a helper that would do just that. Note
    that a pinned positive dentry remains positive - it's ->d_inode is
    stable, etc.; a pinned _negative_ dentry can become positive at any
    point as long as you are not holding its parent at least shared.
    So using lookup_one_len_unlocked() needs to be careful;
    lookup_positive_unlocked() is safer and that's what the callers
    end up open-coding anyway.

    Signed-off-by: Al Viro

    Al Viro
     

11 Sep, 2019

2 commits

  • When filtering xattr list for reading, presence of trusted xattr
    results in a security audit log. However, if there is other content
    no errno will be set, and if there isn't, the errno will be -ENODATA
    and not -EPERM as is usually associated with a lack of capability.
    The check does not block the request to list the xattrs present.

    Switch to ns_capable_noaudit to reflect a more appropriate check.

    Signed-off-by: Mark Salyzyn
    Cc: linux-security-module@vger.kernel.org
    Cc: kernel-team@android.com
    Cc: stable@vger.kernel.org # v3.18+
    Fixes: a082c6f680da ("ovl: filter trusted xattr for non-admin")
    Signed-off-by: Miklos Szeredi

    Mark Salyzyn
     
  • if ovl_encode_real_fh() fails, no memory was allocated
    and the error in the error-valued pointer should be returned.

    Fixes: 9b6faee07470 ("ovl: check ERR_PTR() return value from ovl_encode_fh()")
    Signed-off-by: Ding Xiang
    Cc: # v4.16+
    Signed-off-by: Miklos Szeredi

    Ding Xiang
     

16 Jul, 2019

1 commit

  • Once upon a time, commit 2cac0c00a6cd ("ovl: get exclusive ownership on
    upper/work dirs") in v4.13 added some sanity checks on overlayfs layers.
    This change caused a docker regression. The root cause was mount leaks
    by docker, which as far as I know, still exist.

    To mitigate the regression, commit 85fdee1eef1a ("ovl: fix regression
    caused by exclusive upper/work dir protection") in v4.14 turned the
    mount errors into warnings for the default index=off configuration.

    Recently, commit 146d62e5a586 ("ovl: detect overlapping layers") in
    v5.2, re-introduced exclusive upper/work dir checks regardless of
    index=off configuration.

    This changes the status quo and mount leak related bug reports have
    started to re-surface. Restore the status quo to fix the regressions.
    To clarify, index=off does NOT relax overlapping layers check for this
    ovelayfs mount. index=off only relaxes exclusive upper/work dir checks
    with another overlayfs mount.

    To cover the part of overlapping layers detection that used the
    exclusive upper/work dir checks to detect overlap with self upper/work
    dir, add a trap also on the work base dir.

    Link: https://github.com/moby/moby/issues/34672
    Link: https://lore.kernel.org/linux-fsdevel/20171006121405.GA32700@veci.piliscsaba.szeredi.hu/
    Link: https://github.com/containers/libpod/issues/3540
    Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
    Cc: # v4.19+
    Signed-off-by: Amir Goldstein
    Tested-by: Colin Walters
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

22 Jun, 2019

1 commit

  • Pull still more SPDX updates from Greg KH:
    "Another round of SPDX updates for 5.2-rc6

    Here is what I am guessing is going to be the last "big" SPDX update
    for 5.2. It contains all of the remaining GPLv2 and GPLv2+ updates
    that were "easy" to determine by pattern matching. The ones after this
    are going to be a bit more difficult and the people on the spdx list
    will be discussing them on a case-by-case basis now.

    Another 5000+ files are fixed up, so our overall totals are:
    Files checked: 64545
    Files with SPDX: 45529

    Compared to the 5.1 kernel which was:
    Files checked: 63848
    Files with SPDX: 22576

    This is a huge improvement.

    Also, we deleted another 20000 lines of boilerplate license crud,
    always nice to see in a diffstat"

    * tag 'spdx-5.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx: (65 commits)
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 507
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 506
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 505
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 504
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 503
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 502
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 501
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 499
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 498
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 497
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 496
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 495
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 491
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 490
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 489
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 488
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 487
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 486
    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 485
    ...

    Linus Torvalds
     

19 Jun, 2019

2 commits

  • Based on 2 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation #

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 4122 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Enrico Weigelt
    Reviewed-by: Kate Stewart
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     
  • Relax the condition that overlayfs supports nfs export, to require
    that i_ino is consistent with st_ino/d_ino.

    It is enough to require that st_ino and d_ino are consistent.

    This fixes the failure of xfstest generic/504, due to mismatch of
    st_ino to inode number in the output of /proc/locks.

    Fixes: 12574a9f4c9c ("ovl: consistent i_ino for non-samefs with xino")
    Cc: # v4.19
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

18 Jun, 2019

3 commits

  • Change first argument to MODULE_PARM_DESC() calls, that each of them
    matched the actual module parameter name. The matching results in
    changing (the 'parm' section from) the output of `modinfo overlay` from:

    parm: ovl_check_copy_up:Obsolete; does nothing
    parm: redirect_max:ushort
    parm: ovl_redirect_max:Maximum length of absolute redirect xattr value
    parm: redirect_dir:bool
    parm: ovl_redirect_dir_def:Default to on or off for the redirect_dir feature
    parm: redirect_always_follow:bool
    parm: ovl_redirect_always_follow:Follow redirects even if redirect_dir feature is turned off
    parm: index:bool
    parm: ovl_index_def:Default to on or off for the inodes index feature
    parm: nfs_export:bool
    parm: ovl_nfs_export_def:Default to on or off for the NFS export feature
    parm: xino_auto:bool
    parm: ovl_xino_auto_def:Auto enable xino feature
    parm: metacopy:bool
    parm: ovl_metacopy_def:Default to on or off for the metadata only copy up feature

    into:

    parm: check_copy_up:Obsolete; does nothing
    parm: redirect_max:Maximum length of absolute redirect xattr value (ushort)
    parm: redirect_dir:Default to on or off for the redirect_dir feature (bool)
    parm: redirect_always_follow:Follow redirects even if redirect_dir feature is turned off (bool)
    parm: index:Default to on or off for the inodes index feature (bool)
    parm: nfs_export:Default to on or off for the NFS export feature (bool)
    parm: xino_auto:Auto enable xino feature (bool)
    parm: metacopy:Default to on or off for the metadata only copy up feature (bool)

    Signed-off-by: Nicolas Schier
    Signed-off-by: Miklos Szeredi

    Nicolas Schier
     
  • gcc gets a bit confused by the logic in ovl_setup_trap() and
    can't figure out whether the local 'trap' variable in the caller
    was initialized or not:

    fs/overlayfs/super.c: In function 'ovl_fill_super':
    fs/overlayfs/super.c:1333:4: error: 'trap' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    iput(trap);
    ^~~~~~~~~~
    fs/overlayfs/super.c:1312:17: note: 'trap' was declared here

    Reword slightly to make it easier for the compiler to understand.

    Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Miklos Szeredi

    Arnd Bergmann
     
  • NFS mounts can be disconnected from fs root. Don't fail the overlapping
    layer check because of this.

    The check is not authoritative anyway, since topology can change during or
    after the check.

    Reported-by: Antti Antinoja
    Signed-off-by: Miklos Szeredi
    Fixes: 146d62e5a586 ("ovl: detect overlapping layers")

    Miklos Szeredi
     

11 Jun, 2019

1 commit


29 May, 2019

1 commit

  • Overlapping overlay layers are not supported and can cause unexpected
    behavior, but overlayfs does not currently check or warn about these
    configurations.

    User is not supposed to specify the same directory for upper and
    lower dirs or for different lower layers and user is not supposed to
    specify directories that are descendants of each other for overlay
    layers, but that is exactly what this zysbot repro did:

    https://syzkaller.appspot.com/x/repro.syz?x=12c7a94f400000

    Moving layer root directories into other layers while overlayfs
    is mounted could also result in unexpected behavior.

    This commit places "traps" in the overlay inode hash table.
    Those traps are dummy overlay inodes that are hashed by the layers
    root inodes.

    On mount, the hash table trap entries are used to verify that overlay
    layers are not overlapping. While at it, we also verify that overlay
    layers are not overlapping with directories "in-use" by other overlay
    instances as upperdir/workdir.

    On lookup, the trap entries are used to verify that overlay layers
    root inodes have not been moved into other layers after mount.

    Some examples:

    $ ./run --ov --samefs -s
    ...
    ( mkdir -p base/upper/0/u base/upper/0/w base/lower lower upper mnt
    mount -o bind base/lower lower
    mount -o bind base/upper upper
    mount -t overlay none mnt ...
    -o lowerdir=lower,upperdir=upper/0/u,workdir=upper/0/w)

    $ umount mnt
    $ mount -t overlay none mnt ...
    -o lowerdir=base,upperdir=upper/0/u,workdir=upper/0/w

    [ 94.434900] overlayfs: overlapping upperdir path
    mount: mount overlay on mnt failed: Too many levels of symbolic links

    $ mount -t overlay none mnt ...
    -o lowerdir=upper/0/u,upperdir=upper/0/u,workdir=upper/0/w

    [ 151.350132] overlayfs: conflicting lowerdir path
    mount: none is already mounted or mnt busy

    $ mount -t overlay none mnt ...
    -o lowerdir=lower:lower/a,upperdir=upper/0/u,workdir=upper/0/w

    [ 201.205045] overlayfs: overlapping lowerdir path
    mount: mount overlay on mnt failed: Too many levels of symbolic links

    $ mount -t overlay none mnt ...
    -o lowerdir=lower,upperdir=upper/0/u,workdir=upper/0/w
    $ mv base/upper/0/ base/lower/
    $ find mnt/0
    mnt/0
    mnt/0/w
    find: 'mnt/0/w/work': Too many levels of symbolic links
    find: 'mnt/0/u': Too many levels of symbolic links

    Reported-by: syzbot+9c69c282adc4edd2b540@syzkaller.appspotmail.com
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

27 May, 2019

1 commit

  • They are the extended version of FS_IOC_FS[SG]ETFLAGS ioctls.
    xfs_io -c "chattr " uses the new ioctls for setting flags.

    This used to work in kernel pre v4.19, before stacked file ops
    introduced the ovl_ioctl whitelist.

    Reported-by: Dave Chinner
    Fixes: d1d04ef8572b ("ovl: stack file ops")
    Cc: # v4.19
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     

21 May, 2019

1 commit


15 May, 2019

1 commit


08 May, 2019

2 commits

  • This nasty little syzbot repro:
    https://syzkaller.appspot.com/x/repro.syz?x=12c7a94f400000

    Creates overlay mounts where the same directory is both in upper and lower
    layers. Simplified example:

    mkdir foo work
    mount -t overlay none foo -o"lowerdir=.,upperdir=foo,workdir=work"

    The repro runs several threads in parallel that attempt to chdir into foo
    and attempt to symlink/rename/exec/mkdir the file bar.

    The repro hits a WARN_ON() I placed in ovl_instantiate(), which suggests
    that an overlay inode already exists in cache and is hashed by the pointer
    of the real upper dentry that ovl_create_real() has just created. At the
    point of the WARN_ON(), for overlay dir inode lock is held and upper dir
    inode lock, so at first, I did not see how this was possible.

    On a closer look, I see that after ovl_create_real(), because of the
    overlapping upper and lower layers, a lookup by another thread can find the
    file foo/bar that was just created in upper layer, at overlay path
    foo/foo/bar and hash the an overlay inode with the new real dentry as lower
    dentry. This is possible because the overlay directory foo/foo is not
    locked and the upper dentry foo/bar is in dcache, so ovl_lookup() can find
    it without taking upper dir inode shared lock.

    Overlapping layers is considered a wrong setup which would result in
    unexpected behavior, but it shouldn't crash the kernel and it shouldn't
    trigger WARN_ON() either, so relax this WARN_ON() and leave a pr_warn()
    instead to cover all cases of failure to get an overlay inode.

    The error returned from failure to insert new inode to cache with
    inode_insert5() was changed to -EEXIST, to distinguish from the error
    -ENOMEM returned on failure to get/allocate inode with iget5_locked().

    Reported-by: syzbot+9c69c282adc4edd2b540@syzkaller.appspotmail.com
    Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly...")
    Signed-off-by: Amir Goldstein
    Signed-off-by: Miklos Szeredi

    Amir Goldstein
     
  • Pull misc dcache updates from Al Viro:
    "Most of this pile is putting name length into struct name_snapshot and
    making use of it.

    The beginning of this series ("ovl_lookup_real_one(): don't bother
    with strlen()") ought to have been split in two (separate switch of
    name_snapshot to struct qstr from overlayfs reaping the trivial
    benefits of that), but I wanted to avoid a rebase - by the time I'd
    spotted that it was (a) in -next and (b) close to 5.1-final ;-/"

    * 'work.dcache' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    audit_compare_dname_path(): switch to const struct qstr *
    audit_update_watch(): switch to const struct qstr *
    inotify_handle_event(): don't bother with strlen()
    fsnotify: switch send_to_group() and ->handle_event to const struct qstr *
    fsnotify(): switch to passing const struct qstr * for file_name
    switch fsnotify_move() to passing const struct qstr * for old_name
    ovl_lookup_real_one(): don't bother with strlen()
    sysv: bury the broken "quietly truncate the long filenames" logics
    nsfs: unobfuscate
    unexport d_alloc_pseudo()

    Linus Torvalds
     

06 May, 2019

1 commit

  • We found that it return success when we set IMMUTABLE_FL flag to a file in
    docker even though the docker didn't have the capability
    CAP_LINUX_IMMUTABLE.

    The commit d1d04ef8572b ("ovl: stack file ops") and dab5ca8fd9dd ("ovl: add
    lsattr/chattr support") implemented chattr operations on a regular overlay
    file. ovl_real_ioctl() overridden the current process's subjective
    credentials with ofs->creator_cred which have the capability
    CAP_LINUX_IMMUTABLE so that it will return success in
    vfs_ioctl()->cap_capable().

    Fix this by checking the capability before cred overridden. And here we
    only care about APPEND_FL and IMMUTABLE_FL, so get these information from
    inode.

    [SzM: move check and call to underlying fs inside inode locked region to
    prevent two such calls from racing with each other]

    Signed-off-by: Jiufei Xue
    Signed-off-by: Miklos Szeredi

    Jiufei Xue