License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
// SPDX-License-Identifier: GPL-2.0
2010-04-07 02:14:15 +04:00
# include <linux/ceph/ceph_debug.h>
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
# include <linux/fs.h>
# include <linux/kernel.h>
2017-02-02 21:15:33 +03:00
# include <linux/sched/signal.h>
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 11:04:11 +03:00
# include <linux/slab.h>
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
# include <linux/vmalloc.h>
# include <linux/wait.h>
2010-01-18 03:53:08 +03:00
# include <linux/writeback.h>
2019-06-06 15:06:40 +03:00
# include <linux/iversion.h>
2022-11-20 17:15:34 +03:00
# include <linux/filelock.h>
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
# include "super.h"
2010-04-07 02:14:15 +04:00
# include "mds_client.h"
2013-08-22 01:29:54 +04:00
# include "cache.h"
2020-07-27 17:16:09 +03:00
# include "crypto.h"
2010-04-07 02:14:15 +04:00
# include <linux/ceph/decode.h>
# include <linux/ceph/messenger.h>
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Capability management
*
* The Ceph metadata servers control client access to inode metadata
* and file data by issuing capabilities , granting clients permission
* to read and / or write both inode field and file data to OSDs
* ( storage nodes ) . Each capability consists of a set of bits
* indicating which operations are allowed .
*
* If the client holds a * _SHARED cap , the client has a coherent value
* that can be safely read from the cached inode .
*
* In the case of a * _EXCL ( exclusive ) or FILE_WR capabilities , the
* client is allowed to change inode attributes ( e . g . , file size ,
* mtime ) , note its dirty state in the ceph_cap , and asynchronously
* flush that metadata change to the MDS .
*
* In the event of a conflicting operation ( perhaps by another
* client ) , the MDS will revoke the conflicting client capabilities .
*
* In order for a client to cache an inode , it must hold a capability
* with at least one MDS server . When inodes are released , release
* notifications are batched and periodically sent en masse to the MDS
* cluster to release server state .
*/
2016-07-04 13:06:41 +03:00
static u64 __get_oldest_flush_tid ( struct ceph_mds_client * mdsc ) ;
2016-07-07 13:34:45 +03:00
static void __kick_flushing_caps ( struct ceph_mds_client * mdsc ,
struct ceph_mds_session * session ,
struct ceph_inode_info * ci ,
u64 oldest_flush_tid ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Generate readable cap strings for debugging output .
*/
# define MAX_CAP_STR 20
static char cap_str [ MAX_CAP_STR ] [ 40 ] ;
static DEFINE_SPINLOCK ( cap_str_lock ) ;
static int last_cap_str ;
static char * gcap_string ( char * s , int c )
{
if ( c & CEPH_CAP_GSHARED )
* s + + = ' s ' ;
if ( c & CEPH_CAP_GEXCL )
* s + + = ' x ' ;
if ( c & CEPH_CAP_GCACHE )
* s + + = ' c ' ;
if ( c & CEPH_CAP_GRD )
* s + + = ' r ' ;
if ( c & CEPH_CAP_GWR )
* s + + = ' w ' ;
if ( c & CEPH_CAP_GBUFFER )
* s + + = ' b ' ;
2018-04-25 12:30:23 +03:00
if ( c & CEPH_CAP_GWREXTEND )
* s + + = ' a ' ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( c & CEPH_CAP_GLAZYIO )
* s + + = ' l ' ;
return s ;
}
const char * ceph_cap_string ( int caps )
{
int i ;
char * s ;
int c ;
spin_lock ( & cap_str_lock ) ;
i = last_cap_str + + ;
if ( last_cap_str = = MAX_CAP_STR )
last_cap_str = 0 ;
spin_unlock ( & cap_str_lock ) ;
s = cap_str [ i ] ;
if ( caps & CEPH_CAP_PIN )
* s + + = ' p ' ;
c = ( caps > > CEPH_CAP_SAUTH ) & 3 ;
if ( c ) {
* s + + = ' A ' ;
s = gcap_string ( s , c ) ;
}
c = ( caps > > CEPH_CAP_SLINK ) & 3 ;
if ( c ) {
* s + + = ' L ' ;
s = gcap_string ( s , c ) ;
}
c = ( caps > > CEPH_CAP_SXATTR ) & 3 ;
if ( c ) {
* s + + = ' X ' ;
s = gcap_string ( s , c ) ;
}
c = caps > > CEPH_CAP_SFILE ;
if ( c ) {
* s + + = ' F ' ;
s = gcap_string ( s , c ) ;
}
if ( s = = cap_str [ i ] )
* s + + = ' - ' ;
* s = 0 ;
return cap_str [ i ] ;
}
2010-06-18 03:16:12 +04:00
void ceph_caps_init ( struct ceph_mds_client * mdsc )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2010-06-18 03:16:12 +04:00
INIT_LIST_HEAD ( & mdsc - > caps_list ) ;
spin_lock_init ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2010-06-18 03:16:12 +04:00
void ceph_caps_finalize ( struct ceph_mds_client * mdsc )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_cap * cap ;
2010-06-18 03:16:12 +04:00
spin_lock ( & mdsc - > caps_list_lock ) ;
while ( ! list_empty ( & mdsc - > caps_list ) ) {
cap = list_first_entry ( & mdsc - > caps_list ,
struct ceph_cap , caps_item ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
list_del ( & cap - > caps_item ) ;
kmem_cache_free ( ceph_cap_cachep , cap ) ;
}
2010-06-18 03:16:12 +04:00
mdsc - > caps_total_count = 0 ;
mdsc - > caps_avail_count = 0 ;
mdsc - > caps_use_count = 0 ;
mdsc - > caps_reserve_count = 0 ;
mdsc - > caps_min_count = 0 ;
spin_unlock ( & mdsc - > caps_list_lock ) ;
2010-02-17 21:02:43 +03:00
}
2019-02-01 09:57:15 +03:00
void ceph_adjust_caps_max_min ( struct ceph_mds_client * mdsc ,
struct ceph_mount_options * fsopt )
2010-02-17 21:02:43 +03:00
{
2010-06-18 03:16:12 +04:00
spin_lock ( & mdsc - > caps_list_lock ) ;
2019-02-01 09:57:15 +03:00
mdsc - > caps_min_count = fsopt - > max_readdir ;
if ( mdsc - > caps_min_count < 1024 )
mdsc - > caps_min_count = 1024 ;
mdsc - > caps_use_max = fsopt - > caps_max ;
if ( mdsc - > caps_use_max > 0 & &
mdsc - > caps_use_max < mdsc - > caps_min_count )
mdsc - > caps_use_max = mdsc - > caps_min_count ;
2010-06-18 03:16:12 +04:00
spin_unlock ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2018-07-28 18:15:35 +03:00
static void __ceph_unreserve_caps ( struct ceph_mds_client * mdsc , int nr_caps )
{
struct ceph_cap * cap ;
int i ;
if ( nr_caps ) {
BUG_ON ( mdsc - > caps_reserve_count < nr_caps ) ;
mdsc - > caps_reserve_count - = nr_caps ;
if ( mdsc - > caps_avail_count > =
mdsc - > caps_reserve_count + mdsc - > caps_min_count ) {
mdsc - > caps_total_count - = nr_caps ;
for ( i = 0 ; i < nr_caps ; i + + ) {
cap = list_first_entry ( & mdsc - > caps_list ,
struct ceph_cap , caps_item ) ;
list_del ( & cap - > caps_item ) ;
kmem_cache_free ( ceph_cap_cachep , cap ) ;
}
} else {
mdsc - > caps_avail_count + = nr_caps ;
}
2023-06-12 04:04:07 +03:00
doutc ( mdsc - > fsc - > client ,
" caps %d = %d used + %d resv + %d avail \n " ,
mdsc - > caps_total_count , mdsc - > caps_use_count ,
mdsc - > caps_reserve_count , mdsc - > caps_avail_count ) ;
2018-07-28 18:15:35 +03:00
BUG_ON ( mdsc - > caps_total_count ! = mdsc - > caps_use_count +
mdsc - > caps_reserve_count +
mdsc - > caps_avail_count ) ;
}
}
2018-01-24 16:24:33 +03:00
/*
* Called under mdsc - > mutex .
*/
int ceph_reserve_caps ( struct ceph_mds_client * mdsc ,
2010-06-18 03:16:12 +04:00
struct ceph_cap_reservation * ctx , int need )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2018-01-24 16:24:33 +03:00
int i , j ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap * cap ;
int have ;
int alloc = 0 ;
2018-01-24 16:24:33 +03:00
int max_caps ;
2018-07-28 18:15:37 +03:00
int err = 0 ;
2018-01-24 16:24:33 +03:00
bool trimmed = false ;
struct ceph_mds_session * s ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
LIST_HEAD ( newcaps ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " ctx=%p need=%d \n " , ctx , need ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/* first reserve any caps that are already allocated */
2010-06-18 03:16:12 +04:00
spin_lock ( & mdsc - > caps_list_lock ) ;
if ( mdsc - > caps_avail_count > = need )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
have = need ;
else
2010-06-18 03:16:12 +04:00
have = mdsc - > caps_avail_count ;
mdsc - > caps_avail_count - = have ;
mdsc - > caps_reserve_count + = have ;
BUG_ON ( mdsc - > caps_total_count ! = mdsc - > caps_use_count +
mdsc - > caps_reserve_count +
mdsc - > caps_avail_count ) ;
spin_unlock ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2018-02-24 13:36:02 +03:00
for ( i = have ; i < need ; ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap = kmem_cache_alloc ( ceph_cap_cachep , GFP_NOFS ) ;
2018-02-24 13:36:02 +03:00
if ( cap ) {
list_add ( & cap - > caps_item , & newcaps ) ;
alloc + + ;
i + + ;
continue ;
}
if ( ! trimmed ) {
for ( j = 0 ; j < mdsc - > max_sessions ; j + + ) {
s = __ceph_lookup_mds_session ( mdsc , j ) ;
if ( ! s )
continue ;
mutex_unlock ( & mdsc - > mutex ) ;
mutex_lock ( & s - > s_mutex ) ;
max_caps = s - > s_nr_caps - ( need - i ) ;
ceph_trim_caps ( mdsc , s , max_caps ) ;
mutex_unlock ( & s - > s_mutex ) ;
ceph_put_mds_session ( s ) ;
mutex_lock ( & mdsc - > mutex ) ;
2018-01-24 16:24:33 +03:00
}
2018-02-24 13:36:02 +03:00
trimmed = true ;
spin_lock ( & mdsc - > caps_list_lock ) ;
if ( mdsc - > caps_avail_count ) {
int more_have ;
if ( mdsc - > caps_avail_count > = need - i )
more_have = need - i ;
else
more_have = mdsc - > caps_avail_count ;
i + = more_have ;
have + = more_have ;
mdsc - > caps_avail_count - = more_have ;
mdsc - > caps_reserve_count + = more_have ;
}
spin_unlock ( & mdsc - > caps_list_lock ) ;
continue ;
2018-01-24 16:24:33 +03:00
}
2018-02-24 13:36:02 +03:00
2023-06-12 04:04:07 +03:00
pr_warn_client ( cl , " ctx=%p ENOMEM need=%d got=%d \n " , ctx , need ,
have + alloc ) ;
2018-07-28 18:15:37 +03:00
err = - ENOMEM ;
break ;
}
if ( ! err ) {
BUG_ON ( have + alloc ! = need ) ;
ctx - > count = need ;
2019-02-01 09:57:15 +03:00
ctx - > used = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2010-06-18 03:16:12 +04:00
spin_lock ( & mdsc - > caps_list_lock ) ;
mdsc - > caps_total_count + = alloc ;
mdsc - > caps_reserve_count + = alloc ;
list_splice ( & newcaps , & mdsc - > caps_list ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2010-06-18 03:16:12 +04:00
BUG_ON ( mdsc - > caps_total_count ! = mdsc - > caps_use_count +
mdsc - > caps_reserve_count +
mdsc - > caps_avail_count ) ;
2018-07-28 18:15:37 +03:00
if ( err )
__ceph_unreserve_caps ( mdsc , have + alloc ) ;
2010-06-18 03:16:12 +04:00
spin_unlock ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " ctx=%p %d = %d used + %d resv + %d avail \n " , ctx ,
mdsc - > caps_total_count , mdsc - > caps_use_count ,
mdsc - > caps_reserve_count , mdsc - > caps_avail_count ) ;
2018-07-28 18:15:37 +03:00
return err ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2018-07-28 18:15:35 +03:00
void ceph_unreserve_caps ( struct ceph_mds_client * mdsc ,
2019-02-01 09:57:15 +03:00
struct ceph_cap_reservation * ctx )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2019-02-01 09:57:15 +03:00
bool reclaim = false ;
if ( ! ctx - > count )
return ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " ctx=%p count=%d \n " , ctx , ctx - > count ) ;
2018-07-28 18:15:35 +03:00
spin_lock ( & mdsc - > caps_list_lock ) ;
__ceph_unreserve_caps ( mdsc , ctx - > count ) ;
ctx - > count = 0 ;
2019-02-01 09:57:15 +03:00
if ( mdsc - > caps_use_max > 0 & &
mdsc - > caps_use_count > mdsc - > caps_use_max )
reclaim = true ;
2018-07-28 18:15:35 +03:00
spin_unlock ( & mdsc - > caps_list_lock ) ;
2019-02-01 09:57:15 +03:00
if ( reclaim )
ceph_reclaim_caps_nr ( mdsc , ctx - > used ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2014-04-18 05:57:11 +04:00
struct ceph_cap * ceph_get_cap ( struct ceph_mds_client * mdsc ,
struct ceph_cap_reservation * ctx )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap * cap = NULL ;
/* temporary, until we do something about cap import/export */
2010-06-29 20:28:39 +04:00
if ( ! ctx ) {
cap = kmem_cache_alloc ( ceph_cap_cachep , GFP_NOFS ) ;
if ( cap ) {
2012-11-03 06:32:37 +04:00
spin_lock ( & mdsc - > caps_list_lock ) ;
2010-06-18 03:16:12 +04:00
mdsc - > caps_use_count + + ;
mdsc - > caps_total_count + + ;
2012-11-03 06:32:37 +04:00
spin_unlock ( & mdsc - > caps_list_lock ) ;
2018-02-24 13:35:29 +03:00
} else {
spin_lock ( & mdsc - > caps_list_lock ) ;
if ( mdsc - > caps_avail_count ) {
BUG_ON ( list_empty ( & mdsc - > caps_list ) ) ;
mdsc - > caps_avail_count - - ;
mdsc - > caps_use_count + + ;
cap = list_first_entry ( & mdsc - > caps_list ,
struct ceph_cap , caps_item ) ;
list_del ( & cap - > caps_item ) ;
BUG_ON ( mdsc - > caps_total_count ! = mdsc - > caps_use_count +
mdsc - > caps_reserve_count + mdsc - > caps_avail_count ) ;
}
spin_unlock ( & mdsc - > caps_list_lock ) ;
2010-06-29 20:28:39 +04:00
}
2018-02-24 13:35:29 +03:00
2010-06-29 20:28:39 +04:00
return cap ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2010-06-18 03:16:12 +04:00
spin_lock ( & mdsc - > caps_list_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " ctx=%p (%d) %d = %d used + %d resv + %d avail \n " , ctx ,
ctx - > count , mdsc - > caps_total_count , mdsc - > caps_use_count ,
mdsc - > caps_reserve_count , mdsc - > caps_avail_count ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
BUG_ON ( ! ctx - > count ) ;
2010-06-18 03:16:12 +04:00
BUG_ON ( ctx - > count > mdsc - > caps_reserve_count ) ;
BUG_ON ( list_empty ( & mdsc - > caps_list ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ctx - > count - - ;
2019-02-01 09:57:15 +03:00
ctx - > used + + ;
2010-06-18 03:16:12 +04:00
mdsc - > caps_reserve_count - - ;
mdsc - > caps_use_count + + ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2010-06-18 03:16:12 +04:00
cap = list_first_entry ( & mdsc - > caps_list , struct ceph_cap , caps_item ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
list_del ( & cap - > caps_item ) ;
2010-06-18 03:16:12 +04:00
BUG_ON ( mdsc - > caps_total_count ! = mdsc - > caps_use_count +
mdsc - > caps_reserve_count + mdsc - > caps_avail_count ) ;
spin_unlock ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return cap ;
}
2010-06-18 03:16:12 +04:00
void ceph_put_cap ( struct ceph_mds_client * mdsc , struct ceph_cap * cap )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2010-06-18 03:16:12 +04:00
spin_lock ( & mdsc - > caps_list_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %d = %d used + %d resv + %d avail \n " , cap ,
mdsc - > caps_total_count , mdsc - > caps_use_count ,
mdsc - > caps_reserve_count , mdsc - > caps_avail_count ) ;
2010-06-18 03:16:12 +04:00
mdsc - > caps_use_count - - ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
2010-02-17 21:02:43 +03:00
* Keep some preallocated caps around ( ceph_min_count ) , to
* avoid lots of free / alloc churn .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2010-06-18 03:16:12 +04:00
if ( mdsc - > caps_avail_count > = mdsc - > caps_reserve_count +
mdsc - > caps_min_count ) {
mdsc - > caps_total_count - - ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
kmem_cache_free ( ceph_cap_cachep , cap ) ;
} else {
2010-06-18 03:16:12 +04:00
mdsc - > caps_avail_count + + ;
list_add ( & cap - > caps_item , & mdsc - > caps_list ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2010-06-18 03:16:12 +04:00
BUG_ON ( mdsc - > caps_total_count ! = mdsc - > caps_use_count +
mdsc - > caps_reserve_count + mdsc - > caps_avail_count ) ;
spin_unlock ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2010-04-07 02:14:15 +04:00
void ceph_reservation_status ( struct ceph_fs_client * fsc ,
2010-02-17 21:02:43 +03:00
int * total , int * avail , int * used , int * reserved ,
int * min )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2010-04-07 02:14:15 +04:00
struct ceph_mds_client * mdsc = fsc - > mdsc ;
2010-06-18 03:16:12 +04:00
2018-02-23 12:09:38 +03:00
spin_lock ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( total )
2010-06-18 03:16:12 +04:00
* total = mdsc - > caps_total_count ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( avail )
2010-06-18 03:16:12 +04:00
* avail = mdsc - > caps_avail_count ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( used )
2010-06-18 03:16:12 +04:00
* used = mdsc - > caps_use_count ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( reserved )
2010-06-18 03:16:12 +04:00
* reserved = mdsc - > caps_reserve_count ;
2010-02-17 21:02:43 +03:00
if ( min )
2010-06-18 03:16:12 +04:00
* min = mdsc - > caps_min_count ;
2018-02-23 12:09:38 +03:00
spin_unlock ( & mdsc - > caps_list_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* Find ceph_cap for given mds , if any .
*
2011-11-30 21:47:09 +04:00
* Called with i_ceph_lock held .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2023-04-19 05:39:14 +03:00
struct ceph_cap * __get_cap_for_mds ( struct ceph_inode_info * ci , int mds )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_cap * cap ;
struct rb_node * n = ci - > i_caps . rb_node ;
while ( n ) {
cap = rb_entry ( n , struct ceph_cap , ci_node ) ;
if ( mds < cap - > mds )
n = n - > rb_left ;
else if ( mds > cap - > mds )
n = n - > rb_right ;
else
return cap ;
}
return NULL ;
}
2010-06-30 23:44:34 +04:00
struct ceph_cap * ceph_get_cap_for_mds ( struct ceph_inode_info * ci , int mds )
{
struct ceph_cap * cap ;
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2010-06-30 23:44:34 +04:00
cap = __get_cap_for_mds ( ci , mds ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2010-06-30 23:44:34 +04:00
return cap ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
2011-11-30 21:47:09 +04:00
* Called under i_ceph_lock .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
static void __insert_cap_node ( struct ceph_inode_info * ci ,
struct ceph_cap * new )
{
struct rb_node * * p = & ci - > i_caps . rb_node ;
struct rb_node * parent = NULL ;
struct ceph_cap * cap = NULL ;
while ( * p ) {
parent = * p ;
cap = rb_entry ( parent , struct ceph_cap , ci_node ) ;
if ( new - > mds < cap - > mds )
p = & ( * p ) - > rb_left ;
else if ( new - > mds > cap - > mds )
p = & ( * p ) - > rb_right ;
else
BUG ( ) ;
}
rb_link_node ( & new - > ci_node , parent , p ) ;
rb_insert_color ( & new - > ci_node , & ci - > i_caps ) ;
}
/*
* ( re ) set cap hold timeouts , which control the delayed release
* of unused caps back to the MDS . Should be called on cap use .
*/
static void __cap_set_timeouts ( struct ceph_mds_client * mdsc ,
struct ceph_inode_info * ci )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
2019-02-01 09:57:15 +03:00
struct ceph_mount_options * opt = mdsc - > fsc - > mount_options ;
2023-06-12 04:04:07 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ci - > i_hold_caps_max = round_jiffies ( jiffies +
2019-02-01 09:57:15 +03:00
opt - > caps_wanted_delay_max * HZ ) ;
2023-06-12 04:04:07 +03:00
doutc ( mdsc - > fsc - > client , " %p %llx.%llx %lu \n " , inode ,
ceph_vinop ( inode ) , ci - > i_hold_caps_max - jiffies ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* ( Re ) queue cap at the end of the delayed cap release list .
*
* If I_FLUSH is set , leave the inode at the front of the list .
*
2011-11-30 21:47:09 +04:00
* Caller holds i_ceph_lock
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
* - > we take mdsc - > cap_delay_lock
*/
static void __cap_delay_requeue ( struct ceph_mds_client * mdsc ,
2020-03-05 15:21:01 +03:00
struct ceph_inode_info * ci )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
doutc ( mdsc - > fsc - > client , " %p %llx.%llx flags 0x%lx at %lu \n " ,
inode , ceph_vinop ( inode ) , ci - > i_ceph_flags ,
ci - > i_hold_caps_max ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ! mdsc - > stopping ) {
spin_lock ( & mdsc - > cap_delay_lock ) ;
if ( ! list_empty ( & ci - > i_cap_delay_list ) ) {
if ( ci - > i_ceph_flags & CEPH_I_FLUSH )
goto no_change ;
list_del_init ( & ci - > i_cap_delay_list ) ;
}
2020-03-05 15:21:01 +03:00
__cap_set_timeouts ( mdsc , ci ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
list_add_tail ( & ci - > i_cap_delay_list , & mdsc - > cap_delay_list ) ;
no_change :
spin_unlock ( & mdsc - > cap_delay_lock ) ;
}
}
/*
* Queue an inode for immediate writeback . Mark inode with I_FLUSH ,
* indicating we should send a cap message to flush dirty metadata
* asap , and move to the front of the delayed cap list .
*/
static void __cap_delay_requeue_front ( struct ceph_mds_client * mdsc ,
struct ceph_inode_info * ci )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
doutc ( mdsc - > fsc - > client , " %p %llx.%llx \n " , inode , ceph_vinop ( inode ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
spin_lock ( & mdsc - > cap_delay_lock ) ;
ci - > i_ceph_flags | = CEPH_I_FLUSH ;
if ( ! list_empty ( & ci - > i_cap_delay_list ) )
list_del_init ( & ci - > i_cap_delay_list ) ;
list_add ( & ci - > i_cap_delay_list , & mdsc - > cap_delay_list ) ;
spin_unlock ( & mdsc - > cap_delay_lock ) ;
}
/*
* Cancel delayed work on cap .
*
2011-11-30 21:47:09 +04:00
* Caller must hold i_ceph_lock .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
static void __cap_delay_cancel ( struct ceph_mds_client * mdsc ,
struct ceph_inode_info * ci )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
doutc ( mdsc - > fsc - > client , " %p %llx.%llx \n " , inode , ceph_vinop ( inode ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( list_empty ( & ci - > i_cap_delay_list ) )
return ;
spin_lock ( & mdsc - > cap_delay_lock ) ;
list_del_init ( & ci - > i_cap_delay_list ) ;
spin_unlock ( & mdsc - > cap_delay_lock ) ;
}
2020-01-02 15:11:38 +03:00
/* Common issue checks for add_cap, handle_cap_grant. */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
static void __check_cap_issue ( struct ceph_inode_info * ci , struct ceph_cap * cap ,
unsigned issued )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
unsigned had = __ceph_caps_issued ( ci , NULL ) ;
2020-01-02 15:11:38 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Each time we receive FILE_CACHE anew , we increment
* i_rdcache_gen .
*/
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 23:46:04 +03:00
if ( S_ISREG ( ci - > netfs . inode . i_mode ) & &
2019-05-11 12:27:59 +03:00
( issued & ( CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_LAZYIO ) ) & &
2013-08-22 01:29:54 +04:00
( had & ( CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_LAZYIO ) ) = = 0 ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ci - > i_rdcache_gen + + ;
2013-08-22 01:29:54 +04:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
2017-09-06 05:15:16 +03:00
* If FILE_SHARED is newly issued , mark dir not complete . We don ' t
* know what happened to this directory while we didn ' t have the cap .
* If FILE_SHARED is being revoked , also mark dir not complete . It
* stops on - going cached readdir .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2017-09-06 05:15:16 +03:00
if ( ( issued & CEPH_CAP_FILE_SHARED ) ! = ( had & CEPH_CAP_FILE_SHARED ) ) {
if ( issued & CEPH_CAP_FILE_SHARED )
2017-11-27 05:47:46 +03:00
atomic_inc ( & ci - > i_shared_gen ) ;
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 23:46:04 +03:00
if ( S_ISDIR ( ci - > netfs . inode . i_mode ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " marking %p NOT complete \n " , inode ) ;
2013-03-13 15:44:32 +04:00
__ceph_dir_clear_complete ( ci ) ;
2013-02-18 12:38:14 +04:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2020-01-02 15:11:38 +03:00
/* Wipe saved layout if we're losing DIR_CREATE caps */
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 23:46:04 +03:00
if ( S_ISDIR ( ci - > netfs . inode . i_mode ) & & ( had & CEPH_CAP_DIR_CREATE ) & &
2020-01-02 15:11:38 +03:00
! ( issued & CEPH_CAP_DIR_CREATE ) ) {
ceph_put_string ( rcu_dereference_raw ( ci - > i_cached_layout . pool_ns ) ) ;
memset ( & ci - > i_cached_layout , 0 , sizeof ( ci - > i_cached_layout ) ) ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2020-04-02 00:07:52 +03:00
/**
* change_auth_cap_ses - move inode to appropriate lists when auth caps change
* @ ci : inode to be moved
* @ session : new auth caps session
*/
2022-06-10 05:12:49 +03:00
void change_auth_cap_ses ( struct ceph_inode_info * ci ,
struct ceph_mds_session * session )
2020-04-02 00:07:52 +03:00
{
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
if ( list_empty ( & ci - > i_dirty_item ) & & list_empty ( & ci - > i_flushing_item ) )
return ;
spin_lock ( & session - > s_mdsc - > cap_dirty_lock ) ;
if ( ! list_empty ( & ci - > i_dirty_item ) )
list_move ( & ci - > i_dirty_item , & session - > s_cap_dirty ) ;
if ( ! list_empty ( & ci - > i_flushing_item ) )
list_move_tail ( & ci - > i_flushing_item , & session - > s_cap_flushing ) ;
spin_unlock ( & session - > s_mdsc - > cap_dirty_lock ) ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Add a capability under the given MDS session .
*
2019-07-19 16:41:02 +03:00
* Caller should hold session snap_rwsem ( read ) and ci - > i_ceph_lock
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*
* @ fmode is the open file mode , if we are opening a file , otherwise
* it is < 0. ( This is so we can atomically add the cap and add an
* open file reference to it . )
*/
2014-04-18 05:57:11 +04:00
void ceph_add_cap ( struct inode * inode ,
struct ceph_mds_session * session , u64 cap_id ,
2020-03-05 15:21:02 +03:00
unsigned issued , unsigned wanted ,
2014-04-18 05:57:11 +04:00
unsigned seq , unsigned mseq , u64 realmino , int flags ,
struct ceph_cap * * new_cap )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_inode_to_fs_client ( inode ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
struct ceph_cap * cap ;
int mds = session - > s_mds ;
int actual_wanted ;
2019-07-22 20:12:01 +03:00
u32 gen ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2019-07-19 16:41:02 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx mds%d cap %llx %s seq %d \n " , inode ,
ceph_vinop ( inode ) , session - > s_mds , cap_id ,
ceph_cap_string ( issued ) , seq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2021-06-04 19:03:09 +03:00
gen = atomic_read ( & session - > s_cap_gen ) ;
2019-07-22 20:12:01 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap = __get_cap_for_mds ( ci , mds ) ;
if ( ! cap ) {
2014-04-18 05:57:11 +04:00
cap = * new_cap ;
* new_cap = NULL ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > issued = 0 ;
cap - > implemented = 0 ;
cap - > mds = mds ;
cap - > mds_wanted = 0 ;
2013-02-27 05:26:09 +04:00
cap - > mseq = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > ci = ci ;
__insert_cap_node ( ci , cap ) ;
/* add to session cap list */
cap - > session = session ;
spin_lock ( & session - > s_cap_lock ) ;
list_add_tail ( & cap - > session_caps , & session - > s_caps ) ;
session - > s_nr_caps + + ;
2020-06-30 10:52:16 +03:00
atomic64_inc ( & mdsc - > metric . total_caps ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
spin_unlock ( & session - > s_cap_lock ) ;
2013-11-24 10:44:38 +04:00
} else {
2019-01-23 06:20:00 +03:00
spin_lock ( & session - > s_cap_lock ) ;
list_move_tail ( & cap - > session_caps , & session - > s_caps ) ;
spin_unlock ( & session - > s_cap_lock ) ;
2019-07-22 20:12:01 +03:00
if ( cap - > cap_gen < gen )
2018-12-10 11:35:09 +03:00
cap - > issued = cap - > implemented = CEPH_CAP_PIN ;
2013-11-24 10:44:38 +04:00
/*
* auth mds of the inode changed . we received the cap export
* message , but still haven ' t received the cap import message .
* handle_cap_export ( ) updated the new auth MDS ' cap .
*
* " ceph_seq_cmp(seq, cap->seq) <= 0 " means we are processing
* a message that was send before the cap import message . So
* don ' t remove caps .
*/
if ( ceph_seq_cmp ( seq , cap - > seq ) < = 0 ) {
WARN_ON ( cap ! = ci - > i_auth_cap ) ;
WARN_ON ( cap - > cap_id ! = cap_id ) ;
seq = cap - > seq ;
mseq = cap - > mseq ;
issued | = cap - > issued ;
flags | = CEPH_CAP_FLAG_AUTH ;
}
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2017-12-19 13:00:54 +03:00
if ( ! ci - > i_snap_realm | |
( ( flags & CEPH_CAP_FLAG_AUTH ) & &
realmino ! = ( u64 ) - 1 & & ci - > i_snap_realm - > ino ! = realmino ) ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* add this inode to the appropriate snap realm
*/
struct ceph_snap_realm * realm = ceph_lookup_snap_realm ( mdsc ,
realmino ) ;
2021-08-02 22:32:47 +03:00
if ( realm )
2021-08-02 18:01:26 +03:00
ceph_change_snap_realm ( inode , realm ) ;
2021-08-02 22:32:47 +03:00
else
WARN ( 1 , " %s: couldn't find snap realm 0x%llx (ino 0x%llx oldrealm 0x%llx) \n " ,
__func__ , realmino , ci - > i_vino . ino ,
ci - > i_snap_realm ? ci - > i_snap_realm - > ino : 0 ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
__check_cap_issue ( ci , cap , issued ) ;
/*
* If we are issued caps we don ' t want , or the mds ' wanted
* value appears to be off , queue a check so we ' ll release
* later and / or update the mds wanted value .
*/
actual_wanted = __ceph_caps_wanted ( ci ) ;
if ( ( wanted & ~ actual_wanted ) | |
( issued & ~ actual_wanted & CEPH_CAP_ANY_WR ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " issued %s, mds wanted %s, actual %s, queueing \n " ,
ceph_cap_string ( issued ) , ceph_cap_string ( wanted ) ,
ceph_cap_string ( actual_wanted ) ) ;
2020-03-05 15:21:01 +03:00
__cap_delay_requeue ( mdsc , ci ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2013-05-31 12:37:11 +04:00
if ( flags & CEPH_CAP_FLAG_AUTH ) {
2017-08-20 21:22:02 +03:00
if ( ! ci - > i_auth_cap | |
2014-03-18 06:15:29 +04:00
ceph_seq_cmp ( ci - > i_auth_cap - > mseq , mseq ) < 0 ) {
2020-04-02 00:07:52 +03:00
if ( ci - > i_auth_cap & &
ci - > i_auth_cap - > session ! = cap - > session )
change_auth_cap_ses ( ci , cap - > session ) ;
2013-05-31 12:37:11 +04:00
ci - > i_auth_cap = cap ;
2014-03-18 06:15:29 +04:00
cap - > mds_wanted = wanted ;
}
2013-11-24 10:44:38 +04:00
} else {
WARN_ON ( ci - > i_auth_cap = = cap ) ;
2013-01-04 10:28:07 +04:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " inode %p %llx.%llx cap %p %s now %s seq %d mds%d \n " ,
inode , ceph_vinop ( inode ) , cap , ceph_cap_string ( issued ) ,
ceph_cap_string ( issued | cap - > issued ) , seq , mds ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > cap_id = cap_id ;
cap - > issued = issued ;
cap - > implemented | = issued ;
2013-11-13 10:47:19 +04:00
if ( ceph_seq_cmp ( mseq , cap - > mseq ) > 0 )
2013-02-27 05:26:09 +04:00
cap - > mds_wanted = wanted ;
else
cap - > mds_wanted | = wanted ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > seq = seq ;
cap - > issue_seq = seq ;
cap - > mseq = mseq ;
2019-07-22 20:12:01 +03:00
cap - > cap_gen = gen ;
2022-08-05 07:33:03 +03:00
wake_up_all ( & ci - > i_cap_wq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* Return true if cap has not timed out and belongs to the current
* generation of the MDS session ( i . e . has not gone ' stale ' due to
* us losing touch with the mds ) .
*/
static int __cap_is_valid ( struct ceph_cap * cap )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & cap - > ci - > netfs . inode ;
struct ceph_client * cl = cap - > session - > s_mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
unsigned long ttl ;
2009-11-11 03:02:23 +03:00
u32 gen ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2021-06-04 19:03:09 +03:00
gen = atomic_read ( & cap - > session - > s_cap_gen ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ttl = cap - > session - > s_cap_ttl ;
2009-11-09 23:05:48 +03:00
if ( cap - > cap_gen < gen | | time_after_eq ( jiffies , ttl ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p issued %s but STALE (gen %u vs %u) \n " ,
inode , ceph_vinop ( inode ) , cap ,
ceph_cap_string ( cap - > issued ) , cap - > cap_gen , gen ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return 0 ;
}
return 1 ;
}
/*
* Return set of valid cap bits issued to us . Note that caps time
* out , and may be invalidated in bulk if the client session times out
* and session - > s_cap_gen is bumped .
*/
int __ceph_caps_issued ( struct ceph_inode_info * ci , int * implemented )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2014-04-18 05:57:11 +04:00
int have = ci - > i_snap_caps ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap * cap ;
struct rb_node * p ;
if ( implemented )
* implemented = 0 ;
for ( p = rb_first ( & ci - > i_caps ) ; p ; p = rb_next ( p ) ) {
cap = rb_entry ( p , struct ceph_cap , ci_node ) ;
if ( ! __cap_is_valid ( cap ) )
continue ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p issued %s \n " , inode ,
ceph_vinop ( inode ) , cap , ceph_cap_string ( cap - > issued ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
have | = cap - > issued ;
if ( implemented )
* implemented | = cap - > implemented ;
}
2013-07-02 08:40:20 +04:00
/*
* exclude caps issued by non - auth MDS , but are been revoking
* by the auth MDS . The non - auth MDS should be revoking / exporting
* these caps , but the message is delayed .
*/
if ( ci - > i_auth_cap ) {
cap = ci - > i_auth_cap ;
have & = ~ cap - > implemented | cap - > issued ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return have ;
}
/*
* Get cap bits issued by caps other than @ ocap
*/
int __ceph_caps_issued_other ( struct ceph_inode_info * ci , struct ceph_cap * ocap )
{
int have = ci - > i_snap_caps ;
struct ceph_cap * cap ;
struct rb_node * p ;
for ( p = rb_first ( & ci - > i_caps ) ; p ; p = rb_next ( p ) ) {
cap = rb_entry ( p , struct ceph_cap , ci_node ) ;
if ( cap = = ocap )
continue ;
if ( ! __cap_is_valid ( cap ) )
continue ;
have | = cap - > issued ;
}
return have ;
}
/*
* Move a cap to the end of the LRU ( oldest caps at list head , newest
* at list tail ) .
*/
static void __touch_cap ( struct ceph_cap * cap )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & cap - > ci - > netfs . inode ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_mds_session * s = cap - > session ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = s - > s_mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
spin_lock ( & s - > s_cap_lock ) ;
2017-08-20 21:22:02 +03:00
if ( ! s - > s_cap_iterator ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p mds%d \n " , inode ,
ceph_vinop ( inode ) , cap , s - > s_mds ) ;
2009-12-22 07:40:34 +03:00
list_move_tail ( & cap - > session_caps , & s - > s_caps ) ;
} else {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p mds%d NOP, iterating over caps \n " ,
inode , ceph_vinop ( inode ) , cap , s - > s_mds ) ;
2009-12-22 07:40:34 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
spin_unlock ( & s - > s_cap_lock ) ;
}
/*
* Check if we hold the given mask . If so , move the cap ( s ) to the
* front of their respective LRUs . ( This is the preferred way for
* callers to check for caps they want . )
*/
int __ceph_caps_issued_mask ( struct ceph_inode_info * ci , int mask , int touch )
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap * cap ;
struct rb_node * p ;
int have = ci - > i_snap_caps ;
if ( ( have & mask ) = = mask ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " mask %p %llx.%llx snap issued %s (mask %s) \n " ,
inode , ceph_vinop ( inode ) , ceph_cap_string ( have ) ,
ceph_cap_string ( mask ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return 1 ;
}
for ( p = rb_first ( & ci - > i_caps ) ; p ; p = rb_next ( p ) ) {
cap = rb_entry ( p , struct ceph_cap , ci_node ) ;
if ( ! __cap_is_valid ( cap ) )
continue ;
if ( ( cap - > issued & mask ) = = mask ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " mask %p %llx.%llx cap %p issued %s (mask %s) \n " ,
inode , ceph_vinop ( inode ) , cap ,
ceph_cap_string ( cap - > issued ) ,
ceph_cap_string ( mask ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( touch )
__touch_cap ( cap ) ;
return 1 ;
}
/* does a combination of caps satisfy mask? */
have | = cap - > issued ;
if ( ( have & mask ) = = mask ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " mask %p %llx.%llx combo issued %s (mask %s) \n " ,
inode , ceph_vinop ( inode ) ,
ceph_cap_string ( cap - > issued ) ,
ceph_cap_string ( mask ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( touch ) {
struct rb_node * q ;
2011-03-31 05:57:33 +04:00
/* touch this + preceding caps */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
__touch_cap ( cap ) ;
for ( q = rb_first ( & ci - > i_caps ) ; q ! = p ;
q = rb_next ( q ) ) {
cap = rb_entry ( q , struct ceph_cap ,
ci_node ) ;
if ( ! __cap_is_valid ( cap ) )
continue ;
2019-12-16 08:12:07 +03:00
if ( cap - > issued & mask )
__touch_cap ( cap ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
return 1 ;
}
}
return 0 ;
}
2020-03-20 06:45:00 +03:00
int __ceph_caps_issued_mask_metric ( struct ceph_inode_info * ci , int mask ,
int touch )
{
2023-06-12 05:50:38 +03:00
struct ceph_fs_client * fsc = ceph_sb_to_fs_client ( ci - > netfs . inode . i_sb ) ;
2020-03-20 06:45:00 +03:00
int r ;
r = __ceph_caps_issued_mask ( ci , mask , touch ) ;
if ( r )
ceph_update_cap_hit ( & fsc - > mdsc - > metric ) ;
else
ceph_update_cap_mis ( & fsc - > mdsc - > metric ) ;
return r ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Return true if mask caps are currently being revoked by an MDS .
*/
2013-07-02 08:40:21 +04:00
int __ceph_caps_revoking_other ( struct ceph_inode_info * ci ,
struct ceph_cap * ocap , int mask )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_cap * cap ;
struct rb_node * p ;
for ( p = rb_first ( & ci - > i_caps ) ; p ; p = rb_next ( p ) ) {
cap = rb_entry ( p , struct ceph_cap , ci_node ) ;
2013-11-22 09:50:45 +04:00
if ( cap ! = ocap & &
2013-07-02 08:40:21 +04:00
( cap - > implemented & ~ cap - > issued & mask ) )
return 1 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2013-07-02 08:40:21 +04:00
return 0 ;
}
int ceph_caps_revoking ( struct ceph_inode_info * ci , int mask )
{
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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2013-07-02 08:40:21 +04:00
int ret ;
spin_lock ( & ci - > i_ceph_lock ) ;
ret = __ceph_caps_revoking_other ( ci , NULL , mask ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx %s = %d \n " , inode , ceph_vinop ( inode ) ,
ceph_cap_string ( mask ) , ret ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return ret ;
}
int __ceph_caps_used ( struct ceph_inode_info * ci )
{
int used = 0 ;
if ( ci - > i_pin_ref )
used | = CEPH_CAP_PIN ;
if ( ci - > i_rd_ref )
used | = CEPH_CAP_FILE_RD ;
2015-06-16 15:48:56 +03:00
if ( ci - > i_rdcache_ref | |
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 23:46:04 +03:00
( S_ISREG ( ci - > netfs . inode . i_mode ) & &
ci - > netfs . inode . i_data . nrpages ) )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
used | = CEPH_CAP_FILE_CACHE ;
if ( ci - > i_wr_ref )
used | = CEPH_CAP_FILE_WR ;
2011-05-11 14:29:54 +04:00
if ( ci - > i_wb_ref | | ci - > i_wrbuffer_ref )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
used | = CEPH_CAP_FILE_BUFFER ;
2019-04-02 15:04:30 +03:00
if ( ci - > i_fx_ref )
used | = CEPH_CAP_FILE_EXCL ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return used ;
}
2020-03-05 15:21:00 +03:00
# define FMODE_WAIT_BIAS 1000
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* wanted , by virtue of open file modes
*/
int __ceph_caps_file_wanted ( struct ceph_inode_info * ci )
{
2020-03-05 15:21:00 +03:00
const int PIN_SHIFT = ffs ( CEPH_FILE_MODE_PIN ) ;
const int RD_SHIFT = ffs ( CEPH_FILE_MODE_RD ) ;
const int WR_SHIFT = ffs ( CEPH_FILE_MODE_WR ) ;
const int LAZY_SHIFT = ffs ( CEPH_FILE_MODE_LAZY ) ;
struct ceph_mount_options * opt =
2023-06-12 05:50:38 +03:00
ceph_inode_to_fs_client ( & ci - > netfs . inode ) - > mount_options ;
2020-03-05 15:21:00 +03:00
unsigned long used_cutoff = jiffies - opt - > caps_wanted_delay_max * HZ ;
unsigned long idle_cutoff = jiffies - opt - > caps_wanted_delay_min * HZ ;
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 23:46:04 +03:00
if ( S_ISDIR ( ci - > netfs . inode . i_mode ) ) {
2020-03-05 15:21:00 +03:00
int want = 0 ;
/* use used_cutoff here, to keep dir's wanted caps longer */
if ( ci - > i_nr_by_mode [ RD_SHIFT ] > 0 | |
time_after ( ci - > i_last_rd , used_cutoff ) )
want | = CEPH_CAP_ANY_SHARED ;
if ( ci - > i_nr_by_mode [ WR_SHIFT ] > 0 | |
time_after ( ci - > i_last_wr , used_cutoff ) ) {
want | = CEPH_CAP_ANY_SHARED | CEPH_CAP_FILE_EXCL ;
if ( opt - > flags & CEPH_MOUNT_OPT_ASYNC_DIROPS )
want | = CEPH_CAP_ANY_DIR_OPS ;
}
if ( want | | ci - > i_nr_by_mode [ PIN_SHIFT ] > 0 )
want | = CEPH_CAP_PIN ;
return want ;
} else {
int bits = 0 ;
if ( ci - > i_nr_by_mode [ RD_SHIFT ] > 0 ) {
if ( ci - > i_nr_by_mode [ RD_SHIFT ] > = FMODE_WAIT_BIAS | |
time_after ( ci - > i_last_rd , used_cutoff ) )
bits | = 1 < < RD_SHIFT ;
} else if ( time_after ( ci - > i_last_rd , idle_cutoff ) ) {
bits | = 1 < < RD_SHIFT ;
}
if ( ci - > i_nr_by_mode [ WR_SHIFT ] > 0 ) {
if ( ci - > i_nr_by_mode [ WR_SHIFT ] > = FMODE_WAIT_BIAS | |
time_after ( ci - > i_last_wr , used_cutoff ) )
bits | = 1 < < WR_SHIFT ;
} else if ( time_after ( ci - > i_last_wr , idle_cutoff ) ) {
bits | = 1 < < WR_SHIFT ;
}
/* check lazyio only when read/write is wanted */
if ( ( bits & ( CEPH_FILE_MODE_RDWR < < 1 ) ) & &
ci - > i_nr_by_mode [ LAZY_SHIFT ] > 0 )
bits | = 1 < < LAZY_SHIFT ;
return bits ? ceph_caps_for_mode ( bits > > 1 ) : 0 ;
2016-06-06 11:01:39 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2019-05-11 12:27:59 +03:00
/*
* wanted , by virtue of open file modes AND cap refs ( buffered / cached data )
*/
int __ceph_caps_wanted ( struct ceph_inode_info * ci )
{
int w = __ceph_caps_file_wanted ( ci ) | __ceph_caps_used ( ci ) ;
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 23:46:04 +03:00
if ( S_ISDIR ( ci - > netfs . inode . i_mode ) ) {
2020-02-18 22:12:45 +03:00
/* we want EXCL if holding caps of dir ops */
if ( w & CEPH_CAP_ANY_DIR_OPS )
w | = CEPH_CAP_FILE_EXCL ;
} else {
2019-05-11 12:27:59 +03:00
/* we want EXCL if dirty data */
if ( w & CEPH_CAP_FILE_BUFFER )
w | = CEPH_CAP_FILE_EXCL ;
}
return w ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Return caps we have registered with the MDS ( s ) as ' wanted ' .
*/
2017-01-29 17:15:47 +03:00
int __ceph_caps_mds_wanted ( struct ceph_inode_info * ci , bool check )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_cap * cap ;
struct rb_node * p ;
int mds_wanted = 0 ;
for ( p = rb_first ( & ci - > i_caps ) ; p ; p = rb_next ( p ) ) {
cap = rb_entry ( p , struct ceph_cap , ci_node ) ;
2017-01-29 17:15:47 +03:00
if ( check & & ! __cap_is_valid ( cap ) )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
continue ;
2014-03-08 05:51:45 +04:00
if ( cap = = ci - > i_auth_cap )
mds_wanted | = cap - > mds_wanted ;
else
mds_wanted | = ( cap - > mds_wanted & ~ CEPH_CAP_ANY_FILE_WR ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
return mds_wanted ;
}
2013-11-30 08:47:41 +04:00
int ceph_is_any_caps ( struct inode * inode )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
int ret ;
spin_lock ( & ci - > i_ceph_lock ) ;
2019-12-03 11:00:51 +03:00
ret = __ceph_is_any_real_caps ( ci ) ;
2013-11-30 08:47:41 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
return ret ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
2010-05-12 07:56:31 +04:00
* Remove a cap . Take steps to deal with a racing iterate_session_caps .
*
2011-11-30 21:47:09 +04:00
* caller should hold i_ceph_lock .
2010-02-23 00:59:00 +03:00
* caller will not hold session s_mutex if called from destroy_inode .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2013-09-22 06:15:58 +04:00
void __ceph_remove_cap ( struct ceph_cap * cap , bool queue_release )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_mds_session * session = cap - > session ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = session - > s_mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci = cap - > ci ;
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
2020-11-12 13:45:12 +03:00
struct ceph_mds_client * mdsc ;
2010-05-12 07:56:31 +04:00
int removed = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2020-11-12 13:45:12 +03:00
/* 'ci' being NULL means the remove have already occurred */
if ( ! ci ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " inode is NULL \n " ) ;
2020-11-12 13:45:12 +03:00
return ;
}
2021-08-25 16:45:45 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p from %p %llx.%llx \n " , cap , inode , ceph_vinop ( inode ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 05:50:38 +03:00
mdsc = ceph_inode_to_fs_client ( & ci - > netfs . inode ) - > mdsc ;
2020-11-12 13:45:12 +03:00
2019-10-25 16:05:24 +03:00
/* remove from inode's cap rbtree, and clear auth cap */
rb_erase ( & cap - > ci_node , & ci - > i_caps ) ;
2021-08-25 16:45:45 +03:00
if ( ci - > i_auth_cap = = cap )
2019-10-25 16:05:24 +03:00
ci - > i_auth_cap = NULL ;
ceph: fix iterate_caps removal race
We need to be able to iterate over all caps on a session with a
possibly slow callback on each cap. To allow this, we used to
prevent cap reordering while we were iterating. However, we were
not safe from races with removal: removing the 'next' cap would
make the next pointer from list_for_each_entry_safe be invalid,
and cause a lock up or similar badness.
Instead, we keep an iterator pointer in the session pointing to
the current cap. As before, we avoid reordering. For removal,
if the cap isn't the current cap we are iterating over, we are
fine. If it is, we clear cap->ci (to mark the cap as pending
removal) but leave it in the session list. In iterate_caps, we
can safely finish removal and get the next cap pointer.
While we're at it, clean up put_cap to not take a cap reservation
context, as it was never used.
Signed-off-by: Sage Weil <sage@newdream.net>
2010-02-16 22:39:45 +03:00
/* remove from session list */
spin_lock ( & session - > s_cap_lock ) ;
if ( session - > s_cap_iterator = = cap ) {
/* not yet, we are iterating over this very cap */
2023-06-12 04:04:07 +03:00
doutc ( cl , " delaying %p removal from session %p \n " , cap ,
cap - > session ) ;
ceph: fix iterate_caps removal race
We need to be able to iterate over all caps on a session with a
possibly slow callback on each cap. To allow this, we used to
prevent cap reordering while we were iterating. However, we were
not safe from races with removal: removing the 'next' cap would
make the next pointer from list_for_each_entry_safe be invalid,
and cause a lock up or similar badness.
Instead, we keep an iterator pointer in the session pointing to
the current cap. As before, we avoid reordering. For removal,
if the cap isn't the current cap we are iterating over, we are
fine. If it is, we clear cap->ci (to mark the cap as pending
removal) but leave it in the session list. In iterate_caps, we
can safely finish removal and get the next cap pointer.
While we're at it, clean up put_cap to not take a cap reservation
context, as it was never used.
Signed-off-by: Sage Weil <sage@newdream.net>
2010-02-16 22:39:45 +03:00
} else {
list_del_init ( & cap - > session_caps ) ;
session - > s_nr_caps - - ;
2020-06-30 10:52:16 +03:00
atomic64_dec ( & mdsc - > metric . total_caps ) ;
ceph: fix iterate_caps removal race
We need to be able to iterate over all caps on a session with a
possibly slow callback on each cap. To allow this, we used to
prevent cap reordering while we were iterating. However, we were
not safe from races with removal: removing the 'next' cap would
make the next pointer from list_for_each_entry_safe be invalid,
and cause a lock up or similar badness.
Instead, we keep an iterator pointer in the session pointing to
the current cap. As before, we avoid reordering. For removal,
if the cap isn't the current cap we are iterating over, we are
fine. If it is, we clear cap->ci (to mark the cap as pending
removal) but leave it in the session list. In iterate_caps, we
can safely finish removal and get the next cap pointer.
While we're at it, clean up put_cap to not take a cap reservation
context, as it was never used.
Signed-off-by: Sage Weil <sage@newdream.net>
2010-02-16 22:39:45 +03:00
cap - > session = NULL ;
2010-05-12 07:56:31 +04:00
removed = 1 ;
ceph: fix iterate_caps removal race
We need to be able to iterate over all caps on a session with a
possibly slow callback on each cap. To allow this, we used to
prevent cap reordering while we were iterating. However, we were
not safe from races with removal: removing the 'next' cap would
make the next pointer from list_for_each_entry_safe be invalid,
and cause a lock up or similar badness.
Instead, we keep an iterator pointer in the session pointing to
the current cap. As before, we avoid reordering. For removal,
if the cap isn't the current cap we are iterating over, we are
fine. If it is, we clear cap->ci (to mark the cap as pending
removal) but leave it in the session list. In iterate_caps, we
can safely finish removal and get the next cap pointer.
While we're at it, clean up put_cap to not take a cap reservation
context, as it was never used.
Signed-off-by: Sage Weil <sage@newdream.net>
2010-02-16 22:39:45 +03:00
}
2010-05-12 07:56:31 +04:00
/* protect backpointer with s_cap_lock: see iterate_session_caps */
cap - > ci = NULL ;
2015-05-14 12:22:42 +03:00
/*
* s_cap_reconnect is protected by s_cap_lock . no one changes
* s_cap_gen while session is in the reconnect state .
*/
if ( queue_release & &
2021-06-04 19:03:09 +03:00
( ! session - > s_cap_reconnect | |
cap - > cap_gen = = atomic_read ( & session - > s_cap_gen ) ) ) {
2015-05-14 12:22:42 +03:00
cap - > queue_release = 1 ;
if ( removed ) {
2019-01-14 12:21:19 +03:00
__ceph_queue_cap_release ( session , cap ) ;
2015-05-14 12:22:42 +03:00
removed = 0 ;
}
} else {
cap - > queue_release = 0 ;
}
cap - > cap_ino = ci - > i_vino . ino ;
ceph: fix iterate_caps removal race
We need to be able to iterate over all caps on a session with a
possibly slow callback on each cap. To allow this, we used to
prevent cap reordering while we were iterating. However, we were
not safe from races with removal: removing the 'next' cap would
make the next pointer from list_for_each_entry_safe be invalid,
and cause a lock up or similar badness.
Instead, we keep an iterator pointer in the session pointing to
the current cap. As before, we avoid reordering. For removal,
if the cap isn't the current cap we are iterating over, we are
fine. If it is, we clear cap->ci (to mark the cap as pending
removal) but leave it in the session list. In iterate_caps, we
can safely finish removal and get the next cap pointer.
While we're at it, clean up put_cap to not take a cap reservation
context, as it was never used.
Signed-off-by: Sage Weil <sage@newdream.net>
2010-02-16 22:39:45 +03:00
spin_unlock ( & session - > s_cap_lock ) ;
2010-05-12 07:56:31 +04:00
if ( removed )
2010-06-18 03:16:12 +04:00
ceph_put_cap ( mdsc , cap ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2019-12-03 11:00:51 +03:00
if ( ! __ceph_is_any_real_caps ( ci ) ) {
/* when reconnect denied, we remove session caps forcibly,
* i_wr_ref can be non - zero . If there are ongoing write ,
* keep i_snap_realm .
*/
if ( ci - > i_wr_ref = = 0 & & ci - > i_snap_realm )
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 23:46:04 +03:00
ceph_change_snap_realm ( & ci - > netfs . inode , NULL ) ;
2015-03-23 15:12:20 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
__cap_delay_cancel ( mdsc , ci ) ;
2019-12-03 11:00:51 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2023-06-09 10:15:47 +03:00
void ceph_remove_cap ( struct ceph_mds_client * mdsc , struct ceph_cap * cap ,
bool queue_release )
2021-08-25 16:45:45 +03:00
{
struct ceph_inode_info * ci = cap - > ci ;
struct ceph_fs_client * fsc ;
/* 'ci' being NULL means the remove have already occurred */
if ( ! ci ) {
2023-06-12 04:04:07 +03:00
doutc ( mdsc - > fsc - > client , " inode is NULL \n " ) ;
2021-08-25 16:45:45 +03:00
return ;
}
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2023-06-12 05:50:38 +03:00
fsc = ceph_inode_to_fs_client ( & ci - > netfs . inode ) ;
2021-08-25 16:45:45 +03:00
WARN_ON_ONCE ( ci - > i_auth_cap = = cap & &
! list_empty ( & ci - > i_dirty_item ) & &
! fsc - > blocklisted & &
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 23:46:04 +03:00
! ceph_inode_is_shutdown ( & ci - > netfs . inode ) ) ;
2021-08-25 16:45:45 +03:00
__ceph_remove_cap ( cap , queue_release ) ;
}
2016-11-10 15:42:03 +03:00
struct cap_msg_args {
struct ceph_mds_session * session ;
u64 ino , cid , follows ;
u64 flush_tid , oldest_flush_tid , size , max_size ;
u64 xattr_version ;
2019-06-06 15:06:40 +03:00
u64 change_attr ;
2016-11-10 15:42:03 +03:00
struct ceph_buffer * xattr_buf ;
2020-03-17 15:47:31 +03:00
struct ceph_buffer * old_xattr_buf ;
2019-05-29 19:23:14 +03:00
struct timespec64 atime , mtime , ctime , btime ;
2016-11-10 15:42:03 +03:00
int op , caps , wanted , dirty ;
u32 seq , issue_seq , mseq , time_warp_seq ;
2016-11-10 15:42:06 +03:00
u32 flags ;
2016-11-10 15:42:03 +03:00
kuid_t uid ;
kgid_t gid ;
umode_t mode ;
bool inline_data ;
2020-03-17 15:47:31 +03:00
bool wake ;
2022-08-25 16:31:06 +03:00
bool encrypted ;
2020-07-27 17:16:09 +03:00
u32 fscrypt_auth_len ;
u8 fscrypt_auth [ sizeof ( struct ceph_fscrypt_auth ) ] ; // for context
2016-11-10 15:42:03 +03:00
} ;
2020-03-30 14:20:27 +03:00
/* Marshal up the cap msg to the MDS */
static void encode_cap_msg ( struct ceph_msg * msg , struct cap_msg_args * arg )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_mds_caps * fc ;
2014-11-14 17:39:13 +03:00
void * p ;
2023-06-12 04:04:07 +03:00
struct ceph_mds_client * mdsc = arg - > session - > s_mdsc ;
struct ceph_osd_client * osdc = & mdsc - > fsc - > client - > osdc ;
doutc ( mdsc - > fsc - > client ,
" %s %llx %llx caps %s wanted %s dirty %s seq %u/%u "
" tid %llu/%llu mseq %u follows %lld size %llu/%llu "
" xattr_ver %llu xattr_len %d \n " ,
ceph_cap_op_name ( arg - > op ) , arg - > cid , arg - > ino ,
ceph_cap_string ( arg - > caps ) , ceph_cap_string ( arg - > wanted ) ,
ceph_cap_string ( arg - > dirty ) , arg - > seq , arg - > issue_seq ,
arg - > flush_tid , arg - > oldest_flush_tid , arg - > mseq , arg - > follows ,
arg - > size , arg - > max_size , arg - > xattr_version ,
arg - > xattr_buf ? ( int ) arg - > xattr_buf - > vec . iov_len : 0 ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2020-07-27 17:16:09 +03:00
msg - > hdr . version = cpu_to_le16 ( 12 ) ;
2016-11-10 15:42:03 +03:00
msg - > hdr . tid = cpu_to_le64 ( arg - > flush_tid ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2009-12-22 22:24:33 +03:00
fc = msg - > front . iov_base ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
memset ( fc , 0 , sizeof ( * fc ) ) ;
2016-11-10 15:42:03 +03:00
fc - > cap_id = cpu_to_le64 ( arg - > cid ) ;
fc - > op = cpu_to_le32 ( arg - > op ) ;
fc - > seq = cpu_to_le32 ( arg - > seq ) ;
fc - > issue_seq = cpu_to_le32 ( arg - > issue_seq ) ;
fc - > migrate_seq = cpu_to_le32 ( arg - > mseq ) ;
fc - > caps = cpu_to_le32 ( arg - > caps ) ;
fc - > wanted = cpu_to_le32 ( arg - > wanted ) ;
fc - > dirty = cpu_to_le32 ( arg - > dirty ) ;
fc - > ino = cpu_to_le64 ( arg - > ino ) ;
fc - > snap_follows = cpu_to_le64 ( arg - > follows ) ;
2022-08-25 16:31:06 +03:00
# if IS_ENABLED(CONFIG_FS_ENCRYPTION)
if ( arg - > encrypted )
fc - > size = cpu_to_le64 ( round_up ( arg - > size ,
CEPH_FSCRYPT_BLOCK_SIZE ) ) ;
else
# endif
fc - > size = cpu_to_le64 ( arg - > size ) ;
2016-11-10 15:42:03 +03:00
fc - > max_size = cpu_to_le64 ( arg - > max_size ) ;
2018-07-13 23:18:36 +03:00
ceph_encode_timespec64 ( & fc - > mtime , & arg - > mtime ) ;
ceph_encode_timespec64 ( & fc - > atime , & arg - > atime ) ;
ceph_encode_timespec64 ( & fc - > ctime , & arg - > ctime ) ;
2016-11-10 15:42:03 +03:00
fc - > time_warp_seq = cpu_to_le32 ( arg - > time_warp_seq ) ;
fc - > uid = cpu_to_le32 ( from_kuid ( & init_user_ns , arg - > uid ) ) ;
fc - > gid = cpu_to_le32 ( from_kgid ( & init_user_ns , arg - > gid ) ) ;
fc - > mode = cpu_to_le32 ( arg - > mode ) ;
fc - > xattr_version = cpu_to_le64 ( arg - > xattr_version ) ;
if ( arg - > xattr_buf ) {
msg - > middle = ceph_buffer_get ( arg - > xattr_buf ) ;
fc - > xattr_len = cpu_to_le32 ( arg - > xattr_buf - > vec . iov_len ) ;
msg - > hdr . middle_len = cpu_to_le32 ( arg - > xattr_buf - > vec . iov_len ) ;
2016-11-10 15:42:02 +03:00
}
2014-11-14 17:39:13 +03:00
p = fc + 1 ;
2016-11-10 15:42:05 +03:00
/* flock buffer size (version 2) */
2014-11-14 17:39:13 +03:00
ceph_encode_32 ( & p , 0 ) ;
2016-11-10 15:42:05 +03:00
/* inline version (version 4) */
2016-11-10 15:42:03 +03:00
ceph_encode_64 ( & p , arg - > inline_data ? 0 : CEPH_INLINE_NONE ) ;
2014-11-14 17:39:13 +03:00
/* inline data size */
ceph_encode_32 ( & p , 0 ) ;
2017-04-13 18:07:04 +03:00
/*
* osd_epoch_barrier ( version 5 )
* The epoch_barrier is protected osdc - > lock , so READ_ONCE here in
* case it was recently changed
*/
ceph_encode_32 ( & p , READ_ONCE ( osdc - > epoch_barrier ) ) ;
2016-11-10 15:42:05 +03:00
/* oldest_flush_tid (version 6) */
2016-11-10 15:42:03 +03:00
ceph_encode_64 ( & p , arg - > oldest_flush_tid ) ;
2014-11-14 17:39:13 +03:00
2016-11-10 15:42:05 +03:00
/*
* caller_uid / caller_gid ( version 7 )
*
* Currently , we don ' t properly track which caller dirtied the caps
* last , and force a flush of them when there is a conflict . For now ,
* just set this to 0 : 0 , to emulate how the MDS has worked up to now .
*/
ceph_encode_32 ( & p , 0 ) ;
ceph_encode_32 ( & p , 0 ) ;
/* pool namespace (version 8) (mds always ignores this) */
ceph_encode_32 ( & p , 0 ) ;
2019-06-06 15:06:40 +03:00
/* btime and change_attr (version 9) */
2019-05-29 19:23:14 +03:00
ceph_encode_timespec64 ( p , & arg - > btime ) ;
2016-11-10 15:42:05 +03:00
p + = sizeof ( struct ceph_timespec ) ;
2019-06-06 15:06:40 +03:00
ceph_encode_64 ( & p , arg - > change_attr ) ;
2016-11-10 15:42:05 +03:00
/* Advisory flags (version 10) */
2016-11-10 15:42:06 +03:00
ceph_encode_32 ( & p , arg - > flags ) ;
2020-07-27 17:16:09 +03:00
/* dirstats (version 11) - these are r/o on the client */
ceph_encode_64 ( & p , 0 ) ;
ceph_encode_64 ( & p , 0 ) ;
# if IS_ENABLED(CONFIG_FS_ENCRYPTION)
2022-08-25 16:31:06 +03:00
/*
* fscrypt_auth and fscrypt_file ( version 12 )
*
* fscrypt_auth holds the crypto context ( if any ) . fscrypt_file
* tracks the real i_size as an __le64 field ( and we use a rounded - up
* i_size in the traditional size field ) .
*/
2020-07-27 17:16:09 +03:00
ceph_encode_32 ( & p , arg - > fscrypt_auth_len ) ;
ceph_encode_copy ( & p , arg - > fscrypt_auth , arg - > fscrypt_auth_len ) ;
2022-08-25 16:31:06 +03:00
ceph_encode_32 ( & p , sizeof ( __le64 ) ) ;
ceph_encode_64 ( & p , arg - > size ) ;
2020-07-27 17:16:09 +03:00
# else /* CONFIG_FS_ENCRYPTION */
ceph_encode_32 ( & p , 0 ) ;
ceph_encode_32 ( & p , 0 ) ;
# endif /* CONFIG_FS_ENCRYPTION */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
2019-05-23 06:01:37 +03:00
* Queue cap releases when an inode is dropped from our cache .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2019-05-23 06:01:37 +03:00
void __ceph_remove_caps ( struct ceph_inode_info * ci )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-09 10:15:47 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_inode_to_fs_client ( inode ) - > mdsc ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct rb_node * p ;
2019-05-23 06:01:37 +03:00
/* lock i_ceph_lock, because ceph_d_revalidate(..., LOOKUP_RCU)
* may call __ceph_caps_issued_mask ( ) on a freeing inode . */
spin_lock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
p = rb_first ( & ci - > i_caps ) ;
while ( p ) {
struct ceph_cap * cap = rb_entry ( p , struct ceph_cap , ci_node ) ;
p = rb_next ( p ) ;
2023-06-09 10:15:47 +03:00
ceph_remove_cap ( mdsc , cap , true ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2019-05-23 06:01:37 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
2020-03-17 15:47:31 +03:00
* Prepare to send a cap message to an MDS . Update the cap state , and populate
* the arg struct with the parameters that will need to be sent . This should
* be done under the i_ceph_lock to guard against changes to cap state .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*
* Make note of max_size reported / requested from mds , revoked caps
* that have now been implemented .
*/
2020-03-17 15:47:31 +03:00
static void __prep_cap ( struct cap_msg_args * arg , struct ceph_cap * cap ,
int op , int flags , int used , int want , int retain ,
int flushing , u64 flush_tid , u64 oldest_flush_tid )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_inode_info * ci = cap - > ci ;
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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2017-10-18 14:34:25 +03:00
int held , revoking ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2020-03-17 15:47:31 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2020-01-14 23:06:40 +03:00
2010-02-10 00:41:47 +03:00
held = cap - > issued | cap - > implemented ;
revoking = cap - > implemented & ~ cap - > issued ;
retain & = ~ revoking ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p session %p %s -> %s (revoking %s) \n " ,
inode , ceph_vinop ( inode ) , cap , cap - > session ,
ceph_cap_string ( held ) , ceph_cap_string ( held & retain ) ,
ceph_cap_string ( revoking ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
BUG_ON ( ( retain & CEPH_CAP_PIN ) = = 0 ) ;
2020-03-05 15:21:01 +03:00
ci - > i_ceph_flags & = ~ CEPH_I_FLUSH ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > issued & = retain ; /* drop bits we don't want */
2020-03-17 15:47:31 +03:00
/*
* Wake up any waiters on wanted - > needed transition . This is due to
* the weird transition from buffered to sync IO . . . we need to flush
* dirty pages _before_ allowing sync writes to avoid reordering .
*/
arg - > wake = cap - > implemented & ~ cap - > issued ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > implemented & = cap - > issued | used ;
cap - > mds_wanted = want ;
2020-03-17 15:47:31 +03:00
arg - > session = cap - > session ;
arg - > ino = ceph_vino ( inode ) . ino ;
arg - > cid = cap - > cap_id ;
arg - > follows = flushing ? ci - > i_head_snapc - > seq : 0 ;
arg - > flush_tid = flush_tid ;
arg - > oldest_flush_tid = oldest_flush_tid ;
2021-04-09 22:58:35 +03:00
arg - > size = i_size_read ( inode ) ;
2020-03-17 15:47:31 +03:00
ci - > i_reported_size = arg - > size ;
arg - > max_size = ci - > i_wanted_max_size ;
2020-03-30 14:56:37 +03:00
if ( cap = = ci - > i_auth_cap ) {
if ( want & CEPH_CAP_ANY_FILE_WR )
ci - > i_requested_max_size = arg - > max_size ;
else
ci - > i_requested_max_size = 0 ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2010-08-23 02:16:41 +04:00
if ( flushing & CEPH_CAP_XATTR_EXCL ) {
2020-03-17 15:47:31 +03:00
arg - > old_xattr_buf = __ceph_build_xattrs_blob ( ci ) ;
arg - > xattr_version = ci - > i_xattrs . version ;
2024-02-01 14:37:16 +03:00
arg - > xattr_buf = ceph_buffer_get ( ci - > i_xattrs . blob ) ;
2016-11-10 15:42:03 +03:00
} else {
2020-03-17 15:47:31 +03:00
arg - > xattr_buf = NULL ;
arg - > old_xattr_buf = NULL ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2023-10-04 21:52:09 +03:00
arg - > mtime = inode_get_mtime ( inode ) ;
arg - > atime = inode_get_atime ( inode ) ;
2023-07-05 22:00:55 +03:00
arg - > ctime = inode_get_ctime ( inode ) ;
2020-03-17 15:47:31 +03:00
arg - > btime = ci - > i_btime ;
arg - > change_attr = inode_peek_iversion_raw ( inode ) ;
2016-11-10 15:42:03 +03:00
2020-03-17 15:47:31 +03:00
arg - > op = op ;
arg - > caps = cap - > implemented ;
arg - > wanted = want ;
arg - > dirty = flushing ;
2016-11-10 15:42:03 +03:00
2020-03-17 15:47:31 +03:00
arg - > seq = cap - > seq ;
arg - > issue_seq = cap - > issue_seq ;
arg - > mseq = cap - > mseq ;
arg - > time_warp_seq = ci - > i_time_warp_seq ;
2016-11-10 15:42:03 +03:00
2020-03-17 15:47:31 +03:00
arg - > uid = inode - > i_uid ;
arg - > gid = inode - > i_gid ;
arg - > mode = inode - > i_mode ;
2016-11-10 15:42:03 +03:00
2020-03-17 15:47:31 +03:00
arg - > inline_data = ci - > i_inline_version ! = CEPH_INLINE_NONE ;
2019-06-20 07:09:08 +03:00
if ( ! ( flags & CEPH_CLIENT_CAPS_PENDING_CAPSNAP ) & &
! list_empty ( & ci - > i_cap_snaps ) ) {
struct ceph_cap_snap * capsnap ;
list_for_each_entry_reverse ( capsnap , & ci - > i_cap_snaps , ci_item ) {
if ( capsnap - > cap_flush . tid )
break ;
if ( capsnap - > need_flush ) {
flags | = CEPH_CLIENT_CAPS_PENDING_CAPSNAP ;
break ;
}
}
}
2020-03-17 15:47:31 +03:00
arg - > flags = flags ;
2022-08-25 16:31:06 +03:00
arg - > encrypted = IS_ENCRYPTED ( inode ) ;
2020-07-27 17:16:09 +03:00
# if IS_ENABLED(CONFIG_FS_ENCRYPTION)
if ( ci - > fscrypt_auth_len & &
WARN_ON_ONCE ( ci - > fscrypt_auth_len > sizeof ( struct ceph_fscrypt_auth ) ) ) {
/* Don't set this if it's too big */
arg - > fscrypt_auth_len = 0 ;
} else {
arg - > fscrypt_auth_len = ci - > fscrypt_auth_len ;
memcpy ( arg - > fscrypt_auth , ci - > fscrypt_auth ,
min_t ( size_t , ci - > fscrypt_auth_len ,
sizeof ( arg - > fscrypt_auth ) ) ) ;
}
# endif /* CONFIG_FS_ENCRYPTION */
2020-03-17 15:47:31 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2022-08-25 16:31:06 +03:00
# if IS_ENABLED(CONFIG_FS_ENCRYPTION)
2020-07-27 17:16:09 +03:00
# define CAP_MSG_FIXED_FIELDS (sizeof(struct ceph_mds_caps) + \
2022-08-25 16:31:06 +03:00
4 + 8 + 4 + 4 + 8 + 4 + 4 + 4 + 8 + 8 + 4 + 8 + 8 + 4 + 4 + 8 )
2020-07-27 17:16:09 +03:00
static inline int cap_msg_size ( struct cap_msg_args * arg )
{
2022-08-25 16:31:06 +03:00
return CAP_MSG_FIXED_FIELDS + arg - > fscrypt_auth_len ;
2020-07-27 17:16:09 +03:00
}
# else
2022-08-25 16:31:06 +03:00
# define CAP_MSG_FIXED_FIELDS (sizeof(struct ceph_mds_caps) + \
4 + 8 + 4 + 4 + 8 + 4 + 4 + 4 + 8 + 8 + 4 + 8 + 8 + 4 + 4 )
2020-07-27 17:16:09 +03:00
static inline int cap_msg_size ( struct cap_msg_args * arg )
{
return CAP_MSG_FIXED_FIELDS ;
}
# endif /* CONFIG_FS_ENCRYPTION */
2020-03-17 15:47:31 +03:00
/*
* Send a cap msg on the given inode .
*
* Caller should hold snap_rwsem ( read ) , s_mutex .
*/
2020-03-30 20:07:23 +03:00
static void __send_cap ( struct cap_msg_args * arg , struct ceph_inode_info * ci )
2020-03-17 15:47:31 +03:00
{
2020-03-30 14:20:27 +03:00
struct ceph_msg * msg ;
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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2019-07-19 17:32:21 +03:00
2020-07-27 17:16:09 +03:00
msg = ceph_msg_new ( CEPH_MSG_CLIENT_CAPS , cap_msg_size ( arg ) , GFP_NOFS ,
false ) ;
2020-03-30 14:20:27 +03:00
if ( ! msg ) {
2023-06-12 04:04:07 +03:00
pr_err_client ( cl ,
" error allocating cap msg: ino (%llx.%llx) "
" flushing %s tid %llu, requeuing cap. \n " ,
ceph_vinop ( inode ) , ceph_cap_string ( arg - > dirty ) ,
arg - > flush_tid ) ;
2020-03-05 15:21:01 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
2020-03-30 20:07:23 +03:00
__cap_delay_requeue ( arg - > session - > s_mdsc , ci ) ;
2020-03-05 15:21:01 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2020-03-30 14:20:27 +03:00
return ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2020-03-30 14:20:27 +03:00
encode_cap_msg ( msg , arg ) ;
ceph_con_send ( & arg - > session - > s_con , msg ) ;
2020-03-17 15:47:31 +03:00
ceph_buffer_put ( arg - > old_xattr_buf ) ;
2024-02-01 14:37:16 +03:00
ceph_buffer_put ( arg - > xattr_buf ) ;
2020-03-17 15:47:31 +03:00
if ( arg - > wake )
wake_up_all ( & ci - > i_cap_wq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2016-07-04 13:06:41 +03:00
static inline int __send_flush_snap ( struct inode * inode ,
struct ceph_mds_session * session ,
struct ceph_cap_snap * capsnap ,
u32 mseq , u64 oldest_flush_tid )
{
2016-11-10 15:42:03 +03:00
struct cap_msg_args arg ;
2020-03-30 14:20:27 +03:00
struct ceph_msg * msg ;
2016-11-10 15:42:03 +03:00
arg . session = session ;
arg . ino = ceph_vino ( inode ) . ino ;
arg . cid = 0 ;
arg . follows = capsnap - > follows ;
arg . flush_tid = capsnap - > cap_flush . tid ;
arg . oldest_flush_tid = oldest_flush_tid ;
arg . size = capsnap - > size ;
arg . max_size = 0 ;
arg . xattr_version = capsnap - > xattr_version ;
arg . xattr_buf = capsnap - > xattr_blob ;
2020-03-17 15:47:31 +03:00
arg . old_xattr_buf = NULL ;
2016-11-10 15:42:03 +03:00
arg . atime = capsnap - > atime ;
arg . mtime = capsnap - > mtime ;
arg . ctime = capsnap - > ctime ;
2019-05-29 19:23:14 +03:00
arg . btime = capsnap - > btime ;
2019-06-06 15:06:40 +03:00
arg . change_attr = capsnap - > change_attr ;
2016-11-10 15:42:03 +03:00
arg . op = CEPH_CAP_OP_FLUSHSNAP ;
arg . caps = capsnap - > issued ;
arg . wanted = 0 ;
arg . dirty = capsnap - > dirty ;
arg . seq = 0 ;
arg . issue_seq = 0 ;
arg . mseq = mseq ;
arg . time_warp_seq = capsnap - > time_warp_seq ;
arg . uid = capsnap - > uid ;
arg . gid = capsnap - > gid ;
arg . mode = capsnap - > mode ;
arg . inline_data = capsnap - > inline_data ;
2016-11-10 15:42:06 +03:00
arg . flags = 0 ;
2020-03-17 15:47:31 +03:00
arg . wake = false ;
2022-08-25 16:31:06 +03:00
arg . encrypted = IS_ENCRYPTED ( inode ) ;
2016-11-10 15:42:03 +03:00
2022-08-25 16:31:06 +03:00
/* No fscrypt_auth changes from a capsnap.*/
2020-07-27 17:16:09 +03:00
arg . fscrypt_auth_len = 0 ;
msg = ceph_msg_new ( CEPH_MSG_CLIENT_CAPS , cap_msg_size ( & arg ) ,
GFP_NOFS , false ) ;
if ( ! msg )
return - ENOMEM ;
2016-11-10 15:42:03 +03:00
2020-03-30 14:20:27 +03:00
encode_cap_msg ( msg , & arg ) ;
ceph_con_send ( & arg . session - > s_con , msg ) ;
return 0 ;
2016-07-04 13:06:41 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* When a snapshot is taken , clients accumulate dirty metadata on
* inodes with capabilities in ceph_cap_snaps to describe the file
* state at the time the snapshot was taken . This must be flushed
* asynchronously back to the MDS once sync writes complete and dirty
* data is written out .
*
2021-06-14 22:38:39 +03:00
* Called under i_ceph_lock .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2016-07-05 16:08:07 +03:00
static void __ceph_flush_snaps ( struct ceph_inode_info * ci ,
struct ceph_mds_session * session )
2011-11-30 21:47:09 +04:00
__releases ( ci - > i_ceph_lock )
__acquires ( ci - > i_ceph_lock )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04: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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2016-07-05 16:08:07 +03:00
struct ceph_mds_client * mdsc = session - > s_mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap_snap * capsnap ;
2016-07-05 16:08:07 +03:00
u64 oldest_flush_tid = 0 ;
u64 first_tid = 1 , last_tid = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx session %p \n " , inode , ceph_vinop ( inode ) ,
session ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
list_for_each_entry ( capsnap , & ci - > i_cap_snaps , ci_item ) {
/*
* we need to wait for sync writes to complete and for dirty
* pages to be written out .
*/
if ( capsnap - > dirty_pages | | capsnap - > writing )
2010-09-15 02:50:59 +04:00
break ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2015-05-01 11:57:16 +03:00
/* should be removed by ceph_try_drop_cap_snap() */
BUG_ON ( ! capsnap - > need_flush ) ;
2010-04-01 20:33:46 +04:00
2010-09-17 19:03:08 +04:00
/* only flush each capsnap once */
2016-07-04 13:06:41 +03:00
if ( capsnap - > cap_flush . tid > 0 ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " already flushed %p, skipping \n " , capsnap ) ;
2010-09-17 19:03:08 +04:00
continue ;
}
2015-06-09 10:48:57 +03:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
2016-07-04 13:06:41 +03:00
capsnap - > cap_flush . tid = + + mdsc - > last_cap_flush_tid ;
list_add_tail ( & capsnap - > cap_flush . g_list ,
& mdsc - > cap_flush_list ) ;
2016-07-05 16:08:07 +03:00
if ( oldest_flush_tid = = 0 )
oldest_flush_tid = __get_oldest_flush_tid ( mdsc ) ;
2016-07-04 13:06:41 +03:00
if ( list_empty ( & ci - > i_flushing_item ) ) {
list_add_tail ( & ci - > i_flushing_item ,
& session - > s_cap_flushing ) ;
}
2015-06-09 10:48:57 +03:00
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
2016-07-04 13:06:41 +03:00
list_add_tail ( & capsnap - > cap_flush . i_list ,
& ci - > i_cap_flush_list ) ;
2016-07-05 16:08:07 +03:00
if ( first_tid = = 1 )
first_tid = capsnap - > cap_flush . tid ;
last_tid = capsnap - > cap_flush . tid ;
}
ci - > i_ceph_flags & = ~ CEPH_I_FLUSH_SNAPS ;
while ( first_tid < = last_tid ) {
struct ceph_cap * cap = ci - > i_auth_cap ;
2022-04-01 00:53:28 +03:00
struct ceph_cap_flush * cf = NULL , * iter ;
2016-07-05 16:08:07 +03:00
int ret ;
if ( ! ( cap & & cap - > session = = session ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx auth cap %p not mds%d, stop \n " ,
inode , ceph_vinop ( inode ) , cap , session - > s_mds ) ;
2016-07-05 16:08:07 +03:00
break ;
}
ret = - ENOENT ;
2022-04-01 00:53:28 +03:00
list_for_each_entry ( iter , & ci - > i_cap_flush_list , i_list ) {
if ( iter - > tid > = first_tid ) {
cf = iter ;
2016-07-05 16:08:07 +03:00
ret = 0 ;
break ;
}
}
if ( ret < 0 )
break ;
first_tid = cf - > tid + 1 ;
capsnap = container_of ( cf , struct ceph_cap_snap , cap_flush ) ;
2017-03-03 12:15:07 +03:00
refcount_inc ( & capsnap - > nref ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx capsnap %p tid %llu %s \n " , inode ,
ceph_vinop ( inode ) , capsnap , cf - > tid ,
ceph_cap_string ( capsnap - > dirty ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2016-07-05 16:08:07 +03:00
ret = __send_flush_snap ( inode , session , capsnap , cap - > mseq ,
oldest_flush_tid ) ;
if ( ret < 0 ) {
2023-06-12 04:04:07 +03:00
pr_err_client ( cl , " error sending cap flushsnap, "
" ino (%llx.%llx) tid %llu follows %llu \n " ,
ceph_vinop ( inode ) , cf - > tid ,
capsnap - > follows ) ;
2016-07-05 16:08:07 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2016-07-05 16:08:07 +03:00
ceph_put_cap_snap ( capsnap ) ;
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2016-07-05 16:08:07 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2016-07-05 16:08:07 +03:00
void ceph_flush_snaps ( struct ceph_inode_info * ci ,
struct ceph_mds_session * * psession )
{
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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_inode_to_fs_client ( inode ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2016-08-04 03:43:33 +03:00
struct ceph_mds_session * session = NULL ;
2023-06-01 03:59:31 +03:00
bool need_put = false ;
2016-07-05 16:08:07 +03:00
int mds ;
2016-08-04 03:43:33 +03:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx \n " , inode , ceph_vinop ( inode ) ) ;
2016-08-04 03:43:33 +03:00
if ( psession )
session = * psession ;
2016-07-05 16:08:07 +03:00
retry :
spin_lock ( & ci - > i_ceph_lock ) ;
if ( ! ( ci - > i_ceph_flags & CEPH_I_FLUSH_SNAPS ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " no capsnap needs flush, doing nothing \n " ) ;
2016-07-05 16:08:07 +03:00
goto out ;
}
if ( ! ci - > i_auth_cap ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " no auth cap (migrating?), doing nothing \n " ) ;
2016-07-05 16:08:07 +03:00
goto out ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2016-07-05 16:08:07 +03:00
mds = ci - > i_auth_cap - > session - > s_mds ;
if ( session & & session - > s_mds ! = mds ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " oops, wrong session %p mutex \n " , session ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ceph_put_mds_session ( session ) ;
2016-07-05 16:08:07 +03:00
session = NULL ;
}
if ( ! session ) {
spin_unlock ( & ci - > i_ceph_lock ) ;
mutex_lock ( & mdsc - > mutex ) ;
session = __ceph_lookup_mds_session ( mdsc , mds ) ;
mutex_unlock ( & mdsc - > mutex ) ;
goto retry ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2017-08-15 06:37:32 +03:00
// make sure flushsnap messages are sent in proper order.
2019-06-20 11:00:31 +03:00
if ( ci - > i_ceph_flags & CEPH_I_KICK_FLUSH )
2017-08-15 06:37:32 +03:00
__kick_flushing_caps ( mdsc , session , ci , 0 ) ;
2016-07-05 16:08:07 +03:00
__ceph_flush_snaps ( ci , session ) ;
out :
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2016-07-05 16:08:07 +03:00
2021-06-14 22:38:39 +03:00
if ( psession )
2016-07-05 16:08:07 +03:00
* psession = session ;
2021-06-14 22:38:39 +03:00
else
2016-07-05 16:08:07 +03:00
ceph_put_mds_session ( session ) ;
/* we flushed them all; remove this inode from the queue */
spin_lock ( & mdsc - > snap_flush_lock ) ;
2023-06-01 03:59:31 +03:00
if ( ! list_empty ( & ci - > i_snap_flush_item ) )
need_put = true ;
2016-07-05 16:08:07 +03:00
list_del_init ( & ci - > i_snap_flush_item ) ;
spin_unlock ( & mdsc - > snap_flush_lock ) ;
2023-06-01 03:59:31 +03:00
if ( need_put )
iput ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2009-10-16 05:13:53 +04:00
/*
2011-05-04 22:33:47 +04:00
* Mark caps dirty . If inode is newly dirty , return the dirty flags .
* Caller is then responsible for calling __mark_inode_dirty with the
* returned flags value .
2009-10-16 05:13:53 +04:00
*/
2015-06-10 12:26:13 +03:00
int __ceph_mark_dirty_caps ( struct ceph_inode_info * ci , int mask ,
struct ceph_cap_flush * * pcf )
2009-10-16 05:13:53 +04:00
{
2010-03-26 12:40:33 +03:00
struct ceph_mds_client * mdsc =
2023-06-12 05:50:38 +03:00
ceph_sb_to_fs_client ( ci - > netfs . inode . i_sb ) - > mdsc ;
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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2009-10-16 05:13:53 +04:00
int was = ci - > i_dirty_caps ;
int dirty = 0 ;
2020-02-25 22:08:33 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2015-03-24 06:36:08 +03:00
if ( ! ci - > i_auth_cap ) {
2023-06-12 04:04:07 +03:00
pr_warn_client ( cl , " %p %llx.%llx mask %s, "
" but no auth cap (session was closed?) \n " ,
inode , ceph_vinop ( inode ) ,
ceph_cap_string ( mask ) ) ;
2015-03-24 06:36:08 +03:00
return 0 ;
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx %s dirty %s -> %s \n " , inode ,
ceph_vinop ( inode ) , ceph_cap_string ( mask ) ,
ceph_cap_string ( was ) , ceph_cap_string ( was | mask ) ) ;
2009-10-16 05:13:53 +04:00
ci - > i_dirty_caps | = mask ;
if ( was = = 0 ) {
2020-04-02 00:07:52 +03:00
struct ceph_mds_session * session = ci - > i_auth_cap - > session ;
2015-06-10 12:26:13 +03:00
WARN_ON_ONCE ( ci - > i_prealloc_cap_flush ) ;
swap ( ci - > i_prealloc_cap_flush , * pcf ) ;
2015-05-01 12:49:16 +03:00
if ( ! ci - > i_head_snapc ) {
WARN_ON_ONCE ( ! rwsem_is_locked ( & mdsc - > snap_rwsem ) ) ;
2010-08-24 19:44:16 +04:00
ci - > i_head_snapc = ceph_get_snap_context (
ci - > i_snap_realm - > cached_context ) ;
2015-05-01 12:49:16 +03:00
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx now dirty snapc %p auth cap %p \n " ,
inode , ceph_vinop ( inode ) , ci - > i_head_snapc ,
ci - > i_auth_cap ) ;
2009-10-16 05:13:53 +04:00
BUG_ON ( ! list_empty ( & ci - > i_dirty_item ) ) ;
spin_lock ( & mdsc - > cap_dirty_lock ) ;
2020-04-02 00:07:52 +03:00
list_add ( & ci - > i_dirty_item , & session - > s_cap_dirty ) ;
2009-10-16 05:13:53 +04:00
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
if ( ci - > i_flushing_caps = = 0 ) {
2011-05-03 20:28:08 +04:00
ihold ( inode ) ;
2009-10-16 05:13:53 +04:00
dirty | = I_DIRTY_SYNC ;
}
2015-06-10 12:26:13 +03:00
} else {
WARN_ON_ONCE ( ! ci - > i_prealloc_cap_flush ) ;
2009-10-16 05:13:53 +04:00
}
BUG_ON ( list_empty ( & ci - > i_dirty_item ) ) ;
if ( ( ( was | ci - > i_flushing_caps ) & CEPH_CAP_FILE_BUFFER ) & &
( mask & CEPH_CAP_FILE_BUFFER ) )
dirty | = I_DIRTY_DATASYNC ;
2020-03-05 15:21:01 +03:00
__cap_delay_requeue ( mdsc , ci ) ;
2011-05-04 22:33:47 +04:00
return dirty ;
2009-10-16 05:13:53 +04:00
}
2015-06-10 12:26:13 +03:00
struct ceph_cap_flush * ceph_alloc_cap_flush ( void )
{
2021-08-18 16:38:42 +03:00
struct ceph_cap_flush * cf ;
cf = kmem_cache_alloc ( ceph_cap_flush_cachep , GFP_KERNEL ) ;
2021-08-29 21:18:24 +03:00
if ( ! cf )
return NULL ;
2021-08-18 16:38:42 +03:00
cf - > is_capsnap = false ;
return cf ;
2015-06-10 12:26:13 +03:00
}
void ceph_free_cap_flush ( struct ceph_cap_flush * cf )
{
if ( cf )
kmem_cache_free ( ceph_cap_flush_cachep , cf ) ;
}
2015-06-10 06:09:32 +03:00
static u64 __get_oldest_flush_tid ( struct ceph_mds_client * mdsc )
{
2016-07-06 06:12:56 +03:00
if ( ! list_empty ( & mdsc - > cap_flush_list ) ) {
2015-06-10 06:09:32 +03:00
struct ceph_cap_flush * cf =
2016-07-06 06:12:56 +03:00
list_first_entry ( & mdsc - > cap_flush_list ,
struct ceph_cap_flush , g_list ) ;
2015-06-10 06:09:32 +03:00
return cf - > tid ;
}
return 0 ;
}
2016-07-07 10:22:38 +03:00
/*
* Remove cap_flush from the mdsc ' s or inode ' s flushing cap list .
* Return true if caller needs to wake up flush waiters .
*/
2020-03-18 22:29:34 +03:00
static bool __detach_cap_flush_from_mdsc ( struct ceph_mds_client * mdsc ,
struct ceph_cap_flush * cf )
2016-07-07 10:22:38 +03:00
{
struct ceph_cap_flush * prev ;
bool wake = cf - > wake ;
2020-03-18 22:29:34 +03:00
if ( wake & & cf - > g_list . prev ! = & mdsc - > cap_flush_list ) {
prev = list_prev_entry ( cf , g_list ) ;
prev - > wake = true ;
wake = false ;
}
2021-08-18 16:38:42 +03:00
list_del_init ( & cf - > g_list ) ;
2020-03-18 22:29:34 +03:00
return wake ;
}
static bool __detach_cap_flush_from_ci ( struct ceph_inode_info * ci ,
struct ceph_cap_flush * cf )
{
struct ceph_cap_flush * prev ;
bool wake = cf - > wake ;
if ( wake & & cf - > i_list . prev ! = & ci - > i_cap_flush_list ) {
prev = list_prev_entry ( cf , i_list ) ;
prev - > wake = true ;
wake = false ;
2016-07-07 10:22:38 +03:00
}
2021-08-18 16:38:42 +03:00
list_del_init ( & cf - > i_list ) ;
2016-07-07 10:22:38 +03:00
return wake ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Add dirty inode to the flushing list . Assigned a seq number so we
* can wait for caps to flush without starving .
2009-10-15 01:24:19 +04:00
*
2019-07-08 19:27:57 +03:00
* Called under i_ceph_lock . Returns the flush tid .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2019-07-08 19:27:57 +03:00
static u64 __mark_caps_flushing ( struct inode * inode ,
2016-07-07 10:22:38 +03:00
struct ceph_mds_session * session , bool wake ,
2019-07-08 19:27:57 +03:00
u64 * oldest_flush_tid )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_fs_client ( inode - > i_sb ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2015-06-10 12:26:13 +03:00
struct ceph_cap_flush * cf = NULL ;
2009-10-15 01:24:19 +04:00
int flushing ;
2009-12-02 01:12:07 +03:00
2020-02-25 22:08:33 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2009-10-15 01:24:19 +04:00
BUG_ON ( ci - > i_dirty_caps = = 0 ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
BUG_ON ( list_empty ( & ci - > i_dirty_item ) ) ;
2015-06-10 12:26:13 +03:00
BUG_ON ( ! ci - > i_prealloc_cap_flush ) ;
2009-10-15 01:24:19 +04:00
flushing = ci - > i_dirty_caps ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " flushing %s, flushing_caps %s -> %s \n " ,
ceph_cap_string ( flushing ) ,
ceph_cap_string ( ci - > i_flushing_caps ) ,
ceph_cap_string ( ci - > i_flushing_caps | flushing ) ) ;
2009-10-15 01:24:19 +04:00
ci - > i_flushing_caps | = flushing ;
ci - > i_dirty_caps = 0 ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx now !dirty \n " , inode , ceph_vinop ( inode ) ) ;
2009-10-15 01:24:19 +04:00
2015-06-10 12:26:13 +03:00
swap ( cf , ci - > i_prealloc_cap_flush ) ;
2015-06-09 10:48:57 +03:00
cf - > caps = flushing ;
2016-07-07 10:22:38 +03:00
cf - > wake = wake ;
2015-06-09 10:48:57 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
2009-10-15 01:27:38 +04:00
list_del_init ( & ci - > i_dirty_item ) ;
2015-06-09 10:48:57 +03:00
cf - > tid = + + mdsc - > last_cap_flush_tid ;
2016-07-06 06:12:56 +03:00
list_add_tail ( & cf - > g_list , & mdsc - > cap_flush_list ) ;
2015-06-10 06:09:32 +03:00
* oldest_flush_tid = __get_oldest_flush_tid ( mdsc ) ;
2015-06-09 10:48:57 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( list_empty ( & ci - > i_flushing_item ) ) {
list_add_tail ( & ci - > i_flushing_item , & session - > s_cap_flushing ) ;
mdsc - > num_cap_flushing + + ;
}
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
2009-10-15 01:24:19 +04:00
2016-07-06 06:12:56 +03:00
list_add_tail ( & cf - > i_list , & ci - > i_cap_flush_list ) ;
2015-06-09 10:48:57 +03:00
2019-07-08 19:27:57 +03:00
return cf - > tid ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2010-02-17 21:43:37 +03:00
/*
* try to invalidate mapping pages without blocking .
*/
static int try_nonblocking_invalidate ( struct inode * inode )
2021-09-02 15:31:03 +03:00
__releases ( ci - > i_ceph_lock )
__acquires ( ci - > i_ceph_lock )
2010-02-17 21:43:37 +03:00
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2010-02-17 21:43:37 +03:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
u32 invalidating_gen = ci - > i_rdcache_gen ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2021-12-07 16:44:50 +03:00
ceph_fscache_invalidate ( inode , false ) ;
2010-02-17 21:43:37 +03:00
invalidate_mapping_pages ( & inode - > i_data , 0 , - 1 ) ;
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2010-02-17 21:43:37 +03:00
2010-09-17 21:46:44 +04:00
if ( inode - > i_data . nrpages = = 0 & &
2010-02-17 21:43:37 +03:00
invalidating_gen = = ci - > i_rdcache_gen ) {
/* success. */
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx success \n " , inode ,
ceph_vinop ( inode ) ) ;
2010-11-04 21:05:05 +03:00
/* save any racing async invalidate some trouble */
ci - > i_rdcache_revoking = ci - > i_rdcache_gen - 1 ;
2010-02-17 21:43:37 +03:00
return 0 ;
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx failed \n " , inode , ceph_vinop ( inode ) ) ;
2010-02-17 21:43:37 +03:00
return - 1 ;
}
2017-05-22 07:03:32 +03:00
bool __ceph_should_report_size ( struct ceph_inode_info * ci )
{
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 23:46:04 +03:00
loff_t size = i_size_read ( & ci - > netfs . inode ) ;
2017-05-22 07:03:32 +03:00
/* mds will adjust max size according to the reported size */
if ( ci - > i_flushing_caps & CEPH_CAP_FILE_WR )
return false ;
if ( size > = ci - > i_max_size )
return true ;
/* half of previous max_size increment has been used */
if ( ci - > i_max_size > ci - > i_reported_size & &
( size < < 1 ) > = ci - > i_max_size + ci - > i_reported_size )
return true ;
return false ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Swiss army knife function to examine currently used and wanted
* versus held caps . Release , flush , ack revoked caps to mds as
* appropriate .
*
* CHECK_CAPS_AUTHONLY - we should only check the auth cap
* CHECK_CAPS_FLUSH - we should flush any dirty caps immediately , without
* further delay .
*/
2022-10-18 04:03:29 +03:00
void ceph_check_caps ( struct ceph_inode_info * ci , int flags )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04: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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2020-09-03 16:01:39 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_mdsc ( inode - > i_sb ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap * cap ;
2015-06-10 06:09:32 +03:00
u64 flush_tid , oldest_flush_tid ;
2013-01-04 10:37:57 +04:00
int file_wanted , used , cap_used ;
2010-02-10 00:41:18 +03:00
int issued , implemented , want , retain , revoking , flushing = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int mds = - 1 ; /* keep track of how far we've gone through i_caps list
to avoid an infinite loop on retry */
struct rb_node * p ;
2016-07-06 10:37:42 +03:00
bool queue_invalidate = false ;
bool tried_invalidate = false ;
2022-04-27 09:14:41 +03:00
bool queue_writeback = false ;
2022-10-18 04:03:29 +03:00
struct ceph_mds_session * session = NULL ;
2021-06-04 18:01:25 +03:00
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2022-02-05 16:39:33 +03:00
if ( ci - > i_ceph_flags & CEPH_I_ASYNC_CREATE ) {
2022-10-17 17:17:35 +03:00
ci - > i_ceph_flags | = CEPH_I_ASYNC_CHECK_CAPS ;
2022-02-05 16:39:33 +03:00
/* Don't send messages until we get async create reply */
spin_unlock ( & ci - > i_ceph_lock ) ;
return ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ci - > i_ceph_flags & CEPH_I_FLUSH )
flags | = CHECK_CAPS_FLUSH ;
retry :
2020-10-06 19:24:19 +03:00
/* Caps wanted by virtue of active open files. */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
file_wanted = __ceph_caps_file_wanted ( ci ) ;
2020-10-06 19:24:19 +03:00
/* Caps which have active references against them */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
used = __ceph_caps_used ( ci ) ;
2020-10-06 19:24:19 +03:00
/*
* " issued " represents the current caps that the MDS wants us to have .
* " implemented " is the set that we have been granted , and includes the
* ones that have not yet been returned to the MDS ( the " revoking " set ,
* usually because they have outstanding references ) .
*/
2010-02-10 00:41:18 +03:00
issued = __ceph_caps_issued ( ci , & implemented ) ;
revoking = implemented & ~ issued ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2015-05-25 12:36:42 +03:00
want = file_wanted ;
2020-10-06 19:24:19 +03:00
/* The ones we currently want to retain (may be adjusted below) */
2015-05-25 12:36:42 +03:00
retain = file_wanted | used | CEPH_CAP_PIN ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ! mdsc - > stopping & & inode - > i_nlink > 0 ) {
2015-05-25 12:36:42 +03:00
if ( file_wanted ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
retain | = CEPH_CAP_ANY ; /* be greedy */
2015-03-26 14:06:00 +03:00
} else if ( S_ISDIR ( inode - > i_mode ) & &
( issued & CEPH_CAP_FILE_SHARED ) & &
2018-12-05 06:29:35 +03:00
__ceph_dir_is_complete ( ci ) ) {
2015-03-26 14:06:00 +03:00
/*
* If a directory is complete , we want to keep
* the exclusive cap . So that MDS does not end up
* revoking the shared cap on every create / unlink
* operation .
*/
2020-02-18 22:12:45 +03:00
if ( IS_RDONLY ( inode ) ) {
2018-12-05 06:29:35 +03:00
want = CEPH_CAP_ANY_SHARED ;
2020-02-18 22:12:45 +03:00
} else {
2020-03-05 15:21:00 +03:00
want | = CEPH_CAP_ANY_SHARED | CEPH_CAP_FILE_EXCL ;
2020-02-18 22:12:45 +03:00
}
2015-03-26 14:06:00 +03:00
retain | = want ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
} else {
2015-03-26 14:06:00 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
retain | = CEPH_CAP_ANY_SHARED ;
/*
* keep RD only if we didn ' t have the file open RW ,
* because then the mds would revoke it anyway to
* journal max_size = 0.
*/
if ( ci - > i_max_size = = 0 )
retain | = CEPH_CAP_ANY_RD ;
}
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx file_want %s used %s dirty %s "
" flushing %s issued %s revoking %s retain %s %s%s%s \n " ,
inode , ceph_vinop ( inode ) , ceph_cap_string ( file_wanted ) ,
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ceph_cap_string ( used ) , ceph_cap_string ( ci - > i_dirty_caps ) ,
ceph_cap_string ( ci - > i_flushing_caps ) ,
2010-02-10 00:41:18 +03:00
ceph_cap_string ( issued ) , ceph_cap_string ( revoking ) ,
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ceph_cap_string ( retain ) ,
( flags & CHECK_CAPS_AUTHONLY ) ? " AUTHONLY " : " " ,
2022-06-23 12:17:21 +03:00
( flags & CHECK_CAPS_FLUSH ) ? " FLUSH " : " " ,
( flags & CHECK_CAPS_NOINVAL ) ? " NOINVAL " : " " ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* If we no longer need to hold onto old our caps , and we may
* have cached pages , but don ' t want them , then try to invalidate .
* If we fail , it ' s because pages are locked . . . . try again later .
*/
2020-03-05 15:21:01 +03:00
if ( ( ! ( flags & CHECK_CAPS_NOINVAL ) | | mdsc - > stopping ) & &
2019-05-11 12:27:59 +03:00
S_ISREG ( inode - > i_mode ) & &
2016-05-18 15:58:26 +03:00
! ( ci - > i_wb_ref | | ci - > i_wrbuffer_ref ) & & /* no dirty pages... */
2015-06-16 15:48:56 +03:00
inode - > i_data . nrpages & & /* have cached pages */
2015-10-26 11:08:43 +03:00
( revoking & ( CEPH_CAP_FILE_CACHE |
CEPH_CAP_FILE_LAZYIO ) ) & & /* or revoking cache */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
! tried_invalidate ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " trying to invalidate on %p %llx.%llx \n " ,
inode , ceph_vinop ( inode ) ) ;
2010-02-17 21:43:37 +03:00
if ( try_nonblocking_invalidate ( inode ) < 0 ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " queuing invalidate \n " ) ;
2018-01-08 09:36:25 +03:00
queue_invalidate = true ;
ci - > i_rdcache_revoking = ci - > i_rdcache_gen ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2016-07-06 10:37:42 +03:00
tried_invalidate = true ;
2021-06-04 18:01:25 +03:00
goto retry ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
for ( p = rb_first ( & ci - > i_caps ) ; p ; p = rb_next ( p ) ) {
2020-04-02 01:27:25 +03:00
int mflags = 0 ;
2020-03-17 15:47:31 +03:00
struct cap_msg_args arg ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap = rb_entry ( p , struct ceph_cap , ci_node ) ;
/* avoid looping forever */
if ( mds > = cap - > mds | |
( ( flags & CHECK_CAPS_AUTHONLY ) & & cap ! = ci - > i_auth_cap ) )
continue ;
2020-10-06 19:24:19 +03:00
/*
* If we have an auth cap , we don ' t need to consider any
* overlapping caps as used .
*/
2013-01-04 10:37:57 +04:00
cap_used = used ;
if ( ci - > i_auth_cap & & cap ! = ci - > i_auth_cap )
cap_used & = ~ ci - > i_auth_cap - > issued ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
revoking = cap - > implemented & ~ cap - > issued ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " mds%d cap %p used %s issued %s implemented %s revoking %s \n " ,
cap - > mds , cap , ceph_cap_string ( cap_used ) ,
ceph_cap_string ( cap - > issued ) ,
ceph_cap_string ( cap - > implemented ) ,
ceph_cap_string ( revoking ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-09-13 11:18:34 +03:00
/* completed revocation? going down and there are no caps? */
if ( revoking ) {
if ( ( revoking & cap_used ) = = 0 ) {
doutc ( cl , " completed revocation of %s \n " ,
ceph_cap_string ( cap - > implemented & ~ cap - > issued ) ) ;
goto ack ;
}
/*
* If the " i_wrbuffer_ref " was increased by mmap or generic
* cache write just before the ceph_check_caps ( ) is called ,
* the Fb capability revoking will fail this time . Then we
* must wait for the BDI ' s delayed work to flush the dirty
* pages and to release the " i_wrbuffer_ref " , which will cost
* at most 5 seconds . That means the MDS needs to wait at
* most 5 seconds to finished the Fb capability ' s revocation .
*
* Let ' s queue a writeback for it .
*/
if ( S_ISREG ( inode - > i_mode ) & & ci - > i_wrbuffer_ref & &
( revoking & CEPH_CAP_FILE_BUFFER ) )
queue_writeback = true ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( cap = = ci - > i_auth_cap & &
( cap - > issued & CEPH_CAP_FILE_WR ) ) {
/* request larger max_size from MDS? */
if ( ci - > i_wanted_max_size > ci - > i_max_size & &
ci - > i_wanted_max_size > ci - > i_requested_max_size ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " requesting new max_size \n " ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
goto ack ;
}
/* approaching file_max? */
2017-05-22 07:03:32 +03:00
if ( __ceph_should_report_size ( ci ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " i_size approaching max_size \n " ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
goto ack ;
}
}
/* flush anything dirty? */
2016-07-07 13:34:45 +03:00
if ( cap = = ci - > i_auth_cap ) {
if ( ( flags & CHECK_CAPS_FLUSH ) & & ci - > i_dirty_caps ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " flushing dirty caps \n " ) ;
2016-07-07 13:34:45 +03:00
goto ack ;
}
if ( ci - > i_ceph_flags & CEPH_I_FLUSH_SNAPS ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " flushing snap caps \n " ) ;
2016-07-07 13:34:45 +03:00
goto ack ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/* want more caps from mds? */
2020-03-10 14:34:20 +03:00
if ( want & ~ cap - > mds_wanted ) {
if ( want & ~ ( cap - > mds_wanted | cap - > issued ) )
goto ack ;
if ( ! __cap_is_valid ( cap ) )
goto ack ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/* things we might delay */
2018-11-22 10:26:01 +03:00
if ( ( cap - > issued & ~ retain ) = = 0 )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
continue ; /* nope, all good */
ack :
2021-06-04 18:01:25 +03:00
ceph_put_mds_session ( session ) ;
session = ceph_get_mds_session ( cap - > session ) ;
2016-07-07 13:34:45 +03:00
/* kick flushing and flush snaps before sending normal
* cap message */
if ( cap = = ci - > i_auth_cap & &
( ci - > i_ceph_flags &
( CEPH_I_KICK_FLUSH | CEPH_I_FLUSH_SNAPS ) ) ) {
2019-06-20 11:00:31 +03:00
if ( ci - > i_ceph_flags & CEPH_I_KICK_FLUSH )
2017-08-15 06:37:32 +03:00
__kick_flushing_caps ( mdsc , session , ci , 0 ) ;
2016-07-05 16:08:07 +03:00
if ( ci - > i_ceph_flags & CEPH_I_FLUSH_SNAPS )
__ceph_flush_snaps ( ci , session ) ;
2021-06-04 18:01:25 +03:00
goto retry ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2015-06-09 10:48:57 +03:00
if ( cap = = ci - > i_auth_cap & & ci - > i_dirty_caps ) {
2019-07-08 19:27:57 +03:00
flushing = ci - > i_dirty_caps ;
flush_tid = __mark_caps_flushing ( inode , session , false ,
& oldest_flush_tid ) ;
2020-04-02 01:27:25 +03:00
if ( flags & CHECK_CAPS_FLUSH & &
list_empty ( & session - > s_cap_dirty ) )
mflags | = CEPH_CLIENT_CAPS_SYNC ;
2015-06-09 10:48:57 +03:00
} else {
2011-01-18 19:48:06 +03:00
flushing = 0 ;
2015-06-09 10:48:57 +03:00
flush_tid = 0 ;
2015-06-10 06:09:32 +03:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
oldest_flush_tid = __get_oldest_flush_tid ( mdsc ) ;
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
2015-06-09 10:48:57 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
mds = cap - > mds ; /* remember mds, so we don't repeat */
2020-04-02 01:27:25 +03:00
__prep_cap ( & arg , cap , CEPH_CAP_OP_UPDATE , mflags , cap_used ,
want , retain , flushing , flush_tid , oldest_flush_tid ) ;
2020-03-17 15:47:31 +03:00
2021-06-04 18:01:25 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2020-03-30 20:07:23 +03:00
__send_cap ( & arg , ci ) ;
2021-06-04 18:01:25 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
2020-03-17 15:47:31 +03:00
2011-11-30 21:47:09 +04:00
goto retry ; /* retake i_ceph_lock and restart our cap scan. */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2020-03-05 15:21:01 +03:00
/* periodically re-calculate caps wanted by open files */
if ( __ceph_is_any_real_caps ( ci ) & &
list_empty ( & ci - > i_cap_delay_list ) & &
( file_wanted & ~ CEPH_CAP_PIN ) & &
! ( used & ( CEPH_CAP_FILE_RD | CEPH_CAP_ANY_FILE_WR ) ) ) {
__cap_delay_requeue ( mdsc , ci ) ;
2020-03-05 15:21:00 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2021-06-04 18:01:25 +03:00
ceph_put_mds_session ( session ) ;
2022-04-27 09:14:41 +03:00
if ( queue_writeback )
ceph_queue_writeback ( inode ) ;
2010-02-10 00:41:18 +03:00
if ( queue_invalidate )
2010-02-10 02:24:44 +03:00
ceph_queue_invalidate ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* Try to flush dirty caps back to the auth mds .
*/
2015-06-09 10:48:57 +03:00
static int try_flush_caps ( struct inode * inode , u64 * ptid )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_fs_client ( inode - > i_sb ) - > mdsc ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2015-05-27 04:59:48 +03:00
int flushing = 0 ;
2015-06-10 06:09:32 +03:00
u64 flush_tid = 0 , oldest_flush_tid = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2019-06-20 11:09:37 +03:00
retry_locked :
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ci - > i_dirty_caps & & ci - > i_auth_cap ) {
struct ceph_cap * cap = ci - > i_auth_cap ;
2020-03-17 15:47:31 +03:00
struct cap_msg_args arg ;
2021-06-09 21:01:52 +03:00
struct ceph_mds_session * session = cap - > session ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2021-06-09 21:01:52 +03:00
if ( session - > s_state < CEPH_MDS_SESSION_OPEN ) {
2017-10-19 15:52:58 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
goto out ;
2017-10-19 15:52:58 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2019-06-20 11:09:37 +03:00
if ( ci - > i_ceph_flags &
( CEPH_I_KICK_FLUSH | CEPH_I_FLUSH_SNAPS ) ) {
if ( ci - > i_ceph_flags & CEPH_I_KICK_FLUSH )
__kick_flushing_caps ( mdsc , session , ci , 0 ) ;
if ( ci - > i_ceph_flags & CEPH_I_FLUSH_SNAPS )
__ceph_flush_snaps ( ci , session ) ;
goto retry_locked ;
}
2019-07-08 19:27:57 +03:00
flushing = ci - > i_dirty_caps ;
flush_tid = __mark_caps_flushing ( inode , session , true ,
& oldest_flush_tid ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2020-03-17 15:47:31 +03:00
__prep_cap ( & arg , cap , CEPH_CAP_OP_FLUSH , CEPH_CLIENT_CAPS_SYNC ,
2020-03-05 15:21:01 +03:00
__ceph_caps_used ( ci ) , __ceph_caps_wanted ( ci ) ,
( cap - > issued | cap - > implemented ) ,
flushing , flush_tid , oldest_flush_tid ) ;
2020-03-17 15:47:31 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2020-03-30 20:07:23 +03:00
__send_cap ( & arg , ci ) ;
2015-06-09 10:48:57 +03:00
} else {
2016-07-06 06:12:56 +03:00
if ( ! list_empty ( & ci - > i_cap_flush_list ) ) {
2015-06-09 10:48:57 +03:00
struct ceph_cap_flush * cf =
2016-07-06 06:12:56 +03:00
list_last_entry ( & ci - > i_cap_flush_list ,
2016-07-07 10:22:38 +03:00
struct ceph_cap_flush , i_list ) ;
cf - > wake = true ;
2015-06-09 10:48:57 +03:00
flush_tid = cf - > tid ;
}
flushing = ci - > i_flushing_caps ;
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
out :
2015-06-09 10:48:57 +03:00
* ptid = flush_tid ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return flushing ;
}
/*
* Return true if we ' ve flushed caps through the given flush_tid .
*/
2015-06-09 10:48:57 +03:00
static int caps_are_flushed ( struct inode * inode , u64 flush_tid )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2015-06-09 10:48:57 +03:00
int ret = 1 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2016-07-06 06:12:56 +03:00
if ( ! list_empty ( & ci - > i_cap_flush_list ) ) {
struct ceph_cap_flush * cf =
list_first_entry ( & ci - > i_cap_flush_list ,
struct ceph_cap_flush , i_list ) ;
2015-06-09 10:48:57 +03:00
if ( cf - > tid < = flush_tid )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ret = 0 ;
2015-05-27 04:59:48 +03:00
}
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return ret ;
}
2015-05-27 06:19:34 +03:00
/*
2022-04-18 15:04:51 +03:00
* flush the mdlog and wait for any unsafe requests to complete .
2015-05-27 06:19:34 +03:00
*/
2022-04-18 15:04:51 +03:00
static int flush_mdlog_and_wait_inode_unsafe_requests ( struct inode * inode )
2015-05-27 06:19:34 +03:00
{
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_fs_client ( inode - > i_sb ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2015-05-27 06:19:34 +03:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2015-10-27 13:36:06 +03:00
struct ceph_mds_request * req1 = NULL , * req2 = NULL ;
int ret , err = 0 ;
2015-05-27 06:19:34 +03:00
spin_lock ( & ci - > i_unsafe_lock ) ;
2015-10-27 13:36:06 +03:00
if ( S_ISDIR ( inode - > i_mode ) & & ! list_empty ( & ci - > i_unsafe_dirops ) ) {
req1 = list_last_entry ( & ci - > i_unsafe_dirops ,
struct ceph_mds_request ,
r_unsafe_dir_item ) ;
ceph_mdsc_get_request ( req1 ) ;
}
if ( ! list_empty ( & ci - > i_unsafe_iops ) ) {
req2 = list_last_entry ( & ci - > i_unsafe_iops ,
struct ceph_mds_request ,
r_unsafe_target_item ) ;
ceph_mdsc_get_request ( req2 ) ;
}
spin_unlock ( & ci - > i_unsafe_lock ) ;
2015-05-27 06:19:34 +03:00
2021-07-05 04:22:57 +03:00
/*
* Trigger to flush the journal logs in all the relevant MDSes
* manually , or in the worst case we must wait at most 5 seconds
* to wait the journal logs to be flushed by the MDSes periodically .
*/
2022-11-10 16:01:59 +03:00
if ( req1 | | req2 ) {
2021-07-05 04:22:57 +03:00
struct ceph_mds_request * req ;
2022-11-10 16:01:59 +03:00
struct ceph_mds_session * * sessions ;
struct ceph_mds_session * s ;
unsigned int max_sessions ;
2021-07-05 04:22:57 +03:00
int i ;
2022-11-10 16:01:59 +03:00
mutex_lock ( & mdsc - > mutex ) ;
max_sessions = mdsc - > max_sessions ;
2022-08-19 08:42:55 +03:00
sessions = kcalloc ( max_sessions , sizeof ( s ) , GFP_KERNEL ) ;
2022-01-12 07:29:04 +03:00
if ( ! sessions ) {
2022-11-10 16:01:59 +03:00
mutex_unlock ( & mdsc - > mutex ) ;
2022-01-12 07:29:04 +03:00
err = - ENOMEM ;
goto out ;
}
2021-07-05 04:22:57 +03:00
spin_lock ( & ci - > i_unsafe_lock ) ;
if ( req1 ) {
list_for_each_entry ( req , & ci - > i_unsafe_dirops ,
r_unsafe_dir_item ) {
s = req - > r_session ;
2022-04-14 04:07:21 +03:00
if ( ! s )
continue ;
2021-07-05 04:22:57 +03:00
if ( ! sessions [ s - > s_mds ] ) {
s = ceph_get_mds_session ( s ) ;
sessions [ s - > s_mds ] = s ;
}
}
}
if ( req2 ) {
list_for_each_entry ( req , & ci - > i_unsafe_iops ,
r_unsafe_target_item ) {
s = req - > r_session ;
2022-04-14 04:07:21 +03:00
if ( ! s )
continue ;
2021-07-05 04:22:57 +03:00
if ( ! sessions [ s - > s_mds ] ) {
s = ceph_get_mds_session ( s ) ;
sessions [ s - > s_mds ] = s ;
}
}
}
spin_unlock ( & ci - > i_unsafe_lock ) ;
/* the auth MDS */
spin_lock ( & ci - > i_ceph_lock ) ;
if ( ci - > i_auth_cap ) {
2022-11-10 16:01:59 +03:00
s = ci - > i_auth_cap - > session ;
if ( ! sessions [ s - > s_mds ] )
sessions [ s - > s_mds ] = ceph_get_mds_session ( s ) ;
2021-07-05 04:22:57 +03:00
}
spin_unlock ( & ci - > i_ceph_lock ) ;
2022-11-10 16:01:59 +03:00
mutex_unlock ( & mdsc - > mutex ) ;
2021-07-05 04:22:57 +03:00
/* send flush mdlog request to MDSes */
2022-01-12 07:29:04 +03:00
for ( i = 0 ; i < max_sessions ; i + + ) {
2021-07-05 04:22:57 +03:00
s = sessions [ i ] ;
if ( s ) {
send_flush_mdlog ( s ) ;
ceph_put_mds_session ( s ) ;
}
}
kfree ( sessions ) ;
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx wait on tid %llu %llu \n " , inode ,
ceph_vinop ( inode ) , req1 ? req1 - > r_tid : 0ULL ,
req2 ? req2 - > r_tid : 0ULL ) ;
2015-10-27 13:36:06 +03:00
if ( req1 ) {
ret = ! wait_for_completion_timeout ( & req1 - > r_safe_completion ,
ceph_timeout_jiffies ( req1 - > r_timeout ) ) ;
2015-05-27 06:19:34 +03:00
if ( ret )
2015-10-27 13:36:06 +03:00
err = - EIO ;
}
if ( req2 ) {
ret = ! wait_for_completion_timeout ( & req2 - > r_safe_completion ,
ceph_timeout_jiffies ( req2 - > r_timeout ) ) ;
if ( ret )
err = - EIO ;
}
2022-01-12 07:29:04 +03:00
out :
if ( req1 )
ceph_mdsc_put_request ( req1 ) ;
if ( req2 )
ceph_mdsc_put_request ( req2 ) ;
2015-10-27 13:36:06 +03:00
return err ;
2015-05-27 06:19:34 +03:00
}
2011-07-17 04:44:56 +04:00
int ceph_fsync ( struct file * file , loff_t start , loff_t end , int datasync )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2010-05-26 19:53:25 +04:00
struct inode * inode = file - > f_mapping - > host ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2015-06-09 10:48:57 +03:00
u64 flush_tid ;
2019-07-25 15:16:42 +03:00
int ret , err ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int dirty ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx%s \n " , inode , ceph_vinop ( inode ) ,
datasync ? " datasync " : " " ) ;
2016-06-15 11:29:18 +03:00
2017-07-25 17:50:41 +03:00
ret = file_write_and_wait_range ( file , start , end ) ;
2015-05-27 06:19:34 +03:00
if ( datasync )
goto out ;
2020-01-14 23:06:40 +03:00
ret = ceph_wait_on_async_create ( inode ) ;
if ( ret )
goto out ;
2015-06-09 10:48:57 +03:00
dirty = try_flush_caps ( inode , & flush_tid ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " dirty caps are %s \n " , ceph_cap_string ( dirty ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2022-04-18 15:04:51 +03:00
err = flush_mdlog_and_wait_inode_unsafe_requests ( inode ) ;
2015-05-27 06:19:34 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* only wait on non - file metadata writeback ( the mds
* can recover size and mtime , so we don ' t need to
* wait for that )
*/
2019-07-25 15:16:42 +03:00
if ( ! err & & ( dirty & ~ CEPH_CAP_ANY_FILE_WR ) ) {
err = wait_event_interruptible ( ci - > i_cap_wq ,
2015-05-27 06:19:34 +03:00
caps_are_flushed ( inode , flush_tid ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2019-07-25 15:16:42 +03:00
if ( err < 0 )
ret = err ;
2021-10-07 21:19:49 +03:00
err = file_check_and_advance_wb_err ( file ) ;
if ( err < 0 )
ret = err ;
2015-05-27 06:19:34 +03:00
out :
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx%s result=%d \n " , inode , ceph_vinop ( inode ) ,
datasync ? " datasync " : " " , ret ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return ret ;
}
/*
* Flush any dirty caps back to the mds . If we aren ' t asked to wait ,
* queue inode for flush but don ' t do so immediately , because we can
* get by with fewer MDS messages if we wait for data writeback to
* complete first .
*/
2010-01-18 03:53:08 +03:00
int ceph_write_inode ( struct inode * inode , struct writeback_control * wbc )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2015-06-09 10:48:57 +03:00
u64 flush_tid ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int err = 0 ;
int dirty ;
2018-01-30 05:02:30 +03:00
int wait = ( wbc - > sync_mode = = WB_SYNC_ALL & & ! wbc - > for_sync ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx wait=%d \n " , inode , ceph_vinop ( inode ) , wait ) ;
2021-12-07 16:44:50 +03:00
ceph_fscache_unpin_writeback ( inode , wbc ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( wait ) {
2022-02-05 16:39:33 +03:00
err = ceph_wait_on_async_create ( inode ) ;
if ( err )
return err ;
2015-06-09 10:48:57 +03:00
dirty = try_flush_caps ( inode , & flush_tid ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( dirty )
err = wait_event_interruptible ( ci - > i_cap_wq ,
caps_are_flushed ( inode , flush_tid ) ) ;
} else {
2010-03-26 12:40:33 +03:00
struct ceph_mds_client * mdsc =
2023-06-12 05:50:38 +03:00
ceph_sb_to_fs_client ( inode - > i_sb ) - > mdsc ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( __ceph_caps_dirty ( ci ) )
__cap_delay_requeue_front ( mdsc , ci ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
return err ;
}
2016-07-04 13:06:41 +03:00
static void __kick_flushing_caps ( struct ceph_mds_client * mdsc ,
struct ceph_mds_session * session ,
struct ceph_inode_info * ci ,
u64 oldest_flush_tid )
__releases ( ci - > i_ceph_lock )
__acquires ( ci - > i_ceph_lock )
2015-06-09 10:48:57 +03: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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2015-06-09 10:48:57 +03:00
struct ceph_cap * cap ;
struct ceph_cap_flush * cf ;
2016-07-04 13:06:41 +03:00
int ret ;
2015-06-09 10:48:57 +03:00
u64 first_tid = 0 ;
2019-06-20 07:09:08 +03:00
u64 last_snap_flush = 0 ;
2015-06-09 10:48:57 +03:00
2022-02-05 16:39:33 +03:00
/* Don't do anything until create reply comes in */
if ( ci - > i_ceph_flags & CEPH_I_ASYNC_CREATE )
return ;
2019-06-20 11:00:31 +03:00
ci - > i_ceph_flags & = ~ CEPH_I_KICK_FLUSH ;
2019-06-20 07:09:08 +03:00
list_for_each_entry_reverse ( cf , & ci - > i_cap_flush_list , i_list ) {
2021-08-18 16:38:42 +03:00
if ( cf - > is_capsnap ) {
2019-06-20 07:09:08 +03:00
last_snap_flush = cf - > tid ;
break ;
}
}
2016-07-06 06:12:56 +03:00
list_for_each_entry ( cf , & ci - > i_cap_flush_list , i_list ) {
if ( cf - > tid < first_tid )
continue ;
2015-06-09 10:48:57 +03:00
cap = ci - > i_auth_cap ;
if ( ! ( cap & & cap - > session = = session ) ) {
2023-06-12 04:04:07 +03:00
pr_err_client ( cl , " %p auth cap %p not mds%d ??? \n " ,
inode , cap , session - > s_mds ) ;
2015-06-09 10:48:57 +03:00
break ;
}
first_tid = cf - > tid + 1 ;
2021-08-18 16:38:42 +03:00
if ( ! cf - > is_capsnap ) {
2020-03-17 15:47:31 +03:00
struct cap_msg_args arg ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p tid %llu %s \n " ,
inode , ceph_vinop ( inode ) , cap , cf - > tid ,
ceph_cap_string ( cf - > caps ) ) ;
2020-03-17 15:47:31 +03:00
__prep_cap ( & arg , cap , CEPH_CAP_OP_FLUSH ,
2019-06-20 07:09:08 +03:00
( cf - > tid < last_snap_flush ?
CEPH_CLIENT_CAPS_PENDING_CAPSNAP : 0 ) ,
__ceph_caps_used ( ci ) ,
2016-07-04 13:06:41 +03:00
__ceph_caps_wanted ( ci ) ,
2019-06-20 07:09:08 +03:00
( cap - > issued | cap - > implemented ) ,
2016-07-04 13:06:41 +03:00
cf - > caps , cf - > tid , oldest_flush_tid ) ;
2020-03-17 15:47:31 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2020-03-30 20:07:23 +03:00
__send_cap ( & arg , ci ) ;
2016-07-04 13:06:41 +03:00
} else {
struct ceph_cap_snap * capsnap =
container_of ( cf , struct ceph_cap_snap ,
cap_flush ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx capsnap %p tid %llu %s \n " ,
inode , ceph_vinop ( inode ) , capsnap , cf - > tid ,
ceph_cap_string ( capsnap - > dirty ) ) ;
2016-07-04 13:06:41 +03:00
2017-03-03 12:15:07 +03:00
refcount_inc ( & capsnap - > nref ) ;
2016-07-04 13:06:41 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ret = __send_flush_snap ( inode , session , capsnap , cap - > mseq ,
oldest_flush_tid ) ;
if ( ret < 0 ) {
2023-06-12 04:04:07 +03:00
pr_err_client ( cl , " error sending cap flushsnap, "
" %p %llx.%llx tid %llu follows %llu \n " ,
inode , ceph_vinop ( inode ) , cf - > tid ,
capsnap - > follows ) ;
2016-07-04 13:06:41 +03:00
}
ceph_put_cap_snap ( capsnap ) ;
}
2016-07-06 06:12:56 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
2015-06-09 10:48:57 +03:00
}
}
2015-06-10 10:17:56 +03:00
void ceph_early_kick_flushing_caps ( struct ceph_mds_client * mdsc ,
struct ceph_mds_session * session )
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2015-06-10 10:17:56 +03:00
struct ceph_inode_info * ci ;
struct ceph_cap * cap ;
2016-07-04 13:06:41 +03:00
u64 oldest_flush_tid ;
2015-06-10 10:17:56 +03:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " mds%d \n " , session - > s_mds ) ;
2016-07-04 13:06:41 +03:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
oldest_flush_tid = __get_oldest_flush_tid ( mdsc ) ;
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
2015-06-10 10:17:56 +03:00
list_for_each_entry ( ci , & session - > s_cap_flushing , i_flushing_item ) {
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
2015-06-10 10:17:56 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
cap = ci - > i_auth_cap ;
if ( ! ( cap & & cap - > session = = session ) ) {
2023-06-12 04:04:07 +03:00
pr_err_client ( cl , " %p %llx.%llx auth cap %p not mds%d ??? \n " ,
inode , ceph_vinop ( inode ) , cap ,
session - > s_mds ) ;
2015-06-10 10:17:56 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
continue ;
}
/*
* if flushing caps were revoked , we re - send the cap flush
* in client reconnect stage . This guarantees MDS * processes
* the cap flush message before issuing the flushing caps to
* other client .
*/
if ( ( cap - > issued & ci - > i_flushing_caps ) ! =
ci - > i_flushing_caps ) {
2019-01-01 11:28:33 +03:00
/* encode_caps_cb() also will reset these sequence
* numbers . make sure sequence numbers in cap flush
* message match later reconnect message */
cap - > seq = 0 ;
cap - > issue_seq = 0 ;
cap - > mseq = 0 ;
2016-07-04 13:06:41 +03:00
__kick_flushing_caps ( mdsc , session , ci ,
oldest_flush_tid ) ;
2016-07-05 11:45:21 +03:00
} else {
ci - > i_ceph_flags | = CEPH_I_KICK_FLUSH ;
2015-06-10 10:17:56 +03:00
}
spin_unlock ( & ci - > i_ceph_lock ) ;
}
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
void ceph_kick_flushing_caps ( struct ceph_mds_client * mdsc ,
struct ceph_mds_session * session )
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci ;
2016-07-05 11:45:21 +03:00
struct ceph_cap * cap ;
2016-07-04 13:06:41 +03:00
u64 oldest_flush_tid ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2020-04-03 20:09:07 +03:00
lockdep_assert_held ( & session - > s_mutex ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " mds%d \n " , session - > s_mds ) ;
2016-07-04 13:06:41 +03:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
oldest_flush_tid = __get_oldest_flush_tid ( mdsc ) ;
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
list_for_each_entry ( ci , & session - > s_cap_flushing , i_flushing_item ) {
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
2016-07-04 13:06:41 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
2016-07-05 11:45:21 +03:00
cap = ci - > i_auth_cap ;
if ( ! ( cap & & cap - > session = = session ) ) {
2023-06-12 04:04:07 +03:00
pr_err_client ( cl , " %p %llx.%llx auth cap %p not mds%d ??? \n " ,
inode , ceph_vinop ( inode ) , cap ,
session - > s_mds ) ;
2016-07-05 11:45:21 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
continue ;
}
if ( ci - > i_ceph_flags & CEPH_I_KICK_FLUSH ) {
__kick_flushing_caps ( mdsc , session , ci ,
oldest_flush_tid ) ;
}
2016-07-04 13:06:41 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
2020-02-25 22:49:53 +03:00
void ceph_kick_flushing_inode_caps ( struct ceph_mds_session * session ,
struct ceph_inode_info * ci )
2011-01-18 19:56:01 +03:00
{
2020-02-25 22:49:53 +03:00
struct ceph_mds_client * mdsc = session - > s_mdsc ;
struct ceph_cap * cap = ci - > i_auth_cap ;
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
2020-02-25 22:49:53 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2011-01-18 19:56:01 +03:00
2023-06-12 04:04:07 +03:00
doutc ( mdsc - > fsc - > client , " %p %llx.%llx flushing %s \n " ,
inode , ceph_vinop ( inode ) ,
ceph_cap_string ( ci - > i_flushing_caps ) ) ;
2013-05-31 12:40:24 +04:00
2016-07-04 13:06:41 +03:00
if ( ! list_empty ( & ci - > i_cap_flush_list ) ) {
u64 oldest_flush_tid ;
2013-05-31 12:40:24 +04:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
list_move_tail ( & ci - > i_flushing_item ,
& cap - > session - > s_cap_flushing ) ;
2016-07-04 13:06:41 +03:00
oldest_flush_tid = __get_oldest_flush_tid ( mdsc ) ;
2013-05-31 12:40:24 +04:00
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
2016-07-04 13:06:41 +03:00
__kick_flushing_caps ( mdsc , session , ci , oldest_flush_tid ) ;
2011-01-18 19:56:01 +03:00
}
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Take references to capabilities we hold , so that we don ' t release
* them to the MDS prematurely .
*/
2020-01-14 17:23:49 +03:00
void ceph_take_cap_refs ( struct ceph_inode_info * ci , int got ,
2015-04-30 09:40:54 +03:00
bool snap_rwsem_locked )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2020-01-14 17:23:49 +03:00
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( got & CEPH_CAP_PIN )
ci - > i_pin_ref + + ;
if ( got & CEPH_CAP_FILE_RD )
ci - > i_rd_ref + + ;
if ( got & CEPH_CAP_FILE_CACHE )
ci - > i_rdcache_ref + + ;
2019-04-02 15:04:30 +03:00
if ( got & CEPH_CAP_FILE_EXCL )
ci - > i_fx_ref + + ;
2015-04-30 09:40:54 +03:00
if ( got & CEPH_CAP_FILE_WR ) {
if ( ci - > i_wr_ref = = 0 & & ! ci - > i_head_snapc ) {
BUG_ON ( ! snap_rwsem_locked ) ;
ci - > i_head_snapc = ceph_get_snap_context (
ci - > i_snap_realm - > cached_context ) ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ci - > i_wr_ref + + ;
2015-04-30 09:40:54 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( got & CEPH_CAP_FILE_BUFFER ) {
2011-05-11 14:29:54 +04:00
if ( ci - > i_wb_ref = = 0 )
2023-06-12 04:04:07 +03:00
ihold ( inode ) ;
2011-05-11 14:29:54 +04:00
ci - > i_wb_ref + + ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx wb %d -> %d (?) \n " , inode ,
ceph_vinop ( inode ) , ci - > i_wb_ref - 1 , ci - > i_wb_ref ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
/*
* Try to grab cap references . Specify those refs we @ want , and the
* minimal set we @ need . Also include the larger offset we are writing
* to ( when applicable ) , and check against max_size here as well .
* Note that caller is responsible for ensuring max_size increases are
* requested from the MDS .
2019-04-02 22:58:05 +03:00
*
2020-03-10 14:34:18 +03:00
* Returns 0 if caps were not able to be acquired ( yet ) , 1 if succeed ,
* or a negative error code . There are 3 speical error codes :
2021-09-07 20:54:34 +03:00
* - EAGAIN : need to sleep but non - blocking is specified
* - EFBIG : ask caller to call check_max_size ( ) and try again .
* - EUCLEAN : ask caller to call ceph_renew_caps ( ) and try again .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2019-07-25 15:16:45 +03:00
enum {
2020-03-05 15:21:00 +03:00
/* first 8 bits are reserved for CEPH_FILE_MODE_FOO */
NON_BLOCKING = ( 1 < < 8 ) ,
CHECK_FILELOCK = ( 1 < < 9 ) ,
2019-07-25 15:16:45 +03:00
} ;
2019-07-25 15:16:43 +03:00
static int try_get_cap_refs ( struct inode * inode , int need , int want ,
2019-07-25 15:16:45 +03:00
loff_t endoff , int flags , int * got )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2019-07-25 15:16:43 +03:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_inode_to_fs_client ( inode ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int ret = 0 ;
2015-01-09 10:56:18 +03:00
int have , implemented ;
2015-04-30 09:40:54 +03:00
bool snap_rwsem_locked = false ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx need %s want %s \n " , inode ,
ceph_vinop ( inode ) , ceph_cap_string ( need ) ,
ceph_cap_string ( want ) ) ;
2015-01-09 10:56:18 +03:00
2015-04-30 09:40:54 +03:00
again :
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2019-07-25 15:16:45 +03:00
if ( ( flags & CHECK_FILELOCK ) & &
( ci - > i_ceph_flags & CEPH_I_ERROR_FILELOCK ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx error filelock \n " , inode ,
ceph_vinop ( inode ) ) ;
2019-07-25 15:16:45 +03:00
ret = - EIO ;
goto out_unlock ;
}
2013-04-12 12:11:10 +04:00
/* finish pending truncate */
while ( ci - > i_truncate_pending ) {
spin_unlock ( & ci - > i_ceph_lock ) ;
2015-04-30 09:40:54 +03:00
if ( snap_rwsem_locked ) {
up_read ( & mdsc - > snap_rwsem ) ;
snap_rwsem_locked = false ;
}
2013-07-02 08:40:19 +04:00
__ceph_do_pending_vmtruncate ( inode ) ;
2013-04-12 12:11:10 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
}
2013-08-05 10:10:29 +04:00
have = __ceph_caps_issued ( ci , & implemented ) ;
if ( have & need & CEPH_CAP_FILE_WR ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( endoff > = 0 & & endoff > ( loff_t ) ci - > i_max_size ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx endoff %llu > maxsize %llu \n " ,
inode , ceph_vinop ( inode ) , endoff , ci - > i_max_size ) ;
2019-04-02 22:58:05 +03:00
if ( endoff > ci - > i_requested_max_size )
2021-09-07 20:54:34 +03:00
ret = ci - > i_auth_cap ? - EFBIG : - EUCLEAN ;
2014-11-14 17:10:07 +03:00
goto out_unlock ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* If a sync write is in progress , we must wait , so that we
* can get a final snapshot value for size + mtime .
*/
if ( __ceph_have_pending_cap_snap ( ci ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap_snap_pending \n " , inode ,
ceph_vinop ( inode ) ) ;
2014-11-14 17:10:07 +03:00
goto out_unlock ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
if ( ( have & need ) = = need ) {
/*
* Look at ( implemented & ~ have & not ) so that we keep waiting
* on transition from wanted - > needed caps . This is needed
* for WRBUFFER | WR - > WR to avoid a new WR sync write from
* going before a prior buffered writeback happens .
2022-08-11 08:00:53 +03:00
*
* For RDCACHE | RD - > RD , there is not need to wait and we can
* just exclude the revoking caps and force to sync read .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
int not = want & ~ ( have & need ) ;
int revoking = implemented & ~ have ;
2022-08-11 08:00:53 +03:00
int exclude = revoking & not ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx have %s but not %s (revoking %s) \n " ,
inode , ceph_vinop ( inode ) , ceph_cap_string ( have ) ,
ceph_cap_string ( not ) , ceph_cap_string ( revoking ) ) ;
2022-08-11 08:00:53 +03:00
if ( ! exclude | | ! ( exclude & CEPH_CAP_FILE_BUFFER ) ) {
2015-04-30 09:40:54 +03:00
if ( ! snap_rwsem_locked & &
! ci - > i_head_snapc & &
( need & CEPH_CAP_FILE_WR ) ) {
if ( ! down_read_trylock ( & mdsc - > snap_rwsem ) ) {
/*
* we can not call down_read ( ) when
* task isn ' t in TASK_RUNNING state
*/
2019-07-25 15:16:45 +03:00
if ( flags & NON_BLOCKING ) {
2019-04-02 22:58:05 +03:00
ret = - EAGAIN ;
2015-04-30 09:40:54 +03:00
goto out_unlock ;
}
spin_unlock ( & ci - > i_ceph_lock ) ;
down_read ( & mdsc - > snap_rwsem ) ;
snap_rwsem_locked = true ;
goto again ;
}
snap_rwsem_locked = true ;
}
2020-02-18 16:17:08 +03:00
if ( ( have & want ) = = want )
2022-08-11 08:00:53 +03:00
* got = need | ( want & ~ exclude ) ;
2020-02-18 16:17:08 +03:00
else
* got = need ;
2020-01-14 17:23:49 +03:00
ceph_take_cap_refs ( ci , * got , true ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ret = 1 ;
}
} else {
2015-01-05 06:04:04 +03:00
int session_readonly = false ;
2020-03-05 15:20:59 +03:00
int mds_wanted ;
2019-05-11 12:27:59 +03:00
if ( ci - > i_auth_cap & &
( need & ( CEPH_CAP_FILE_WR | CEPH_CAP_FILE_EXCL ) ) ) {
2015-01-05 06:04:04 +03:00
struct ceph_mds_session * s = ci - > i_auth_cap - > session ;
spin_lock ( & s - > s_cap_lock ) ;
session_readonly = s - > s_readonly ;
spin_unlock ( & s - > s_cap_lock ) ;
}
if ( session_readonly ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx need %s but mds%d readonly \n " ,
inode , ceph_vinop ( inode ) , ceph_cap_string ( need ) ,
ci - > i_auth_cap - > mds ) ;
2019-04-02 22:58:05 +03:00
ret = - EROFS ;
2015-01-05 06:04:04 +03:00
goto out_unlock ;
}
2021-08-31 20:39:13 +03:00
if ( ceph_inode_is_shutdown ( inode ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx inode is shutdown \n " ,
inode , ceph_vinop ( inode ) ) ;
2021-08-31 20:39:13 +03:00
ret = - ESTALE ;
2020-03-05 15:20:59 +03:00
goto out_unlock ;
}
mds_wanted = __ceph_caps_mds_wanted ( ci , false ) ;
if ( need & ~ mds_wanted ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx need %s > mds_wanted %s \n " ,
inode , ceph_vinop ( inode ) , ceph_cap_string ( need ) ,
ceph_cap_string ( mds_wanted ) ) ;
2021-09-07 20:54:34 +03:00
ret = - EUCLEAN ;
2020-03-05 15:20:59 +03:00
goto out_unlock ;
2015-07-01 11:27:46 +03:00
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx have %s need %s \n " , inode ,
ceph_vinop ( inode ) , ceph_cap_string ( have ) ,
ceph_cap_string ( need ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2014-11-14 17:10:07 +03:00
out_unlock :
2020-03-05 15:21:00 +03:00
__ceph_touch_fmode ( ci , mdsc , flags ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2015-04-30 09:40:54 +03:00
if ( snap_rwsem_locked )
up_read ( & mdsc - > snap_rwsem ) ;
2014-11-14 17:10:07 +03:00
2020-03-20 06:45:00 +03:00
if ( ! ret )
ceph_update_cap_mis ( & mdsc - > metric ) ;
else if ( ret = = 1 )
ceph_update_cap_hit ( & mdsc - > metric ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx ret %d got %s \n " , inode ,
ceph_vinop ( inode ) , ret , ceph_cap_string ( * got ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return ret ;
}
/*
* Check the offset we are writing up to against our current
* max_size . If necessary , tell the MDS we want to write to
* a larger offset .
*/
static void check_max_size ( struct inode * inode , loff_t endoff )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int check = 0 ;
/* do we need to explicitly request a larger max_size? */
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2013-08-05 10:10:29 +04:00
if ( endoff > = ci - > i_max_size & & endoff > ci - > i_wanted_max_size ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " write %p %llx.%llx at large endoff %llu, req max_size \n " ,
inode , ceph_vinop ( inode ) , endoff ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ci - > i_wanted_max_size = endoff ;
}
2013-08-05 10:10:29 +04:00
/* duplicate ceph_check_caps()'s logic */
if ( ci - > i_auth_cap & &
( ci - > i_auth_cap - > issued & CEPH_CAP_FILE_WR ) & &
ci - > i_wanted_max_size > ci - > i_max_size & &
ci - > i_wanted_max_size > ci - > i_requested_max_size )
check = 1 ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( check )
2022-10-18 04:03:29 +03:00
ceph_check_caps ( ci , CHECK_CAPS_AUTHONLY ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2020-03-05 15:21:00 +03:00
static inline int get_used_fmode ( int caps )
{
int fmode = 0 ;
if ( caps & CEPH_CAP_FILE_RD )
fmode | = CEPH_FILE_MODE_RD ;
if ( caps & CEPH_CAP_FILE_WR )
fmode | = CEPH_FILE_MODE_WR ;
return fmode ;
}
2019-07-25 15:16:43 +03:00
int ceph_try_get_caps ( struct inode * inode , int need , int want ,
2018-10-15 18:45:57 +03:00
bool nonblock , int * got )
2016-10-25 05:51:55 +03:00
{
2020-03-05 15:21:00 +03:00
int ret , flags ;
2016-10-25 05:51:55 +03:00
BUG_ON ( need & ~ CEPH_CAP_FILE_RD ) ;
2020-02-18 22:12:45 +03:00
BUG_ON ( want & ~ ( CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_LAZYIO |
CEPH_CAP_FILE_SHARED | CEPH_CAP_FILE_EXCL |
CEPH_CAP_ANY_DIR_OPS ) ) ;
if ( need ) {
ret = ceph_pool_perm_check ( inode , need ) ;
if ( ret < 0 )
return ret ;
}
2016-10-25 05:51:55 +03:00
2020-03-05 15:21:00 +03:00
flags = get_used_fmode ( need | want ) ;
if ( nonblock )
flags | = NON_BLOCKING ;
ret = try_get_cap_refs ( inode , need , want , 0 , flags , got ) ;
2020-03-10 14:34:18 +03:00
/* three special error codes */
2021-09-07 20:54:34 +03:00
if ( ret = = - EAGAIN | | ret = = - EFBIG | | ret = = - EUCLEAN )
2020-03-10 14:34:18 +03:00
ret = 0 ;
return ret ;
2016-10-25 05:51:55 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Wait for caps , and take cap references . If we can ' t get a WR cap
* due to a small max_size , make sure we check_max_size ( and possibly
* ask the mds ) so we don ' t get hung up indefinitely .
*/
2022-08-25 16:31:11 +03:00
int __ceph_get_caps ( struct inode * inode , struct ceph_file_info * fi , int need ,
int want , loff_t endoff , int * got )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2019-07-25 15:16:43 +03:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 05:50:38 +03:00
struct ceph_fs_client * fsc = ceph_inode_to_fs_client ( inode ) ;
2019-07-25 15:16:45 +03:00
int ret , _got , flags ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2019-07-25 15:16:43 +03:00
ret = ceph_pool_perm_check ( inode , need ) ;
2015-04-27 10:33:28 +03:00
if ( ret < 0 )
return ret ;
2022-08-25 16:31:11 +03:00
if ( fi & & ( fi - > fmode & CEPH_FILE_MODE_WR ) & &
2019-07-25 15:16:46 +03:00
fi - > filp_gen ! = READ_ONCE ( fsc - > filp_gen ) )
return - EBADF ;
2020-03-05 15:21:00 +03:00
flags = get_used_fmode ( need | want ) ;
2015-04-30 09:40:54 +03:00
while ( true ) {
2020-03-05 15:21:00 +03:00
flags & = CEPH_FILE_MODE_MASK ;
2022-11-17 05:43:21 +03:00
if ( vfs_inode_has_locks ( inode ) )
2020-03-05 15:21:00 +03:00
flags | = CHECK_FILELOCK ;
2015-04-30 09:40:54 +03:00
_got = 0 ;
2019-07-25 15:16:43 +03:00
ret = try_get_cap_refs ( inode , need , want , endoff ,
2019-07-25 15:16:45 +03:00
flags , & _got ) ;
2020-03-10 14:34:18 +03:00
WARN_ON_ONCE ( ret = = - EAGAIN ) ;
2019-05-20 04:50:09 +03:00
if ( ! ret ) {
2019-11-20 20:00:59 +03:00
struct ceph_mds_client * mdsc = fsc - > mdsc ;
struct cap_wait cw ;
2016-10-11 12:04:09 +03:00
DEFINE_WAIT_FUNC ( wait , woken_wake_function ) ;
2019-11-20 20:00:59 +03:00
ceph: fix inode number handling on arches with 32-bit ino_t
Tuan and Ulrich mentioned that they were hitting a problem on s390x,
which has a 32-bit ino_t value, even though it's a 64-bit arch (for
historical reasons).
I think the current handling of inode numbers in the ceph driver is
wrong. It tries to use 32-bit inode numbers on 32-bit arches, but that's
actually not a problem. 32-bit arches can deal with 64-bit inode numbers
just fine when userland code is compiled with LFS support (the common
case these days).
What we really want to do is just use 64-bit numbers everywhere, unless
someone has mounted with the ino32 mount option. In that case, we want
to ensure that we hash the inode number down to something that will fit
in 32 bits before presenting the value to userland.
Add new helper functions that do this, and only do the conversion before
presenting these values to userland in getattr and readdir.
The inode table hashvalue is changed to just cast the inode number to
unsigned long, as low-order bits are the most likely to vary anyway.
While it's not strictly required, we do want to put something in
inode->i_ino. Instead of basing it on BITS_PER_LONG, however, base it on
the size of the ino_t type.
NOTE: This is a user-visible change on 32-bit arches:
1/ inode numbers will be seen to have changed between kernel versions.
32-bit arches will see large inode numbers now instead of the hashed
ones they saw before.
2/ any really old software not built with LFS support may start failing
stat() calls with -EOVERFLOW on inode numbers >2^32. Nothing much we
can do about these, but hopefully the intersection of people running
such code on ceph will be very small.
The workaround for both problems is to mount with "-o ino32".
[ idryomov: changelog tweak ]
URL: https://tracker.ceph.com/issues/46828
Reported-by: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Reported-and-Tested-by: Tuan Hoang1 <Tuan.Hoang1@ibm.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2020-08-18 15:03:48 +03:00
cw . ino = ceph_ino ( inode ) ;
2019-11-20 20:00:59 +03:00
cw . tgid = current - > tgid ;
cw . need = need ;
cw . want = want ;
spin_lock ( & mdsc - > caps_list_lock ) ;
list_add ( & cw . list , & mdsc - > cap_wait_list ) ;
spin_unlock ( & mdsc - > caps_list_lock ) ;
2020-03-05 15:21:00 +03:00
/* make sure used fmode not timeout */
ceph_get_fmode ( ci , flags , FMODE_WAIT_BIAS ) ;
2016-10-11 12:04:09 +03:00
add_wait_queue ( & ci - > i_cap_wq , & wait ) ;
2019-07-25 15:16:45 +03:00
flags | = NON_BLOCKING ;
2019-07-25 15:16:43 +03:00
while ( ! ( ret = try_get_cap_refs ( inode , need , want ,
2019-07-25 15:16:45 +03:00
endoff , flags , & _got ) ) ) {
2016-12-22 11:05:43 +03:00
if ( signal_pending ( current ) ) {
ret = - ERESTARTSYS ;
break ;
}
2016-10-11 12:04:09 +03:00
wait_woken ( & wait , TASK_INTERRUPTIBLE , MAX_SCHEDULE_TIMEOUT ) ;
2016-12-22 11:05:43 +03:00
}
2016-10-11 12:04:09 +03:00
remove_wait_queue ( & ci - > i_cap_wq , & wait ) ;
2020-03-05 15:21:00 +03:00
ceph_put_fmode ( ci , flags , FMODE_WAIT_BIAS ) ;
2019-11-20 20:00:59 +03:00
spin_lock ( & mdsc - > caps_list_lock ) ;
list_del ( & cw . list ) ;
spin_unlock ( & mdsc - > caps_list_lock ) ;
2019-05-20 04:50:09 +03:00
if ( ret = = - EAGAIN )
2015-04-30 09:40:54 +03:00
continue ;
2016-04-08 10:27:16 +03:00
}
2019-07-25 15:16:46 +03:00
2022-08-25 16:31:11 +03:00
if ( fi & & ( fi - > fmode & CEPH_FILE_MODE_WR ) & &
2019-07-25 15:16:46 +03:00
fi - > filp_gen ! = READ_ONCE ( fsc - > filp_gen ) ) {
if ( ret > = 0 & & _got )
ceph_put_cap_refs ( ci , _got ) ;
return - EBADF ;
}
2019-05-20 04:50:09 +03:00
if ( ret < 0 ) {
2021-09-07 20:54:34 +03:00
if ( ret = = - EFBIG | | ret = = - EUCLEAN ) {
2020-03-10 14:34:21 +03:00
int ret2 = ceph_wait_on_async_create ( inode ) ;
if ( ret2 < 0 )
return ret2 ;
}
2020-03-10 14:34:18 +03:00
if ( ret = = - EFBIG ) {
check_max_size ( inode , endoff ) ;
continue ;
}
2021-09-07 20:54:34 +03:00
if ( ret = = - EUCLEAN ) {
2019-05-20 04:50:09 +03:00
/* session was killed, try renew caps */
2020-03-05 15:21:00 +03:00
ret = ceph_renew_caps ( inode , flags ) ;
2019-05-20 04:50:09 +03:00
if ( ret = = 0 )
continue ;
}
2016-04-08 10:27:16 +03:00
return ret ;
2015-04-30 09:40:54 +03:00
}
2015-01-09 10:56:18 +03: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 23:46:04 +03:00
if ( S_ISREG ( ci - > netfs . inode . i_mode ) & &
2022-06-07 05:13:53 +03:00
ceph_has_inline_data ( ci ) & &
2015-04-30 09:40:54 +03:00
( _got & ( CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_LAZYIO ) ) & &
2019-07-25 15:16:43 +03:00
i_size_read ( inode ) > 0 ) {
2015-04-30 09:40:54 +03:00
struct page * page =
2019-07-25 15:16:43 +03:00
find_get_page ( inode - > i_mapping , 0 ) ;
2015-04-30 09:40:54 +03:00
if ( page ) {
2021-04-05 19:19:35 +03:00
bool uptodate = PageUptodate ( page ) ;
mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.
This promise never materialized. And unlikely will.
We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE. And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.
Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.
Let's stop pretending that pages in page cache are special. They are
not.
The changes are pretty straight-forward:
- <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
- page_cache_get() -> get_page();
- page_cache_release() -> put_page();
This patch contains automated changes generated with coccinelle using
script below. For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.
The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.
There are few places in the code where coccinelle didn't reach. I'll
fix them manually in a separate patch. Comments and documentation also
will be addressed with the separate patch.
virtual patch
@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT
@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE
@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK
@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)
@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)
@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-01 15:29:47 +03:00
put_page ( page ) ;
2021-04-05 19:19:35 +03:00
if ( uptodate )
break ;
2015-01-09 10:56:18 +03:00
}
2015-04-30 09:40:54 +03:00
/*
* drop cap refs first because getattr while
* holding * caps refs can cause deadlock .
*/
ceph_put_cap_refs ( ci , _got ) ;
_got = 0 ;
2015-01-09 10:56:18 +03:00
2015-04-30 09:40:54 +03:00
/*
* getattr request will bring inline data into
* page cache
*/
2019-07-25 15:16:43 +03:00
ret = __ceph_do_getattr ( inode , NULL ,
2015-04-30 09:40:54 +03:00
CEPH_STAT_CAP_INLINE_DATA ,
true ) ;
if ( ret < 0 )
return ret ;
continue ;
}
break ;
2015-01-09 10:56:18 +03:00
}
* got = _got ;
return 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2022-08-25 16:31:11 +03:00
int ceph_get_caps ( struct file * filp , int need , int want , loff_t endoff ,
int * got )
{
struct ceph_file_info * fi = filp - > private_data ;
struct inode * inode = file_inode ( filp ) ;
return __ceph_get_caps ( inode , fi , need , want , endoff , got ) ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Take cap refs . Caller must already know we hold at least one ref
* on the caps in question or we don ' t know this is safe .
*/
void ceph_get_cap_refs ( struct ceph_inode_info * ci , int caps )
{
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2020-01-14 17:23:49 +03:00
ceph_take_cap_refs ( ci , caps , false ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2015-05-01 11:57:16 +03:00
/*
* drop cap_snap that is not associated with any snapshot .
* we don ' t need to send FLUSHSNAP message for it .
*/
2016-07-06 11:21:30 +03:00
static int ceph_try_drop_cap_snap ( struct ceph_inode_info * ci ,
struct ceph_cap_snap * capsnap )
2015-05-01 11:57:16 +03:00
{
2023-06-12 04:04:07 +03:00
struct inode * inode = & ci - > netfs . inode ;
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2015-05-01 11:57:16 +03:00
if ( ! capsnap - > need_flush & &
! capsnap - > writing & & ! capsnap - > dirty_pages ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p follows %llu \n " , capsnap , capsnap - > follows ) ;
2016-07-04 13:06:41 +03:00
BUG_ON ( capsnap - > cap_flush . tid > 0 ) ;
2015-05-01 11:57:16 +03:00
ceph_put_snap_context ( capsnap - > context ) ;
2016-07-06 11:21:30 +03:00
if ( ! list_is_last ( & capsnap - > ci_item , & ci - > i_cap_snaps ) )
ci - > i_ceph_flags | = CEPH_I_FLUSH_SNAPS ;
2015-05-01 11:57:16 +03:00
list_del ( & capsnap - > ci_item ) ;
ceph_put_cap_snap ( capsnap ) ;
return 1 ;
}
return 0 ;
}
2020-12-10 22:39:26 +03:00
enum put_cap_refs_mode {
PUT_CAP_REFS_SYNC = 0 ,
PUT_CAP_REFS_ASYNC ,
} ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Release cap refs .
*
* If we released the last ref on any given cap , call ceph_check_caps
* to release ( or schedule a release ) .
*
* If we are releasing a WR cap ( from a sync write ) , finalize any affected
* cap_snap , and wake up any waiters .
*/
2020-05-27 16:09:27 +03:00
static void __ceph_put_cap_refs ( struct ceph_inode_info * ci , int had ,
2020-12-10 22:39:26 +03:00
enum put_cap_refs_mode mode )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04: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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int last = 0 , put = 0 , flushsnaps = 0 , wake = 0 ;
2021-02-02 09:54:53 +03:00
bool check_flushsnaps = false ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( had & CEPH_CAP_PIN )
- - ci - > i_pin_ref ;
if ( had & CEPH_CAP_FILE_RD )
if ( - - ci - > i_rd_ref = = 0 )
last + + ;
if ( had & CEPH_CAP_FILE_CACHE )
if ( - - ci - > i_rdcache_ref = = 0 )
last + + ;
2019-04-02 15:04:30 +03:00
if ( had & CEPH_CAP_FILE_EXCL )
if ( - - ci - > i_fx_ref = = 0 )
last + + ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( had & CEPH_CAP_FILE_BUFFER ) {
2011-05-11 14:29:54 +04:00
if ( - - ci - > i_wb_ref = = 0 ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
last + + ;
2021-02-02 09:54:53 +03:00
/* put the ref held by ceph_take_cap_refs() */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
put + + ;
2021-02-02 09:54:53 +03:00
check_flushsnaps = true ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx wb %d -> %d (?) \n " , inode ,
ceph_vinop ( inode ) , ci - > i_wb_ref + 1 , ci - > i_wb_ref ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2021-02-02 09:54:53 +03:00
if ( had & CEPH_CAP_FILE_WR ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( - - ci - > i_wr_ref = = 0 ) {
2023-05-11 08:19:45 +03:00
/*
* The Fb caps will always be took and released
* together with the Fw caps .
*/
WARN_ON_ONCE ( ci - > i_wb_ref ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
last + + ;
2021-02-02 09:54:53 +03:00
check_flushsnaps = true ;
2015-04-30 09:40:54 +03:00
if ( ci - > i_wrbuffer_ref_head = = 0 & &
ci - > i_dirty_caps = = 0 & &
ci - > i_flushing_caps = = 0 ) {
BUG_ON ( ! ci - > i_head_snapc ) ;
ceph_put_snap_context ( ci - > i_head_snapc ) ;
ci - > i_head_snapc = NULL ;
}
2015-03-23 15:12:20 +03:00
/* see comment in __ceph_remove_cap() */
2019-12-03 11:00:51 +03:00
if ( ! __ceph_is_any_real_caps ( ci ) & & ci - > i_snap_realm )
2021-08-02 18:01:26 +03:00
ceph_change_snap_realm ( inode , NULL ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2021-02-02 09:54:53 +03:00
}
if ( check_flushsnaps & & __ceph_have_pending_cap_snap ( ci ) ) {
struct ceph_cap_snap * capsnap =
list_last_entry ( & ci - > i_cap_snaps ,
struct ceph_cap_snap ,
ci_item ) ;
capsnap - > writing = 0 ;
if ( ceph_try_drop_cap_snap ( ci , capsnap ) )
/* put the ref held by ceph_queue_cap_snap() */
put + + ;
else if ( __ceph_finish_cap_snap ( ci , capsnap ) )
flushsnaps = 1 ;
wake = 1 ;
}
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx had %s%s%s \n " , inode , ceph_vinop ( inode ) ,
ceph_cap_string ( had ) , last ? " last " : " " , put ? " put " : " " ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2020-12-10 22:39:26 +03:00
switch ( mode ) {
case PUT_CAP_REFS_SYNC :
2020-12-10 21:35:46 +03:00
if ( last )
2022-10-18 04:03:29 +03:00
ceph_check_caps ( ci , 0 ) ;
2020-12-10 21:35:46 +03:00
else if ( flushsnaps )
ceph_flush_snaps ( ci , NULL ) ;
2020-12-10 22:39:26 +03:00
break ;
case PUT_CAP_REFS_ASYNC :
if ( last )
ceph_queue_check_caps ( inode ) ;
else if ( flushsnaps )
ceph_queue_flush_snaps ( inode ) ;
break ;
default :
break ;
2020-12-10 21:35:46 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( wake )
2010-07-28 00:11:08 +04:00
wake_up_all ( & ci - > i_cap_wq ) ;
2015-05-01 11:57:16 +03:00
while ( put - - > 0 )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
iput ( inode ) ;
}
2020-05-27 16:09:27 +03:00
void ceph_put_cap_refs ( struct ceph_inode_info * ci , int had )
{
2020-12-10 22:39:26 +03:00
__ceph_put_cap_refs ( ci , had , PUT_CAP_REFS_SYNC ) ;
}
void ceph_put_cap_refs_async ( struct ceph_inode_info * ci , int had )
{
__ceph_put_cap_refs ( ci , had , PUT_CAP_REFS_ASYNC ) ;
2020-05-27 16:09:27 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Release @ nr WRBUFFER refs on dirty pages for the given @ snapc snap
* context . Adjust per - snap dirty page accounting as appropriate .
* Once all dirty data for a cap_snap is flushed , flush snapped file
* metadata back to the MDS . If we dropped the last ref , call
* ceph_check_caps .
*/
void ceph_put_wrbuffer_cap_refs ( struct ceph_inode_info * ci , int nr ,
struct ceph_snap_context * snapc )
{
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 23:46:04 +03:00
struct inode * inode = & ci - > netfs . inode ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2022-04-01 00:53:29 +03:00
struct ceph_cap_snap * capsnap = NULL , * iter ;
2016-07-06 11:21:30 +03:00
int put = 0 ;
bool last = false ;
bool flush_snaps = false ;
bool complete_capsnap = false ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ci - > i_wrbuffer_ref - = nr ;
2016-07-06 11:21:30 +03:00
if ( ci - > i_wrbuffer_ref = = 0 ) {
last = true ;
put + + ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ci - > i_head_snapc = = snapc ) {
ci - > i_wrbuffer_ref_head - = nr ;
2010-08-24 19:44:16 +04:00
if ( ci - > i_wrbuffer_ref_head = = 0 & &
2015-04-30 09:40:54 +03:00
ci - > i_wr_ref = = 0 & &
ci - > i_dirty_caps = = 0 & &
ci - > i_flushing_caps = = 0 ) {
2010-08-24 19:44:16 +04:00
BUG_ON ( ! ci - > i_head_snapc ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ceph_put_snap_context ( ci - > i_head_snapc ) ;
ci - > i_head_snapc = NULL ;
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " on %p %llx.%llx head %d/%d -> %d/%d %s \n " ,
inode , ceph_vinop ( inode ) , ci - > i_wrbuffer_ref + nr ,
ci - > i_wrbuffer_ref_head + nr , ci - > i_wrbuffer_ref ,
ci - > i_wrbuffer_ref_head , last ? " LAST " : " " ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
} else {
2022-04-01 00:53:29 +03:00
list_for_each_entry ( iter , & ci - > i_cap_snaps , ci_item ) {
if ( iter - > context = = snapc ) {
capsnap = iter ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
break ;
}
}
2021-08-25 16:45:43 +03:00
2022-04-01 00:53:29 +03:00
if ( ! capsnap ) {
2021-08-25 16:45:43 +03:00
/*
* The capsnap should already be removed when removing
* auth cap in the case of a forced unmount .
*/
WARN_ON_ONCE ( ci - > i_auth_cap ) ;
goto unlock ;
}
2010-04-01 20:33:46 +04:00
capsnap - > dirty_pages - = nr ;
if ( capsnap - > dirty_pages = = 0 ) {
2016-07-06 11:21:30 +03:00
complete_capsnap = true ;
if ( ! capsnap - > writing ) {
if ( ceph_try_drop_cap_snap ( ci , capsnap ) ) {
put + + ;
} else {
ci - > i_ceph_flags | = CEPH_I_FLUSH_SNAPS ;
flush_snaps = true ;
}
}
2010-04-01 20:33:46 +04:00
}
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap_snap %p snap %lld %d/%d -> %d/%d %s%s \n " ,
inode , ceph_vinop ( inode ) , capsnap , capsnap - > context - > seq ,
ci - > i_wrbuffer_ref + nr , capsnap - > dirty_pages + nr ,
ci - > i_wrbuffer_ref , capsnap - > dirty_pages ,
last ? " (wrbuffer last) " : " " ,
complete_capsnap ? " (complete capsnap) " : " " ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2021-08-25 16:45:43 +03:00
unlock :
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( last ) {
2022-10-18 04:03:29 +03:00
ceph_check_caps ( ci , 0 ) ;
2016-07-06 11:21:30 +03:00
} else if ( flush_snaps ) {
2016-07-05 16:08:07 +03:00
ceph_flush_snaps ( ci , NULL ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2016-07-06 11:21:30 +03:00
if ( complete_capsnap )
wake_up_all ( & ci - > i_cap_wq ) ;
2019-05-18 15:39:55 +03:00
while ( put - - > 0 ) {
2021-06-04 19:03:09 +03:00
iput ( inode ) ;
2019-05-18 15:39:55 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2013-07-21 06:07:51 +04:00
/*
* Invalidate unlinked inode ' s aliases , so we can drop the inode ASAP .
*/
static void invalidate_aliases ( struct inode * inode )
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
2013-07-21 06:07:51 +04:00
struct dentry * dn , * prev = NULL ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx \n " , inode , ceph_vinop ( inode ) ) ;
2013-07-21 06:07:51 +04:00
d_prune_aliases ( inode ) ;
/*
* For non - directory inode , d_find_alias ( ) only returns
2014-01-17 02:42:53 +04:00
* hashed dentry . After calling d_invalidate ( ) , the
* dentry becomes unhashed .
2013-07-21 06:07:51 +04:00
*
2013-09-02 11:19:54 +04:00
* For directory inode , d_find_alias ( ) can return
2014-01-17 02:42:53 +04:00
* unhashed dentry . But directory inode should have
2013-07-21 06:07:51 +04:00
* one alias at most .
*/
while ( ( dn = d_find_alias ( inode ) ) ) {
if ( dn = = prev ) {
dput ( dn ) ;
break ;
}
2013-09-02 11:19:54 +04:00
d_invalidate ( dn ) ;
2013-07-21 06:07:51 +04:00
if ( prev )
dput ( prev ) ;
prev = dn ;
}
if ( prev )
dput ( prev ) ;
}
2018-04-27 05:29:44 +03:00
struct cap_extra_info {
struct ceph_string * pool_ns ;
/* inline data */
u64 inline_version ;
void * inline_data ;
u32 inline_len ;
2018-04-27 06:11:31 +03:00
/* dirstat */
bool dirstat_valid ;
u64 nfiles ;
u64 nsubdirs ;
2019-06-06 15:06:40 +03:00
u64 change_attr ;
2018-04-27 05:29:44 +03:00
/* currently issued */
int issued ;
2019-05-29 19:23:14 +03:00
struct timespec64 btime ;
2022-08-25 16:31:09 +03:00
u8 * fscrypt_auth ;
u32 fscrypt_auth_len ;
u64 fscrypt_file_size ;
2018-04-27 05:29:44 +03:00
} ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Handle a cap GRANT message from the MDS . ( Note that a GRANT may
* actually be a revocation if it specifies a smaller cap set . )
*
2011-11-30 21:47:09 +04:00
* caller holds s_mutex and i_ceph_lock , we drop both .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2018-04-27 05:29:44 +03:00
static void handle_cap_grant ( struct inode * inode ,
2010-03-16 23:42:00 +03:00
struct ceph_mds_session * session ,
2018-04-27 05:29:44 +03:00
struct ceph_cap * cap ,
struct ceph_mds_caps * grant ,
struct ceph_buffer * xattr_buf ,
struct cap_extra_info * extra_info )
2014-04-18 09:20:27 +04:00
__releases ( ci - > i_ceph_lock )
2018-04-27 05:29:44 +03:00
__releases ( session - > s_mdsc - > snap_rwsem )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2010-10-28 07:59:49 +04:00
int seq = le32_to_cpu ( grant - > seq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int newcaps = le32_to_cpu ( grant - > caps ) ;
2014-04-18 09:20:27 +04:00
int used , wanted , dirty ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
u64 size = le64_to_cpu ( grant - > size ) ;
u64 max_size = le64_to_cpu ( grant - > max_size ) ;
2018-11-22 10:26:01 +03:00
unsigned char check_caps = 0 ;
2021-06-04 19:03:09 +03:00
bool was_stale = cap - > cap_gen < atomic_read ( & session - > s_cap_gen ) ;
2014-10-10 01:16:35 +04:00
bool wake = false ;
bool writeback = false ;
bool queue_trunc = false ;
bool queue_invalidate = false ;
bool deleted_inode = false ;
2014-11-14 16:41:55 +03:00
bool fill_inline = false ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2022-08-25 16:31:09 +03:00
/*
* If there is at least one crypto block then we ' ll trust
* fscrypt_file_size . If the real length of the file is 0 , then
* ignore it ( it has probably been truncated down to 0 by the MDS ) .
*/
if ( IS_ENCRYPTED ( inode ) & & size )
size = extra_info - > fscrypt_file_size ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p mds%d seq %d %s \n " , inode ,
ceph_vinop ( inode ) , cap , session - > s_mds , seq ,
ceph_cap_string ( newcaps ) ) ;
doutc ( cl , " size %llu max_size %llu, i_size %llu \n " , size ,
max_size , i_size_read ( inode ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2013-11-24 10:44:38 +04:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* If CACHE is being revoked , and we have no dirty buffers ,
* try to invalidate ( once ) . ( If there are dirty buffers , we
* will invalidate _after_ writeback . )
*/
2019-05-11 12:27:59 +03:00
if ( S_ISREG ( inode - > i_mode ) & & /* don't invalidate readdir cache */
2015-06-16 15:48:56 +03:00
( ( cap - > issued & ~ newcaps ) & CEPH_CAP_FILE_CACHE ) & &
2010-06-11 00:20:33 +04:00
( newcaps & CEPH_CAP_FILE_LAZYIO ) = = 0 & &
2016-05-18 15:58:26 +03:00
! ( ci - > i_wrbuffer_ref | | ci - > i_wb_ref ) ) {
2013-08-16 09:00:25 +04:00
if ( try_nonblocking_invalidate ( inode ) ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/* there were locked pages.. invalidate later
in a separate thread . */
if ( ci - > i_rdcache_revoking ! = ci - > i_rdcache_gen ) {
2014-10-10 01:16:35 +04:00
queue_invalidate = true ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ci - > i_rdcache_revoking = ci - > i_rdcache_gen ;
}
}
}
2018-12-10 11:35:09 +03:00
if ( was_stale )
cap - > issued = cap - > implemented = CEPH_CAP_PIN ;
/*
* auth mds of the inode changed . we received the cap export message ,
* but still haven ' t received the cap import message . handle_cap_export
* updated the new auth MDS ' cap .
*
* " ceph_seq_cmp(seq, cap->seq) <= 0 " means we are processing a message
* that was sent before the cap import message . So don ' t remove caps .
*/
if ( ceph_seq_cmp ( seq , cap - > seq ) < = 0 ) {
WARN_ON ( cap ! = ci - > i_auth_cap ) ;
WARN_ON ( cap - > cap_id ! = le64_to_cpu ( grant - > cap_id ) ) ;
seq = cap - > seq ;
newcaps | = cap - > issued ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/* side effects now are allowed */
2021-06-04 19:03:09 +03:00
cap - > cap_gen = atomic_read ( & session - > s_cap_gen ) ;
2013-11-24 10:44:38 +04:00
cap - > seq = seq ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
__check_cap_issue ( ci , cap , newcaps ) ;
2019-06-06 15:06:40 +03:00
inode_set_max_iversion_raw ( inode , extra_info - > change_attr ) ;
2014-04-17 04:55:50 +04:00
if ( ( newcaps & CEPH_CAP_AUTH_SHARED ) & &
2018-04-27 05:29:44 +03:00
( extra_info - > issued & CEPH_CAP_AUTH_EXCL ) = = 0 ) {
2021-02-25 23:04:16 +03:00
umode_t mode = le32_to_cpu ( grant - > mode ) ;
if ( inode_wrong_type ( inode , mode ) )
pr_warn_once ( " inode type changed! (ino %llx.%llx is 0%o, mds says 0%o) \n " ,
ceph_vinop ( inode ) , inode - > i_mode , mode ) ;
else
inode - > i_mode = mode ;
2013-01-31 14:56:19 +04:00
inode - > i_uid = make_kuid ( & init_user_ns , le32_to_cpu ( grant - > uid ) ) ;
inode - > i_gid = make_kgid ( & init_user_ns , le32_to_cpu ( grant - > gid ) ) ;
2019-05-29 19:23:14 +03:00
ci - > i_btime = extra_info - > btime ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx mode 0%o uid.gid %d.%d \n " , inode ,
ceph_vinop ( inode ) , inode - > i_mode ,
from_kuid ( & init_user_ns , inode - > i_uid ) ,
from_kgid ( & init_user_ns , inode - > i_gid ) ) ;
2022-08-25 16:31:09 +03:00
# if IS_ENABLED(CONFIG_FS_ENCRYPTION)
if ( ci - > fscrypt_auth_len ! = extra_info - > fscrypt_auth_len | |
memcmp ( ci - > fscrypt_auth , extra_info - > fscrypt_auth ,
ci - > fscrypt_auth_len ) )
2023-06-12 04:04:07 +03:00
pr_warn_ratelimited_client ( cl ,
" cap grant attempt to change fscrypt_auth on non-I_NEW inode (old len %d new len %d) \n " ,
ci - > fscrypt_auth_len ,
2022-08-25 16:31:09 +03:00
extra_info - > fscrypt_auth_len ) ;
# endif
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2018-05-25 06:22:56 +03:00
if ( ( newcaps & CEPH_CAP_LINK_SHARED ) & &
2018-04-27 05:29:44 +03:00
( extra_info - > issued & CEPH_CAP_LINK_EXCL ) = = 0 ) {
2011-10-28 16:13:29 +04:00
set_nlink ( inode , le32_to_cpu ( grant - > nlink ) ) ;
2022-01-06 04:35:52 +03:00
if ( inode - > i_nlink = = 0 )
2014-10-10 01:16:35 +04:00
deleted_inode = true ;
2013-07-21 06:07:51 +04:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2018-04-27 05:29:44 +03:00
if ( ( extra_info - > issued & CEPH_CAP_XATTR_EXCL ) = = 0 & &
grant - > xattr_len ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int len = le32_to_cpu ( grant - > xattr_len ) ;
u64 version = le64_to_cpu ( grant - > xattr_version ) ;
if ( version > ci - > i_xattrs . version ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " got new xattrs v%llu on %p %llx.%llx len %d \n " ,
version , inode , ceph_vinop ( inode ) , len ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ci - > i_xattrs . blob )
ceph_buffer_put ( ci - > i_xattrs . blob ) ;
ci - > i_xattrs . blob = ceph_buffer_get ( xattr_buf ) ;
ci - > i_xattrs . version = version ;
2013-11-11 11:18:03 +04:00
ceph_forget_all_cached_acls ( inode ) ;
2019-05-26 11:27:56 +03:00
ceph_security_invalidate_secctx ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
2014-04-17 04:55:50 +04:00
if ( newcaps & CEPH_CAP_ANY_RD ) {
2018-07-13 23:18:36 +03:00
struct timespec64 mtime , atime , ctime ;
2014-04-17 04:55:50 +04:00
/* ctime/mtime/atime? */
2018-07-13 23:18:36 +03:00
ceph_decode_timespec64 ( & mtime , & grant - > mtime ) ;
ceph_decode_timespec64 ( & atime , & grant - > atime ) ;
ceph_decode_timespec64 ( & ctime , & grant - > ctime ) ;
2018-04-27 05:29:44 +03:00
ceph_fill_file_time ( inode , extra_info - > issued ,
2014-04-17 04:55:50 +04:00
le32_to_cpu ( grant - > time_warp_seq ) ,
& ctime , & mtime , & atime ) ;
}
2018-04-27 06:11:31 +03:00
if ( ( newcaps & CEPH_CAP_FILE_SHARED ) & & extra_info - > dirstat_valid ) {
ci - > i_files = extra_info - > nfiles ;
ci - > i_subdirs = extra_info - > nsubdirs ;
}
2014-04-17 04:55:50 +04:00
if ( newcaps & ( CEPH_CAP_ANY_FILE_RD | CEPH_CAP_ANY_FILE_WR ) ) {
/* file layout may have changed */
2016-02-03 16:24:49 +03:00
s64 old_pool = ci - > i_layout . pool_id ;
2016-03-07 04:35:06 +03:00
struct ceph_string * old_ns ;
2016-02-03 16:24:49 +03:00
ceph_file_layout_from_legacy ( & ci - > i_layout , & grant - > layout ) ;
2016-03-07 04:35:06 +03:00
old_ns = rcu_dereference_protected ( ci - > i_layout . pool_ns ,
lockdep_is_held ( & ci - > i_ceph_lock ) ) ;
2018-04-27 05:29:44 +03:00
rcu_assign_pointer ( ci - > i_layout . pool_ns , extra_info - > pool_ns ) ;
2016-03-07 04:35:06 +03:00
2018-04-27 05:29:44 +03:00
if ( ci - > i_layout . pool_id ! = old_pool | |
extra_info - > pool_ns ! = old_ns )
2016-02-03 16:24:49 +03:00
ci - > i_ceph_flags & = ~ CEPH_I_POOL_PERM ;
2016-02-14 13:06:41 +03:00
2018-04-27 05:29:44 +03:00
extra_info - > pool_ns = old_ns ;
2016-03-07 04:35:06 +03:00
2014-04-17 04:55:50 +04:00
/* size/truncate_seq? */
2018-04-27 05:29:44 +03:00
queue_trunc = ceph_fill_file_size ( inode , extra_info - > issued ,
2014-04-17 04:55:50 +04:00
le32_to_cpu ( grant - > truncate_seq ) ,
le64_to_cpu ( grant - > truncate_size ) ,
size ) ;
2017-05-16 03:55:34 +03:00
}
if ( ci - > i_auth_cap = = cap & & ( newcaps & CEPH_CAP_ANY_FILE_WR ) ) {
if ( max_size ! = ci - > i_max_size ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " max_size %lld -> %llu \n " , ci - > i_max_size ,
max_size ) ;
2014-04-17 04:55:50 +04:00
ci - > i_max_size = max_size ;
if ( max_size > = ci - > i_wanted_max_size ) {
ci - > i_wanted_max_size = 0 ; /* reset */
ci - > i_requested_max_size = 0 ;
}
2014-10-10 01:16:35 +04:00
wake = true ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
/* check cap bits */
wanted = __ceph_caps_wanted ( ci ) ;
used = __ceph_caps_used ( ci ) ;
dirty = __ceph_caps_dirty ( ci ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " my wanted = %s, used = %s, dirty %s \n " ,
ceph_cap_string ( wanted ) , ceph_cap_string ( used ) ,
ceph_cap_string ( dirty ) ) ;
2018-11-22 10:26:01 +03:00
if ( ( was_stale | | le32_to_cpu ( grant - > op ) = = CEPH_CAP_OP_IMPORT ) & &
( wanted & ~ ( cap - > mds_wanted | newcaps ) ) ) {
/*
* If mds is importing cap , prior cap messages that update
* ' wanted ' may get dropped by mds ( migrate seq mismatch ) .
*
* We don ' t send cap message to update ' wanted ' if what we
* want are already issued . If mds revokes caps , cap message
* that releases caps also tells mds what we want . But if
* caps got revoked by mds forcedly ( session stale ) . We may
* haven ' t told mds what we want .
*/
check_caps = 1 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/* revocation, grant, or no-op? */
if ( cap - > issued & ~ newcaps ) {
2010-06-11 00:20:33 +04:00
int revoking = cap - > issued & ~ newcaps ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " revocation: %s -> %s (revoking %s) \n " ,
ceph_cap_string ( cap - > issued ) , ceph_cap_string ( newcaps ) ,
ceph_cap_string ( revoking ) ) ;
2019-05-11 12:27:59 +03:00
if ( S_ISREG ( inode - > i_mode ) & &
( revoking & used & CEPH_CAP_FILE_BUFFER ) )
2014-10-10 01:16:35 +04:00
writeback = true ; /* initiate writeback; will delay ack */
2019-05-11 12:27:59 +03:00
else if ( queue_invalidate & &
revoking = = CEPH_CAP_FILE_CACHE & &
( newcaps & CEPH_CAP_FILE_LAZYIO ) = = 0 )
2010-06-11 00:20:33 +04:00
; /* do nothing yet, invalidation will be queued */
else if ( cap = = ci - > i_auth_cap )
check_caps = 1 ; /* check auth cap only */
else
check_caps = 2 ; /* check all caps */
2022-08-05 07:33:03 +03:00
/* If there is new caps, try to wake up the waiters */
if ( ~ cap - > issued & newcaps )
wake = true ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > issued = newcaps ;
2010-03-09 02:27:53 +03:00
cap - > implemented | = newcaps ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
} else if ( cap - > issued = = newcaps ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " caps unchanged: %s -> %s \n " ,
ceph_cap_string ( cap - > issued ) ,
ceph_cap_string ( newcaps ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
} else {
2023-06-12 04:04:07 +03:00
doutc ( cl , " grant: %s -> %s \n " , ceph_cap_string ( cap - > issued ) ,
ceph_cap_string ( newcaps ) ) ;
2013-07-02 08:40:21 +04:00
/* non-auth MDS is revoking the newly grant caps ? */
if ( cap = = ci - > i_auth_cap & &
__ceph_caps_revoking_other ( ci , cap , newcaps ) )
check_caps = 2 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > issued = newcaps ;
cap - > implemented | = newcaps ; /* add bits only, to
* avoid stepping on a
* pending revocation */
2014-10-10 01:16:35 +04:00
wake = true ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2010-03-09 02:27:53 +03:00
BUG_ON ( cap - > issued & ~ cap - > implemented ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-28 02:57:09 +03:00
/* don't let check_caps skip sending a response to MDS for revoke msgs */
if ( le32_to_cpu ( grant - > op ) = = CEPH_CAP_OP_REVOKE ) {
cap - > mds_wanted = 0 ;
if ( cap = = ci - > i_auth_cap )
check_caps = 1 ; /* check auth cap only */
else
check_caps = 2 ; /* check all caps */
}
2018-04-27 05:29:44 +03:00
if ( extra_info - > inline_version > 0 & &
extra_info - > inline_version > = ci - > i_inline_version ) {
ci - > i_inline_version = extra_info - > inline_version ;
2014-11-14 16:41:55 +03:00
if ( ci - > i_inline_version ! = CEPH_INLINE_NONE & &
( newcaps & ( CEPH_CAP_FILE_CACHE | CEPH_CAP_FILE_LAZYIO ) ) )
fill_inline = true ;
}
2022-06-03 23:39:57 +03:00
if ( le32_to_cpu ( grant - > op ) = = CEPH_CAP_OP_IMPORT ) {
if ( ci - > i_auth_cap = = cap ) {
if ( newcaps & ~ extra_info - > issued )
wake = true ;
if ( ci - > i_requested_max_size > max_size | |
! ( le32_to_cpu ( grant - > wanted ) & CEPH_CAP_ANY_FILE_WR ) ) {
/* re-request max_size if necessary */
ci - > i_requested_max_size = 0 ;
wake = true ;
}
2020-03-30 14:56:37 +03:00
2022-06-03 23:39:57 +03:00
ceph_kick_flushing_inode_caps ( session , ci ) ;
2020-03-30 14:56:37 +03:00
}
2018-04-27 05:29:44 +03:00
up_read ( & session - > s_mdsc - > snap_rwsem ) ;
2014-04-18 09:20:27 +04:00
}
2022-06-03 23:39:57 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2014-04-18 09:20:27 +04:00
2014-11-14 16:41:55 +03:00
if ( fill_inline )
2018-04-27 05:29:44 +03:00
ceph_fill_inline_data ( inode , NULL , extra_info - > inline_data ,
extra_info - > inline_len ) ;
2014-11-14 16:41:55 +03:00
2016-05-20 10:41:20 +03:00
if ( queue_trunc )
2014-04-11 06:18:07 +04:00
ceph_queue_vmtruncate ( inode ) ;
2010-02-10 02:24:44 +03:00
if ( writeback )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* queue inode for writeback : we can ' t actually call
* filemap_write_and_wait , etc . from message handler
* context .
*/
2010-02-10 02:24:44 +03:00
ceph_queue_writeback ( inode ) ;
if ( queue_invalidate )
ceph_queue_invalidate ( inode ) ;
2013-07-21 06:07:51 +04:00
if ( deleted_inode )
invalidate_aliases ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( wake )
2010-07-28 00:11:08 +04:00
wake_up_all ( & ci - > i_cap_wq ) ;
2010-03-16 23:42:00 +03:00
2021-06-04 18:01:25 +03:00
mutex_unlock ( & session - > s_mutex ) ;
2010-03-16 23:42:00 +03:00
if ( check_caps = = 1 )
2022-10-18 04:03:29 +03:00
ceph_check_caps ( ci , CHECK_CAPS_AUTHONLY | CHECK_CAPS_NOINVAL ) ;
2010-03-16 23:42:00 +03:00
else if ( check_caps = = 2 )
2022-10-18 04:03:29 +03:00
ceph_check_caps ( ci , CHECK_CAPS_NOINVAL ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* Handle FLUSH_ACK from MDS , indicating that metadata we sent to the
* MDS has been safely committed .
*/
2009-12-22 22:24:33 +03:00
static void handle_cap_flush_ack ( struct inode * inode , u64 flush_tid ,
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_mds_caps * m ,
struct ceph_mds_session * session ,
struct ceph_cap * cap )
2011-11-30 21:47:09 +04:00
__releases ( ci - > i_ceph_lock )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_fs_client ( inode - > i_sb ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2016-07-06 06:12:56 +03:00
struct ceph_cap_flush * cf , * tmp_cf ;
2015-06-09 10:48:57 +03:00
LIST_HEAD ( to_remove ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
unsigned seq = le32_to_cpu ( m - > seq ) ;
int dirty = le32_to_cpu ( m - > dirty ) ;
int cleaned = 0 ;
2016-07-07 10:22:38 +03:00
bool drop = false ;
2017-10-07 17:02:21 +03:00
bool wake_ci = false ;
bool wake_mdsc = false ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2016-07-06 06:12:56 +03:00
list_for_each_entry_safe ( cf , tmp_cf , & ci - > i_cap_flush_list , i_list ) {
2020-03-18 22:34:20 +03:00
/* Is this the one that was flushed? */
2015-06-09 10:48:57 +03:00
if ( cf - > tid = = flush_tid )
cleaned = cf - > caps ;
2020-03-18 22:34:20 +03:00
/* Is this a capsnap? */
2021-08-18 16:38:42 +03:00
if ( cf - > is_capsnap )
2016-07-04 13:06:41 +03:00
continue ;
2020-03-18 22:34:20 +03:00
2015-06-09 10:48:57 +03:00
if ( cf - > tid < = flush_tid ) {
2020-03-18 22:34:20 +03:00
/*
* An earlier or current tid . The FLUSH_ACK should
* represent a superset of this flush ' s caps .
*/
2020-03-18 22:29:34 +03:00
wake_ci | = __detach_cap_flush_from_ci ( ci , cf ) ;
2016-07-06 06:12:56 +03:00
list_add_tail ( & cf - > i_list , & to_remove ) ;
2015-06-09 10:48:57 +03:00
} else {
2020-03-18 22:34:20 +03:00
/*
* This is a later one . Any caps in it are still dirty
* so don ' t count them as cleaned .
*/
2015-06-09 10:48:57 +03:00
cleaned & = ~ cf - > caps ;
if ( ! cleaned )
break ;
}
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx mds%d seq %d on %s cleaned %s, flushing %s -> %s \n " ,
inode , ceph_vinop ( inode ) , session - > s_mds , seq ,
ceph_cap_string ( dirty ) , ceph_cap_string ( cleaned ) ,
ceph_cap_string ( ci - > i_flushing_caps ) ,
ceph_cap_string ( ci - > i_flushing_caps & ~ cleaned ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2015-06-09 12:20:12 +03:00
if ( list_empty ( & to_remove ) & & ! cleaned )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
goto out ;
ci - > i_flushing_caps & = ~ cleaned ;
spin_lock ( & mdsc - > cap_dirty_lock ) ;
2015-06-09 12:20:12 +03:00
2020-03-18 22:29:34 +03:00
list_for_each_entry ( cf , & to_remove , i_list )
wake_mdsc | = __detach_cap_flush_from_mdsc ( mdsc , cf ) ;
2015-06-09 12:20:12 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ci - > i_flushing_caps = = 0 ) {
2016-07-04 13:06:41 +03:00
if ( list_empty ( & ci - > i_cap_flush_list ) ) {
list_del_init ( & ci - > i_flushing_item ) ;
if ( ! list_empty ( & session - > s_cap_flushing ) ) {
2023-06-12 04:04:07 +03:00
struct inode * inode =
& list_first_entry ( & session - > s_cap_flushing ,
struct ceph_inode_info ,
i_flushing_item ) - > netfs . inode ;
doutc ( cl , " mds%d still flushing cap on %p %llx.%llx \n " ,
session - > s_mds , inode , ceph_vinop ( inode ) ) ;
2016-07-04 13:06:41 +03:00
}
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
mdsc - > num_cap_flushing - - ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx now !flushing \n " , inode ,
ceph_vinop ( inode ) ) ;
2009-10-15 01:27:38 +04:00
if ( ci - > i_dirty_caps = = 0 ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx now clean \n " , inode ,
ceph_vinop ( inode ) ) ;
2009-10-15 01:27:38 +04:00
BUG_ON ( ! list_empty ( & ci - > i_dirty_item ) ) ;
2016-07-07 10:22:38 +03:00
drop = true ;
2015-04-30 09:40:54 +03:00
if ( ci - > i_wr_ref = = 0 & &
ci - > i_wrbuffer_ref_head = = 0 ) {
2010-08-24 19:44:16 +04:00
BUG_ON ( ! ci - > i_head_snapc ) ;
ceph_put_snap_context ( ci - > i_head_snapc ) ;
ci - > i_head_snapc = NULL ;
}
2009-10-16 05:13:53 +04:00
} else {
BUG_ON ( list_empty ( & ci - > i_dirty_item ) ) ;
2009-10-15 01:27:38 +04:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
out :
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2015-06-09 10:48:57 +03:00
while ( ! list_empty ( & to_remove ) ) {
cf = list_first_entry ( & to_remove ,
2016-07-06 06:12:56 +03:00
struct ceph_cap_flush , i_list ) ;
2021-08-18 16:38:42 +03:00
list_del_init ( & cf - > i_list ) ;
if ( ! cf - > is_capsnap )
ceph_free_cap_flush ( cf ) ;
2015-06-09 10:48:57 +03:00
}
2016-07-07 10:22:38 +03:00
if ( wake_ci )
wake_up_all ( & ci - > i_cap_wq ) ;
if ( wake_mdsc )
wake_up_all ( & mdsc - > cap_flushing_wq ) ;
2009-10-15 01:27:38 +04:00
if ( drop )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
iput ( inode ) ;
}
2021-08-25 16:45:43 +03:00
void __ceph_remove_capsnap ( struct inode * inode , struct ceph_cap_snap * capsnap ,
bool * wake_ci , bool * wake_mdsc )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_fs_client ( inode - > i_sb ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2021-08-25 16:45:43 +03:00
bool ret ;
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " removing capsnap %p, %p %llx.%llx ci %p \n " , capsnap ,
inode , ceph_vinop ( inode ) , ci ) ;
2021-08-25 16:45:43 +03:00
list_del_init ( & capsnap - > ci_item ) ;
ret = __detach_cap_flush_from_ci ( ci , & capsnap - > cap_flush ) ;
if ( wake_ci )
* wake_ci = ret ;
spin_lock ( & mdsc - > cap_dirty_lock ) ;
if ( list_empty ( & ci - > i_cap_flush_list ) )
list_del_init ( & ci - > i_flushing_item ) ;
ret = __detach_cap_flush_from_mdsc ( mdsc , & capsnap - > cap_flush ) ;
if ( wake_mdsc )
* wake_mdsc = ret ;
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
}
void ceph_remove_capsnap ( struct inode * inode , struct ceph_cap_snap * capsnap ,
bool * wake_ci , bool * wake_mdsc )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
WARN_ON_ONCE ( capsnap - > dirty_pages | | capsnap - > writing ) ;
__ceph_remove_capsnap ( inode , capsnap , wake_ci , wake_mdsc ) ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Handle FLUSHSNAP_ACK . MDS has flushed snap data to disk and we can
* throw away our cap_snap .
*
* Caller hold s_mutex .
*/
2009-12-22 22:24:33 +03:00
static void handle_cap_flushsnap_ack ( struct inode * inode , u64 flush_tid ,
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_mds_caps * m ,
struct ceph_mds_session * session )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_fs_client ( inode - > i_sb ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
u64 follows = le64_to_cpu ( m - > snap_follows ) ;
2022-04-01 00:53:29 +03:00
struct ceph_cap_snap * capsnap = NULL , * iter ;
2016-07-07 10:22:38 +03:00
bool wake_ci = false ;
bool wake_mdsc = false ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx ci %p mds%d follows %lld \n " , inode ,
ceph_vinop ( inode ) , ci , session - > s_mds , follows ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2022-04-01 00:53:29 +03:00
list_for_each_entry ( iter , & ci - > i_cap_snaps , ci_item ) {
if ( iter - > follows = = follows ) {
if ( iter - > cap_flush . tid ! = flush_tid ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " cap_snap %p follows %lld "
" tid %lld != %lld \n " , iter ,
follows , flush_tid ,
iter - > cap_flush . tid ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
break ;
}
2022-04-01 00:53:29 +03:00
capsnap = iter ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
break ;
} else {
2023-06-12 04:04:07 +03:00
doutc ( cl , " skipping cap_snap %p follows %lld \n " ,
iter , iter - > follows ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
2022-04-01 00:53:29 +03:00
if ( capsnap )
2021-08-25 16:45:43 +03:00
ceph_remove_capsnap ( inode , capsnap , & wake_ci , & wake_mdsc ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2021-08-25 16:45:43 +03:00
2022-04-01 00:53:29 +03:00
if ( capsnap ) {
2016-07-04 13:06:41 +03:00
ceph_put_snap_context ( capsnap - > context ) ;
ceph_put_cap_snap ( capsnap ) ;
2016-07-07 10:22:38 +03:00
if ( wake_ci )
wake_up_all ( & ci - > i_cap_wq ) ;
if ( wake_mdsc )
wake_up_all ( & mdsc - > cap_flushing_wq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
iput ( inode ) ;
2016-07-04 13:06:41 +03:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* Handle TRUNC from MDS , indicating file truncation .
*
* caller hold s_mutex .
*/
2020-03-18 23:43:30 +03:00
static bool handle_cap_trunc ( struct inode * inode ,
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_mds_caps * trunc ,
2022-08-25 16:31:09 +03:00
struct ceph_mds_session * session ,
struct cap_extra_info * extra_info )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int mds = session - > s_mds ;
int seq = le32_to_cpu ( trunc - > seq ) ;
u32 truncate_seq = le32_to_cpu ( trunc - > truncate_seq ) ;
u64 truncate_size = le64_to_cpu ( trunc - > truncate_size ) ;
u64 size = le64_to_cpu ( trunc - > size ) ;
int implemented = 0 ;
int dirty = __ceph_caps_dirty ( ci ) ;
int issued = __ceph_caps_issued ( ceph_inode ( inode ) , & implemented ) ;
2020-03-18 23:43:30 +03:00
bool queue_trunc = false ;
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
issued | = implemented | dirty ;
2022-08-25 16:31:09 +03:00
/*
* If there is at least one crypto block then we ' ll trust
* fscrypt_file_size . If the real length of the file is 0 , then
* ignore it ( it has probably been truncated down to 0 by the MDS ) .
*/
if ( IS_ENCRYPTED ( inode ) & & size )
size = extra_info - > fscrypt_file_size ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx mds%d seq %d to %lld truncate seq %d \n " ,
inode , ceph_vinop ( inode ) , mds , seq , truncate_size , truncate_seq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
queue_trunc = ceph_fill_file_size ( inode , issued ,
truncate_seq , truncate_size , size ) ;
2020-03-18 23:43:30 +03:00
return queue_trunc ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* Handle EXPORT from MDS . Cap is being migrated _from_ this mds to a
* different one . If we are the most recent migration we ' ve seen ( as
* indicated by mseq ) , make note of the migrating cap bits for the
* duration ( until we see the corresponding IMPORT ) .
*
* caller holds s_mutex
*/
static void handle_cap_export ( struct inode * inode , struct ceph_mds_caps * ex ,
2013-11-24 10:44:38 +04:00
struct ceph_mds_cap_peer * ph ,
struct ceph_mds_session * session )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 05:50:38 +03:00
struct ceph_mds_client * mdsc = ceph_inode_to_fs_client ( inode ) - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2013-11-24 10:44:38 +04:00
struct ceph_mds_session * tsession = NULL ;
2014-04-18 05:57:11 +04:00
struct ceph_cap * cap , * tcap , * new_cap = NULL ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2013-11-24 10:44:38 +04:00
u64 t_cap_id ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
unsigned mseq = le32_to_cpu ( ex - > migrate_seq ) ;
2013-11-24 10:44:38 +04:00
unsigned t_seq , t_mseq ;
int target , issued ;
int mds = session - > s_mds ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2013-11-24 10:44:38 +04:00
if ( ph ) {
t_cap_id = le64_to_cpu ( ph - > cap_id ) ;
t_seq = le32_to_cpu ( ph - > seq ) ;
t_mseq = le32_to_cpu ( ph - > mseq ) ;
target = le32_to_cpu ( ph - > mds ) ;
} else {
t_cap_id = t_seq = t_mseq = 0 ;
target = - 1 ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx ci %p mds%d mseq %d target %d \n " ,
inode , ceph_vinop ( inode ) , ci , mds , mseq , target ) ;
2013-11-24 10:44:38 +04:00
retry :
2022-03-15 18:29:47 +03:00
down_read ( & mdsc - > snap_rwsem ) ;
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2013-11-24 10:44:38 +04:00
cap = __get_cap_for_mds ( ci , mds ) ;
2014-04-21 11:46:37 +04:00
if ( ! cap | | cap - > cap_id ! = le64_to_cpu ( ex - > cap_id ) )
2013-11-24 10:44:38 +04:00
goto out_unlock ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2013-11-24 10:44:38 +04:00
if ( target < 0 ) {
2023-06-09 10:15:47 +03:00
ceph_remove_cap ( mdsc , cap , false ) ;
2013-11-24 10:44:38 +04:00
goto out_unlock ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2013-11-24 10:44:38 +04:00
/*
* now we know we haven ' t received the cap import message yet
* because the exported cap still exist .
*/
2011-05-24 22:46:31 +04:00
2013-11-24 10:44:38 +04:00
issued = cap - > issued ;
2018-01-03 06:16:27 +03:00
if ( issued ! = cap - > implemented )
2023-06-12 04:04:07 +03:00
pr_err_ratelimited_client ( cl , " issued != implemented: "
" %p %llx.%llx mds%d seq %d mseq %d "
" issued %s implemented %s \n " ,
inode , ceph_vinop ( inode ) , mds ,
cap - > seq , cap - > mseq ,
ceph_cap_string ( issued ) ,
ceph_cap_string ( cap - > implemented ) ) ;
2018-01-03 06:16:27 +03:00
2013-11-24 10:44:38 +04:00
tcap = __get_cap_for_mds ( ci , target ) ;
if ( tcap ) {
/* already have caps from the target */
2017-08-28 10:07:42 +03:00
if ( tcap - > cap_id = = t_cap_id & &
2013-11-24 10:44:38 +04:00
ceph_seq_cmp ( tcap - > seq , t_seq ) < 0 ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " updating import cap %p mds%d \n " , tcap ,
target ) ;
2013-11-24 10:44:38 +04:00
tcap - > cap_id = t_cap_id ;
tcap - > seq = t_seq - 1 ;
tcap - > issue_seq = t_seq - 1 ;
tcap - > issued | = issued ;
tcap - > implemented | = issued ;
2020-04-02 00:07:52 +03:00
if ( cap = = ci - > i_auth_cap ) {
2013-11-24 10:44:38 +04:00
ci - > i_auth_cap = tcap ;
2020-04-02 00:07:52 +03:00
change_auth_cap_ses ( ci , tcap - > session ) ;
2011-05-24 22:46:31 +04:00
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2023-06-09 10:15:47 +03:00
ceph_remove_cap ( mdsc , cap , false ) ;
2013-11-24 10:44:38 +04:00
goto out_unlock ;
2014-04-18 05:57:11 +04:00
} else if ( tsession ) {
2013-11-24 10:44:38 +04:00
/* add placeholder for the export tagert */
2014-04-18 05:57:11 +04:00
int flag = ( cap = = ci - > i_auth_cap ) ? CEPH_CAP_FLAG_AUTH : 0 ;
2017-01-24 05:02:32 +03:00
tcap = new_cap ;
2020-03-05 15:21:02 +03:00
ceph_add_cap ( inode , tsession , t_cap_id , issued , 0 ,
2014-04-18 05:57:11 +04:00
t_seq - 1 , t_mseq , ( u64 ) - 1 , flag , & new_cap ) ;
2017-01-24 05:02:32 +03:00
if ( ! list_empty ( & ci - > i_cap_flush_list ) & &
ci - > i_auth_cap = = tcap ) {
spin_lock ( & mdsc - > cap_dirty_lock ) ;
list_move_tail ( & ci - > i_flushing_item ,
& tcap - > session - > s_cap_flushing ) ;
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
}
2023-06-09 10:15:47 +03:00
ceph_remove_cap ( mdsc , cap , false ) ;
2014-04-18 05:57:11 +04:00
goto out_unlock ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2022-03-15 18:29:47 +03:00
up_read ( & mdsc - > snap_rwsem ) ;
2013-11-24 10:44:38 +04:00
mutex_unlock ( & session - > s_mutex ) ;
/* open target session */
tsession = ceph_mdsc_open_export_target_session ( mdsc , target ) ;
if ( ! IS_ERR ( tsession ) ) {
if ( mds > target ) {
mutex_lock ( & session - > s_mutex ) ;
mutex_lock_nested ( & tsession - > s_mutex ,
SINGLE_DEPTH_NESTING ) ;
} else {
mutex_lock ( & tsession - > s_mutex ) ;
mutex_lock_nested ( & session - > s_mutex ,
SINGLE_DEPTH_NESTING ) ;
}
2014-04-18 05:57:11 +04:00
new_cap = ceph_get_cap ( mdsc , NULL ) ;
2013-11-24 10:44:38 +04:00
} else {
WARN_ON ( 1 ) ;
tsession = NULL ;
target = - 1 ;
2020-04-30 09:12:49 +03:00
mutex_lock ( & session - > s_mutex ) ;
2013-11-24 10:44:38 +04:00
}
goto retry ;
out_unlock :
spin_unlock ( & ci - > i_ceph_lock ) ;
2022-03-15 18:29:47 +03:00
up_read ( & mdsc - > snap_rwsem ) ;
2013-11-24 10:44:38 +04:00
mutex_unlock ( & session - > s_mutex ) ;
if ( tsession ) {
mutex_unlock ( & tsession - > s_mutex ) ;
ceph_put_mds_session ( tsession ) ;
}
2014-04-18 05:57:11 +04:00
if ( new_cap )
ceph_put_cap ( mdsc , new_cap ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
2014-04-18 09:20:27 +04:00
* Handle cap IMPORT .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*
2014-04-18 09:20:27 +04:00
* caller holds s_mutex . acquires i_ceph_lock
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
static void handle_cap_import ( struct ceph_mds_client * mdsc ,
struct inode * inode , struct ceph_mds_caps * im ,
2013-11-24 10:43:46 +04:00
struct ceph_mds_cap_peer * ph ,
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_mds_session * session ,
2014-04-18 09:20:27 +04:00
struct ceph_cap * * target_cap , int * old_issued )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2014-04-18 09:20:27 +04:00
struct ceph_cap * cap , * ocap , * new_cap = NULL ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int mds = session - > s_mds ;
2014-04-18 09:20:27 +04:00
int issued ;
unsigned caps = le32_to_cpu ( im - > caps ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
unsigned wanted = le32_to_cpu ( im - > wanted ) ;
unsigned seq = le32_to_cpu ( im - > seq ) ;
unsigned mseq = le32_to_cpu ( im - > migrate_seq ) ;
u64 realmino = le64_to_cpu ( im - > realm ) ;
u64 cap_id = le64_to_cpu ( im - > cap_id ) ;
2013-11-24 10:43:46 +04:00
u64 p_cap_id ;
int peer ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2013-11-24 10:43:46 +04:00
if ( ph ) {
p_cap_id = le64_to_cpu ( ph - > cap_id ) ;
peer = le32_to_cpu ( ph - > mds ) ;
} else {
p_cap_id = 0 ;
peer = - 1 ;
}
2011-05-24 22:46:31 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx ci %p mds%d mseq %d peer %d \n " ,
inode , ceph_vinop ( inode ) , ci , mds , mseq , peer ) ;
2014-04-18 05:57:11 +04:00
retry :
cap = __get_cap_for_mds ( ci , mds ) ;
if ( ! cap ) {
if ( ! new_cap ) {
spin_unlock ( & ci - > i_ceph_lock ) ;
new_cap = ceph_get_cap ( mdsc , NULL ) ;
2020-03-19 19:00:16 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
2014-04-18 05:57:11 +04:00
goto retry ;
}
2014-04-18 09:20:27 +04:00
cap = new_cap ;
} else {
if ( new_cap ) {
ceph_put_cap ( mdsc , new_cap ) ;
new_cap = NULL ;
}
2014-04-18 05:57:11 +04:00
}
2014-04-18 09:20:27 +04:00
__ceph_caps_issued ( ci , & issued ) ;
issued | = __ceph_caps_dirty ( ci ) ;
2020-03-05 15:21:02 +03:00
ceph_add_cap ( inode , session , cap_id , caps , wanted , seq , mseq ,
2014-04-18 05:57:11 +04:00
realmino , CEPH_CAP_FLAG_AUTH , & new_cap ) ;
2014-04-18 09:20:27 +04:00
ocap = peer > = 0 ? __get_cap_for_mds ( ci , peer ) : NULL ;
if ( ocap & & ocap - > cap_id = = p_cap_id ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " remove export cap %p mds%d flags %d \n " ,
ocap , peer , ph - > flags ) ;
2013-11-24 10:43:46 +04:00
if ( ( ph - > flags & CEPH_CAP_FLAG_AUTH ) & &
2014-04-18 09:20:27 +04:00
( ocap - > seq ! = le32_to_cpu ( ph - > seq ) | |
ocap - > mseq ! = le32_to_cpu ( ph - > mseq ) ) ) {
2023-06-12 04:04:07 +03:00
pr_err_ratelimited_client ( cl , " mismatched seq/mseq: "
" %p %llx.%llx mds%d seq %d mseq %d "
" importer mds%d has peer seq %d mseq %d \n " ,
inode , ceph_vinop ( inode ) , peer ,
ocap - > seq , ocap - > mseq , mds ,
le32_to_cpu ( ph - > seq ) ,
2018-01-03 06:16:27 +03:00
le32_to_cpu ( ph - > mseq ) ) ;
2011-05-24 22:46:31 +04:00
}
2023-06-09 10:15:47 +03:00
ceph_remove_cap ( mdsc , ocap , ( ph - > flags & CEPH_CAP_FLAG_RELEASE ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2014-04-18 09:20:27 +04:00
* old_issued = issued ;
* target_cap = cap ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2022-08-25 16:31:09 +03:00
# ifdef CONFIG_FS_ENCRYPTION
static int parse_fscrypt_fields ( void * * p , void * end ,
struct cap_extra_info * extra )
{
u32 len ;
ceph_decode_32_safe ( p , end , extra - > fscrypt_auth_len , bad ) ;
if ( extra - > fscrypt_auth_len ) {
ceph_decode_need ( p , end , extra - > fscrypt_auth_len , bad ) ;
extra - > fscrypt_auth = kmalloc ( extra - > fscrypt_auth_len ,
GFP_KERNEL ) ;
if ( ! extra - > fscrypt_auth )
return - ENOMEM ;
ceph_decode_copy_safe ( p , end , extra - > fscrypt_auth ,
extra - > fscrypt_auth_len , bad ) ;
}
ceph_decode_32_safe ( p , end , len , bad ) ;
if ( len > = sizeof ( u64 ) ) {
ceph_decode_64_safe ( p , end , extra - > fscrypt_file_size , bad ) ;
len - = sizeof ( u64 ) ;
}
ceph_decode_skip_n ( p , end , len , bad ) ;
return 0 ;
bad :
return - EIO ;
}
# else
static int parse_fscrypt_fields ( void * * p , void * end ,
struct cap_extra_info * extra )
{
u32 len ;
/* Don't care about these fields unless we're encryption-capable */
ceph_decode_32_safe ( p , end , len , bad ) ;
if ( len )
ceph_decode_skip_n ( p , end , len , bad ) ;
ceph_decode_32_safe ( p , end , len , bad ) ;
if ( len )
ceph_decode_skip_n ( p , end , len , bad ) ;
return 0 ;
bad :
return - EIO ;
}
# endif
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Handle a caps message from the MDS .
*
* Identify the appropriate session , inode , and call the right handler
* based on the cap op .
*/
void ceph_handle_caps ( struct ceph_mds_session * session ,
struct ceph_msg * msg )
{
struct ceph_mds_client * mdsc = session - > s_mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct inode * inode ;
2011-11-30 21:47:09 +04:00
struct ceph_inode_info * ci ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap * cap ;
struct ceph_mds_caps * h ;
2013-11-24 10:43:46 +04:00
struct ceph_mds_cap_peer * peer = NULL ;
2016-03-07 04:35:06 +03:00
struct ceph_snap_realm * realm = NULL ;
2018-04-27 05:29:44 +03:00
int op ;
2018-04-27 06:11:31 +03:00
int msg_version = le16_to_cpu ( msg - > hdr . version ) ;
2010-06-10 03:47:10 +04:00
u32 seq , mseq ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_vino vino ;
2010-03-02 00:20:50 +03:00
void * snaptrace ;
2010-08-03 02:09:39 +04:00
size_t snaptrace_len ;
2014-11-14 16:29:55 +03:00
void * p , * end ;
2018-04-27 05:29:44 +03:00
struct cap_extra_info extra_info = { } ;
2020-03-18 23:43:30 +03:00
bool queue_trunc ;
2023-02-01 04:36:45 +03:00
bool close_sessions = false ;
2023-06-13 07:49:59 +03:00
bool do_cap_release = false ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " from mds%d \n " , session - > s_mds ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2022-12-21 09:13:51 +03:00
if ( ! ceph_inc_mds_stopping_blocker ( mdsc , session ) )
return ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/* decode */
2013-11-24 10:43:46 +04:00
end = msg - > front . iov_base + msg - > front . iov_len ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( msg - > front . iov_len < sizeof ( * h ) )
goto bad ;
h = msg - > front . iov_base ;
op = le32_to_cpu ( h - > op ) ;
vino . ino = le64_to_cpu ( h - > ino ) ;
vino . snap = CEPH_NOSNAP ;
seq = le32_to_cpu ( h - > seq ) ;
2010-06-10 03:47:10 +04:00
mseq = le32_to_cpu ( h - > migrate_seq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2010-08-03 02:09:39 +04:00
snaptrace = h + 1 ;
snaptrace_len = le32_to_cpu ( h - > snap_trace_len ) ;
2014-11-14 16:29:55 +03:00
p = snaptrace + snaptrace_len ;
2010-08-03 02:09:39 +04:00
2018-04-27 06:11:31 +03:00
if ( msg_version > = 2 ) {
2014-11-14 16:29:55 +03:00
u32 flock_len ;
2010-08-03 02:09:39 +04:00
ceph_decode_32_safe ( & p , end , flock_len , bad ) ;
2013-11-24 10:43:46 +04:00
if ( p + flock_len > end )
goto bad ;
2014-11-14 16:29:55 +03:00
p + = flock_len ;
2010-08-03 02:09:39 +04:00
}
2018-04-27 06:11:31 +03:00
if ( msg_version > = 3 ) {
2013-11-24 10:43:46 +04:00
if ( op = = CEPH_CAP_OP_IMPORT ) {
if ( p + sizeof ( * peer ) > end )
goto bad ;
peer = p ;
2014-11-14 16:29:55 +03:00
p + = sizeof ( * peer ) ;
2013-11-24 10:44:38 +04:00
} else if ( op = = CEPH_CAP_OP_EXPORT ) {
/* recorded in unused fields */
peer = ( void * ) & h - > size ;
2013-11-24 10:43:46 +04:00
}
}
2018-04-27 06:11:31 +03:00
if ( msg_version > = 4 ) {
2018-04-27 05:29:44 +03:00
ceph_decode_64_safe ( & p , end , extra_info . inline_version , bad ) ;
ceph_decode_32_safe ( & p , end , extra_info . inline_len , bad ) ;
if ( p + extra_info . inline_len > end )
2014-11-14 16:29:55 +03:00
goto bad ;
2018-04-27 05:29:44 +03:00
extra_info . inline_data = p ;
p + = extra_info . inline_len ;
2014-11-14 16:29:55 +03:00
}
2018-04-27 06:11:31 +03:00
if ( msg_version > = 5 ) {
2017-04-13 18:07:04 +03:00
struct ceph_osd_client * osdc = & mdsc - > fsc - > client - > osdc ;
u32 epoch_barrier ;
ceph_decode_32_safe ( & p , end , epoch_barrier , bad ) ;
ceph_osdc_update_epoch_barrier ( osdc , epoch_barrier ) ;
}
2018-04-27 06:11:31 +03:00
if ( msg_version > = 8 ) {
2016-03-07 04:35:06 +03:00
u32 pool_ns_len ;
2017-04-13 18:07:04 +03:00
2016-02-14 13:06:41 +03:00
/* version >= 6 */
2020-09-30 02:32:19 +03:00
ceph_decode_skip_64 ( & p , end , bad ) ; // flush_tid
2016-02-14 13:06:41 +03:00
/* version >= 7 */
2020-09-30 02:32:19 +03:00
ceph_decode_skip_32 ( & p , end , bad ) ; // caller_uid
ceph_decode_skip_32 ( & p , end , bad ) ; // caller_gid
2016-02-14 13:06:41 +03:00
/* version >= 8 */
ceph_decode_32_safe ( & p , end , pool_ns_len , bad ) ;
2016-03-07 04:35:06 +03:00
if ( pool_ns_len > 0 ) {
ceph_decode_need ( & p , end , pool_ns_len , bad ) ;
2018-04-27 05:29:44 +03:00
extra_info . pool_ns =
ceph_find_or_create_string ( p , pool_ns_len ) ;
2016-03-07 04:35:06 +03:00
p + = pool_ns_len ;
}
2016-02-14 13:06:41 +03:00
}
2019-05-29 19:23:14 +03:00
if ( msg_version > = 9 ) {
2018-04-27 06:11:31 +03:00
struct ceph_timespec * btime ;
if ( p + sizeof ( * btime ) > end )
goto bad ;
btime = p ;
2019-05-29 19:23:14 +03:00
ceph_decode_timespec64 ( & extra_info . btime , btime ) ;
2018-04-27 06:11:31 +03:00
p + = sizeof ( * btime ) ;
2019-06-06 15:06:40 +03:00
ceph_decode_64_safe ( & p , end , extra_info . change_attr , bad ) ;
2019-05-29 19:23:14 +03:00
}
if ( msg_version > = 11 ) {
2018-04-27 06:11:31 +03:00
/* version >= 10 */
2020-09-30 02:32:19 +03:00
ceph_decode_skip_32 ( & p , end , bad ) ; // flags
2018-04-27 06:11:31 +03:00
/* version >= 11 */
extra_info . dirstat_valid = true ;
ceph_decode_64_safe ( & p , end , extra_info . nfiles , bad ) ;
ceph_decode_64_safe ( & p , end , extra_info . nsubdirs , bad ) ;
}
2022-08-25 16:31:09 +03:00
if ( msg_version > = 12 ) {
if ( parse_fscrypt_fields ( & p , end , & extra_info ) )
goto bad ;
}
2014-09-17 03:45:12 +04:00
/* lookup ino */
2018-04-27 05:29:44 +03:00
inode = ceph_find_inode ( mdsc - > fsc - > sb , vino ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " op %s ino %llx.%llx inode %p \n " , ceph_cap_op_name ( op ) ,
vino . ino , vino . snap , inode ) ;
2014-09-17 03:45:12 +04:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
mutex_lock ( & session - > s_mutex ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " mds%d seq %lld cap seq %u \n " , session - > s_mds ,
session - > s_seq , ( unsigned ) seq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ! inode ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " i don't have ino %llx \n " , vino . ino ) ;
2010-06-10 03:47:10 +04:00
2023-06-13 07:49:59 +03:00
switch ( op ) {
case CEPH_CAP_OP_IMPORT :
case CEPH_CAP_OP_REVOKE :
case CEPH_CAP_OP_GRANT :
do_cap_release = true ;
break ;
default :
break ;
2013-09-22 06:15:58 +04:00
}
2020-05-20 17:36:07 +03:00
goto flush_cap_releases ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2022-03-02 10:29:51 +03:00
ci = ceph_inode ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/* these will work even if we don't have a cap yet */
switch ( op ) {
case CEPH_CAP_OP_FLUSHSNAP_ACK :
2018-04-27 05:29:44 +03:00
handle_cap_flushsnap_ack ( inode , le64_to_cpu ( msg - > hdr . tid ) ,
h , session ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
goto done ;
case CEPH_CAP_OP_EXPORT :
2013-11-24 10:44:38 +04:00
handle_cap_export ( inode , h , peer , session ) ;
goto done_unlocked ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
case CEPH_CAP_OP_IMPORT :
2014-12-23 10:30:54 +03:00
realm = NULL ;
if ( snaptrace_len ) {
down_write ( & mdsc - > snap_rwsem ) ;
2023-02-01 04:36:45 +03:00
if ( ceph_update_snap_trace ( mdsc , snaptrace ,
snaptrace + snaptrace_len ,
false , & realm ) ) {
up_write ( & mdsc - > snap_rwsem ) ;
close_sessions = true ;
goto done ;
}
2014-12-23 10:30:54 +03:00
downgrade_write ( & mdsc - > snap_rwsem ) ;
} else {
down_read ( & mdsc - > snap_rwsem ) ;
}
2020-03-19 19:00:16 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
2013-11-24 10:43:46 +04:00
handle_cap_import ( mdsc , inode , h , peer , session ,
2018-04-27 05:29:44 +03:00
& cap , & extra_info . issued ) ;
handle_cap_grant ( inode , session , cap ,
h , msg - > middle , & extra_info ) ;
2014-12-23 10:30:54 +03:00
if ( realm )
ceph_put_snap_realm ( mdsc , realm ) ;
2014-04-18 09:20:27 +04:00
goto done_unlocked ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/* the rest require a cap */
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2018-04-27 05:29:44 +03:00
cap = __get_cap_for_mds ( ceph_inode ( inode ) , session - > s_mds ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ! cap ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " no cap on %p ino %llx.%llx from mds%d \n " ,
inode , ceph_ino ( inode ) , ceph_snap ( inode ) ,
session - > s_mds ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2023-06-13 07:49:59 +03:00
switch ( op ) {
case CEPH_CAP_OP_REVOKE :
case CEPH_CAP_OP_GRANT :
do_cap_release = true ;
break ;
default :
break ;
}
2010-10-07 02:46:30 +04:00
goto flush_cap_releases ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2011-11-30 21:47:09 +04:00
/* note that each of these drops i_ceph_lock for us */
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
switch ( op ) {
case CEPH_CAP_OP_REVOKE :
case CEPH_CAP_OP_GRANT :
2018-04-27 05:29:44 +03:00
__ceph_caps_issued ( ci , & extra_info . issued ) ;
extra_info . issued | = __ceph_caps_dirty ( ci ) ;
handle_cap_grant ( inode , session , cap ,
h , msg - > middle , & extra_info ) ;
2010-03-16 23:42:00 +03:00
goto done_unlocked ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
case CEPH_CAP_OP_FLUSH_ACK :
2018-04-27 05:29:44 +03:00
handle_cap_flush_ack ( inode , le64_to_cpu ( msg - > hdr . tid ) ,
h , session , cap ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
break ;
case CEPH_CAP_OP_TRUNC :
2022-08-25 16:31:09 +03:00
queue_trunc = handle_cap_trunc ( inode , h , session ,
& extra_info ) ;
2020-03-18 23:43:30 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
if ( queue_trunc )
ceph_queue_vmtruncate ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
break ;
default :
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
2023-06-12 04:04:07 +03:00
pr_err_client ( cl , " unknown cap op %d %s \n " , op ,
ceph_cap_op_name ( op ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2019-01-14 12:21:19 +03:00
done :
mutex_unlock ( & session - > s_mutex ) ;
done_unlocked :
2021-06-04 19:03:09 +03:00
iput ( inode ) ;
2021-07-01 17:41:46 +03:00
out :
2022-12-21 09:13:51 +03:00
ceph_dec_mds_stopping_blocker ( mdsc ) ;
2021-07-01 17:41:46 +03:00
ceph_put_string ( extra_info . pool_ns ) ;
2023-02-01 04:36:45 +03:00
/* Defer closing the sessions after s_mutex lock being released */
if ( close_sessions )
ceph_mdsc_close_sessions ( mdsc ) ;
2022-08-25 16:31:09 +03:00
kfree ( extra_info . fscrypt_auth ) ;
2019-01-14 12:21:19 +03:00
return ;
2010-10-07 02:46:30 +04:00
flush_cap_releases :
/*
2015-05-14 12:22:42 +03:00
* send any cap release message to try to move things
2010-10-07 02:46:30 +04:00
* along for the mds ( who clearly thinks we still have this
* cap ) .
*/
2023-06-13 07:49:59 +03:00
if ( do_cap_release ) {
cap = ceph_get_cap ( mdsc , NULL ) ;
cap - > cap_ino = vino . ino ;
cap - > queue_release = 1 ;
cap - > cap_id = le64_to_cpu ( h - > cap_id ) ;
cap - > mseq = mseq ;
cap - > seq = seq ;
cap - > issue_seq = seq ;
spin_lock ( & session - > s_cap_lock ) ;
__ceph_queue_cap_release ( session , cap ) ;
spin_unlock ( & session - > s_cap_lock ) ;
}
2019-01-14 12:21:19 +03:00
ceph_flush_cap_releases ( mdsc , session ) ;
goto done ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
bad :
2023-06-12 04:04:07 +03:00
pr_err_client ( cl , " corrupt message \n " ) ;
2009-12-15 02:13:47 +03:00
ceph_msg_dump ( msg ) ;
2021-07-01 17:41:46 +03:00
goto out ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
/*
* Delayed work handler to process end of delayed cap release LRU list .
2021-07-06 16:52:41 +03:00
*
* If new caps are added to the list while processing it , these won ' t get
* processed in this run . In this case , the ci - > i_hold_caps_max will be
* returned so that the work can be scheduled accordingly .
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
*/
2021-07-06 16:52:41 +03:00
unsigned long ceph_check_delayed_caps ( struct ceph_mds_client * mdsc )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
{
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2017-06-27 12:17:24 +03:00
struct inode * inode ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_inode_info * ci ;
2021-07-06 16:52:41 +03:00
struct ceph_mount_options * opt = mdsc - > fsc - > mount_options ;
unsigned long delay_max = opt - > caps_wanted_delay_max * HZ ;
unsigned long loop_start = jiffies ;
unsigned long delay = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " begin \n " ) ;
2020-06-30 22:36:21 +03:00
spin_lock ( & mdsc - > cap_delay_lock ) ;
while ( ! list_empty ( & mdsc - > cap_delay_list ) ) {
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
ci = list_first_entry ( & mdsc - > cap_delay_list ,
struct ceph_inode_info ,
i_cap_delay_list ) ;
2021-07-06 16:52:41 +03:00
if ( time_before ( loop_start , ci - > i_hold_caps_max - delay_max ) ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " caps added recently. Exiting loop " ) ;
2021-07-06 16:52:41 +03:00
delay = ci - > i_hold_caps_max ;
break ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
if ( ( ci - > i_ceph_flags & CEPH_I_FLUSH ) = = 0 & &
time_before ( jiffies , ci - > i_hold_caps_max ) )
break ;
list_del_init ( & ci - > i_cap_delay_list ) ;
2017-06-27 12:17:24 +03: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 23:46:04 +03:00
inode = igrab ( & ci - > netfs . inode ) ;
2017-06-27 12:17:24 +03:00
if ( inode ) {
2020-06-30 22:36:21 +03:00
spin_unlock ( & mdsc - > cap_delay_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " on %p %llx.%llx \n " , inode ,
ceph_vinop ( inode ) ) ;
2022-10-18 04:03:29 +03:00
ceph_check_caps ( ci , 0 ) ;
2021-06-04 19:03:09 +03:00
iput ( inode ) ;
2020-06-30 22:36:21 +03:00
spin_lock ( & mdsc - > cap_delay_lock ) ;
2017-06-27 12:17:24 +03:00
}
2024-01-17 07:42:11 +03:00
/*
* Make sure too many dirty caps or general
* slowness doesn ' t block mdsc delayed work ,
* preventing send_renew_caps ( ) from running .
*/
if ( jiffies - loop_start > = 5 * HZ )
break ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
spin_unlock ( & mdsc - > cap_delay_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " done \n " ) ;
2021-07-06 16:52:41 +03:00
return delay ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2009-10-15 01:27:38 +04:00
/*
* Flush all dirty caps to the mds
*/
2020-04-02 00:07:52 +03:00
static void flush_dirty_session_caps ( struct ceph_mds_session * s )
2009-10-15 01:27:38 +04:00
{
2020-04-02 00:07:52 +03:00
struct ceph_mds_client * mdsc = s - > s_mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2011-05-24 22:46:31 +04:00
struct ceph_inode_info * ci ;
struct inode * inode ;
2009-10-15 01:27:38 +04:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " begin \n " ) ;
2009-10-15 01:27:38 +04:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
2020-04-02 00:07:52 +03:00
while ( ! list_empty ( & s - > s_cap_dirty ) ) {
ci = list_first_entry ( & s - > s_cap_dirty , struct ceph_inode_info ,
2011-05-24 22:46:31 +04:00
i_dirty_item ) ;
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 23:46:04 +03:00
inode = & ci - > netfs . inode ;
2011-05-27 20:24:26 +04:00
ihold ( inode ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx \n " , inode , ceph_vinop ( inode ) ) ;
2009-10-15 01:27:38 +04:00
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
2022-06-07 02:31:42 +03:00
ceph_wait_on_async_create ( inode ) ;
2022-10-18 04:03:29 +03:00
ceph_check_caps ( ci , CHECK_CAPS_FLUSH ) ;
2011-05-27 20:24:26 +04:00
iput ( inode ) ;
2009-10-15 01:27:38 +04:00
spin_lock ( & mdsc - > cap_dirty_lock ) ;
}
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " done \n " ) ;
2009-10-15 01:27:38 +04:00
}
2020-04-02 00:07:52 +03:00
void ceph_flush_dirty_caps ( struct ceph_mds_client * mdsc )
{
2021-07-05 04:22:55 +03:00
ceph_mdsc_iterate_sessions ( mdsc , flush_dirty_session_caps , true ) ;
2020-04-02 00:07:52 +03:00
}
2020-03-05 15:21:00 +03:00
void __ceph_touch_fmode ( struct ceph_inode_info * ci ,
struct ceph_mds_client * mdsc , int fmode )
{
unsigned long now = jiffies ;
if ( fmode & CEPH_FILE_MODE_RD )
ci - > i_last_rd = now ;
if ( fmode & CEPH_FILE_MODE_WR )
ci - > i_last_wr = now ;
/* queue periodic check */
if ( fmode & &
__ceph_is_any_real_caps ( ci ) & &
list_empty ( & ci - > i_cap_delay_list ) )
2020-03-05 15:21:01 +03:00
__cap_delay_requeue ( mdsc , ci ) ;
2020-03-05 15:21:00 +03:00
}
void ceph_get_fmode ( struct ceph_inode_info * ci , int fmode , int count )
{
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 23:46:04 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_mdsc ( ci - > netfs . inode . i_sb ) ;
2020-03-05 15:21:00 +03:00
int bits = ( fmode < < 1 ) | 1 ;
2021-11-22 17:22:12 +03:00
bool already_opened = false ;
2020-09-03 16:01:40 +03:00
int i ;
if ( count = = 1 )
atomic64_inc ( & mdsc - > metric . opened_files ) ;
2020-03-05 15:21:00 +03:00
spin_lock ( & ci - > i_ceph_lock ) ;
for ( i = 0 ; i < CEPH_FILE_MODE_BITS ; i + + ) {
2020-09-03 16:01:40 +03:00
/*
2021-11-22 17:22:12 +03:00
* If any of the mode ref is larger than 0 ,
2020-09-03 16:01:40 +03:00
* that means it has been already opened by
* others . Just skip checking the PIN ref .
*/
2021-11-22 17:22:12 +03:00
if ( i & & ci - > i_nr_by_mode [ i ] )
already_opened = true ;
if ( bits & ( 1 < < i ) )
ci - > i_nr_by_mode [ i ] + = count ;
2020-03-05 15:21:00 +03:00
}
2020-09-03 16:01:40 +03:00
2021-11-22 17:22:12 +03:00
if ( ! already_opened )
2020-09-03 16:01:40 +03:00
percpu_counter_inc ( & mdsc - > metric . opened_inodes ) ;
2020-03-05 15:21:00 +03:00
spin_unlock ( & ci - > i_ceph_lock ) ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Drop open file reference . If we were the last open file ,
* we may need to release capabilities to the MDS ( or schedule
* their delayed release ) .
*/
2020-03-05 15:21:00 +03:00
void ceph_put_fmode ( struct ceph_inode_info * ci , int fmode , int count )
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04: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 23:46:04 +03:00
struct ceph_mds_client * mdsc = ceph_sb_to_mdsc ( ci - > netfs . inode . i_sb ) ;
2016-06-06 11:01:39 +03:00
int bits = ( fmode < < 1 ) | 1 ;
2020-09-03 16:01:40 +03:00
bool is_closed = true ;
int i ;
if ( count = = 1 )
atomic64_dec ( & mdsc - > metric . opened_files ) ;
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2016-06-06 11:01:39 +03:00
for ( i = 0 ; i < CEPH_FILE_MODE_BITS ; i + + ) {
if ( bits & ( 1 < < i ) ) {
2020-03-05 15:21:00 +03:00
BUG_ON ( ci - > i_nr_by_mode [ i ] < count ) ;
ci - > i_nr_by_mode [ i ] - = count ;
2016-06-06 11:01:39 +03:00
}
2020-09-03 16:01:40 +03:00
/*
* If any of the mode ref is not 0 after
* decreased , that means it is still opened
* by others . Just skip checking the PIN ref .
*/
if ( i & & ci - > i_nr_by_mode [ i ] )
is_closed = false ;
2016-06-06 11:01:39 +03:00
}
2020-09-03 16:01:40 +03:00
if ( is_closed )
percpu_counter_dec ( & mdsc - > metric . opened_inodes ) ;
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
2018-01-24 16:24:33 +03:00
/*
2019-04-02 21:20:24 +03:00
* For a soon - to - be unlinked file , drop the LINK caps . If it
2018-01-24 16:24:33 +03:00
* looks like the link count will hit 0 , drop any other caps ( other
* than PIN ) we don ' t specifically want ( due to the file still being
* open ) .
*/
int ceph_drop_caps_for_unlink ( struct inode * inode )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
int drop = CEPH_CAP_LINK_SHARED | CEPH_CAP_LINK_EXCL ;
spin_lock ( & ci - > i_ceph_lock ) ;
if ( inode - > i_nlink = = 1 ) {
drop | = ~ ( __ceph_caps_wanted ( ci ) | CEPH_CAP_PIN ) ;
if ( __ceph_caps_dirty ( ci ) ) {
struct ceph_mds_client * mdsc =
2023-06-12 05:50:38 +03:00
ceph_inode_to_fs_client ( inode ) - > mdsc ;
2023-09-14 05:29:16 +03:00
doutc ( mdsc - > fsc - > client , " %p %llx.%llx \n " , inode ,
ceph_vinop ( inode ) ) ;
2024-04-09 03:56:03 +03:00
spin_lock ( & mdsc - > cap_delay_lock ) ;
2023-09-14 05:29:16 +03:00
ci - > i_ceph_flags | = CEPH_I_FLUSH ;
if ( ! list_empty ( & ci - > i_cap_delay_list ) )
list_del_init ( & ci - > i_cap_delay_list ) ;
list_add_tail ( & ci - > i_cap_delay_list ,
& mdsc - > cap_unlink_delay_list ) ;
2024-04-09 03:56:03 +03:00
spin_unlock ( & mdsc - > cap_delay_lock ) ;
2023-09-14 05:29:16 +03:00
/*
* Fire the work immediately , because the MDS maybe
* waiting for caps release .
*/
ceph_queue_cap_unlink_work ( mdsc ) ;
2018-01-24 16:24:33 +03:00
}
}
spin_unlock ( & ci - > i_ceph_lock ) ;
return drop ;
}
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* Helpers for embedding cap and dentry lease releases into mds
* requests .
*
* @ force is used by dentry_release ( below ) to force inclusion of a
* record for the directory inode , even when there aren ' t any caps to
* drop .
*/
int ceph_encode_inode_release ( void * * p , struct inode * inode ,
int mds , int drop , int unless , int force )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = ceph_inode_to_client ( inode ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
struct ceph_cap * cap ;
struct ceph_mds_request_release * rel = * p ;
2010-06-25 02:12:37 +04:00
int used , dirty ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int ret = 0 ;
2011-11-30 21:47:09 +04:00
spin_lock ( & ci - > i_ceph_lock ) ;
2010-03-17 01:01:07 +03:00
used = __ceph_caps_used ( ci ) ;
2010-06-25 02:12:37 +04:00
dirty = __ceph_caps_dirty ( ci ) ;
2010-03-17 01:01:07 +03:00
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx mds%d used|dirty %s drop %s unless %s \n " ,
inode , ceph_vinop ( inode ) , mds , ceph_cap_string ( used | dirty ) ,
ceph_cap_string ( drop ) , ceph_cap_string ( unless ) ) ;
2010-03-17 01:01:07 +03:00
2010-06-25 02:12:37 +04:00
/* only drop unused, clean caps */
drop & = ~ ( used | dirty ) ;
2010-03-17 01:01:07 +03:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap = __get_cap_for_mds ( ci , mds ) ;
if ( cap & & __cap_is_valid ( cap ) ) {
2017-11-23 12:47:15 +03:00
unless & = cap - > issued ;
if ( unless ) {
if ( unless & CEPH_CAP_AUTH_EXCL )
drop & = ~ CEPH_CAP_AUTH_SHARED ;
if ( unless & CEPH_CAP_LINK_EXCL )
drop & = ~ CEPH_CAP_LINK_SHARED ;
if ( unless & CEPH_CAP_XATTR_EXCL )
drop & = ~ CEPH_CAP_XATTR_SHARED ;
if ( unless & CEPH_CAP_FILE_EXCL )
drop & = ~ CEPH_CAP_FILE_SHARED ;
}
if ( force | | ( cap - > issued & drop ) ) {
if ( cap - > issued & drop ) {
2013-06-03 14:22:17 +04:00
int wanted = __ceph_caps_wanted ( ci ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p %s -> %s, "
" wanted %s -> %s \n " , inode ,
ceph_vinop ( inode ) , cap ,
ceph_cap_string ( cap - > issued ) ,
ceph_cap_string ( cap - > issued & ~ drop ) ,
ceph_cap_string ( cap - > mds_wanted ) ,
ceph_cap_string ( wanted ) ) ;
2013-06-03 14:22:17 +04:00
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
cap - > issued & = ~ drop ;
cap - > implemented & = ~ drop ;
2013-06-03 14:22:17 +04:00
cap - > mds_wanted = wanted ;
2020-03-30 14:56:37 +03:00
if ( cap = = ci - > i_auth_cap & &
! ( wanted & CEPH_CAP_ANY_FILE_WR ) )
ci - > i_requested_max_size = 0 ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
} else {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p %s (force) \n " ,
inode , ceph_vinop ( inode ) , cap ,
ceph_cap_string ( cap - > issued ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
rel - > ino = cpu_to_le64 ( ceph_ino ( inode ) ) ;
rel - > cap_id = cpu_to_le64 ( cap - > cap_id ) ;
rel - > seq = cpu_to_le32 ( cap - > seq ) ;
2014-07-23 18:41:11 +04:00
rel - > issue_seq = cpu_to_le32 ( cap - > issue_seq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
rel - > mseq = cpu_to_le32 ( cap - > mseq ) ;
2014-04-17 04:02:02 +04:00
rel - > caps = cpu_to_le32 ( cap - > implemented ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
rel - > wanted = cpu_to_le32 ( cap - > mds_wanted ) ;
rel - > dname_len = 0 ;
rel - > dname_seq = 0 ;
* p + = sizeof ( * rel ) ;
ret = 1 ;
} else {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p %llx.%llx cap %p %s (noop) \n " ,
inode , ceph_vinop ( inode ) , cap ,
ceph_cap_string ( cap - > issued ) ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
}
2011-11-30 21:47:09 +04:00
spin_unlock ( & ci - > i_ceph_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
return ret ;
}
2020-08-07 16:28:31 +03:00
/**
* ceph_encode_dentry_release - encode a dentry release into an outgoing request
* @ p : outgoing request buffer
* @ dentry : dentry to release
* @ dir : dir to release it from
* @ mds : mds that we ' re speaking to
* @ drop : caps being dropped
* @ unless : unless we have these caps
*
* Encode a dentry release into an outgoing request buffer . Returns 1 if the
* thing was released , or a negative error code otherwise .
*/
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int ceph_encode_dentry_release ( void * * p , struct dentry * dentry ,
2016-12-15 16:37:59 +03:00
struct inode * dir ,
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int mds , int drop , int unless )
{
struct ceph_mds_request_release * rel = * p ;
struct ceph_dentry_info * di = ceph_dentry ( dentry ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
int force = 0 ;
int ret ;
2023-11-17 08:26:18 +03:00
/* This shouldn't happen */
BUG_ON ( ! dir ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
/*
* force an record for the directory caps if we have a dentry lease .
2011-11-30 21:47:09 +04:00
* this is racy ( can ' t take i_ceph_lock and d_lock together ) , but it
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
* doesn ' t have to be perfect ; the mds will revoke anything we don ' t
* release .
*/
spin_lock ( & dentry - > d_lock ) ;
if ( di - > lease_session & & di - > lease_session - > s_mds = = mds )
force = 1 ;
spin_unlock ( & dentry - > d_lock ) ;
2016-12-15 16:37:59 +03:00
ret = ceph_encode_inode_release ( p , dir , mds , drop , unless , force ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
2023-06-12 04:04:07 +03:00
cl = ceph_inode_to_client ( dir ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
spin_lock ( & dentry - > d_lock ) ;
if ( ret & & di - > lease_session & & di - > lease_session - > s_mds = = mds ) {
2023-06-12 04:04:07 +03:00
doutc ( cl , " %p mds%d seq %d \n " , dentry , mds ,
( int ) di - > lease_seq ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
rel - > dname_seq = cpu_to_le32 ( di - > lease_seq ) ;
2010-07-24 00:54:21 +04:00
__ceph_mdsc_drop_dentry_lease ( dentry ) ;
2020-08-07 16:28:31 +03:00
spin_unlock ( & dentry - > d_lock ) ;
if ( IS_ENCRYPTED ( dir ) & & fscrypt_has_encryption_key ( dir ) ) {
int ret2 = ceph_encode_encrypted_fname ( dir , dentry , * p ) ;
if ( ret2 < 0 )
return ret2 ;
rel - > dname_len = cpu_to_le32 ( ret2 ) ;
* p + = ret2 ;
} else {
rel - > dname_len = cpu_to_le32 ( dentry - > d_name . len ) ;
memcpy ( * p , dentry - > d_name . name , dentry - > d_name . len ) ;
* p + = dentry - > d_name . len ;
}
} else {
spin_unlock ( & dentry - > d_lock ) ;
ceph: capability management
The Ceph metadata servers control client access to inode metadata and
file data by issuing capabilities, granting clients permission to read
and/or write both inode field and file data to OSDs (storage nodes).
Each capability consists of a set of bits indicating which operations
are allowed.
If the client holds a *_SHARED cap, the client has a coherent value
that can be safely read from the cached inode.
In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the client
is allowed to change inode attributes (e.g., file size, mtime), note
its dirty state in the ceph_cap, and asynchronously flush that
metadata change to the MDS.
In the event of a conflicting operation (perhaps by another client),
the MDS will revoke the conflicting client capabilities.
In order for a client to cache an inode, it must hold a capability
with at least one MDS server. When inodes are released, release
notifications are batched and periodically sent en masse to the MDS
cluster to release server state.
Signed-off-by: Sage Weil <sage@newdream.net>
2009-10-06 22:31:12 +04:00
}
return ret ;
}
2021-09-02 20:06:57 +03:00
static int remove_capsnaps ( struct ceph_mds_client * mdsc , struct inode * inode )
{
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = mdsc - > fsc - > client ;
2021-09-02 20:06:57 +03:00
struct ceph_cap_snap * capsnap ;
int capsnap_release = 0 ;
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " removing capsnaps, ci is %p, %p %llx.%llx \n " ,
ci , inode , ceph_vinop ( inode ) ) ;
2021-09-02 20:06:57 +03:00
while ( ! list_empty ( & ci - > i_cap_snaps ) ) {
capsnap = list_first_entry ( & ci - > i_cap_snaps ,
struct ceph_cap_snap , ci_item ) ;
__ceph_remove_capsnap ( inode , capsnap , NULL , NULL ) ;
ceph_put_snap_context ( capsnap - > context ) ;
ceph_put_cap_snap ( capsnap ) ;
capsnap_release + + ;
}
wake_up_all ( & ci - > i_cap_wq ) ;
wake_up_all ( & mdsc - > cap_flushing_wq ) ;
return capsnap_release ;
}
int ceph_purge_inode_cap ( struct inode * inode , struct ceph_cap * cap , bool * invalidate )
{
2023-06-12 05:50:38 +03:00
struct ceph_fs_client * fsc = ceph_inode_to_fs_client ( inode ) ;
2021-09-02 20:06:57 +03:00
struct ceph_mds_client * mdsc = fsc - > mdsc ;
2023-06-12 04:04:07 +03:00
struct ceph_client * cl = fsc - > client ;
2021-09-02 20:06:57 +03:00
struct ceph_inode_info * ci = ceph_inode ( inode ) ;
bool is_auth ;
bool dirty_dropped = false ;
int iputs = 0 ;
lockdep_assert_held ( & ci - > i_ceph_lock ) ;
2023-06-12 04:04:07 +03:00
doutc ( cl , " removing cap %p, ci is %p, %p %llx.%llx \n " ,
cap , ci , inode , ceph_vinop ( inode ) ) ;
2021-09-02 20:06:57 +03:00
is_auth = ( cap = = ci - > i_auth_cap ) ;
__ceph_remove_cap ( cap , false ) ;
if ( is_auth ) {
struct ceph_cap_flush * cf ;
2021-08-31 20:39:13 +03:00
if ( ceph_inode_is_shutdown ( inode ) ) {
2021-09-02 20:06:57 +03:00
if ( inode - > i_data . nrpages > 0 )
* invalidate = true ;
if ( ci - > i_wrbuffer_ref > 0 )
mapping_set_error ( & inode - > i_data , - EIO ) ;
}
spin_lock ( & mdsc - > cap_dirty_lock ) ;
/* trash all of the cap flushes for this inode */
while ( ! list_empty ( & ci - > i_cap_flush_list ) ) {
cf = list_first_entry ( & ci - > i_cap_flush_list ,
struct ceph_cap_flush , i_list ) ;
list_del_init ( & cf - > g_list ) ;
list_del_init ( & cf - > i_list ) ;
if ( ! cf - > is_capsnap )
ceph_free_cap_flush ( cf ) ;
}
if ( ! list_empty ( & ci - > i_dirty_item ) ) {
2023-06-12 04:04:07 +03:00
pr_warn_ratelimited_client ( cl ,
" dropping dirty %s state for %p %llx.%llx \n " ,
2021-09-02 20:06:57 +03:00
ceph_cap_string ( ci - > i_dirty_caps ) ,
2023-06-12 04:04:07 +03:00
inode , ceph_vinop ( inode ) ) ;
2021-09-02 20:06:57 +03:00
ci - > i_dirty_caps = 0 ;
list_del_init ( & ci - > i_dirty_item ) ;
dirty_dropped = true ;
}
if ( ! list_empty ( & ci - > i_flushing_item ) ) {
2023-06-12 04:04:07 +03:00
pr_warn_ratelimited_client ( cl ,
" dropping dirty+flushing %s state for %p %llx.%llx \n " ,
2021-09-02 20:06:57 +03:00
ceph_cap_string ( ci - > i_flushing_caps ) ,
2023-06-12 04:04:07 +03:00
inode , ceph_vinop ( inode ) ) ;
2021-09-02 20:06:57 +03:00
ci - > i_flushing_caps = 0 ;
list_del_init ( & ci - > i_flushing_item ) ;
mdsc - > num_cap_flushing - - ;
dirty_dropped = true ;
}
spin_unlock ( & mdsc - > cap_dirty_lock ) ;
if ( dirty_dropped ) {
mapping_set_error ( inode - > i_mapping , - EIO ) ;
if ( ci - > i_wrbuffer_ref_head = = 0 & &
ci - > i_wr_ref = = 0 & &
ci - > i_dirty_caps = = 0 & &
ci - > i_flushing_caps = = 0 ) {
ceph_put_snap_context ( ci - > i_head_snapc ) ;
ci - > i_head_snapc = NULL ;
}
}
if ( atomic_read ( & ci - > i_filelock_ref ) > 0 ) {
/* make further file lock syscall return -EIO */
ci - > i_ceph_flags | = CEPH_I_ERROR_FILELOCK ;
2023-06-12 04:04:07 +03:00
pr_warn_ratelimited_client ( cl ,
" dropping file locks for %p %llx.%llx \n " ,
inode , ceph_vinop ( inode ) ) ;
2021-09-02 20:06:57 +03:00
}
if ( ! ci - > i_dirty_caps & & ci - > i_prealloc_cap_flush ) {
cf = ci - > i_prealloc_cap_flush ;
ci - > i_prealloc_cap_flush = NULL ;
if ( ! cf - > is_capsnap )
ceph_free_cap_flush ( cf ) ;
}
if ( ! list_empty ( & ci - > i_cap_snaps ) )
iputs = remove_capsnaps ( mdsc , inode ) ;
}
if ( dirty_dropped )
+ + iputs ;
return iputs ;
}