2019-07-26 12:51:27 +00:00
|
|
|
=======
|
|
|
|
Locking
|
|
|
|
=======
|
|
|
|
|
|
|
|
The text below describes the locking rules for VFS-related methods.
|
2005-04-16 22:20:36 +00:00
|
|
|
It is (believed to be) up-to-date. *Please*, if you change anything in
|
|
|
|
prototypes or locking protocols - update this file. And update the relevant
|
|
|
|
instances in the tree, don't leave that to maintainers of filesystems/devices/
|
|
|
|
etc. At the very least, put the list of dubious cases in the end of this file.
|
|
|
|
Don't turn it into log - maintainers of out-of-the-tree code are supposed to
|
|
|
|
be able to use diff(1).
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
Thing currently missing here: socket operations. Alexey?
|
|
|
|
|
|
|
|
dentry_operations
|
|
|
|
=================
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
2012-06-10 20:03:43 +00:00
|
|
|
int (*d_revalidate)(struct dentry *, unsigned int);
|
2013-02-20 16:19:05 +00:00
|
|
|
int (*d_weak_revalidate)(struct dentry *, unsigned int);
|
2013-05-21 22:22:44 +00:00
|
|
|
int (*d_hash)(const struct dentry *, struct qstr *);
|
2016-07-31 20:37:25 +00:00
|
|
|
int (*d_compare)(const struct dentry *,
|
2011-01-07 06:49:27 +00:00
|
|
|
unsigned int, const char *, const struct qstr *);
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*d_delete)(struct dentry *);
|
2016-06-28 09:47:32 +00:00
|
|
|
int (*d_init)(struct dentry *);
|
2005-04-16 22:20:36 +00:00
|
|
|
void (*d_release)(struct dentry *);
|
|
|
|
void (*d_iput)(struct dentry *, struct inode *);
|
2007-05-08 07:26:18 +00:00
|
|
|
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
|
Add a dentry op to handle automounting rather than abusing follow_link()
Add a dentry op (d_automount) to handle automounting directories rather than
abusing the follow_link() inode operation. The operation is keyed off a new
dentry flag (DCACHE_NEED_AUTOMOUNT).
This also makes it easier to add an AT_ flag to suppress terminal segment
automount during pathwalk and removes the need for the kludge code in the
pathwalk algorithm to handle directories with follow_link() semantics.
The ->d_automount() dentry operation:
struct vfsmount *(*d_automount)(struct path *mountpoint);
takes a pointer to the directory to be mounted upon, which is expected to
provide sufficient data to determine what should be mounted. If successful, it
should return the vfsmount struct it creates (which it should also have added
to the namespace using do_add_mount() or similar). If there's a collision with
another automount attempt, NULL should be returned. If the directory specified
by the parameter should be used directly rather than being mounted upon,
-EISDIR should be returned. In any other case, an error code should be
returned.
The ->d_automount() operation is called with no locks held and may sleep. At
this point the pathwalk algorithm will be in ref-walk mode.
Within fs/namei.c itself, a new pathwalk subroutine (follow_automount()) is
added to handle mountpoints. It will return -EREMOTE if the automount flag was
set, but no d_automount() op was supplied, -ELOOP if we've encountered too many
symlinks or mountpoints, -EISDIR if the walk point should be used without
mounting and 0 if successful. The path will be updated to point to the mounted
filesystem if a successful automount took place.
__follow_mount() is replaced by follow_managed() which is more generic
(especially with the patch that adds ->d_manage()). This handles transits from
directories during pathwalk, including automounting and skipping over
mountpoints (and holding processes with the next patch).
__follow_mount_rcu() will jump out of RCU-walk mode if it encounters an
automount point with nothing mounted on it.
follow_dotdot*() does not handle automounts as you don't want to trigger them
whilst following "..".
I've also extracted the mount/don't-mount logic from autofs4 and included it
here. It makes the mount go ahead anyway if someone calls open() or creat(),
tries to traverse the directory, tries to chdir/chroot/etc. into the directory,
or sticks a '/' on the end of the pathname. If they do a stat(), however,
they'll only trigger the automount if they didn't also say O_NOFOLLOW.
I've also added an inode flag (S_AUTOMOUNT) so that filesystems can mark their
inodes as automount points. This flag is automatically propagated to the
dentry as DCACHE_NEED_AUTOMOUNT by __d_instantiate(). This saves NFS and could
save AFS a private flag bit apiece, but is not strictly necessary. It would be
preferable to do the propagation in d_set_d_op(), but that doesn't normally
have access to the inode.
[AV: fixed breakage in case if __follow_mount_rcu() fails and nameidata_drop_rcu()
succeeds in RCU case of do_lookup(); we need to fall through to non-RCU case after
that, rather than just returning with ungrabbed *path]
Signed-off-by: David Howells <dhowells@redhat.com>
Was-Acked-by: Ian Kent <raven@themaw.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-01-14 18:45:21 +00:00
|
|
|
struct vfsmount *(*d_automount)(struct path *path);
|
2016-11-23 21:03:41 +00:00
|
|
|
int (*d_manage)(const struct path *, bool);
|
2024-02-02 11:01:32 +00:00
|
|
|
struct dentry *(*d_real)(struct dentry *, enum d_real_type type);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
locking rules:
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
================== =========== ======== ============== ========
|
|
|
|
ops rename_lock ->d_lock may block rcu-walk
|
|
|
|
================== =========== ======== ============== ========
|
|
|
|
d_revalidate: no no yes (ref-walk) maybe
|
|
|
|
d_weak_revalidate: no no yes no
|
|
|
|
d_hash no no no maybe
|
|
|
|
d_compare: yes no no maybe
|
|
|
|
d_delete: no yes no no
|
|
|
|
d_init: no no yes no
|
|
|
|
d_release: no no yes no
|
|
|
|
d_prune: no yes no no
|
|
|
|
d_iput: no no yes no
|
|
|
|
d_dname: no no no no
|
|
|
|
d_automount: no no yes no
|
|
|
|
d_manage: no no yes (ref-walk) maybe
|
|
|
|
d_real no no yes no
|
|
|
|
================== =========== ======== ============== ========
|
|
|
|
|
|
|
|
inode_operations
|
|
|
|
================
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
2023-01-13 11:49:13 +00:00
|
|
|
int (*create) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t, bool);
|
2012-06-10 21:13:09 +00:00
|
|
|
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*link) (struct dentry *,struct inode *,struct dentry *);
|
|
|
|
int (*unlink) (struct inode *,struct dentry *);
|
2023-01-13 11:49:14 +00:00
|
|
|
int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *);
|
2023-01-13 11:49:15 +00:00
|
|
|
int (*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t);
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*rmdir) (struct inode *,struct dentry *);
|
2023-01-13 11:49:16 +00:00
|
|
|
int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t);
|
2023-01-13 11:49:17 +00:00
|
|
|
int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *,
|
2014-04-01 15:08:42 +00:00
|
|
|
struct inode *, struct dentry *, unsigned int);
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*readlink) (struct dentry *, char __user *,int);
|
2019-04-11 23:16:29 +00:00
|
|
|
const char *(*get_link) (struct dentry *, struct inode *, struct delayed_call *);
|
2005-04-16 22:20:36 +00:00
|
|
|
void (*truncate) (struct inode *);
|
2023-01-13 11:49:22 +00:00
|
|
|
int (*permission) (struct mnt_idmap *, struct inode *, int, unsigned int);
|
2022-09-22 15:17:00 +00:00
|
|
|
struct posix_acl * (*get_inode_acl)(struct inode *, int, bool);
|
2023-01-13 11:49:11 +00:00
|
|
|
int (*setattr) (struct mnt_idmap *, struct dentry *, struct iattr *);
|
2023-01-13 11:49:12 +00:00
|
|
|
int (*getattr) (struct mnt_idmap *, const struct path *, struct kstat *, u32, unsigned int);
|
2005-04-16 22:20:36 +00:00
|
|
|
ssize_t (*listxattr) (struct dentry *, char *, size_t);
|
2010-12-16 11:04:54 +00:00
|
|
|
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
|
2012-03-26 13:59:21 +00:00
|
|
|
void (*update_time)(struct inode *, struct timespec *, int);
|
2012-06-22 08:39:14 +00:00
|
|
|
int (*atomic_open)(struct inode *, struct dentry *,
|
2012-06-22 08:40:19 +00:00
|
|
|
struct file *, unsigned open_flag,
|
2018-07-09 23:20:08 +00:00
|
|
|
umode_t create_mode);
|
2023-01-13 11:49:18 +00:00
|
|
|
int (*tmpfile) (struct mnt_idmap *, struct inode *,
|
2022-09-24 05:00:00 +00:00
|
|
|
struct file *, umode_t);
|
2023-01-13 11:49:21 +00:00
|
|
|
int (*fileattr_set)(struct mnt_idmap *idmap,
|
2021-04-07 12:36:42 +00:00
|
|
|
struct dentry *dentry, struct fileattr *fa);
|
|
|
|
int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
|
2023-01-13 11:49:19 +00:00
|
|
|
struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int);
|
2023-06-30 17:48:49 +00:00
|
|
|
struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
locking rules:
|
2010-12-16 11:04:54 +00:00
|
|
|
all may block
|
2019-07-26 12:51:27 +00:00
|
|
|
|
2023-06-30 17:48:49 +00:00
|
|
|
============== ==================================================
|
2019-07-26 12:51:27 +00:00
|
|
|
ops i_rwsem(inode)
|
2023-06-30 17:48:49 +00:00
|
|
|
============== ==================================================
|
2018-05-24 02:29:10 +00:00
|
|
|
lookup: shared
|
|
|
|
create: exclusive
|
|
|
|
link: exclusive (both)
|
|
|
|
mknod: exclusive
|
|
|
|
symlink: exclusive
|
|
|
|
mkdir: exclusive
|
|
|
|
unlink: exclusive (both)
|
|
|
|
rmdir: exclusive (both)(see below)
|
rename(): fix the locking of subdirectories
We should never lock two subdirectories without having taken
->s_vfs_rename_mutex; inode pointer order or not, the "order" proposed
in 28eceeda130f "fs: Lock moved directories" is not transitive, with
the usual consequences.
The rationale for locking renamed subdirectory in all cases was
the possibility of race between rename modifying .. in a subdirectory to
reflect the new parent and another thread modifying the same subdirectory.
For a lot of filesystems that's not a problem, but for some it can lead
to trouble (e.g. the case when short directory contents is kept in the
inode, but creating a file in it might push it across the size limit
and copy its contents into separate data block(s)).
However, we need that only in case when the parent does change -
otherwise ->rename() doesn't need to do anything with .. entry in the
first place. Some instances are lazy and do a tautological update anyway,
but it's really not hard to avoid.
Amended locking rules for rename():
find the parent(s) of source and target
if source and target have the same parent
lock the common parent
else
lock ->s_vfs_rename_mutex
lock both parents, in ancestor-first order; if neither
is an ancestor of another, lock the parent of source
first.
find the source and target.
if source and target have the same parent
if operation is an overwriting rename of a subdirectory
lock the target subdirectory
else
if source is a subdirectory
lock the source
if target is a subdirectory
lock the target
lock non-directories involved, in inode pointer order if both
source and target are such.
That way we are guaranteed that parents are locked (for obvious reasons),
that any renamed non-directory is locked (nfsd relies upon that),
that any victim is locked (emptiness check needs that, among other things)
and subdirectory that changes parent is locked (needed to protect the update
of .. entries). We are also guaranteed that any operation locking more
than one directory either takes ->s_vfs_rename_mutex or locks a parent
followed by its child.
Cc: stable@vger.kernel.org
Fixes: 28eceeda130f "fs: Lock moved directories"
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-11-20 01:25:58 +00:00
|
|
|
rename: exclusive (both parents, some children) (see below)
|
2005-04-16 22:20:36 +00:00
|
|
|
readlink: no
|
2015-11-17 15:20:54 +00:00
|
|
|
get_link: no
|
2018-05-24 02:29:10 +00:00
|
|
|
setattr: exclusive
|
2011-01-07 06:49:58 +00:00
|
|
|
permission: no (may not block if called in rcu-walk mode)
|
2022-09-22 15:17:00 +00:00
|
|
|
get_inode_acl: no
|
2022-09-22 15:17:01 +00:00
|
|
|
get_acl: no
|
2005-04-16 22:20:36 +00:00
|
|
|
getattr: no
|
|
|
|
listxattr: no
|
2010-12-16 11:04:54 +00:00
|
|
|
fiemap: no
|
2012-03-26 13:59:21 +00:00
|
|
|
update_time: no
|
2019-10-30 10:46:54 +00:00
|
|
|
atomic_open: shared (exclusive if O_CREAT is set in open flags)
|
2013-07-03 12:19:23 +00:00
|
|
|
tmpfile: no
|
2021-04-07 12:36:42 +00:00
|
|
|
fileattr_get: no or exclusive
|
|
|
|
fileattr_set: exclusive
|
2023-06-30 17:48:49 +00:00
|
|
|
get_offset_ctx no
|
|
|
|
============== ==================================================
|
2012-03-26 13:59:21 +00:00
|
|
|
|
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-09-29 15:48:44 +00:00
|
|
|
|
2018-05-24 02:29:10 +00:00
|
|
|
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_rwsem
|
|
|
|
exclusive on victim.
|
2016-09-27 09:03:58 +00:00
|
|
|
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
|
rename(): fix the locking of subdirectories
We should never lock two subdirectories without having taken
->s_vfs_rename_mutex; inode pointer order or not, the "order" proposed
in 28eceeda130f "fs: Lock moved directories" is not transitive, with
the usual consequences.
The rationale for locking renamed subdirectory in all cases was
the possibility of race between rename modifying .. in a subdirectory to
reflect the new parent and another thread modifying the same subdirectory.
For a lot of filesystems that's not a problem, but for some it can lead
to trouble (e.g. the case when short directory contents is kept in the
inode, but creating a file in it might push it across the size limit
and copy its contents into separate data block(s)).
However, we need that only in case when the parent does change -
otherwise ->rename() doesn't need to do anything with .. entry in the
first place. Some instances are lazy and do a tautological update anyway,
but it's really not hard to avoid.
Amended locking rules for rename():
find the parent(s) of source and target
if source and target have the same parent
lock the common parent
else
lock ->s_vfs_rename_mutex
lock both parents, in ancestor-first order; if neither
is an ancestor of another, lock the parent of source
first.
find the source and target.
if source and target have the same parent
if operation is an overwriting rename of a subdirectory
lock the target subdirectory
else
if source is a subdirectory
lock the source
if target is a subdirectory
lock the target
lock non-directories involved, in inode pointer order if both
source and target are such.
That way we are guaranteed that parents are locked (for obvious reasons),
that any renamed non-directory is locked (nfsd relies upon that),
that any victim is locked (emptiness check needs that, among other things)
and subdirectory that changes parent is locked (needed to protect the update
of .. entries). We are also guaranteed that any operation locking more
than one directory either takes ->s_vfs_rename_mutex or locks a parent
followed by its child.
Cc: stable@vger.kernel.org
Fixes: 28eceeda130f "fs: Lock moved directories"
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-11-20 01:25:58 +00:00
|
|
|
->unlink() and ->rename() have ->i_rwsem exclusive on all non-directories
|
|
|
|
involved.
|
|
|
|
->rename() has ->i_rwsem exclusive on any subdirectory that changes parent.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
See Documentation/filesystems/directory-locking.rst for more detailed discussion
|
2005-04-16 22:20:36 +00:00
|
|
|
of the locking scheme for directory operations.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
xattr_handler operations
|
|
|
|
========================
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-09-29 15:48:44 +00:00
|
|
|
bool (*list)(struct dentry *dentry);
|
|
|
|
int (*get)(const struct xattr_handler *handler, struct dentry *dentry,
|
|
|
|
struct inode *inode, const char *name, void *buffer,
|
|
|
|
size_t size);
|
2021-01-21 13:19:27 +00:00
|
|
|
int (*set)(const struct xattr_handler *handler,
|
2023-01-13 11:49:23 +00:00
|
|
|
struct mnt_idmap *idmap,
|
2021-01-21 13:19:27 +00:00
|
|
|
struct dentry *dentry, struct inode *inode, const char *name,
|
|
|
|
const void *buffer, size_t size, int flags);
|
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-09-29 15:48:44 +00:00
|
|
|
|
|
|
|
locking rules:
|
|
|
|
all may block
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
===== ==============
|
|
|
|
ops i_rwsem(inode)
|
|
|
|
===== ==============
|
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-09-29 15:48:44 +00:00
|
|
|
list: no
|
|
|
|
get: no
|
2018-05-24 02:29:10 +00:00
|
|
|
set: exclusive
|
2019-07-26 12:51:27 +00:00
|
|
|
===== ==============
|
|
|
|
|
|
|
|
super_operations
|
|
|
|
================
|
|
|
|
|
|
|
|
prototypes::
|
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-09-29 15:48:44 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
struct inode *(*alloc_inode)(struct super_block *sb);
|
2019-04-10 18:43:44 +00:00
|
|
|
void (*free_inode)(struct inode *);
|
2005-04-16 22:20:36 +00:00
|
|
|
void (*destroy_inode)(struct inode *);
|
2011-05-27 10:53:02 +00:00
|
|
|
void (*dirty_inode) (struct inode *, int flags);
|
2010-12-16 11:04:54 +00:00
|
|
|
int (*write_inode) (struct inode *, struct writeback_control *wbc);
|
2010-06-08 04:37:12 +00:00
|
|
|
int (*drop_inode) (struct inode *);
|
|
|
|
void (*evict_inode) (struct inode *);
|
2005-04-16 22:20:36 +00:00
|
|
|
void (*put_super) (struct super_block *);
|
|
|
|
int (*sync_fs)(struct super_block *sb, int wait);
|
2009-01-10 00:40:58 +00:00
|
|
|
int (*freeze_fs) (struct super_block *);
|
|
|
|
int (*unfreeze_fs) (struct super_block *);
|
2006-06-23 09:02:58 +00:00
|
|
|
int (*statfs) (struct dentry *, struct kstatfs *);
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*remount_fs) (struct super_block *, int *, char *);
|
|
|
|
void (*umount_begin) (struct super_block *);
|
2011-12-09 02:32:45 +00:00
|
|
|
int (*show_options)(struct seq_file *, struct dentry *);
|
2005-04-16 22:20:36 +00:00
|
|
|
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
|
|
|
|
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
|
|
|
|
|
|
|
|
locking rules:
|
2010-06-08 04:37:12 +00:00
|
|
|
All may block [not true, see below]
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
====================== ============ ========================
|
|
|
|
ops s_umount note
|
|
|
|
====================== ============ ========================
|
2009-06-19 18:22:37 +00:00
|
|
|
alloc_inode:
|
2019-04-10 18:43:44 +00:00
|
|
|
free_inode: called from RCU callback
|
2009-06-19 18:22:37 +00:00
|
|
|
destroy_inode:
|
2011-05-27 10:53:02 +00:00
|
|
|
dirty_inode:
|
2009-06-19 18:22:37 +00:00
|
|
|
write_inode:
|
2011-03-22 11:23:39 +00:00
|
|
|
drop_inode: !!!inode->i_lock!!!
|
2010-06-08 04:37:12 +00:00
|
|
|
evict_inode:
|
2009-06-19 18:22:37 +00:00
|
|
|
put_super: write
|
|
|
|
sync_fs: read
|
2012-06-12 14:20:48 +00:00
|
|
|
freeze_fs: write
|
|
|
|
unfreeze_fs: write
|
2010-06-08 04:37:12 +00:00
|
|
|
statfs: maybe(read) (see below)
|
|
|
|
remount_fs: write
|
2009-06-19 18:22:37 +00:00
|
|
|
umount_begin: no
|
|
|
|
show_options: no (namespace_sem)
|
|
|
|
quota_read: no (see below)
|
|
|
|
quota_write: no (see below)
|
2019-07-26 12:51:27 +00:00
|
|
|
====================== ============ ========================
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-06-08 04:37:12 +00:00
|
|
|
->statfs() has s_umount (shared) when called by ustat(2) (native or
|
|
|
|
compat), but that's an accident of bad API; s_umount is used to pin
|
|
|
|
the superblock down when we only have dev_t given us by userland to
|
|
|
|
identify the superblock. Everything else (statfs(), fstatfs(), etc.)
|
|
|
|
doesn't hold it when calling ->statfs() - superblock is pinned down
|
|
|
|
by resolving the pathname passed to syscall.
|
2019-07-26 12:51:27 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
->quota_read() and ->quota_write() functions are both guaranteed to
|
|
|
|
be the only ones operating on the quota file by the quota code (via
|
|
|
|
dqio_sem) (unless an admin really wants to screw up something and
|
|
|
|
writes to quota files with quotas on). For other details about locking
|
|
|
|
see also dquot_operations section.
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
file_system_type
|
|
|
|
================
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
2010-12-16 11:04:54 +00:00
|
|
|
struct dentry *(*mount) (struct file_system_type *, int,
|
|
|
|
const char *, void *);
|
2005-04-16 22:20:36 +00:00
|
|
|
void (*kill_sb) (struct super_block *);
|
2019-07-26 12:51:27 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
locking rules:
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
======= =========
|
|
|
|
ops may block
|
|
|
|
======= =========
|
2010-12-16 11:04:54 +00:00
|
|
|
mount yes
|
|
|
|
kill_sb yes
|
2019-07-26 12:51:27 +00:00
|
|
|
======= =========
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-03-16 13:07:58 +00:00
|
|
|
->mount() returns ERR_PTR or the root dentry; its superblock should be locked
|
|
|
|
on return.
|
2019-07-26 12:51:27 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
->kill_sb() takes a write-locked superblock, does all shutdown work on it,
|
|
|
|
unlocks and drops the reference.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
address_space_operations
|
|
|
|
========================
|
|
|
|
prototypes::
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*writepage)(struct page *page, struct writeback_control *wbc);
|
2022-04-29 12:45:43 +00:00
|
|
|
int (*read_folio)(struct file *, struct folio *);
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*writepages)(struct address_space *, struct writeback_control *);
|
2022-02-09 20:22:00 +00:00
|
|
|
bool (*dirty_folio)(struct address_space *, struct folio *folio);
|
2020-06-02 04:46:44 +00:00
|
|
|
void (*readahead)(struct readahead_control *);
|
2008-10-29 21:00:55 +00:00
|
|
|
int (*write_begin)(struct file *, struct address_space *mapping,
|
2022-02-22 19:31:43 +00:00
|
|
|
loff_t pos, unsigned len,
|
2024-07-15 18:24:01 +00:00
|
|
|
struct folio **foliop, void **fsdata);
|
2008-10-29 21:00:55 +00:00
|
|
|
int (*write_end)(struct file *, struct address_space *mapping,
|
|
|
|
loff_t pos, unsigned len, unsigned copied,
|
2024-07-10 19:45:32 +00:00
|
|
|
struct folio *folio, void *fsdata);
|
2005-04-16 22:20:36 +00:00
|
|
|
sector_t (*bmap)(struct address_space *, sector_t);
|
2022-02-09 20:21:32 +00:00
|
|
|
void (*invalidate_folio) (struct folio *, size_t start, size_t len);
|
2022-04-29 21:00:05 +00:00
|
|
|
bool (*release_folio)(struct folio *, gfp_t);
|
2022-05-01 11:35:31 +00:00
|
|
|
void (*free_folio)(struct folio *);
|
2016-04-07 15:51:58 +00:00
|
|
|
int (*direct_IO)(struct kiocb *, struct iov_iter *iter);
|
2022-06-06 13:00:16 +00:00
|
|
|
int (*migrate_folio)(struct address_space *, struct folio *dst,
|
|
|
|
struct folio *src, enum migrate_mode);
|
2022-02-09 20:21:52 +00:00
|
|
|
int (*launder_folio)(struct folio *);
|
2022-02-09 20:21:27 +00:00
|
|
|
bool (*is_partially_uptodate)(struct folio *, size_t from, size_t count);
|
2023-11-17 16:14:47 +00:00
|
|
|
int (*error_remove_folio)(struct address_space *, struct folio *);
|
2022-05-10 01:20:48 +00:00
|
|
|
int (*swap_activate)(struct swap_info_struct *sis, struct file *f, sector_t *span)
|
2012-07-31 23:44:55 +00:00
|
|
|
int (*swap_deactivate)(struct file *);
|
2022-05-10 01:20:48 +00:00
|
|
|
int (*swap_rw)(struct kiocb *iocb, struct iov_iter *iter);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
locking rules:
|
2022-05-01 11:35:31 +00:00
|
|
|
All except dirty_folio and free_folio may block
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-01-28 18:19:45 +00:00
|
|
|
====================== ======================== ========= ===============
|
2022-05-01 11:35:31 +00:00
|
|
|
ops folio locked i_rwsem invalidate_lock
|
2021-01-28 18:19:45 +00:00
|
|
|
====================== ======================== ========= ===============
|
2010-12-16 11:04:54 +00:00
|
|
|
writepage: yes, unlocks (see below)
|
2022-04-29 12:45:43 +00:00
|
|
|
read_folio: yes, unlocks shared
|
2010-12-16 11:04:54 +00:00
|
|
|
writepages:
|
2022-04-29 21:00:05 +00:00
|
|
|
dirty_folio: maybe
|
2021-01-28 18:19:45 +00:00
|
|
|
readahead: yes, unlocks shared
|
2024-07-15 18:24:01 +00:00
|
|
|
write_begin: locks the folio exclusive
|
2019-07-26 12:51:27 +00:00
|
|
|
write_end: yes, unlocks exclusive
|
2010-12-16 11:04:54 +00:00
|
|
|
bmap:
|
2022-02-09 20:21:32 +00:00
|
|
|
invalidate_folio: yes exclusive
|
2022-04-29 21:00:05 +00:00
|
|
|
release_folio: yes
|
2022-05-01 11:35:31 +00:00
|
|
|
free_folio: yes
|
2010-12-16 11:04:54 +00:00
|
|
|
direct_IO:
|
2022-06-06 13:00:16 +00:00
|
|
|
migrate_folio: yes (both)
|
2022-02-09 20:21:52 +00:00
|
|
|
launder_folio: yes
|
2010-12-16 11:04:54 +00:00
|
|
|
is_partially_uptodate: yes
|
2023-11-17 16:14:47 +00:00
|
|
|
error_remove_folio: yes
|
2012-07-31 23:44:55 +00:00
|
|
|
swap_activate: no
|
|
|
|
swap_deactivate: no
|
2022-05-10 01:20:48 +00:00
|
|
|
swap_rw: yes, unlocks
|
2021-07-27 23:22:12 +00:00
|
|
|
====================== ======================== ========= ===============
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-04-29 12:45:43 +00:00
|
|
|
->write_begin(), ->write_end() and ->read_folio() may be called from
|
2016-03-07 04:27:26 +00:00
|
|
|
the request handler (/dev/loop).
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-04-29 12:45:43 +00:00
|
|
|
->read_folio() unlocks the folio, either synchronously or via I/O
|
2005-04-16 22:20:36 +00:00
|
|
|
completion.
|
|
|
|
|
2022-04-29 12:45:43 +00:00
|
|
|
->readahead() unlocks the folios that I/O is attempted on like ->read_folio().
|
2020-06-02 04:46:44 +00:00
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
->writepage() is used for two purposes: for "memory cleansing" and for
|
2005-04-16 22:20:36 +00:00
|
|
|
"sync". These are quite different operations and the behaviour may differ
|
|
|
|
depending upon the mode.
|
|
|
|
|
|
|
|
If writepage is called for sync (wbc->sync_mode != WBC_SYNC_NONE) then
|
|
|
|
it *must* start I/O against the page, even if that would involve
|
|
|
|
blocking on in-progress I/O.
|
|
|
|
|
|
|
|
If writepage is called for memory cleansing (sync_mode ==
|
|
|
|
WBC_SYNC_NONE) then its role is to get as much writeout underway as
|
|
|
|
possible. So writepage should try to avoid blocking against
|
|
|
|
currently-in-progress I/O.
|
|
|
|
|
|
|
|
If the filesystem is not called for "sync" and it determines that it
|
|
|
|
would need to block against in-progress I/O to be able to start new I/O
|
|
|
|
against the page the filesystem should redirty the page with
|
|
|
|
redirty_page_for_writepage(), then unlock the page and return zero.
|
|
|
|
This may also be done to avoid internal deadlocks, but rarely.
|
|
|
|
|
2007-10-19 21:10:43 +00:00
|
|
|
If the filesystem is called for sync then it must wait on any
|
2005-04-16 22:20:36 +00:00
|
|
|
in-progress I/O and then start new I/O.
|
|
|
|
|
2005-05-01 15:58:37 +00:00
|
|
|
The filesystem should unlock the page synchronously, before returning to the
|
|
|
|
caller, unless ->writepage() returns special WRITEPAGE_ACTIVATE
|
|
|
|
value. WRITEPAGE_ACTIVATE means that page cannot really be written out
|
|
|
|
currently, and VM should stop calling ->writepage() on this page for some
|
|
|
|
time. VM does this by moving page to the head of the active list, hence the
|
|
|
|
name.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
Unless the filesystem is going to redirty_page_for_writepage(), unlock the page
|
|
|
|
and return zero, writepage *must* run set_page_writeback() against the page,
|
|
|
|
followed by unlocking it. Once set_page_writeback() has been run against the
|
|
|
|
page, write I/O can be submitted and the write I/O completion handler must run
|
|
|
|
end_page_writeback() once the I/O is complete. If no I/O is submitted, the
|
|
|
|
filesystem must run end_page_writeback() against the page before returning from
|
|
|
|
writepage.
|
|
|
|
|
|
|
|
That is: after 2.5.12, pages which are under writeout are *not* locked. Note,
|
|
|
|
if the filesystem needs the page to be locked during writeout, that is ok, too,
|
|
|
|
the page is allowed to be unlocked at any point in time between the calls to
|
|
|
|
set_page_writeback() and end_page_writeback().
|
|
|
|
|
|
|
|
Note, failure to run either redirty_page_for_writepage() or the combination of
|
|
|
|
set_page_writeback()/end_page_writeback() on a page submitted to writepage
|
|
|
|
will leave the page itself marked clean but it will be tagged as dirty in the
|
|
|
|
radix tree. This incoherency can lead to all sorts of hard-to-debug problems
|
|
|
|
in the filesystem like having dirty inodes at umount and losing written data.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
->writepages() is used for periodic writeback and for syscall-initiated
|
2005-04-16 22:20:36 +00:00
|
|
|
sync operations. The address_space should start I/O against at least
|
2019-07-26 12:51:27 +00:00
|
|
|
``*nr_to_write`` pages. ``*nr_to_write`` must be decremented for each page
|
|
|
|
which is written. The address_space implementation may write more (or less)
|
|
|
|
pages than ``*nr_to_write`` asks for, but it should try to be reasonably close.
|
|
|
|
If nr_to_write is NULL, all dirty pages must be written.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
writepages should _only_ write pages which are present on
|
|
|
|
mapping->io_pages.
|
|
|
|
|
2022-02-09 20:22:00 +00:00
|
|
|
->dirty_folio() is called from various places in the kernel when
|
|
|
|
the target folio is marked as needing writeback. The folio cannot be
|
|
|
|
truncated because either the caller holds the folio lock, or the caller
|
|
|
|
has found the folio while holding the page table lock which will block
|
|
|
|
truncation.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
->bmap() is currently used by legacy ioctl() (FIBMAP) provided by some
|
2010-12-16 11:04:54 +00:00
|
|
|
filesystems and by the swapper. The latter will eventually go away. Please,
|
|
|
|
keep it that way and don't breed new callers.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-02-09 20:21:32 +00:00
|
|
|
->invalidate_folio() is called when the filesystem must attempt to drop
|
2013-05-22 03:17:23 +00:00
|
|
|
some or all of the buffers from the page when it is being truncated. It
|
2022-02-09 20:21:32 +00:00
|
|
|
returns zero on success. The filesystem must exclusively acquire
|
|
|
|
invalidate_lock before invalidating page cache in truncate / hole punch
|
|
|
|
path (and thus calling into ->invalidate_folio) to block races between page
|
|
|
|
cache invalidation and page cache filling functions (fault, read, ...).
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-06-02 20:33:20 +00:00
|
|
|
->release_folio() is called when the MM wants to make a change to the
|
|
|
|
folio that would invalidate the filesystem's private data. For example,
|
|
|
|
it may be about to be removed from the address_space or split. The folio
|
|
|
|
is locked and not under writeback. It may be dirty. The gfp parameter
|
|
|
|
is not usually used for allocation, but rather to indicate what the
|
|
|
|
filesystem may do to attempt to free the private data. The filesystem may
|
|
|
|
return false to indicate that the folio's private data cannot be freed.
|
|
|
|
If it returns true, it should have already removed the private data from
|
|
|
|
the folio. If a filesystem does not provide a ->release_folio method,
|
|
|
|
the pagecache will assume that private data is buffer_heads and call
|
|
|
|
try_to_free_buffers().
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-05-01 11:35:31 +00:00
|
|
|
->free_folio() is called when the kernel has dropped the folio
|
2010-12-01 18:35:19 +00:00
|
|
|
from the page cache.
|
|
|
|
|
2022-02-09 20:21:52 +00:00
|
|
|
->launder_folio() may be called prior to releasing a folio if
|
|
|
|
it is still found to be dirty. It returns zero if the folio was successfully
|
|
|
|
cleaned, or an error value if not. Note that in order to prevent the folio
|
2007-01-11 07:15:39 +00:00
|
|
|
getting mapped back in and redirtied, it needs to be kept locked
|
|
|
|
across the entire operation.
|
|
|
|
|
2022-05-10 01:20:48 +00:00
|
|
|
->swap_activate() will be called to prepare the given file for swap. It
|
|
|
|
should perform any validation and preparation necessary to ensure that
|
|
|
|
writes can be performed with minimal memory allocation. It should call
|
|
|
|
add_swap_extent(), or the helper iomap_swapfile_activate(), and return
|
|
|
|
the number of extents added. If IO should be submitted through
|
|
|
|
->swap_rw(), it should set SWP_FS_OPS, otherwise IO will be submitted
|
|
|
|
directly to the block device ``sis->bdev``.
|
2012-07-31 23:44:55 +00:00
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
->swap_deactivate() will be called in the sys_swapoff()
|
2012-07-31 23:44:55 +00:00
|
|
|
path after ->swap_activate() returned success.
|
|
|
|
|
2022-05-10 01:20:48 +00:00
|
|
|
->swap_rw will be called for swap IO if SWP_FS_OPS was set by ->swap_activate().
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
file_lock_operations
|
|
|
|
====================
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
|
|
|
|
void (*fl_release_private)(struct file_lock *);
|
|
|
|
|
|
|
|
|
|
|
|
locking rules:
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
=================== ============= =========
|
|
|
|
ops inode->i_lock may block
|
|
|
|
=================== ============= =========
|
2010-12-16 11:04:54 +00:00
|
|
|
fl_copy_lock: yes no
|
2019-07-26 12:51:27 +00:00
|
|
|
fl_release_private: maybe maybe[1]_
|
|
|
|
=================== ============= =========
|
|
|
|
|
|
|
|
.. [1]:
|
|
|
|
->fl_release_private for flock or POSIX locks is currently allowed
|
|
|
|
to block. Leases however can still be freed while the i_lock is held and
|
|
|
|
so fl_release_private called on a lease should not block.
|
2014-08-12 14:38:07 +00:00
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
lock_manager_operations
|
|
|
|
=======================
|
|
|
|
|
|
|
|
prototypes::
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-07-21 00:21:59 +00:00
|
|
|
void (*lm_notify)(struct file_lock *); /* unblock callback */
|
|
|
|
int (*lm_grant)(struct file_lock *, struct file_lock *, int);
|
|
|
|
void (*lm_break)(struct file_lock *); /* break_lease callback */
|
|
|
|
int (*lm_change)(struct file_lock **, int);
|
2017-07-28 20:35:15 +00:00
|
|
|
bool (*lm_breaker_owns_lease)(struct file_lock *);
|
2022-05-02 21:19:25 +00:00
|
|
|
bool (*lm_lock_expirable)(struct file_lock *);
|
|
|
|
void (*lm_expire_lock)(void);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
locking rules:
|
2013-06-21 12:58:15 +00:00
|
|
|
|
2020-06-15 03:22:19 +00:00
|
|
|
====================== ============= ================= =========
|
2022-02-12 18:12:52 +00:00
|
|
|
ops flc_lock blocked_lock_lock may block
|
2020-06-15 03:22:19 +00:00
|
|
|
====================== ============= ================= =========
|
2022-02-12 18:12:52 +00:00
|
|
|
lm_notify: no yes no
|
2013-06-21 12:58:20 +00:00
|
|
|
lm_grant: no no no
|
|
|
|
lm_break: yes no no
|
|
|
|
lm_change yes no no
|
2022-02-12 18:12:52 +00:00
|
|
|
lm_breaker_owns_lease: yes no no
|
2022-05-02 21:19:25 +00:00
|
|
|
lm_lock_expirable yes no no
|
|
|
|
lm_expire_lock no no yes
|
2020-06-15 03:22:19 +00:00
|
|
|
====================== ============= ================= =========
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
buffer_head
|
|
|
|
===========
|
|
|
|
|
|
|
|
prototypes::
|
2013-06-21 12:58:15 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
void (*b_end_io)(struct buffer_head *bh, int uptodate);
|
|
|
|
|
|
|
|
locking rules:
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
called from interrupts. In other words, extreme care is needed here.
|
2005-04-16 22:20:36 +00:00
|
|
|
bh is locked, but that's all warranties we have here. Currently only RAID1,
|
|
|
|
highmem, fs/buffer.c, and fs/ntfs/aops.c are providing these. Block devices
|
|
|
|
call this method upon the IO completion.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
block_device_operations
|
|
|
|
=======================
|
|
|
|
prototypes::
|
|
|
|
|
2010-10-06 08:46:53 +00:00
|
|
|
int (*open) (struct block_device *, fmode_t);
|
|
|
|
int (*release) (struct gendisk *, fmode_t);
|
|
|
|
int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
|
|
|
|
int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
|
2016-06-04 01:06:47 +00:00
|
|
|
int (*direct_access) (struct block_device *, sector_t, void **,
|
2015-08-18 19:55:41 +00:00
|
|
|
unsigned long *);
|
2010-10-06 08:46:53 +00:00
|
|
|
void (*unlock_native_capacity) (struct gendisk *);
|
|
|
|
int (*getgeo)(struct block_device *, struct hd_geometry *);
|
|
|
|
void (*swap_slot_free_notify) (struct block_device *, unsigned long);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
locking rules:
|
2019-07-26 12:51:27 +00:00
|
|
|
|
|
|
|
======================= ===================
|
2021-05-25 06:12:56 +00:00
|
|
|
ops open_mutex
|
2019-07-26 12:51:27 +00:00
|
|
|
======================= ===================
|
2010-12-16 11:04:54 +00:00
|
|
|
open: yes
|
|
|
|
release: yes
|
|
|
|
ioctl: no
|
|
|
|
compat_ioctl: no
|
|
|
|
direct_access: no
|
|
|
|
unlock_native_capacity: no
|
|
|
|
getgeo: no
|
|
|
|
swap_slot_free_notify: no (see below)
|
2019-07-26 12:51:27 +00:00
|
|
|
======================= ===================
|
2010-10-06 08:46:53 +00:00
|
|
|
|
|
|
|
swap_slot_free_notify is called with swap_lock and sometimes the page lock
|
|
|
|
held.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
file_operations
|
|
|
|
===============
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
loff_t (*llseek) (struct file *, loff_t, int);
|
|
|
|
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
|
|
|
|
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
|
2014-02-11 23:37:41 +00:00
|
|
|
ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
|
|
|
|
ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
|
2021-05-10 17:13:53 +00:00
|
|
|
int (*iopoll) (struct kiocb *kiocb, bool spin);
|
2018-05-24 02:29:10 +00:00
|
|
|
int (*iterate_shared) (struct file *, struct dir_context *);
|
2018-01-02 21:50:45 +00:00
|
|
|
__poll_t (*poll) (struct file *, struct poll_table_struct *);
|
2005-04-16 22:20:36 +00:00
|
|
|
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
|
|
|
|
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
|
|
|
|
int (*mmap) (struct file *, struct vm_area_struct *);
|
|
|
|
int (*open) (struct inode *, struct file *);
|
|
|
|
int (*flush) (struct file *);
|
|
|
|
int (*release) (struct inode *, struct file *);
|
2011-07-17 00:44:56 +00:00
|
|
|
int (*fsync) (struct file *, loff_t start, loff_t end, int datasync);
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*fasync) (int, struct file *, int);
|
|
|
|
int (*lock) (struct file *, int, struct file_lock *);
|
|
|
|
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
|
|
|
|
unsigned long, unsigned long, unsigned long);
|
|
|
|
int (*check_flags)(int);
|
2010-12-16 11:04:54 +00:00
|
|
|
int (*flock) (struct file *, int, struct file_lock *);
|
|
|
|
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *,
|
|
|
|
size_t, unsigned int);
|
|
|
|
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *,
|
|
|
|
size_t, unsigned int);
|
2014-08-22 14:40:25 +00:00
|
|
|
int (*setlease)(struct file *, long, struct file_lock **, void **);
|
2011-01-14 12:07:43 +00:00
|
|
|
long (*fallocate)(struct file *, int, loff_t, loff_t);
|
2021-05-10 17:13:53 +00:00
|
|
|
void (*show_fdinfo)(struct seq_file *m, struct file *f);
|
|
|
|
unsigned (*mmap_capabilities)(struct file *);
|
|
|
|
ssize_t (*copy_file_range)(struct file *, loff_t, struct file *,
|
|
|
|
loff_t, size_t, unsigned int);
|
|
|
|
loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in,
|
|
|
|
struct file *file_out, loff_t pos_out,
|
|
|
|
loff_t len, unsigned int remap_flags);
|
|
|
|
int (*fadvise)(struct file *, loff_t, loff_t, int);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
locking rules:
|
2018-06-28 16:43:44 +00:00
|
|
|
All may block.
|
2010-12-16 11:04:54 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
->llseek() locking has moved from llseek to the individual llseek
|
|
|
|
implementations. If your fs is not using generic_file_llseek, you
|
|
|
|
need to acquire and release the appropriate locks in your ->llseek().
|
|
|
|
For many filesystems, it is probably safe to acquire the inode
|
2010-05-26 21:44:54 +00:00
|
|
|
mutex or just to use i_size_read() instead.
|
|
|
|
Note: this does not protect the file->f_pos against concurrent modifications
|
|
|
|
since this is something the userspace has to take care about.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
vfs: get rid of old '->iterate' directory operation
All users now just use '->iterate_shared()', which only takes the
directory inode lock for reading.
Filesystems that never got convered to shared mode now instead use a
wrapper that drops the lock, re-takes it in write mode, calls the old
function, and then downgrades the lock back to read mode.
This way the VFS layer and other callers no longer need to care about
filesystems that never got converted to the modern era.
The filesystems that use the new wrapper are ceph, coda, exfat, jfs,
ntfs, ocfs2, overlayfs, and vboxsf.
Honestly, several of them look like they really could just iterate their
directories in shared mode and skip the wrapper entirely, but the point
of this change is to not change semantics or fix filesystems that
haven't been fixed in the last 7+ years, but to finally get rid of the
dual iterators.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-08-05 19:25:01 +00:00
|
|
|
->iterate_shared() is called with i_rwsem held for reading, and with the
|
|
|
|
file f_pos_lock held exclusively
|
2018-05-24 02:29:10 +00:00
|
|
|
|
2010-12-16 11:04:54 +00:00
|
|
|
->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags.
|
|
|
|
Most instances call fasync_helper(), which does that maintenance, so it's
|
|
|
|
not normally something one needs to worry about. Return values > 0 will be
|
|
|
|
mapped to zero in the VFS layer.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
->readdir() and ->ioctl() on directories must be changed. Ideally we would
|
|
|
|
move ->readdir() to inode_operations and use a separate method for directory
|
|
|
|
->ioctl() or kill the latter completely. One of the problems is that for
|
|
|
|
anything that resembles union-mount we won't have a struct file for all
|
|
|
|
components. And there are other reasons why the current interface is a mess...
|
|
|
|
|
|
|
|
->read on directories probably must go away - we should just enforce -EISDIR
|
|
|
|
in sys_read() and friends.
|
|
|
|
|
2014-08-22 22:50:48 +00:00
|
|
|
->setlease operations should call generic_setlease() before or after setting
|
|
|
|
the lease within the individual filesystem to record the result of the
|
|
|
|
operation
|
|
|
|
|
2021-01-28 18:19:45 +00:00
|
|
|
->fallocate implementation must be really careful to maintain page cache
|
|
|
|
consistency when punching holes or performing other operations that invalidate
|
|
|
|
page cache contents. Usually the filesystem needs to call
|
|
|
|
truncate_inode_pages_range() to invalidate relevant range of the page cache.
|
|
|
|
However the filesystem usually also needs to update its internal (and on disk)
|
|
|
|
view of file offset -> disk block mapping. Until this update is finished, the
|
|
|
|
filesystem needs to block page faults and reads from reloading now-stale page
|
|
|
|
cache contents from the disk. Since VFS acquires mapping->invalidate_lock in
|
|
|
|
shared mode when loading pages from disk (filemap_fault(), filemap_read(),
|
|
|
|
readahead paths), the fallocate implementation must take the invalidate_lock to
|
|
|
|
prevent reloading.
|
|
|
|
|
|
|
|
->copy_file_range and ->remap_file_range implementations need to serialize
|
|
|
|
against modifications of file data while the operation is running. For
|
|
|
|
blocking changes through write(2) and similar operations inode->i_rwsem can be
|
|
|
|
used. To block changes to file contents via a memory mapping during the
|
|
|
|
operation, the filesystem must take mapping->invalidate_lock to coordinate
|
|
|
|
with ->page_mkwrite.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
dquot_operations
|
|
|
|
================
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
int (*write_dquot) (struct dquot *);
|
|
|
|
int (*acquire_dquot) (struct dquot *);
|
|
|
|
int (*release_dquot) (struct dquot *);
|
|
|
|
int (*mark_dirty) (struct dquot *);
|
|
|
|
int (*write_info) (struct super_block *, int);
|
|
|
|
|
|
|
|
These operations are intended to be more or less wrapping functions that ensure
|
|
|
|
a proper locking wrt the filesystem and call the generic quota operations.
|
|
|
|
|
|
|
|
What filesystem should expect from the generic quota functions:
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
============== ============ =========================
|
|
|
|
ops FS recursion Held locks when called
|
|
|
|
============== ============ =========================
|
2005-04-16 22:20:36 +00:00
|
|
|
write_dquot: yes dqonoff_sem or dqptr_sem
|
|
|
|
acquire_dquot: yes dqonoff_sem or dqptr_sem
|
|
|
|
release_dquot: yes dqonoff_sem or dqptr_sem
|
|
|
|
mark_dirty: no -
|
|
|
|
write_info: yes dqonoff_sem
|
2019-07-26 12:51:27 +00:00
|
|
|
============== ============ =========================
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
FS recursion means calling ->quota_read() and ->quota_write() from superblock
|
|
|
|
operations.
|
|
|
|
|
|
|
|
More details about quota locking can be found in fs/dquot.c.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
vm_operations_struct
|
|
|
|
====================
|
|
|
|
|
|
|
|
prototypes::
|
|
|
|
|
2023-08-18 20:23:34 +00:00
|
|
|
void (*open)(struct vm_area_struct *);
|
|
|
|
void (*close)(struct vm_area_struct *);
|
|
|
|
vm_fault_t (*fault)(struct vm_fault *);
|
|
|
|
vm_fault_t (*huge_fault)(struct vm_fault *, unsigned int order);
|
|
|
|
vm_fault_t (*map_pages)(struct vm_fault *, pgoff_t start, pgoff_t end);
|
2018-07-22 13:01:34 +00:00
|
|
|
vm_fault_t (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
|
|
|
vm_fault_t (*pfn_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
2008-07-24 04:27:05 +00:00
|
|
|
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
locking rules:
|
2019-07-26 12:51:27 +00:00
|
|
|
|
2023-08-18 20:23:34 +00:00
|
|
|
============= ========== ===========================
|
2020-06-09 04:33:54 +00:00
|
|
|
ops mmap_lock PageLocked(page)
|
2023-08-18 20:23:34 +00:00
|
|
|
============= ========== ===========================
|
|
|
|
open: write
|
|
|
|
close: read/write
|
|
|
|
fault: read can return with page locked
|
|
|
|
huge_fault: maybe-read
|
|
|
|
map_pages: maybe-read
|
|
|
|
page_mkwrite: read can return with page locked
|
|
|
|
pfn_mkwrite: read
|
|
|
|
access: read
|
|
|
|
============= ========== ===========================
|
2007-07-19 08:47:01 +00:00
|
|
|
|
2021-01-28 18:19:45 +00:00
|
|
|
->fault() is called when a previously not present pte is about to be faulted
|
|
|
|
in. The filesystem must find and return the page associated with the passed in
|
|
|
|
"pgoff" in the vm_fault structure. If it is possible that the page may be
|
|
|
|
truncated and/or invalidated, then the filesystem must lock invalidate_lock,
|
|
|
|
then ensure the page is not already truncated (invalidate_lock will block
|
mm: close page_mkwrite races
Change page_mkwrite to allow implementations to return with the page
locked, and also change it's callers (in page fault paths) to hold the
lock until the page is marked dirty. This allows the filesystem to have
full control of page dirtying events coming from the VM.
Rather than simply hold the page locked over the page_mkwrite call, we
call page_mkwrite with the page unlocked and allow callers to return with
it locked, so filesystems can avoid LOR conditions with page lock.
The problem with the current scheme is this: a filesystem that wants to
associate some metadata with a page as long as the page is dirty, will
perform this manipulation in its ->page_mkwrite. It currently then must
return with the page unlocked and may not hold any other locks (according
to existing page_mkwrite convention).
In this window, the VM could write out the page, clearing page-dirty. The
filesystem has no good way to detect that a dirty pte is about to be
attached, so it will happily write out the page, at which point, the
filesystem may manipulate the metadata to reflect that the page is no
longer dirty.
It is not always possible to perform the required metadata manipulation in
->set_page_dirty, because that function cannot block or fail. The
filesystem may need to allocate some data structure, for example.
And the VM cannot mark the pte dirty before page_mkwrite, because
page_mkwrite is allowed to fail, so we must not allow any window where the
page could be written to if page_mkwrite does fail.
This solution of holding the page locked over the 3 critical operations
(page_mkwrite, setting the pte dirty, and finally setting the page dirty)
closes out races nicely, preventing page cleaning for writeout being
initiated in that window. This provides the filesystem with a strong
synchronisation against the VM here.
- Sage needs this race closed for ceph filesystem.
- Trond for NFS (http://bugzilla.kernel.org/show_bug.cgi?id=12913).
- I need it for fsblock.
- I suspect other filesystems may need it too (eg. btrfs).
- I have converted buffer.c to the new locking. Even simple block allocation
under dirty pages might be susceptible to i_size changing under partial page
at the end of file (we also have a buffer.c-side problem here, but it cannot
be fixed properly without this patch).
- Other filesystems (eg. NFS, maybe btrfs) will need to change their
page_mkwrite functions themselves.
[ This also moves page_mkwrite another step closer to fault, which should
eventually allow page_mkwrite to be moved into ->fault, and thus avoiding a
filesystem calldown and page lock/unlock cycle in __do_fault. ]
[akpm@linux-foundation.org: fix derefs of NULL ->mapping]
Cc: Sage Weil <sage@newdream.net>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-30 22:08:16 +00:00
|
|
|
subsequent truncate), and then return with VM_FAULT_LOCKED, and the page
|
|
|
|
locked. The VM will unlock the page.
|
|
|
|
|
2023-08-18 20:23:34 +00:00
|
|
|
->huge_fault() is called when there is no PUD or PMD entry present. This
|
|
|
|
gives the filesystem the opportunity to install a PUD or PMD sized page.
|
|
|
|
Filesystems can also use the ->fault method to return a PMD sized page,
|
|
|
|
so implementing this function may not be necessary. In particular,
|
|
|
|
filesystems should not call filemap_fault() from ->huge_fault().
|
|
|
|
The mmap_lock may not be held when this method is called.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
->map_pages() is called when VM asks to map easy accessible pages.
|
2016-07-26 22:25:20 +00:00
|
|
|
Filesystem should find and map pages associated with offsets from "start_pgoff"
|
2023-03-27 17:45:15 +00:00
|
|
|
till "end_pgoff". ->map_pages() is called with the RCU lock held and must
|
mm: introduce vm_ops->map_pages()
Here's new version of faultaround patchset. It took a while to tune it
and collect performance data.
First patch adds new callback ->map_pages to vm_operations_struct.
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from
"pgoff" till "max_pgoff". ->map_pages() is called with page table
locked and must not block. If it's not possible to reach a page without
blocking, filesystem should skip it. Filesystem should use do_set_pte()
to setup page table entry. Pointer to entry associated with offset
"pgoff" is passed in "pte" field in vm_fault structure. Pointers to
entries for other offsets should be calculated relative to "pte".
Currently VM use ->map_pages only on read page fault path. We try to
map FAULT_AROUND_PAGES a time. FAULT_AROUND_PAGES is 16 for now.
Performance data for different FAULT_AROUND_ORDER is below.
TODO:
- implement ->map_pages() for shmem/tmpfs;
- modify get_user_pages() to be able to use ->map_pages() and implement
mmap(MAP_POPULATE|MAP_NONBLOCK) on top.
=========================================================================
Tested on 4-socket machine (120 threads) with 128GiB of RAM.
Few real-world workloads. The sweet spot for FAULT_AROUND_ORDER here is
somewhere between 3 and 5. Let's say 4 :)
Linux build (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 283,301,572 247,151,987 212,215,789 204,772,882 199,568,944 194,703,779 193,381,485
time, seconds 151.227629483 153.920996480 151.356125472 150.863792049 150.879207877 151.150764954 151.450962358
Linux rebuild (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 5,396,854 4,148,444 2,855,286 2,577,282 2,361,957 2,169,573 2,112,643
time, seconds 27.404543757 27.559725591 27.030057426 26.855045126 26.678618635 26.974523490 26.761320095
Git test suite (make -j60 test)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 129,591,823 99,200,751 66,106,718 57,606,410 51,510,808 45,776,813 44,085,515
time, seconds 66.087215026 64.784546905 64.401156567 65.282708668 66.034016829 66.793780811 67.237810413
Two synthetic tests: access every word in file in sequential/random order.
It doesn't improve much after FAULT_AROUND_ORDER == 4.
Sequential access 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 4,195,437 2,098,275 525,068 262,251 131,170 32,856 8,282
time, seconds 7.250461742 6.461711074 5.493859139 5.488488147 5.707213983 5.898510832 5.109232856
8 threads
minor-faults 33,557,540 16,892,728 4,515,848 2,366,999 1,423,382 442,732 142,339
time, seconds 16.649304881 9.312555263 6.612490639 6.394316732 6.669827501 6.75078944 6.371900528
32 threads
minor-faults 134,228,222 67,526,810 17,725,386 9,716,537 4,763,731 1,668,921 537,200
time, seconds 49.164430543 29.712060103 12.938649729 10.175151004 11.840094583 9.594081325 9.928461797
60 threads
minor-faults 251,687,988 126,146,952 32,919,406 18,208,804 10,458,947 2,733,907 928,217
time, seconds 86.260656897 49.626551828 22.335007632 17.608243696 16.523119035 16.339489186 16.326390902
120 threads
minor-faults 503,352,863 252,939,677 67,039,168 35,191,827 19,170,091 4,688,357 1,471,862
time, seconds 124.589206333 79.757867787 39.508707872 32.167281632 29.972989292 28.729834575 28.042251622
Random access 1GiB file
1 thread
minor-faults 262,636 132,743 34,369 17,299 8,527 3,451 1,222
time, seconds 15.351890914 16.613802482 16.569227308 15.179220992 16.557356122 16.578247824 15.365266994
8 threads
minor-faults 2,098,948 1,061,871 273,690 154,501 87,110 25,663 7,384
time, seconds 15.040026343 15.096933500 14.474757288 14.289129964 14.411537468 14.296316837 14.395635804
32 threads
minor-faults 8,390,734 4,231,023 1,054,432 528,847 269,242 97,746 26,881
time, seconds 20.430433109 21.585235358 22.115062928 14.872878951 14.880856305 14.883370649 14.821261690
60 threads
minor-faults 15,733,258 7,892,809 1,973,393 988,266 594,789 164,994 51,691
time, seconds 26.577302548 25.692397770 18.728863715 20.153026398 21.619101933 17.745086260 17.613215273
120 threads
minor-faults 31,471,111 15,816,616 3,959,209 1,978,685 1,008,299 264,635 96,010
time, seconds 41.835322703 40.459786095 36.085306105 35.313894834 35.814445675 36.552633793 34.289210594
Touch only one page in page table in 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 8,372 8,324 8,270 8,260 8,249 8,239 8,237
time, seconds 0.039892712 0.045369149 0.051846126 0.063681685 0.079095975 0.17652406 0.541213386
8 threads
minor-faults 65,731 65,681 65,628 65,620 65,608 65,599 65,596
time, seconds 0.124159196 0.488600638 0.156854426 0.191901957 0.242631486 0.543569456 1.677303984
32 threads
minor-faults 262,388 262,341 262,285 262,276 262,266 262,257 263,183
time, seconds 0.452421421 0.488600638 0.565020946 0.648229739 0.789850823 1.651584361 5.000361559
60 threads
minor-faults 491,822 491,792 491,723 491,711 491,701 491,691 491,825
time, seconds 0.763288616 0.869620515 0.980727360 1.161732354 1.466915814 3.04041448 9.308612938
120 threads
minor-faults 983,466 983,655 983,366 983,372 983,363 984,083 984,164
time, seconds 1.595846553 1.667902182 2.008959376 2.425380942 2.941368804 5.977807890 18.401846125
This patch (of 2):
Introduce new vm_ops callback ->map_pages() and uses it for mapping easy
accessible pages around fault address.
On read page fault, if filesystem provides ->map_pages(), we try to map up
to FAULT_AROUND_PAGES pages around page fault address in hope to reduce
number of minor page faults.
We call ->map_pages first and use ->fault() as fallback if page by the
offset is not ready to be mapped (cold page cache or something).
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ning Qu <quning@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-07 22:37:18 +00:00
|
|
|
not block. If it's not possible to reach a page without blocking,
|
2023-08-02 15:14:04 +00:00
|
|
|
filesystem should skip it. Filesystem should use set_pte_range() to setup
|
2016-07-26 22:25:20 +00:00
|
|
|
page table entry. Pointer to entry associated with the page is passed in
|
2016-12-14 23:06:58 +00:00
|
|
|
"pte" field in vm_fault structure. Pointers to entries for other offsets
|
2016-07-26 22:25:20 +00:00
|
|
|
should be calculated relative to "pte".
|
mm: introduce vm_ops->map_pages()
Here's new version of faultaround patchset. It took a while to tune it
and collect performance data.
First patch adds new callback ->map_pages to vm_operations_struct.
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from
"pgoff" till "max_pgoff". ->map_pages() is called with page table
locked and must not block. If it's not possible to reach a page without
blocking, filesystem should skip it. Filesystem should use do_set_pte()
to setup page table entry. Pointer to entry associated with offset
"pgoff" is passed in "pte" field in vm_fault structure. Pointers to
entries for other offsets should be calculated relative to "pte".
Currently VM use ->map_pages only on read page fault path. We try to
map FAULT_AROUND_PAGES a time. FAULT_AROUND_PAGES is 16 for now.
Performance data for different FAULT_AROUND_ORDER is below.
TODO:
- implement ->map_pages() for shmem/tmpfs;
- modify get_user_pages() to be able to use ->map_pages() and implement
mmap(MAP_POPULATE|MAP_NONBLOCK) on top.
=========================================================================
Tested on 4-socket machine (120 threads) with 128GiB of RAM.
Few real-world workloads. The sweet spot for FAULT_AROUND_ORDER here is
somewhere between 3 and 5. Let's say 4 :)
Linux build (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 283,301,572 247,151,987 212,215,789 204,772,882 199,568,944 194,703,779 193,381,485
time, seconds 151.227629483 153.920996480 151.356125472 150.863792049 150.879207877 151.150764954 151.450962358
Linux rebuild (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 5,396,854 4,148,444 2,855,286 2,577,282 2,361,957 2,169,573 2,112,643
time, seconds 27.404543757 27.559725591 27.030057426 26.855045126 26.678618635 26.974523490 26.761320095
Git test suite (make -j60 test)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 129,591,823 99,200,751 66,106,718 57,606,410 51,510,808 45,776,813 44,085,515
time, seconds 66.087215026 64.784546905 64.401156567 65.282708668 66.034016829 66.793780811 67.237810413
Two synthetic tests: access every word in file in sequential/random order.
It doesn't improve much after FAULT_AROUND_ORDER == 4.
Sequential access 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 4,195,437 2,098,275 525,068 262,251 131,170 32,856 8,282
time, seconds 7.250461742 6.461711074 5.493859139 5.488488147 5.707213983 5.898510832 5.109232856
8 threads
minor-faults 33,557,540 16,892,728 4,515,848 2,366,999 1,423,382 442,732 142,339
time, seconds 16.649304881 9.312555263 6.612490639 6.394316732 6.669827501 6.75078944 6.371900528
32 threads
minor-faults 134,228,222 67,526,810 17,725,386 9,716,537 4,763,731 1,668,921 537,200
time, seconds 49.164430543 29.712060103 12.938649729 10.175151004 11.840094583 9.594081325 9.928461797
60 threads
minor-faults 251,687,988 126,146,952 32,919,406 18,208,804 10,458,947 2,733,907 928,217
time, seconds 86.260656897 49.626551828 22.335007632 17.608243696 16.523119035 16.339489186 16.326390902
120 threads
minor-faults 503,352,863 252,939,677 67,039,168 35,191,827 19,170,091 4,688,357 1,471,862
time, seconds 124.589206333 79.757867787 39.508707872 32.167281632 29.972989292 28.729834575 28.042251622
Random access 1GiB file
1 thread
minor-faults 262,636 132,743 34,369 17,299 8,527 3,451 1,222
time, seconds 15.351890914 16.613802482 16.569227308 15.179220992 16.557356122 16.578247824 15.365266994
8 threads
minor-faults 2,098,948 1,061,871 273,690 154,501 87,110 25,663 7,384
time, seconds 15.040026343 15.096933500 14.474757288 14.289129964 14.411537468 14.296316837 14.395635804
32 threads
minor-faults 8,390,734 4,231,023 1,054,432 528,847 269,242 97,746 26,881
time, seconds 20.430433109 21.585235358 22.115062928 14.872878951 14.880856305 14.883370649 14.821261690
60 threads
minor-faults 15,733,258 7,892,809 1,973,393 988,266 594,789 164,994 51,691
time, seconds 26.577302548 25.692397770 18.728863715 20.153026398 21.619101933 17.745086260 17.613215273
120 threads
minor-faults 31,471,111 15,816,616 3,959,209 1,978,685 1,008,299 264,635 96,010
time, seconds 41.835322703 40.459786095 36.085306105 35.313894834 35.814445675 36.552633793 34.289210594
Touch only one page in page table in 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 8,372 8,324 8,270 8,260 8,249 8,239 8,237
time, seconds 0.039892712 0.045369149 0.051846126 0.063681685 0.079095975 0.17652406 0.541213386
8 threads
minor-faults 65,731 65,681 65,628 65,620 65,608 65,599 65,596
time, seconds 0.124159196 0.488600638 0.156854426 0.191901957 0.242631486 0.543569456 1.677303984
32 threads
minor-faults 262,388 262,341 262,285 262,276 262,266 262,257 263,183
time, seconds 0.452421421 0.488600638 0.565020946 0.648229739 0.789850823 1.651584361 5.000361559
60 threads
minor-faults 491,822 491,792 491,723 491,711 491,701 491,691 491,825
time, seconds 0.763288616 0.869620515 0.980727360 1.161732354 1.466915814 3.04041448 9.308612938
120 threads
minor-faults 983,466 983,655 983,366 983,372 983,363 984,083 984,164
time, seconds 1.595846553 1.667902182 2.008959376 2.425380942 2.941368804 5.977807890 18.401846125
This patch (of 2):
Introduce new vm_ops callback ->map_pages() and uses it for mapping easy
accessible pages around fault address.
On read page fault, if filesystem provides ->map_pages(), we try to map up
to FAULT_AROUND_PAGES pages around page fault address in hope to reduce
number of minor page faults.
We call ->map_pages first and use ->fault() as fallback if page by the
offset is not ready to be mapped (cold page cache or something).
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ning Qu <quning@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-07 22:37:18 +00:00
|
|
|
|
2021-01-28 18:19:45 +00:00
|
|
|
->page_mkwrite() is called when a previously read-only pte is about to become
|
|
|
|
writeable. The filesystem again must ensure that there are no
|
|
|
|
truncate/invalidate races or races with operations such as ->remap_file_range
|
|
|
|
or ->copy_file_range, and then return with the page locked. Usually
|
|
|
|
mapping->invalidate_lock is suitable for proper serialization. If the page has
|
|
|
|
been truncated, the filesystem should not look up a new page like the ->fault()
|
|
|
|
handler, but simply return with VM_FAULT_NOPAGE, which will cause the VM to
|
|
|
|
retry the fault.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
->pfn_mkwrite() is the same as page_mkwrite but when the pte is
|
2015-04-15 23:15:11 +00:00
|
|
|
VM_PFNMAP or VM_MIXEDMAP with a page-less entry. Expected return is
|
|
|
|
VM_FAULT_NOPAGE. Or one of the VM_FAULT_ERROR types. The default behavior
|
|
|
|
after this call is to make the pte read-write, unless pfn_mkwrite returns
|
|
|
|
an error.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
->access() is called when get_user_pages() fails in
|
2013-12-05 19:34:05 +00:00
|
|
|
access_process_vm(), typically used to debug a process through
|
2008-07-24 04:27:05 +00:00
|
|
|
/proc/pid/mem or ptrace. This function is needed only for
|
|
|
|
VM_IO | VM_PFNMAP VMAs.
|
|
|
|
|
2019-07-26 12:51:27 +00:00
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
Dubious stuff
|
|
|
|
|
|
|
|
(if you break something or notice that it is broken and do not fix it yourself
|
|
|
|
- at least put it here)
|