- 20 Dec, 2020 1 commit
-
-
J. R. Okajima authored
simply follows 8151b4c8bee43 2020-06-02 mm: add readahead address space operation Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 22 Jan, 2020 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)
-
- 07 Jun, 2019 2 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 4596850541ed7144f7fea951d02f0f6251c4a997)
-
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: Kirill Kolyshkin <kolyshkin@gmail.com> Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit b633d7b2635b9615fe294b85257d05008e3747a3)
-
- 09 Apr, 2019 1 commit
-
-
J. R. Okajima authored
With a little hope to make it easier to read. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Mar, 2019 2 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
As a result of branch management, the virtual inode may point a different real inode from it used to. And aufs has to maintain its address_space_operations, since its definition may affect the behaviour. I know some people (including grsec-patch) doesn't like a non-const address_space_operations, but in order to keep the consistency of the behaviour, the correct address_space_operations is important. See also the document in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-