1. 03 Sep, 2019 2 commits
  2. 31 Aug, 2019 9 commits
  3. 03 Aug, 2019 8 commits
  4. 11 Jul, 2019 2 commits
  5. 08 Jun, 2019 6 commits
  6. 07 Jun, 2019 4 commits
    • J. R. Okajima's avatar
      296aa84b
    • 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
  7. 28 May, 2019 5 commits
  8. 27 May, 2019 4 commits