GitLab

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)

This reverts commit 02e6255c.

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

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)

Add missing break statement for case Opt_wsum in au_opt_simple.
Signed-off-by: He Zhe <zhe.he@windriver.com>
See-also: https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05684.html
(cherry picked from commit 9e7d29356ab57fa5db7e92e51267176e50c1497c)

Simply follows the commit in mainline,
	622445541b75 2019-07-29 kbuild: detect missing "WITH
		Linux-syscall-note" for uapi headers
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

By the commit,
	387e3746d01c 2019-06-19 locks: eliminate false positive
		conflicts for write lease
inode->i_readcount becomes common to CONFIG_IMA and CONFIG_FILE_LOCKING.
In aufs branch management, eg. re-setting the branch attribute RW to RO,
aufs has to maintain i_readcount too.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>

By the commit,
	c71fd893f614 2019-06-17 locking/rwsem: Make owner available even
		if !CONFIG_RWSEM_SPIN_ON_OWNER
rwsem->owner is always defined regardless CONFIG_RWSEM_SPIN_ON_OWNER.
Aufs simply follows it.

This is detected by the commit in v5.3-rc1,
	d6fc9fcbaa65 2019-07-08 kbuild: compile-test exported headers to
		ensure they are self-contained
But the issue is not for v5.3-rc1 only I am afraid.  So this commit is
brought to aufs4.14 which is my current development base.
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit d38615f7fef1c65e30e3cc418daa9e19c93ed98f)

This reverts commit 2012b764.

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

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

The scenario is very similar to previous commit
"aufs: bugfix, ignore the being freed dynop object".
One exception is that this commit is for sbinfo object which is managed
by kobject (instead of kref).

In order to enter the plink-maintenance mode, users write an ID to
"/proc/fs/aufs/plink_maint" (this path is defined as macros in
include/uapi/linux/aufs_type.h).  If someone else is unmounting the
aufs mount corresponding that ID, then the searcher task may find a
being freed sbinfo object.
The problem and the fix is very similar to previous commit
"aufs: bugfix, ignore the being freed dynop object".
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 949b498ae30797b19b9e7ac9b230815f31ffe378)

Aufs DYNOP (Dynamically customizable FS operations) object is managed by
kref, and when its counter reaches zero, the callback function removes
the object from the internal list which is protected by a spinlock and
then frees the object.
Here there is a small time window between
A: the counter reaches zero, and
B: require the lock to remove the object from the list.
If someone else acquires the lock and searches the list, it may find the
counter-zero'ed object which means the object is being freed.
This commit ignores the object whose counter is already zero.
Reported-and-tested-by: Kirill Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit b633d7b2635b9615fe294b85257d05008e3747a3)

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

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