kernel/git/stable/linux.git/fs/overlayfs, branch linux-4.13.y

ovl: do not cleanup unsupported index entries

2017-11-02T08:54:47+00:00

commit fa0096e3bad69ed6f34843fd7ae1c45ca987012a upstream. 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: 61b674710cd9 ("ovl: do not cleanup directory and whiteout index..") Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman

ovl: handle ENOENT on index lookup

2017-11-02T08:54:47+00:00

commit 7937a56fdf0b064c2ffa33025210f725a4ebc822 upstream. 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: 359f392ca53e ("ovl: lookup index entry for copy up origin") Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman

ovl: fix EIO from lookup of non-indexed upper

2017-11-02T08:54:47+00:00

commit 6eaf011144af10cad34c0d46f82e50d382c8e926 upstream. Commit fbaf94ee3cd5 ("ovl: don't set origin on broken lower hardlink") attempt to avoid the condition of non-indexed upper inode with lower hardlink as origin. If this condition is found, lookup returns EIO. The protection of commit mentioned above does not cover the case of lower that is not a hardlink when it is copied up (with either index=off/on) and then lower is hardlinked while overlay is offline. Changes to lower layer while overlayfs is offline should not result in unexpected behavior, so a permanent EIO error after creating a link in lower layer should not be considered as correct behavior. This fix replaces EIO error with success in cases where upper has origin but no index is found, or index is found that does not match upper inode. In those cases, lookup will not fail and the returned overlay inode will be hashed by upper inode instead of by lower origin inode. Fixes: 359f392ca53e ("ovl: lookup index entry for copy up origin") Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

ovl: add NULL check in ovl_alloc_inode

2017-11-02T08:54:46+00:00

commit b3885bd6edb41b91a0e3976469f72ae31bfb8d95 upstream. This was detected by fault injection test Signed-off-by: Hirofumi Nakagawa Fixes: 13cf199d0088 ("ovl: allocate an ovl_inode struct") Signed-off-by: Greg Kroah-Hartman

ovl: fix regression caused by exclusive upper/work dir protection

2017-10-12T09:56:16+00:00

commit 85fdee1eef1a9e48ad5716916677e0c5fbc781e3 upstream. Enforcing exclusive ownership on upper/work dirs caused a docker regression: https://github.com/moby/moby/issues/34672. Euan spotted the regression and pointed to the offending commit. Vivek has brought the regression to my attention and provided this reproducer: Terminal 1: mount -t overlay -o workdir=work,lowerdir=lower,upperdir=upper none merged/ Terminal 2: unshare -m Terminal 1: umount merged mount -t overlay -o workdir=work,lowerdir=lower,upperdir=upper none merged/ mount: /root/overlay-testing/merged: none already mounted or mount point busy To fix the regression, I replaced the error with an alarming warning. With index feature enabled, mount does fail, but logs a suggestion to override exclusive dir protection by disabling index. Note that index=off mount does take the inuse locks, so a concurrent index=off will issue the warning and a concurrent index=on mount will fail. Documentation was updated to reflect this change. Fixes: 2cac0c00a6cd ("ovl: get exclusive ownership on upper/work dirs") Reported-by: Euan Kemp Reported-by: Vivek Goyal Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

ovl: fix missing unlock_rename() in ovl_do_copy_up()

2017-10-12T09:56:15+00:00

commit 5820dc0888d302ac05f8b91ffdf7e4e53b4fbf53 upstream. Use the ovl_lock_rename_workdir() helper which requires unlock_rename() only on lock success. Fixes: ("fd210b7d67ee ovl: move copy up lock out") Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

ovl: fix dentry leak in ovl_indexdir_cleanup()

2017-10-12T09:56:15+00:00

commit dc7ab6773e8171e07f16fd0df0c5eea28c899503 upstream. index dentry was not released when breaking out of the loop due to index verification error. Fixes: 415543d5c64f ("ovl: cleanup bad and stale index entries on mount") Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

ovl: fix dput() of ERR_PTR in ovl_cleanup_index()

2017-10-12T09:56:15+00:00

commit 9f4ec904dbd4eb1a2db10d5e7dc16eae386fe64d upstream. Fixes: caf70cb2ba5d ("ovl: cleanup orphan index entries") Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

ovl: fix error value printed in ovl_lookup_index()

2017-10-12T09:56:15+00:00

commit e0082a0f04c432cb6d7128ef60d8e425e45ce025 upstream. Fixes: 359f392ca53e ("ovl: lookup index entry for copy up origin") Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman

ovl: fix false positive ESTALE on lookup

2017-09-20T06:27:48+00:00

commit 939ae4efd51c627da270af74ef069db5124cb5b0 upstream. Commit b9ac5c274b8c ("ovl: hash overlay non-dir inodes by copy up origin") verifies that the origin lower inode stored in the overlayfs inode matched the inode of a copy up origin dentry found by lookup. There is a false positive result in that check when lower fs does not support file handles and copy up origin cannot be followed by file handle at lookup time. The false negative happens when finding an overlay inode in cache on a copied up overlay dentry lookup. The overlay inode still 'remembers' the copy up origin inode, but the copy up origin dentry is not available for verification. Relax the check in case copy up origin dentry is not available. Fixes: b9ac5c274b8c ("ovl: hash overlay non-dir inodes by copy up...") Reported-by: Jordi Pujol Signed-off-by: Amir Goldstein Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman