GitLab

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

In aufs5.4, kmemleak reported several false positives in
fs/aufs/xino.c.  I don't know why, but it may be related to the
"delayed" kfree (by RCU).  So I simply replace it by direct kfree()
call.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 03836b8128073f92b4e4a1cb54f91d0d7c290d1f)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

# Conflicts:
#	Documentation/filesystems/aufs/design/01intro.txt
#	Documentation/filesystems/aufs/design/02struct.txt
#	Documentation/filesystems/aufs/design/03atomic_open.txt
#	Documentation/filesystems/aufs/design/03lookup.txt
#	Documentation/filesystems/aufs/design/04branch.txt
#	Documentation/filesystems/aufs/design/05wbr_policy.txt
#	Documentation/filesystems/aufs/design/06dirren.txt
#	Documentation/filesystems/aufs/design/06fhsm.txt
#	Documentation/filesystems/aufs/design/06mmap.txt
#	Documentation/filesystems/aufs/design/06xattr.txt
#	Documentation/filesystems/aufs/design/07export.txt
#	Documentation/filesystems/aufs/design/08shwh.txt
#	Documentation/filesystems/aufs/design/10dynop.txt
#	fs/aufs/aufs.h
#	fs/aufs/branch.c
#	fs/aufs/branch.h
#	fs/aufs/cpup.c
#	fs/aufs/cpup.h
#	fs/aufs/dbgaufs.c
#	fs/aufs/dbgaufs.h
#	fs/aufs/dcsub.c
#	fs/aufs/dcsub.h
#	fs/aufs/debug.c
#	fs/aufs/debug.h
#	fs/aufs/dentry.c
#	fs/aufs/dentry.h
#	fs/aufs/dinfo.c
#	fs/aufs/dir.c
#	fs/aufs/dir.h
#	fs/aufs/dirren.c
#	fs/aufs/dirren.h
#	fs/aufs/dynop.c
#	fs/aufs/dynop.h
#	fs/aufs/export.c
#	fs/aufs/f_op.c
#	fs/aufs/fhsm.c
#	fs/aufs/file.c
#	fs/aufs/file.h
#	fs/aufs/finfo.c
#	fs/aufs/fstype.h
#	fs/aufs/hbl.h
#	fs/aufs/hfsnotify.c
#	fs/aufs/hfsplus.c
#	fs/aufs/hnotify.c
#	fs/aufs/i_op.c
#	fs/aufs/i_op_add.c
#	fs/aufs/i_op_del.c
#	fs/aufs/i_op_ren.c
#	fs/aufs/iinfo.c
#	fs/aufs/inode.c
#	fs/aufs/inode.h
#	fs/aufs/ioctl.c
#	fs/aufs/lcnt.h
#	fs/aufs/loop.c
#	fs/aufs/loop.h
#	fs/aufs/module.c
#	fs/aufs/module.h
#	fs/aufs/mvdown.c
#	fs/aufs/opts.c
#	fs/aufs/opts.h
#	fs/aufs/plink.c
#	fs/aufs/poll.c
#	fs/aufs/posix_acl.c
#	fs/aufs/procfs.c
#	fs/aufs/rdu.c
#	fs/aufs/rwsem.h
#	fs/aufs/sbinfo.c
#	fs/aufs/super.c
#	fs/aufs/super.h
#	fs/aufs/sysaufs.c
#	fs/aufs/sysaufs.h
#	fs/aufs/sysfs.c
#	fs/aufs/sysrq.c
#	fs/aufs/vdir.c
#	fs/aufs/vfsub.c
#	fs/aufs/vfsub.h
#	fs/aufs/wbr_policy.c
#	fs/aufs/whout.c
#	fs/aufs/whout.h
#	fs/aufs/wkq.c
#	fs/aufs/wkq.h
#	fs/aufs/xattr.c
#	fs/aufs/xino.c
#	include/uapi/linux/aufs_type.h

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

# Conflicts:
#	include/uapi/linux/aufs_type.h

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 0f5f91bda77d0690c23732fd2592ae97c908a704)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 9e47f923ad8bf55c272fed3d3699fa5df14b6f72)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 7555811a8741218089016a6abed15a440baca476)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 75664fa01701d5f79e6cee87a800354df6e70f70)

These "+1" were left accidentally when refining the lookup routine.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 4177c438179671556de7312107c8aa766ea3d658)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 2c79658cfdc070c6fc4ea5ac3ef898f2b15fb2f3)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

When a branch filesystem doesn't cache ACL, aufs should not cache
either.  Until now aufs has never met such fs, but theoretically it
could happen.  Actually, in linux-v5.1-rc1, NFSv3 changed its behaviour
by the commit
	ded52fbe7020 2019-02-20 nfs: fix xfstest generic/099 failed on nfsv3
The commit ded52fbe7020 doesn't "forget" the previous acl though.
Doesn't it mean that the obsoleted acl is kept until NFS's attribute
cache is expired?  I don't know.  I've asked it on LKML, but got no
answer.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit e448daa00228186b869356fdef8d98d9f95caf53)

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>