Skip to content

GitLab

Switch branch/tag
  1. 16 Jan, 2020 5 commits
  3. 06 Jan, 2020 1 commit
  5. 31 Dec, 2019 3 commits
  7. 18 Dec, 2019 4 commits
  9. 16 Dec, 2019 1 commit
  11. 15 Dec, 2019 3 commits
  13. 02 Dec, 2019 4 commits
  15. 09 Oct, 2019 2 commits
  17. 08 Oct, 2019 2 commits
    • J. R. Okajima's avatar
      Merge branch 'aufs5.0/00base' into aufs5.1/00base · da54e0b3
      J. R. Okajima authored
      da54e0b3
    • J. R. Okajima's avatar
      aufs: possible bugfix, uncached acl · a8614c2e
      J. R. Okajima authored 
      

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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit e448daa00228186b869356fdef8d98d9f95caf53)
      a8614c2e
  19. 03 Sep, 2019 1 commit
  21. 31 Aug, 2019 4 commits
  23. 03 Aug, 2019 3 commits
  25. 11 Jul, 2019 1 commit
  27. 08 Jun, 2019 2 commits
  29. 07 Jun, 2019 3 commits
    • J. R. Okajima's avatar
      aufs: bugfix, no nested RCU for kfree() · 0e79e96a
      J. R. Okajima authored 
      
Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 4596850541ed7144f7fea951d02f0f6251c4a997)
      0e79e96a
    • J. R. Okajima's avatar
      aufs: possible bugfix, ignore the being freed sbinfo object · 01a1817a
      J. R. Okajima authored 
      

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: default avatarJ. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit 949b498ae30797b19b9e7ac9b230815f31ffe378)
      01a1817a
    • J. R. Okajima's avatar
      aufs: bugfix, ignore the being freed dynop object · e870e818
      J. R. Okajima authored 
      

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: default avatarKirill Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: default avatarJ. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit b633d7b2635b9615fe294b85257d05008e3747a3)
      e870e818
  31. 28 May, 2019 1 commit