GitLab

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)