GitLab

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>