GitLab

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)

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)

A compilation -Wimplicit-fallthrough warning was enabled by commit
a035d552a93b ("Makefile: Globally enable fall-through warning")
and triggers the following warning.

fs/aufs/opts.h:78:11:
warning: this statement may fall through [-Wimplicit-fallthrough=]

This patch adds comments according GNU manual.
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

Signed-off-by: He Zhe <zhe.he@windriver.com>
See-also: https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05685.html
(cherry picked from commit e7619996b014c5d8fd2f6ad89542c545a207667f)