2019-05-19 13:08:20 +01:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2010-06-30 21:34:01 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
2020-07-27 10:16:09 -04:00
|
|
|
|
2026-02-10 09:06:26 +00:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2012-07-30 16:23:22 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2022-01-10 18:28:33 -05:00
|
|
|
|
|
|
|
|
|
2025-09-25 12:45:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-16 10:05:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2018-05-28 18:37:40 +01:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2021-10-05 11:12:58 -04:00
|
|
|
|
2017-08-16 10:19:27 -04:00
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2017-08-16 10:19:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2018-05-28 18:37:40 +01:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-24 16:43:49 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2013-02-22 15:31:00 -08:00
|
|
|
|
2018-01-31 10:53:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2022-06-24 16:43:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2010-06-01 12:51:12 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2017-10-23 10:58:40 -04:00
|
|
|
|
2021-10-05 11:12:58 -04:00
|
|
|
|
2018-05-28 18:37:40 +01:00
|
|
|
|
2021-10-05 11:12:58 -04:00
|
|
|
|
|
|
|
|
|
2018-05-28 18:37:40 +01:00
|
|
|
|
|
|
|
|
|
2021-10-05 11:12:58 -04:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-30 09:38:13 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-07-30 09:38:13 -07:00
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2024-07-29 16:04:11 +08:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-07-30 09:38:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-04 08:03:44 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-02-01 14:57:15 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 11:25:38 +08:00
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-15 07:43:54 -06:00
|
|
|
|
2012-01-10 09:12:55 -08:00
|
|
|
|
2011-01-21 16:44:03 -08:00
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
2015-04-27 15:33:28 +08:00
|
|
|
|
2016-11-10 16:02:06 +08:00
|
|
|
|
2014-02-16 10:05:29 -08:00
|
|
|
|
2018-01-31 10:53:13 +00:00
|
|
|
|
2018-10-15 16:46:00 +01:00
|
|
|
|
ceph: perform asynchronous unlink if we have sufficient caps
The MDS is getting a new lock-caching facility that will allow it
to cache the necessary locks to allow asynchronous directory operations.
Since the CEPH_CAP_FILE_* caps are currently unused on directories,
we can repurpose those bits for this purpose.
When performing an unlink, if we have Fx on the parent directory,
and CEPH_CAP_DIR_UNLINK (aka Fr), and we know that the dentry being
removed is the primary link, then then we can fire off an unlink
request immediately and don't need to wait on reply before returning.
In that situation, just fix up the dcache and link count and return
immediately after issuing the call to the MDS. This does mean that we
need to hold an extra reference to the inode being unlinked, and extra
references to the caps to avoid races. Those references are put and
error handling is done in the r_callback routine.
If the operation ends up failing, then set a writeback error on the
directory inode, and the inode itself that can be fetched later by
an fsync on the dir.
The behavior of dir caps is slightly different from caps on normal
files. Because these are just considered an optimization, if the
session is reconnected, we will not automatically reclaim them. They
are instead considered lost until we do another synchronous op in the
parent directory.
Async dirops are enabled via the "nowsync" mount option, which is
patterned after the xfs "wsync" mount option. For now, the default
is "wsync", but eventually we may flip that.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-04-02 15:35:56 -04:00
|
|
|
|
2021-11-30 14:12:13 -05:00
|
|
|
|
2022-02-26 06:33:03 -05:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-12-16 13:33:32 -05:00
|
|
|
|
2019-09-06 22:12:08 -04:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-07 07:23:15 -04:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-17 20:03:59 -05:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
|
|
|
|
|
2019-09-06 22:12:08 -04:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
ceph: perform asynchronous unlink if we have sufficient caps
The MDS is getting a new lock-caching facility that will allow it
to cache the necessary locks to allow asynchronous directory operations.
Since the CEPH_CAP_FILE_* caps are currently unused on directories,
we can repurpose those bits for this purpose.
When performing an unlink, if we have Fx on the parent directory,
and CEPH_CAP_DIR_UNLINK (aka Fr), and we know that the dentry being
removed is the primary link, then then we can fire off an unlink
request immediately and don't need to wait on reply before returning.
In that situation, just fix up the dcache and link count and return
immediately after issuing the call to the MDS. This does mean that we
need to hold an extra reference to the inode being unlinked, and extra
references to the caps to avoid races. Those references are put and
error handling is done in the r_callback routine.
If the operation ends up failing, then set a writeback error on the
directory inode, and the inode itself that can be fetched later by
an fsync on the dir.
The behavior of dir caps is slightly different from caps on normal
files. Because these are just considered an optimization, if the
session is reconnected, we will not automatically reclaim them. They
are instead considered lost until we do another synchronous op in the
parent directory.
Async dirops are enabled via the "nowsync" mount option, which is
patterned after the xfs "wsync" mount option. For now, the default
is "wsync", but eventually we may flip that.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-04-02 15:35:56 -04:00
|
|
|
|
2021-11-30 14:12:13 -05:00
|
|
|
|
2022-02-26 06:33:03 -05:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-10 22:51:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-12 20:54:11 -04:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
2024-10-12 20:54:11 -04:00
|
|
|
|
2024-10-12 21:13:13 -04:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-12 20:54:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
2024-10-12 20:54:11 -04:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-18 13:51:57 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-18 13:51:57 -08:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2019-12-21 21:31:52 -05:00
|
|
|
|
2009-12-18 13:51:57 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2019-12-20 09:34:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-10 22:51:08 +01:00
|
|
|
|
2019-12-20 09:34:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-10 22:51:08 +01:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-21 00:16:49 -05:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-07 07:23:15 -04:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2024-11-20 16:43:51 +01:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2016-03-30 17:18:34 +08:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
2018-02-06 08:25:55 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2016-03-30 17:18:34 +08:00
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2019-12-21 21:31:52 -05:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2011-08-04 08:03:44 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2011-08-04 08:03:44 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-02-01 14:57:15 +08:00
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-01 14:57:15 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2012-02-15 07:43:54 -06:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2012-01-10 09:12:55 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-10 09:12:55 -08:00
|
|
|
|
2011-01-21 16:44:03 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-15 07:43:54 -06:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
2019-11-07 09:39:32 -05:00
|
|
|
|
2018-02-07 10:27:06 +08:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
2019-11-07 09:39:32 -05:00
|
|
|
|
2019-12-21 21:31:52 -05:00
|
|
|
|
2019-11-07 09:39:32 -05:00
|
|
|
|
2015-04-27 15:33:28 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-27 15:33:28 +08:00
|
|
|
|
2016-11-10 16:02:06 +08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-10 16:02:06 +08:00
|
|
|
|
2018-01-31 10:53:13 +00:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-31 10:53:13 +00:00
|
|
|
|
2018-10-15 16:46:00 +01:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-15 16:46:00 +01:00
|
|
|
|
2014-02-16 10:05:29 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-21 21:31:52 -05:00
|
|
|
|
2014-02-16 10:05:29 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-16 10:05:29 -08:00
|
|
|
|
ceph: perform asynchronous unlink if we have sufficient caps
The MDS is getting a new lock-caching facility that will allow it
to cache the necessary locks to allow asynchronous directory operations.
Since the CEPH_CAP_FILE_* caps are currently unused on directories,
we can repurpose those bits for this purpose.
When performing an unlink, if we have Fx on the parent directory,
and CEPH_CAP_DIR_UNLINK (aka Fr), and we know that the dentry being
removed is the primary link, then then we can fire off an unlink
request immediately and don't need to wait on reply before returning.
In that situation, just fix up the dcache and link count and return
immediately after issuing the call to the MDS. This does mean that we
need to hold an extra reference to the inode being unlinked, and extra
references to the caps to avoid races. Those references are put and
error handling is done in the r_callback routine.
If the operation ends up failing, then set a writeback error on the
directory inode, and the inode itself that can be fetched later by
an fsync on the dir.
The behavior of dir caps is slightly different from caps on normal
files. Because these are just considered an optimization, if the
session is reconnected, we will not automatically reclaim them. They
are instead considered lost until we do another synchronous op in the
parent directory.
Async dirops are enabled via the "nowsync" mount option, which is
patterned after the xfs "wsync" mount option. For now, the default
is "wsync", but eventually we may flip that.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-04-02 15:35:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 14:12:13 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-26 06:33:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2019-12-21 21:31:52 -05:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2016-07-08 11:25:38 +08:00
|
|
|
|
2016-04-21 11:09:55 +08:00
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 11:25:38 +08:00
|
|
|
|
|
|
|
|
|
2020-02-10 22:51:08 +01:00
|
|
|
|
2016-07-08 11:25:38 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-12-20 09:34:04 -05:00
|
|
|
|
2020-02-10 22:51:08 +01:00
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
|
|
|
|
|
2019-12-20 09:34:04 -05:00
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
2016-04-21 11:09:55 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 21:32:45 -05:00
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
2011-12-08 21:32:45 -05:00
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2015-03-25 21:02:16 +03:00
|
|
|
|
|
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
2015-03-25 21:02:16 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2018-12-18 04:31:48 -05:00
|
|
|
|
2015-03-25 21:02:16 +03:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2015-03-25 21:02:16 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-25 10:44:33 +08:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
2015-03-25 21:10:09 +03:00
|
|
|
|
2012-01-10 09:12:55 -08:00
|
|
|
|
2018-06-04 16:03:51 +08:00
|
|
|
|
|
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
2018-02-15 15:39:05 +08:00
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
2015-04-27 15:33:28 +08:00
|
|
|
|
|
|
|
|
|
2018-01-31 10:53:13 +00:00
|
|
|
|
|
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
2014-02-16 10:05:29 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2014-02-16 10:05:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-10 10:23:12 +00:00
|
|
|
|
|
|
|
|
|
2018-10-15 16:46:00 +01:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
2018-02-15 15:39:05 +08:00
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-09 11:55:15 -04:00
|
|
|
|
|
|
|
|
|
2021-11-30 14:12:13 -05:00
|
|
|
|
|
|
|
|
|
2022-02-26 06:33:03 -05:00
|
|
|
|
|
|
|
|
|
2021-11-30 14:12:13 -05:00
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
|
|
|
|
|
2018-05-03 16:26:55 +02:00
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2017-07-11 15:56:09 +08:00
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2011-08-04 08:03:44 -07:00
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2019-02-01 14:57:15 +08:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-09-09 15:58:55 -04:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
fs: create and use seq_show_option for escaping
Many file systems that implement the show_options hook fail to correctly
escape their output which could lead to unescaped characters (e.g. new
lines) leaking into /proc/mounts and /proc/[pid]/mountinfo files. This
could lead to confusion, spoofed entries (resulting in things like
systemd issuing false d-bus "mount" notifications), and who knows what
else. This looks like it would only be the root user stepping on
themselves, but it's possible weird things could happen in containers or
in other situations with delegated mount privileges.
Here's an example using overlay with setuid fusermount trusting the
contents of /proc/mounts (via the /etc/mtab symlink). Imagine the use
of "sudo" is something more sneaky:
$ BASE="ovl"
$ MNT="$BASE/mnt"
$ LOW="$BASE/lower"
$ UP="$BASE/upper"
$ WORK="$BASE/work/ 0 0
none /proc fuse.pwn user_id=1000"
$ mkdir -p "$LOW" "$UP" "$WORK"
$ sudo mount -t overlay -o "lowerdir=$LOW,upperdir=$UP,workdir=$WORK" none /mnt
$ cat /proc/mounts
none /root/ovl/mnt overlay rw,relatime,lowerdir=ovl/lower,upperdir=ovl/upper,workdir=ovl/work/ 0 0
none /proc fuse.pwn user_id=1000 0 0
$ fusermount -u /proc
$ cat /proc/mounts
cat: /proc/mounts: No such file or directory
This fixes the problem by adding new seq_show_option and
seq_show_option_n helpers, and updating the vulnerable show_option
handlers to use them as needed. Some, like SELinux, need to be open
coded due to unusual existing escape mechanisms.
[akpm@linux-foundation.org: add lost chunk, per Kees]
[keescook@chromium.org: seq_show_option should be using const parameters]
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Acked-by: Jan Kara <jack@suse.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Cc: J. R. Okajima <hooanon05g@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-09-04 15:44:57 -07:00
|
|
|
|
2015-03-25 21:02:16 +03:00
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 11:25:38 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-24 15:32:43 +02:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2011-09-23 11:53:30 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-24 15:32:43 +02:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2018-08-24 15:32:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2017-03-03 18:16:07 +01:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-24 15:32:43 +02:00
|
|
|
|
2018-05-30 16:29:14 +02:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2018-12-18 04:31:48 -05:00
|
|
|
|
2016-07-08 11:25:38 +08:00
|
|
|
|
2017-08-20 20:22:02 +02:00
|
|
|
|
2016-07-08 11:25:38 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-25 20:16:46 +08:00
|
|
|
|
2020-01-08 10:03:53 +00:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2022-03-22 14:39:04 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2011-01-03 14:49:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-05-18 11:18:44 +08:00
|
|
|
|
|
|
|
|
|
2017-04-12 12:24:33 +02:00
|
|
|
|
2025-09-16 10:29:06 +02:00
|
|
|
|
2019-01-14 17:21:19 +08:00
|
|
|
|
2019-05-18 11:18:44 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2022-05-10 09:47:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-16 10:05:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-05-18 11:18:44 +08:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-24 15:32:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-18 16:05:51 +08:00
|
|
|
|
|
|
|
|
|
2019-05-18 11:18:44 +08:00
|
|
|
|
2019-01-14 17:21:19 +08:00
|
|
|
|
2018-05-18 16:05:51 +08:00
|
|
|
|
|
|
|
|
|
2011-09-23 11:53:30 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2020-07-16 10:05:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-12 08:07:56 -04:00
|
|
|
|
2019-05-18 11:18:44 +08:00
|
|
|
|
2019-01-14 17:21:19 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-15 20:23:14 +08:00
|
|
|
|
2015-06-10 17:26:13 +08:00
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
|
|
|
|
|
2018-03-13 10:42:44 +08:00
|
|
|
|
2020-02-17 18:38:37 -05:00
|
|
|
|
2020-07-30 11:03:55 -04:00
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
netfs: Fix gcc-12 warning by embedding vfs inode in netfs_i_context
While randstruct was satisfied with using an open-coded "void *" offset
cast for the netfs_i_context <-> inode casting, __builtin_object_size() as
used by FORTIFY_SOURCE was not as easily fooled. This was causing the
following complaint[1] from gcc v12:
In file included from include/linux/string.h:253,
from include/linux/ceph/ceph_debug.h:7,
from fs/ceph/inode.c:2:
In function 'fortify_memset_chk',
inlined from 'netfs_i_context_init' at include/linux/netfs.h:326:2,
inlined from 'ceph_alloc_inode' at fs/ceph/inode.c:463:2:
include/linux/fortify-string.h:242:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
242 | __write_overflow_field(p_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix this by embedding a struct inode into struct netfs_i_context (which
should perhaps be renamed to struct netfs_inode). The struct inode
vfs_inode fields are then removed from the 9p, afs, ceph and cifs inode
structs and vfs_inode is then simply changed to "netfs.inode" in those
filesystems.
Further, rename netfs_i_context to netfs_inode, get rid of the
netfs_inode() function that converted a netfs_i_context pointer to an
inode pointer (that can now be done with &ctx->inode) and rename the
netfs_i_context() function to netfs_inode() (which is now a wrapper
around container_of()).
Most of the changes were done with:
perl -p -i -e 's/vfs_inode/netfs.inode/'g \
`git grep -l 'vfs_inode' -- fs/{9p,afs,ceph,cifs}/*.[ch]`
Kees suggested doing it with a pair structure[2] and a special
declarator to insert that into the network filesystem's inode
wrapper[3], but I think it's cleaner to embed it - and then it doesn't
matter if struct randomisation reorders things.
Dave Chinner suggested using a filesystem-specific VFS_I() function in
each filesystem to convert that filesystem's own inode wrapper struct
into the VFS inode struct[4].
Version #2:
- Fix a couple of missed name changes due to a disabled cifs option.
- Rename nfs_i_context to nfs_inode
- Use "netfs" instead of "nic" as the member name in per-fs inode wrapper
structs.
[ This also undoes commit 507160f46c55 ("netfs: gcc-12: temporarily
disable '-Wattribute-warning' for now") that is no longer needed ]
Fixes: bc899ee1c898 ("netfs: Add a netfs inode context")
Reported-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
cc: Jonathan Corbet <corbet@lwn.net>
cc: Eric Van Hensbergen <ericvh@gmail.com>
cc: Latchesar Ionkov <lucho@ionkov.net>
cc: Dominique Martinet <asmadeus@codewreck.org>
cc: Christian Schoenebeck <linux_oss@crudebyte.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Ilya Dryomov <idryomov@gmail.com>
cc: Steve French <smfrench@gmail.com>
cc: William Kucharski <william.kucharski@oracle.com>
cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
cc: Dave Chinner <david@fromorbit.com>
cc: linux-doc@vger.kernel.org
cc: v9fs-developer@lists.sourceforge.net
cc: linux-afs@lists.infradead.org
cc: ceph-devel@vger.kernel.org
cc: linux-cifs@vger.kernel.org
cc: samba-technical@lists.samba.org
cc: linux-fsdevel@vger.kernel.org
cc: linux-hardening@vger.kernel.org
Link: https://lore.kernel.org/r/d2ad3a3d7bdd794c6efb562d2f2b655fb67756b9.camel@kernel.org/ [1]
Link: https://lore.kernel.org/r/20220517210230.864239-1-keescook@chromium.org/ [2]
Link: https://lore.kernel.org/r/20220518202212.2322058-1-keescook@chromium.org/ [3]
Link: https://lore.kernel.org/r/20220524101205.GI2306852@dread.disaster.area/ [4]
Link: https://lore.kernel.org/r/165296786831.3591209.12111293034669289733.stgit@warthog.procyon.org.uk/ # v1
Link: https://lore.kernel.org/r/165305805651.4094995.7763502506786714216.stgit@warthog.procyon.org.uk # v2
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-06-09 21:46:04 +01:00
|
|
|
|
2010-04-29 16:38:32 -07:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
|
|
|
|
|
2017-08-20 20:22:02 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
2017-08-20 20:22:02 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
2022-02-15 20:23:14 +08:00
|
|
|
|
|
|
|
|
|
2015-06-10 17:26:13 +08:00
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
2017-08-20 20:22:02 +02:00
|
|
|
|
2015-06-10 17:26:13 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
2017-08-20 20:22:02 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
2017-08-20 20:22:02 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
2018-03-13 10:42:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-12 20:32:19 -07:00
|
|
|
|
2020-02-17 18:38:37 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-11 14:47:56 +08:00
|
|
|
|
|
|
|
|
|
2020-07-30 11:03:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-10 09:06:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
2018-03-01 14:24:51 +08:00
|
|
|
|
2026-02-10 09:06:26 +00:00
|
|
|
|
|
|
|
|
|
2020-07-30 11:03:55 -04:00
|
|
|
|
2021-12-07 08:44:50 -05:00
|
|
|
|
2020-02-17 18:38:37 -05:00
|
|
|
|
2018-03-13 10:42:44 +08:00
|
|
|
|
|
|
|
|
|
2018-03-01 14:24:51 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-10 17:26:13 +08:00
|
|
|
|
|
|
|
|
|
2022-02-15 20:23:14 +08:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-26 11:33:07 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-21 17:29:54 -04:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2022-02-15 20:23:14 +08:00
|
|
|
|
2015-06-10 17:26:13 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2018-03-13 10:42:44 +08:00
|
|
|
|
2020-02-17 18:38:37 -05:00
|
|
|
|
2020-07-30 11:03:55 -04:00
|
|
|
|
2026-02-10 09:06:26 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2020-09-25 07:55:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2020-07-17 16:36:04 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2021-10-14 11:10:47 -04:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2025-06-02 11:49:56 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2020-09-25 07:55:39 -04:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-10 15:18:50 -04:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2025-09-15 14:57:29 +02:00
|
|
|
|
2019-06-02 09:45:38 +08:00
|
|
|
|
2010-07-30 09:38:13 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2010-05-22 12:01:14 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2015-03-21 12:54:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-15 12:02:17 +03:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-09 16:34:32 -05:00
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2016-09-14 14:53:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-11 09:48:08 -08:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-09 16:34:32 -05:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2016-03-12 13:20:48 +08:00
|
|
|
|
2020-02-10 22:51:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-03 21:34:01 +01:00
|
|
|
|
2016-03-12 13:20:48 +08:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2018-02-09 20:40:59 +08:00
|
|
|
|
2019-06-12 16:55:38 +02:00
|
|
|
|
2018-02-09 20:40:59 +08:00
|
|
|
|
2016-09-14 14:53:05 +08:00
|
|
|
|
2016-03-12 13:20:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-14 14:53:05 +08:00
|
|
|
|
2016-10-13 17:15:37 +02:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-07-26 16:17:55 +04:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2016-03-12 13:20:48 +08:00
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
2016-03-12 13:20:48 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2018-07-19 22:15:24 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2013-11-11 15:18:03 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2018-07-19 22:15:24 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2025-02-23 19:39:47 -05:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2019-06-27 14:51:22 +01:00
|
|
|
|
2019-03-21 14:34:38 -07:00
|
|
|
|
|
|
|
|
|
2022-04-20 13:13:02 +08:00
|
|
|
|
ceph: set superblock s_magic for IMA fsmagic matching
The CephFS kernel driver forgets to set the filesystem magic signature in
its superblock. As a result, IMA policy rules based on fsmagic matching do
not apply as intended. This causes a major performance regression in Talos
Linux [1] when mounting CephFS volumes, such as when deploying Rook Ceph
[2]. Talos Linux ships a hardened kernel with the following IMA policy
(irrelevant lines omitted):
[...]
dont_measure fsmagic=0xc36400 # CEPH_SUPER_MAGIC
[...]
measure func=FILE_CHECK mask=^MAY_READ euid=0
measure func=FILE_CHECK mask=^MAY_READ uid=0
[...]
Currently, IMA compares 0xc36400 == 0x0 for CephFS files, resulting in all
files opened with O_RDONLY or O_RDWR getting measured with SHA512 on every
open(2):
10 69990c87e8af323d47e2d6ae4... ima-ng sha512:<hash> /data/cephfs/test-file
Since O_WRONLY is rare, this results in an order of magnitude lower
performance than expected for practically all file operations. Properly
setting CEPH_SUPER_MAGIC in the CephFS superblock resolves the regression.
Tests performed on a 3x replicated Ceph v19.3.0 cluster across three
i5-7200U nodes each equipped with one Micron 7400 MAX M.2 disk (BlueStore)
and Gigabit ethernet, on Talos Linux v1.10.2:
FS-Mark 3.3
Test: 500 Files, Empty
Files/s > Higher Is Better
6.12.27-talos . 16.6 |====
+twelho patch . 208.4 |====================================================
FS-Mark 3.3
Test: 500 Files, 1KB Size
Files/s > Higher Is Better
6.12.27-talos . 15.6 |=======
+twelho patch . 118.6 |====================================================
FS-Mark 3.3
Test: 500 Files, 32 Sub Dirs, 1MB Size
Files/s > Higher Is Better
6.12.27-talos . 12.7 |===============
+twelho patch . 44.7 |=====================================================
IO500 [3] 2fcd6d6 results (benchmarks within variance omitted):
| IO500 benchmark | 6.12.27-talos | +twelho patch | Speedup |
|-------------------|----------------|----------------|-----------|
| mdtest-easy-write | 0.018524 kIOPS | 1.135027 kIOPS | 6027.33 % |
| mdtest-hard-write | 0.018498 kIOPS | 0.973312 kIOPS | 5161.71 % |
| ior-easy-read | 0.064727 GiB/s | 0.155324 GiB/s | 139.97 % |
| mdtest-hard-read | 0.018246 kIOPS | 0.780800 kIOPS | 4179.29 % |
This applies outside of synthetic benchmarks as well, for example, the time
to rsync a 55 MiB directory with ~12k of mostly small files drops from an
unusable 10m5s to a reasonable 26s (23x the throughput).
[1]: https://www.talos.dev/
[2]: https://www.talos.dev/v1.10/kubernetes-guides/configuration/ceph-with-rook/
[3]: https://github.com/IO500/io500
Cc: stable@vger.kernel.org
Signed-off-by: Dennis Marttinen <twelho@welho.tech>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2025-05-29 17:45:12 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2020-07-27 10:16:09 -04:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2021-09-30 08:33:13 -04:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2021-09-30 08:33:13 -04:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2021-09-30 08:33:13 -04:00
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2021-09-30 08:33:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2021-09-30 08:33:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-10 11:13:58 -04:00
|
|
|
|
2010-05-04 16:39:35 -07:00
|
|
|
|
2017-04-12 12:24:33 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-12 12:24:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-04 08:03:44 -07:00
|
|
|
|
2017-07-11 18:49:44 +08:00
|
|
|
|
2011-07-22 11:12:28 -07:00
|
|
|
|
2017-07-11 15:56:09 +08:00
|
|
|
|
|
|
|
|
|
2017-01-10 14:17:56 +01:00
|
|
|
|
2017-04-12 12:24:33 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2010-07-26 16:17:55 +04:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-21 21:31:52 -05:00
|
|
|
|
2021-07-14 15:35:52 +05:30
|
|
|
|
|
|
|
|
|
2014-02-16 10:05:29 -08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-27 11:50:50 -07:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2017-04-12 12:24:33 +02:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2019-12-10 20:29:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2010-03-21 19:22:29 -04:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
ceph: perform asynchronous unlink if we have sufficient caps
The MDS is getting a new lock-caching facility that will allow it
to cache the necessary locks to allow asynchronous directory operations.
Since the CEPH_CAP_FILE_* caps are currently unused on directories,
we can repurpose those bits for this purpose.
When performing an unlink, if we have Fx on the parent directory,
and CEPH_CAP_DIR_UNLINK (aka Fr), and we know that the dentry being
removed is the primary link, then then we can fire off an unlink
request immediately and don't need to wait on reply before returning.
In that situation, just fix up the dcache and link count and return
immediately after issuing the call to the MDS. This does mean that we
need to hold an extra reference to the inode being unlinked, and extra
references to the caps to avoid races. Those references are put and
error handling is done in the r_callback routine.
If the operation ends up failing, then set a writeback error on the
directory inode, and the inode itself that can be fetched later by
an fsync on the dir.
The behavior of dir caps is slightly different from caps on normal
files. Because these are just considered an optimization, if the
session is reconnected, we will not automatically reclaim them. They
are instead considered lost until we do another synchronous op in the
parent directory.
Async dirops are enabled via the "nowsync" mount option, which is
patterned after the xfs "wsync" mount option. For now, the default
is "wsync", but eventually we may flip that.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-04-02 15:35:56 -04:00
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ceph: perform asynchronous unlink if we have sufficient caps
The MDS is getting a new lock-caching facility that will allow it
to cache the necessary locks to allow asynchronous directory operations.
Since the CEPH_CAP_FILE_* caps are currently unused on directories,
we can repurpose those bits for this purpose.
When performing an unlink, if we have Fx on the parent directory,
and CEPH_CAP_DIR_UNLINK (aka Fr), and we know that the dentry being
removed is the primary link, then then we can fire off an unlink
request immediately and don't need to wait on reply before returning.
In that situation, just fix up the dcache and link count and return
immediately after issuing the call to the MDS. This does mean that we
need to hold an extra reference to the inode being unlinked, and extra
references to the caps to avoid races. Those references are put and
error handling is done in the r_callback routine.
If the operation ends up failing, then set a writeback error on the
directory inode, and the inode itself that can be fetched later by
an fsync on the dir.
The behavior of dir caps is slightly different from caps on normal
files. Because these are just considered an optimization, if the
session is reconnected, we will not automatically reclaim them. They
are instead considered lost until we do another synchronous op in the
parent directory.
Async dirops are enabled via the "nowsync" mount option, which is
patterned after the xfs "wsync" mount option. For now, the default
is "wsync", but eventually we may flip that.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2019-04-02 15:35:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-26 06:33:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:53 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
|
|
|
|
|
2021-07-14 15:35:53 +05:30
|
|
|
|
|
|
|
|
|
2020-09-08 09:47:40 -04:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-11 01:53:16 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-09 16:38:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
|
|
|
|
|
2015-01-14 10:42:38 +01:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2015-01-14 10:42:38 +01:00
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
2018-05-18 16:05:51 +08:00
|
|
|
|
|
|
|
|
|
2023-07-25 12:03:59 +08:00
|
|
|
|
|
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-25 12:03:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-04 16:02:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-25 12:03:59 +08:00
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
2023-06-12 09:04:07 +08:00
|
|
|
|
2022-12-21 14:13:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-11 15:19:00 -04:00
|
|
|
|
2017-06-22 16:26:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-27 11:57:56 +08:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-25 16:38:32 +00:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2023-08-07 15:26:26 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2013-03-02 19:39:14 -08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2019-07-25 20:16:44 +08:00
|
|
|
|
|
|
|
|
|
2023-06-12 10:50:38 +08:00
|
|
|
|
2019-07-25 20:16:44 +08:00
|
|
|
|
|
|
|
|
|
2020-09-25 07:55:39 -04:00
|
|
|
|
|
|
|
|
|
2019-07-25 20:16:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 13:39:19 +02:00
|
|
|
|
2019-07-25 20:16:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-25 20:16:47 +08:00
|
|
|
|
2020-09-14 13:39:19 +02:00
|
|
|
|
2019-07-25 20:16:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2014-03-09 23:16:40 +08:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2019-04-18 14:15:49 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
2010-04-06 15:14:15 -07:00
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
2019-04-18 14:15:49 +02:00
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-16 10:05:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-03 10:30:39 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-07 15:26:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-06 11:31:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|