[GIT PULL] overlayfs update for 4.15

[GIT PULL] overlayfs update for 4.15

[Miklos Szeredi]

Hi Linus,

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-linus

Report constant st_ino values across copy-up even if underlying layers are on
different filesystems, but using different st_dev values for each layer.
Ideally we'd report the same st_dev across the overlay, and it's possible to do
for filesystems that use only 32bits for st_ino by unifying the inum space.  It
would be nice if it wasn't a choice of 32 or 64, rather filesystems could report
their current maximum (that could change on resize, so it wouldn't be set in
stone).

There are also miscellaneus fixes and a cleanup of ovl_fill_super(), that was
long overdue.

Created a path_put_init() helper that clears out the pointers after putting the
ref.  I think this could be useful elsewhere, so added it to <linux/path.h>.

Thanks,
Miklos

---
Amir Goldstein (6):
      ovl: lockdep annotate of nested OVL_I(inode)->lock
      ovl: no direct iteration for dir with origin xattr
      ovl: move include of ovl_entry.h into overlayfs.h
      ovl: relax same fs constraint for constant st_ino
      ovl: update cache version of impure parent on rename
      ovl: remove unneeded arg from ovl_verify_origin()

Chandan Rajendra (3):
      ovl: re-structure overlay lower layers in-memory
      ovl: allocate anonymous devs for lowerdirs
      ovl: return anonymous st_dev for lower inodes

Miklos Szeredi (18):
      vfs: add path_put_init()
      ovl: use path_put_init() in error paths for ovl_fill_super()
      ovl: split out ovl_get_upperpath() from ovl_fill_super()
      ovl: split out ovl_get_workpath() from ovl_fill_super()
      ovl: split out ovl_get_lowerstack() from ovl_fill_super()
      ovl: split out ovl_get_upper() from ovl_fill_super()
      ovl: split out ovl_get_workdir() from ovl_fill_super()
      ovl: split out ovl_get_lower_layers() from ovl_fill_super()
      ovl: split out ovl_get_indexdir() from ovl_fill_super()
      ovl: grab reference to workbasedir early
      ovl: factor out ovl_free_fs() helper
      ovl: change order of setup in ovl_fill_super()
      ovl: reduce the number of arguments for ovl_workdir_create()
      ovl: move ovl_get_workdir() and ovl_get_lower_layers()
      ovl: clean up getting upper layer
      ovl: clean up workdir creation
      ovl: clean up getting lower layers
      ovl: rename ufs to ofs

Vivek Goyal (1):
      ovl: Put upperdentry if ovl_check_origin() fails

zhangyi (F) (2):
      ovl: simplify ovl_check_empty_and_clear()
      ovl: fix rmdir problem on non-merge dir with origin xattr

---
 fs/overlayfs/copy_up.c   |   8 +-
 fs/overlayfs/dir.c       |  25 +-
 fs/overlayfs/inode.c     |  63 ++++-
 fs/overlayfs/namei.c     |  59 ++--
 fs/overlayfs/overlayfs.h |  13 +-
 fs/overlayfs/ovl_entry.h |  14 +-
 fs/overlayfs/readdir.c   |  55 +++-
 fs/overlayfs/super.c     | 688 ++++++++++++++++++++++++++---------------------
 fs/overlayfs/util.c      |  21 +-
 include/linux/path.h     |   6 +
 10 files changed, 576 insertions(+), 376 deletions(-)

Re: [GIT PULL] overlayfs update for 4.15

[Linus Torvalds]

On Fri, Nov 17, 2017 at 7:13 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> Created a path_put_init() helper that clears out the pointers after putting the
> ref.  I think this could be useful elsewhere, so added it to <linux/path.h>.

Slight eww.

The problem with your helper is that we've seen gcc generate really
horrible code for things like that.

So when you do

     *path = (struct path) { };

we've seen gcc first create an local empty "struct path" on stack, and
then memcpy() it over the target. Which is _technically_ what that
code does, of course, but it's also excessively stupid.

So I suspect that would be better off as just

     memset(path, 0, sizeof(*path));

which then matches the code that you actually would expect gcc to generate.

I hope that "struct path" is small enough that gcc doesn't mess up,
and that odd code generation is probably specific to some gcc versions
anyway, but we've definitely seen this.

NOTE! The above pattern of assignment is very different from the
initialization pattern. Gcc generally does well on structure
initializers:

    struct xyz a = { .. };

generally generates reasonable code in ways that

    struct xyz a;
    ..
    a = (struct xyz) { ...};

sometimes doesn't.  I suspect it's mainly a "initializers are common,
unnamed temporary local structures are not" thing.

                  Linus