- 29 May, 2019 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 28 May, 2019 10 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
- 27 May, 2019 6 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
-
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)
-
- 23 May, 2019 2 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 19 May, 2019 5 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
This reverts commit 181d4988.
-
- 18 May, 2019 3 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Apr, 2019 5 commits
-
-
J. R. Okajima authored
-
J. R. Okajima authored
-
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>
-
- 10 Mar, 2019 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
- 09 Mar, 2019 7 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
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>
-
J. R. Okajima authored
Fuse doesn't want the callers to access the inode attributes without issuing stat, and it is not assured that they are valid after lookup or iget(). The inode attribute is critical for aufs, and aufs decided to call stat every time for fuse. Of course, it makes aufs slow. But when the branch fs is not fuse, stat is not called. Currently, only FUSE implements ->poll(), and aufs supports it. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Basically ramfs is limited for its size, and is not suitable for aufs RW branch. But people sometimes use it as RW branch without knowing it or with knowing it. This configuration is for those who knows what he is doing. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-