- 13 May, 2020 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
SELinux's d_instantiate hook calls __vfs_getxattr() BEFORE d_inode is set. Aufs should not rely upon d_inode and should use the parameter inode instead. Reported-by: "jon bird" <news@onasticksoftware.co.uk> Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 5777718fd657e1cfdf006cd16b524c65cf2fe09b)
-
- 20 Apr, 2020 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
In linux v5.7-rc2, zero-length array declarations are replaced by FAM (flexible-array member), a2008395fe2e 2020-04-18 dirent.h: Replace zero-length array with flexible-array member Aufs simply follows this trend. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 747a01ec1835988fa20177789a6fb65c5198fcb9)
-
- 29 Feb, 2020 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
In aufs5.4, kmemleak reported several false positives in fs/aufs/xino.c. I don't know why, but it may be related to the "delayed" kfree (by RCU). So I simply replace it by direct kfree() call. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 03836b8128073f92b4e4a1cb54f91d0d7c290d1f)
-
- 22 Jan, 2020 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)
-
- 16 Jan, 2020 3 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> # Conflicts: # include/uapi/linux/aufs_type.h
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 0f5f91bda77d0690c23732fd2592ae97c908a704)
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 9e47f923ad8bf55c272fed3d3699fa5df14b6f72)
-
- 31 Dec, 2019 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 7555811a8741218089016a6abed15a440baca476)
-
- 18 Dec, 2019 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 75664fa01701d5f79e6cee87a800354df6e70f70)
-
- 15 Dec, 2019 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
These "+1" were left accidentally when refining the lookup routine. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 4177c438179671556de7312107c8aa766ea3d658)
-
- 02 Dec, 2019 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 2c79658cfdc070c6fc4ea5ac3ef898f2b15fb2f3)
-
- 08 Oct, 2019 2 commits
-
-
J. R. Okajima authored
-
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: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit e448daa00228186b869356fdef8d98d9f95caf53)
-
- 31 Aug, 2019 3 commits
-
-
J. R. Okajima authored
-
He Zhe authored
A compilation -Wimplicit-fallthrough warning was enabled by commit a035d552a93b ("Makefile: Globally enable fall-through warning") and triggers the following warning. fs/aufs/opts.h:78:11: warning: this statement may fall through [-Wimplicit-fallthrough=] This patch adds comments according GNU manual. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options Signed-off-by: He Zhe <zhe.he@windriver.com> See-also: https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05685.html (cherry picked from commit e7619996b014c5d8fd2f6ad89542c545a207667f)
-
He Zhe authored
Add missing break statement for case Opt_wsum in au_opt_simple. Signed-off-by: He Zhe <zhe.he@windriver.com> See-also: https://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg05684.html (cherry picked from commit 9e7d29356ab57fa5db7e92e51267176e50c1497c)
-
- 03 Aug, 2019 2 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
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)
-
- 08 Jun, 2019 1 commit
-
-
J. R. Okajima authored
-
- 07 Jun, 2019 3 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 4596850541ed7144f7fea951d02f0f6251c4a997)
-
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: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 949b498ae30797b19b9e7ac9b230815f31ffe378)
-
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)
-
- 27 May, 2019 4 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 9dbd45984201453ecebcc03a91699878aa38239d)
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 94c692425480664a02aaac3d6f7d496ea1d05c1f)
-
J. R. Okajima authored
At the mount-time, XINO files are created and removed very soon. When multiple mounts with being given the same XINO file path executed in parallel, some of them may fail in creating XINO due to EEXIST. Introducing a local mutex, make it serialized. By default, XINO is created at the top dir of the first writable branch. In this case, the new mutex won't be used. Obviously this is an unnecessary overhead when the XINO file path is not same, and such lock should be done by inode_lock() for the parent dir. Actually au_xino_create2() behaves in this manner. Then why didn't I apply the same way to this au_xino_create()? It is just because of my laziness. Calling VFS filp_open() here is easy for me. Reported-by: Kirill Kolyshkin <kolyshkin@gmail.com> Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 30d9273f2a1ce331b1a79b770bdb4c493919a673)
-
- 18 May, 2019 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Apr, 2019 3 commits
-
-
J. R. Okajima authored
With a little hope to make it easier to read. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
In mainline, by the commit e220140ff624 2019-02-06 fsnotify: remove dirent events from FS_EVENTS_POSS_ON_CHILD mask the macro is redefined, and aufs simply follows it. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
In mainline, by the commit 71368af9027f 2019-01-29 x86/speculation: Add PR_SPEC_DISABLE_NOEXEC a new flag is introduced. And aufs simply follows it. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Mar, 2019 2 commits
-
-
J. R. Okajima authored
Although I am not sure module_exit is necessary for the statically linked module, here is it. I hope it does no harm. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
They are historical options and a branch attribute. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-