GitLab

This reverts commit 2012b764.

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

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>

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)