[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/*
|
|
|
|
FUSE: Filesystem in Userspace
|
2008-11-26 11:03:54 +00:00
|
|
|
Copyright (C) 2001-2008 Miklos Szeredi <miklos@szeredi.hu>
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
|
|
|
|
This program can be distributed under the terms of the GNU GPL.
|
|
|
|
See the file COPYING.
|
|
|
|
*/
|
|
|
|
|
2008-10-16 14:08:57 +00:00
|
|
|
#ifndef _FS_FUSE_I_H
|
|
|
|
#define _FS_FUSE_I_H
|
|
|
|
|
2019-03-27 09:15:17 +00:00
|
|
|
#ifndef pr_fmt
|
|
|
|
# define pr_fmt(fmt) "fuse: " fmt
|
|
|
|
#endif
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
#include <linux/fuse.h>
|
|
|
|
#include <linux/fs.h>
|
2006-06-25 12:48:50 +00:00
|
|
|
#include <linux/mount.h>
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
#include <linux/wait.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/backing-dev.h>
|
2006-06-25 12:48:51 +00:00
|
|
|
#include <linux/mutex.h>
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
#include <linux/rwsem.h>
|
2008-11-26 11:03:55 +00:00
|
|
|
#include <linux/rbtree.h>
|
|
|
|
#include <linux/poll.h>
|
2011-02-25 13:44:58 +00:00
|
|
|
#include <linux/workqueue.h>
|
2016-03-11 16:35:34 +00:00
|
|
|
#include <linux/kref.h>
|
2016-08-29 13:46:37 +00:00
|
|
|
#include <linux/xattr.h>
|
2014-07-02 21:29:19 +00:00
|
|
|
#include <linux/pid_namespace.h>
|
2017-03-03 09:04:03 +00:00
|
|
|
#include <linux/refcount.h>
|
2018-02-21 17:18:07 +00:00
|
|
|
#include <linux/user_namespace.h>
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
|
fuse: add max_pages to init_out
Replace FUSE_MAX_PAGES_PER_REQ with the configurable parameter max_pages to
improve performance.
Old RFC with detailed description of the problem and many fixes by Mitsuo
Hayasaka (mitsuo.hayasaka.hu@hitachi.com):
- https://lkml.org/lkml/2012/7/5/136
We've encountered performance degradation and fixed it on a big and complex
virtual environment.
Environment to reproduce degradation and improvement:
1. Add lag to user mode FUSE
Add nanosleep(&(struct timespec){ 0, 1000 }, NULL); to xmp_write_buf in
passthrough_fh.c
2. patch UM fuse with configurable max_pages parameter. The patch will be
provided latter.
3. run test script and perform test on tmpfs
fuse_test()
{
cd /tmp
mkdir -p fusemnt
passthrough_fh -o max_pages=$1 /tmp/fusemnt
grep fuse /proc/self/mounts
dd conv=fdatasync oflag=dsync if=/dev/zero of=fusemnt/tmp/tmp \
count=1K bs=1M 2>&1 | grep -v records
rm fusemnt/tmp/tmp
killall passthrough_fh
}
Test results:
passthrough_fh /tmp/fusemnt fuse.passthrough_fh \
rw,nosuid,nodev,relatime,user_id=0,group_id=0 0 0
1073741824 bytes (1.1 GB) copied, 1.73867 s, 618 MB/s
passthrough_fh /tmp/fusemnt fuse.passthrough_fh \
rw,nosuid,nodev,relatime,user_id=0,group_id=0,max_pages=256 0 0
1073741824 bytes (1.1 GB) copied, 1.15643 s, 928 MB/s
Obviously with bigger lag the difference between 'before' and 'after'
will be more significant.
Mitsuo Hayasaka, in 2012 (https://lkml.org/lkml/2012/7/5/136),
observed improvement from 400-550 to 520-740.
Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2018-09-06 12:37:06 +00:00
|
|
|
/** Default max number of pages that can be used in a single read request */
|
|
|
|
#define FUSE_DEFAULT_MAX_PAGES_PER_REQ 32
|
|
|
|
|
|
|
|
/** Maximum of max_pages received in init_out */
|
|
|
|
#define FUSE_MAX_MAX_PAGES 256
|
2005-09-09 20:10:27 +00:00
|
|
|
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
/** Bias for fi->writectr, meaning new writepages must not be sent */
|
|
|
|
#define FUSE_NOWRITE INT_MIN
|
|
|
|
|
2006-01-06 08:19:40 +00:00
|
|
|
/** It could be as large as PATH_MAX, but would that have any uses? */
|
|
|
|
#define FUSE_NAME_MAX 1024
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/** Number of dentries for each connection in the control filesystem */
|
2009-08-26 17:18:24 +00:00
|
|
|
#define FUSE_CTL_NUM_DENTRIES 5
|
2006-06-25 12:48:51 +00:00
|
|
|
|
|
|
|
/** List of active connections */
|
|
|
|
extern struct list_head fuse_conn_list;
|
|
|
|
|
|
|
|
/** Global mutex protecting fuse_conn_list and the control filesystem */
|
|
|
|
extern struct mutex fuse_mutex;
|
2005-09-09 20:10:35 +00:00
|
|
|
|
2009-08-26 17:18:24 +00:00
|
|
|
/** Module parameters */
|
|
|
|
extern unsigned max_user_bgreq;
|
|
|
|
extern unsigned max_user_congthresh;
|
|
|
|
|
2010-12-07 19:16:56 +00:00
|
|
|
/* One forget request */
|
|
|
|
struct fuse_forget_link {
|
2010-12-07 19:16:56 +00:00
|
|
|
struct fuse_forget_one forget_one;
|
2010-12-07 19:16:56 +00:00
|
|
|
struct fuse_forget_link *next;
|
|
|
|
};
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/** FUSE inode */
|
|
|
|
struct fuse_inode {
|
|
|
|
/** Inode data */
|
|
|
|
struct inode inode;
|
|
|
|
|
|
|
|
/** Unique ID, which identifies the inode between userspace
|
|
|
|
* and kernel */
|
|
|
|
u64 nodeid;
|
|
|
|
|
2005-09-09 20:10:29 +00:00
|
|
|
/** Number of lookups on this inode */
|
|
|
|
u64 nlookup;
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/** The request used for sending the FORGET message */
|
2010-12-07 19:16:56 +00:00
|
|
|
struct fuse_forget_link *forget;
|
2005-09-09 20:10:28 +00:00
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/** Time in jiffies until the file attributes are valid */
|
2006-07-30 10:04:10 +00:00
|
|
|
u64 i_time;
|
2007-10-17 06:31:03 +00:00
|
|
|
|
2018-10-15 13:43:06 +00:00
|
|
|
/* Which attributes are invalid */
|
|
|
|
u32 inval_mask;
|
|
|
|
|
2007-10-17 06:31:03 +00:00
|
|
|
/** The sticky bit in inode->i_mode may have been removed, so
|
|
|
|
preserve the original mode */
|
2011-07-26 07:17:33 +00:00
|
|
|
umode_t orig_i_mode;
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
|
2023-08-10 10:45:05 +00:00
|
|
|
/* Cache birthtime */
|
|
|
|
struct timespec64 i_btime;
|
|
|
|
|
2012-05-10 15:49:38 +00:00
|
|
|
/** 64 bit inode number */
|
|
|
|
u64 orig_ino;
|
|
|
|
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
/** Version of last attribute change */
|
|
|
|
u64 attr_version;
|
2007-10-18 10:07:03 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
union {
|
|
|
|
/* Write related fields (regular file only) */
|
|
|
|
struct {
|
2018-11-09 10:33:22 +00:00
|
|
|
/* Files usable in writepage. Protected by fi->lock */
|
2018-10-01 08:07:05 +00:00
|
|
|
struct list_head write_files;
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* Writepages pending on truncate or fsync */
|
|
|
|
struct list_head queued_writes;
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* Number of sent writes, a negative bias
|
|
|
|
* (FUSE_NOWRITE) means more writes are blocked */
|
|
|
|
int writectr;
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* Waitq for writepage completion */
|
|
|
|
wait_queue_head_t page_waitq;
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* List of writepage requestst (pending or sent) */
|
2019-09-19 14:11:20 +00:00
|
|
|
struct rb_root writepages;
|
2018-10-01 08:07:05 +00:00
|
|
|
};
|
2013-01-15 03:23:28 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* readdir cache (directory only) */
|
|
|
|
struct {
|
|
|
|
/* true if fully cached */
|
|
|
|
bool cached;
|
2018-10-01 08:07:04 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* size of cache */
|
|
|
|
loff_t size;
|
2018-10-01 08:07:04 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* position at end of cache (position of next entry) */
|
|
|
|
loff_t pos;
|
2018-10-01 08:07:04 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* version of the cache */
|
|
|
|
u64 version;
|
2018-10-01 08:07:04 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* modification time of directory when cache was
|
|
|
|
* started */
|
|
|
|
struct timespec64 mtime;
|
2018-10-01 08:07:04 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* iversion of directory when cache was started */
|
|
|
|
u64 iversion;
|
2018-10-01 08:07:05 +00:00
|
|
|
|
2018-10-01 08:07:05 +00:00
|
|
|
/* protects above fields */
|
|
|
|
spinlock_t lock;
|
|
|
|
} rdc;
|
|
|
|
};
|
2018-10-01 08:07:04 +00:00
|
|
|
|
2013-01-15 03:23:28 +00:00
|
|
|
/** Miscellaneous bits describing inode state */
|
|
|
|
unsigned long state;
|
2016-06-30 11:10:49 +00:00
|
|
|
|
|
|
|
/** Lock for serializing lookup and readdir for back compatibility*/
|
|
|
|
struct mutex mutex;
|
2018-11-09 10:33:22 +00:00
|
|
|
|
|
|
|
/** Lock to protect write related fields */
|
|
|
|
spinlock_t lock;
|
2020-08-19 22:19:51 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_FUSE_DAX
|
|
|
|
/*
|
|
|
|
* Dax specific inode data
|
|
|
|
*/
|
|
|
|
struct fuse_inode_dax *dax;
|
|
|
|
#endif
|
2013-01-15 03:23:28 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/** FUSE inode state bits */
|
|
|
|
enum {
|
|
|
|
/** Advise readdirplus */
|
|
|
|
FUSE_I_ADVISE_RDPLUS,
|
2013-10-01 14:41:22 +00:00
|
|
|
/** Initialized with readdirplus */
|
|
|
|
FUSE_I_INIT_RDPLUS,
|
fuse: hotfix truncate_pagecache() issue
The way how fuse calls truncate_pagecache() from fuse_change_attributes()
is completely wrong. Because, w/o i_mutex held, we never sure whether
'oldsize' and 'attr->size' are valid by the time of execution of
truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
released fc->lock in the middle of fuse_change_attributes(), we completely
loose control of actions which may happen with given inode until we reach
truncate_pagecache. The list of potentially dangerous actions includes
mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.
The typical outcome of doing truncate_pagecache() with outdated arguments
is data corruption from user point of view. This is (in some sense)
acceptable in cases when the issue is triggered by a change of the file on
the server (i.e. externally wrt fuse operation), but it is absolutely
intolerable in scenarios when a single fuse client modifies a file without
any external intervention. A real life case I discovered by fsx-linux
looked like this:
1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
to the server synchronously, then calls fuse_change_attributes(). The
latter updates i_size, releases fc->lock, but before comparing oldsize vs
attr->size..
3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
updating attributes and i_size, but now oldsize is equal to
outarg.attr.size because i_size has just been updated (step 2). Hence,
fuse_do_setattr() returns w/o calling truncate_pagecache().
4. As soon as ftruncate(2) completes, the user extends file size by
write(2) making a hole in the middle of file, then reads data from the hole
either by read(2) or mmap-ed read. The user expects to get zero data from
the hole, but gets stale data because truncate_pagecache() is not executed
yet.
The scenario above illustrates one side of the problem: not truncating the
page cache even though we should. Another side corresponds to truncating
page cache too late, when the state of inode changed significantly.
Theoretically, the following is possible:
1. As in the previous scenario fuse_dentry_revalidate() discovered that
i_size changed (due to our own fuse_do_setattr()) and is going to call
truncate_pagecache() for some 'new_size' it believes valid right now. But
by the time that particular truncate_pagecache() is called ...
2. fuse_do_setattr() returns (either having called truncate_pagecache() or
not -- it doesn't matter).
3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
4. mmap-ed write makes a page in the extended region dirty.
The result will be the lost of data user wrote on the fourth step.
The patch is a hotfix resolving the issue in a simplistic way: let's skip
dangerous i_size update and truncate_pagecache if an operation changing
file size is in progress. This simplistic approach looks correct for the
cases w/o external changes. And to handle them properly, more sophisticated
and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
postpone it until the issue is well discussed on the mailing list(s).
Changed in v2:
- improved patch description to cover both sides of the issue.
Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
2013-08-30 13:06:04 +00:00
|
|
|
/** An operation changing file size is in progress */
|
|
|
|
FUSE_I_SIZE_UNSTABLE,
|
2020-12-10 14:33:14 +00:00
|
|
|
/* Bad inode */
|
|
|
|
FUSE_I_BAD,
|
2023-08-10 10:45:05 +00:00
|
|
|
/* Has btime */
|
|
|
|
FUSE_I_BTIME,
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
};
|
|
|
|
|
2009-04-28 14:56:36 +00:00
|
|
|
struct fuse_conn;
|
2020-05-06 15:44:12 +00:00
|
|
|
struct fuse_mount;
|
2019-09-10 13:04:10 +00:00
|
|
|
struct fuse_release_args;
|
2009-04-28 14:56:36 +00:00
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** FUSE specific file data */
|
|
|
|
struct fuse_file {
|
2009-04-28 14:56:36 +00:00
|
|
|
/** Fuse connection for this file */
|
2020-05-06 15:44:12 +00:00
|
|
|
struct fuse_mount *fm;
|
2009-04-28 14:56:36 +00:00
|
|
|
|
2019-09-10 13:04:10 +00:00
|
|
|
/* Argument space reserved for release */
|
|
|
|
struct fuse_release_args *release_args;
|
2005-09-09 20:10:30 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** Kernel file handle guaranteed to be unique */
|
|
|
|
u64 kh;
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** File handle used by userspace */
|
|
|
|
u64 fh;
|
2007-10-17 06:31:00 +00:00
|
|
|
|
2009-04-28 14:56:36 +00:00
|
|
|
/** Node id of this file */
|
|
|
|
u64 nodeid;
|
|
|
|
|
2007-10-17 06:31:00 +00:00
|
|
|
/** Refcount */
|
2017-03-03 09:04:03 +00:00
|
|
|
refcount_t count;
|
2007-10-18 10:07:03 +00:00
|
|
|
|
2009-04-28 14:56:37 +00:00
|
|
|
/** FOPEN_* flags returned by open */
|
|
|
|
u32 open_flags;
|
|
|
|
|
2007-10-18 10:07:03 +00:00
|
|
|
/** Entry on inode's write_files list */
|
|
|
|
struct list_head write_entry;
|
2008-11-26 11:03:55 +00:00
|
|
|
|
2018-10-01 08:07:04 +00:00
|
|
|
/* Readdir related */
|
|
|
|
struct {
|
|
|
|
/*
|
|
|
|
* Protects below fields against (crazy) parallel readdir on
|
|
|
|
* same open file. Uncontended in the normal case.
|
|
|
|
*/
|
|
|
|
struct mutex lock;
|
|
|
|
|
|
|
|
/* Dir stream position */
|
|
|
|
loff_t pos;
|
|
|
|
|
|
|
|
/* Offset in cache */
|
|
|
|
loff_t cache_off;
|
2018-10-01 08:07:04 +00:00
|
|
|
|
|
|
|
/* Version of cache we are reading */
|
|
|
|
u64 version;
|
|
|
|
|
2018-10-01 08:07:04 +00:00
|
|
|
} readdir;
|
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** RB node to be linked on fuse_conn->polled_files */
|
|
|
|
struct rb_node polled_node;
|
|
|
|
|
|
|
|
/** Wait queue head for poll */
|
|
|
|
wait_queue_head_t poll_wait;
|
2011-08-08 14:08:08 +00:00
|
|
|
|
|
|
|
/** Has flock been performed on this file? */
|
|
|
|
bool flock:1;
|
2005-09-09 20:10:30 +00:00
|
|
|
};
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** One input argument of a request */
|
|
|
|
struct fuse_in_arg {
|
|
|
|
unsigned size;
|
|
|
|
const void *value;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** One output argument of a request */
|
|
|
|
struct fuse_arg {
|
|
|
|
unsigned size;
|
|
|
|
void *value;
|
|
|
|
};
|
|
|
|
|
2012-10-26 15:49:24 +00:00
|
|
|
/** FUSE page descriptor */
|
|
|
|
struct fuse_page_desc {
|
|
|
|
unsigned int length;
|
|
|
|
unsigned int offset;
|
|
|
|
};
|
|
|
|
|
2014-12-12 08:49:05 +00:00
|
|
|
struct fuse_args {
|
2019-09-10 13:04:08 +00:00
|
|
|
uint64_t nodeid;
|
2019-09-10 13:04:08 +00:00
|
|
|
uint32_t opcode;
|
2022-11-10 14:46:33 +00:00
|
|
|
uint8_t in_numargs;
|
|
|
|
uint8_t out_numargs;
|
|
|
|
uint8_t ext_idx;
|
2019-09-10 13:04:08 +00:00
|
|
|
bool force:1;
|
2019-09-10 13:04:08 +00:00
|
|
|
bool noreply:1;
|
2019-09-10 13:04:08 +00:00
|
|
|
bool nocreds:1;
|
2019-09-10 13:04:09 +00:00
|
|
|
bool in_pages:1;
|
|
|
|
bool out_pages:1;
|
2022-03-07 15:30:44 +00:00
|
|
|
bool user_pages:1;
|
2019-09-10 13:04:08 +00:00
|
|
|
bool out_argvar:1;
|
2019-09-10 13:04:09 +00:00
|
|
|
bool page_zeroing:1;
|
|
|
|
bool page_replace:1;
|
2020-04-20 15:01:34 +00:00
|
|
|
bool may_block:1;
|
2022-11-10 14:46:33 +00:00
|
|
|
bool is_ext:1;
|
2019-09-10 13:04:08 +00:00
|
|
|
struct fuse_in_arg in_args[3];
|
|
|
|
struct fuse_arg out_args[2];
|
2020-05-06 15:44:12 +00:00
|
|
|
void (*end)(struct fuse_mount *fm, struct fuse_args *args, int error);
|
2014-12-12 08:49:05 +00:00
|
|
|
};
|
|
|
|
|
2019-09-10 13:04:09 +00:00
|
|
|
struct fuse_args_pages {
|
|
|
|
struct fuse_args args;
|
|
|
|
struct page **pages;
|
|
|
|
struct fuse_page_desc *descs;
|
|
|
|
unsigned int num_pages;
|
|
|
|
};
|
|
|
|
|
2014-12-12 08:49:05 +00:00
|
|
|
#define FUSE_ARGS(args) struct fuse_args args = {}
|
|
|
|
|
2012-12-14 15:20:41 +00:00
|
|
|
/** The request IO state (for asynchronous processing) */
|
|
|
|
struct fuse_io_priv {
|
2016-03-11 16:35:34 +00:00
|
|
|
struct kref refcnt;
|
2012-12-14 15:20:41 +00:00
|
|
|
int async;
|
|
|
|
spinlock_t lock;
|
|
|
|
unsigned reqs;
|
|
|
|
ssize_t bytes;
|
|
|
|
size_t size;
|
|
|
|
__u64 offset;
|
|
|
|
bool write;
|
2017-07-13 02:26:58 +00:00
|
|
|
bool should_dirty;
|
2012-12-14 15:20:41 +00:00
|
|
|
int err;
|
|
|
|
struct kiocb *iocb;
|
2015-02-02 13:59:43 +00:00
|
|
|
struct completion *done;
|
2016-04-07 11:48:11 +00:00
|
|
|
bool blocking;
|
2012-12-14 15:20:41 +00:00
|
|
|
};
|
|
|
|
|
2017-09-12 14:57:53 +00:00
|
|
|
#define FUSE_IO_PRIV_SYNC(i) \
|
2016-03-11 16:35:34 +00:00
|
|
|
{ \
|
2016-11-14 16:12:23 +00:00
|
|
|
.refcnt = KREF_INIT(1), \
|
2016-03-11 16:35:34 +00:00
|
|
|
.async = 0, \
|
2017-09-12 14:57:53 +00:00
|
|
|
.iocb = i, \
|
2016-03-11 16:35:34 +00:00
|
|
|
}
|
|
|
|
|
2015-07-01 14:25:58 +00:00
|
|
|
/**
|
|
|
|
* Request flags
|
|
|
|
*
|
|
|
|
* FR_ISREPLY: set if the request has reply
|
|
|
|
* FR_FORCE: force sending of the request even if interrupted
|
|
|
|
* FR_BACKGROUND: request is sent in the background
|
|
|
|
* FR_WAITING: request is counted as "waiting"
|
|
|
|
* FR_ABORTED: the request was aborted
|
|
|
|
* FR_INTERRUPTED: the request has been interrupted
|
|
|
|
* FR_LOCKED: data is being copied to/from the request
|
2015-07-01 14:26:01 +00:00
|
|
|
* FR_PENDING: request is not yet in userspace
|
|
|
|
* FR_SENT: request is in userspace, waiting for an answer
|
|
|
|
* FR_FINISHED: request is finished
|
2015-07-01 14:26:06 +00:00
|
|
|
* FR_PRIVATE: request is on private list
|
2020-02-13 08:16:07 +00:00
|
|
|
* FR_ASYNC: request is asynchronous
|
2015-07-01 14:25:58 +00:00
|
|
|
*/
|
|
|
|
enum fuse_req_flag {
|
|
|
|
FR_ISREPLY,
|
|
|
|
FR_FORCE,
|
|
|
|
FR_BACKGROUND,
|
|
|
|
FR_WAITING,
|
|
|
|
FR_ABORTED,
|
|
|
|
FR_INTERRUPTED,
|
|
|
|
FR_LOCKED,
|
2015-07-01 14:26:01 +00:00
|
|
|
FR_PENDING,
|
|
|
|
FR_SENT,
|
|
|
|
FR_FINISHED,
|
2015-07-01 14:26:06 +00:00
|
|
|
FR_PRIVATE,
|
2020-02-13 08:16:07 +00:00
|
|
|
FR_ASYNC,
|
2015-07-01 14:25:58 +00:00
|
|
|
};
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/**
|
|
|
|
* A request to the client
|
2015-07-01 14:25:58 +00:00
|
|
|
*
|
|
|
|
* .waitq.lock protects the following fields:
|
|
|
|
* - FR_ABORTED
|
|
|
|
* - FR_LOCKED (may also be modified under fc->lock, tested under both)
|
2005-09-09 20:10:27 +00:00
|
|
|
*/
|
|
|
|
struct fuse_req {
|
2006-04-11 05:54:58 +00:00
|
|
|
/** This can be on either pending processing or io lists in
|
|
|
|
fuse_conn */
|
2005-09-09 20:10:27 +00:00
|
|
|
struct list_head list;
|
|
|
|
|
2006-06-25 12:48:54 +00:00
|
|
|
/** Entry on the interrupts list */
|
|
|
|
struct list_head intr_entry;
|
|
|
|
|
2019-09-10 13:04:10 +00:00
|
|
|
/* Input/output arguments */
|
|
|
|
struct fuse_args *args;
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** refcount */
|
2017-03-03 09:04:04 +00:00
|
|
|
refcount_t count;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2015-07-01 14:25:58 +00:00
|
|
|
/* Request flags, updated with test/set/clear_bit() */
|
|
|
|
unsigned long flags;
|
2006-04-11 19:16:09 +00:00
|
|
|
|
2019-09-10 13:04:11 +00:00
|
|
|
/* The request input header */
|
|
|
|
struct {
|
|
|
|
struct fuse_in_header h;
|
|
|
|
} in;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2019-09-10 13:04:11 +00:00
|
|
|
/* The request output header */
|
|
|
|
struct {
|
|
|
|
struct fuse_out_header h;
|
|
|
|
} out;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
|
|
|
/** Used to wake up the task waiting for completion of request*/
|
|
|
|
wait_queue_head_t waitq;
|
|
|
|
|
virtio-fs: add virtiofs filesystem
Add a basic file system module for virtio-fs. This does not yet contain
shared data support between host and guest or metadata coherency speedups.
However it is already significantly faster than virtio-9p.
Design Overview
===============
With the goal of designing something with better performance and local file
system semantics, a bunch of ideas were proposed.
- Use fuse protocol (instead of 9p) for communication between guest and
host. Guest kernel will be fuse client and a fuse server will run on
host to serve the requests.
- For data access inside guest, mmap portion of file in QEMU address space
and guest accesses this memory using dax. That way guest page cache is
bypassed and there is only one copy of data (on host). This will also
enable mmap(MAP_SHARED) between guests.
- For metadata coherency, there is a shared memory region which contains
version number associated with metadata and any guest changing metadata
updates version number and other guests refresh metadata on next access.
This is yet to be implemented.
How virtio-fs differs from existing approaches
==============================================
The unique idea behind virtio-fs is to take advantage of the co-location of
the virtual machine and hypervisor to avoid communication (vmexits).
DAX allows file contents to be accessed without communication with the
hypervisor. The shared memory region for metadata avoids communication in
the common case where metadata is unchanged.
By replacing expensive communication with cheaper shared memory accesses,
we expect to achieve better performance than approaches based on network
file system protocols. In addition, this also makes it easier to achieve
local file system semantics (coherency).
These techniques are not applicable to network file system protocols since
the communications channel is bypassed by taking advantage of shared memory
on a local machine. This is why we decided to build virtio-fs rather than
focus on 9P or NFS.
Caching Modes
=============
Like virtio-9p, different caching modes are supported which determine the
coherency level as well. The “cache=FOO” and “writeback” options control
the level of coherence between the guest and host filesystems.
- cache=none
metadata, data and pathname lookup are not cached in guest. They are
always fetched from host and any changes are immediately pushed to host.
- cache=always
metadata, data and pathname lookup are cached in guest and never expire.
- cache=auto
metadata and pathname lookup cache expires after a configured amount of
time (default is 1 second). Data is cached while the file is open
(close to open consistency).
- writeback/no_writeback
These options control the writeback strategy. If writeback is disabled,
then normal writes will immediately be synchronized with the host fs.
If writeback is enabled, then writes may be cached in the guest until
the file is closed or an fsync(2) performed. This option has no effect
on mmap-ed writes or writes going through the DAX mechanism.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2018-06-12 08:41:17 +00:00
|
|
|
#if IS_ENABLED(CONFIG_VIRTIO_FS)
|
|
|
|
/** virtio-fs's physically contiguous buffer for in and out args */
|
|
|
|
void *argbuf;
|
|
|
|
#endif
|
2020-04-20 15:54:38 +00:00
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/** fuse_mount this request belongs to */
|
|
|
|
struct fuse_mount *fm;
|
2005-09-09 20:10:27 +00:00
|
|
|
};
|
|
|
|
|
2018-06-18 14:53:19 +00:00
|
|
|
struct fuse_iqueue;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Input queue callbacks
|
|
|
|
*
|
|
|
|
* Input queue signalling is device-specific. For example, the /dev/fuse file
|
|
|
|
* uses fiq->waitq and fasync to wake processes that are waiting on queue
|
|
|
|
* readiness. These callbacks allow other device types to respond to input
|
|
|
|
* queue activity.
|
|
|
|
*/
|
|
|
|
struct fuse_iqueue_ops {
|
|
|
|
/**
|
|
|
|
* Signal that a forget has been queued
|
|
|
|
*/
|
|
|
|
void (*wake_forget_and_unlock)(struct fuse_iqueue *fiq)
|
|
|
|
__releases(fiq->lock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Signal that an INTERRUPT request has been queued
|
|
|
|
*/
|
|
|
|
void (*wake_interrupt_and_unlock)(struct fuse_iqueue *fiq)
|
|
|
|
__releases(fiq->lock);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Signal that a request has been queued
|
|
|
|
*/
|
|
|
|
void (*wake_pending_and_unlock)(struct fuse_iqueue *fiq)
|
|
|
|
__releases(fiq->lock);
|
virtio-fs: add virtiofs filesystem
Add a basic file system module for virtio-fs. This does not yet contain
shared data support between host and guest or metadata coherency speedups.
However it is already significantly faster than virtio-9p.
Design Overview
===============
With the goal of designing something with better performance and local file
system semantics, a bunch of ideas were proposed.
- Use fuse protocol (instead of 9p) for communication between guest and
host. Guest kernel will be fuse client and a fuse server will run on
host to serve the requests.
- For data access inside guest, mmap portion of file in QEMU address space
and guest accesses this memory using dax. That way guest page cache is
bypassed and there is only one copy of data (on host). This will also
enable mmap(MAP_SHARED) between guests.
- For metadata coherency, there is a shared memory region which contains
version number associated with metadata and any guest changing metadata
updates version number and other guests refresh metadata on next access.
This is yet to be implemented.
How virtio-fs differs from existing approaches
==============================================
The unique idea behind virtio-fs is to take advantage of the co-location of
the virtual machine and hypervisor to avoid communication (vmexits).
DAX allows file contents to be accessed without communication with the
hypervisor. The shared memory region for metadata avoids communication in
the common case where metadata is unchanged.
By replacing expensive communication with cheaper shared memory accesses,
we expect to achieve better performance than approaches based on network
file system protocols. In addition, this also makes it easier to achieve
local file system semantics (coherency).
These techniques are not applicable to network file system protocols since
the communications channel is bypassed by taking advantage of shared memory
on a local machine. This is why we decided to build virtio-fs rather than
focus on 9P or NFS.
Caching Modes
=============
Like virtio-9p, different caching modes are supported which determine the
coherency level as well. The “cache=FOO” and “writeback” options control
the level of coherence between the guest and host filesystems.
- cache=none
metadata, data and pathname lookup are not cached in guest. They are
always fetched from host and any changes are immediately pushed to host.
- cache=always
metadata, data and pathname lookup are cached in guest and never expire.
- cache=auto
metadata and pathname lookup cache expires after a configured amount of
time (default is 1 second). Data is cached while the file is open
(close to open consistency).
- writeback/no_writeback
These options control the writeback strategy. If writeback is disabled,
then normal writes will immediately be synchronized with the host fs.
If writeback is enabled, then writes may be cached in the guest until
the file is closed or an fsync(2) performed. This option has no effect
on mmap-ed writes or writes going through the DAX mechanism.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2018-06-12 08:41:17 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Clean up when fuse_iqueue is destroyed
|
|
|
|
*/
|
|
|
|
void (*release)(struct fuse_iqueue *fiq);
|
2018-06-18 14:53:19 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/** /dev/fuse input queue operations */
|
|
|
|
extern const struct fuse_iqueue_ops fuse_dev_fiq_ops;
|
|
|
|
|
2015-07-01 14:26:01 +00:00
|
|
|
struct fuse_iqueue {
|
2015-07-01 14:26:01 +00:00
|
|
|
/** Connection established */
|
|
|
|
unsigned connected;
|
|
|
|
|
fuse: fix deadlock with aio poll and fuse_iqueue::waitq.lock
When IOCB_CMD_POLL is used on the FUSE device, aio_poll() disables IRQs
and takes kioctx::ctx_lock, then fuse_iqueue::waitq.lock.
This may have to wait for fuse_iqueue::waitq.lock to be released by one
of many places that take it with IRQs enabled. Since the IRQ handler
may take kioctx::ctx_lock, lockdep reports that a deadlock is possible.
Fix it by protecting the state of struct fuse_iqueue with a separate
spinlock, and only accessing fuse_iqueue::waitq using the versions of
the waitqueue functions which do IRQ-safe locking internally.
Reproducer:
#include <fcntl.h>
#include <stdio.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <linux/aio_abi.h>
int main()
{
char opts[128];
int fd = open("/dev/fuse", O_RDWR);
aio_context_t ctx = 0;
struct iocb cb = { .aio_lio_opcode = IOCB_CMD_POLL, .aio_fildes = fd };
struct iocb *cbp = &cb;
sprintf(opts, "fd=%d,rootmode=040000,user_id=0,group_id=0", fd);
mkdir("mnt", 0700);
mount("foo", "mnt", "fuse", 0, opts);
syscall(__NR_io_setup, 1, &ctx);
syscall(__NR_io_submit, ctx, 1, &cbp);
}
Beginning of lockdep output:
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
5.3.0-rc5 #9 Not tainted
-----------------------------------------------------
syz_fuse/135 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
000000003590ceda (&fiq->waitq){+.+.}, at: spin_lock include/linux/spinlock.h:338 [inline]
000000003590ceda (&fiq->waitq){+.+.}, at: aio_poll fs/aio.c:1751 [inline]
000000003590ceda (&fiq->waitq){+.+.}, at: __io_submit_one.constprop.0+0x203/0x5b0 fs/aio.c:1825
and this task is already holding:
0000000075037284 (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq include/linux/spinlock.h:363 [inline]
0000000075037284 (&(&ctx->ctx_lock)->rlock){..-.}, at: aio_poll fs/aio.c:1749 [inline]
0000000075037284 (&(&ctx->ctx_lock)->rlock){..-.}, at: __io_submit_one.constprop.0+0x1f4/0x5b0 fs/aio.c:1825
which would create a new lock dependency:
(&(&ctx->ctx_lock)->rlock){..-.} -> (&fiq->waitq){+.+.}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(&(&ctx->ctx_lock)->rlock){..-.}
[...]
Reported-by: syzbot+af05535bb79520f95431@syzkaller.appspotmail.com
Reported-by: syzbot+d86c4426a01f60feddc7@syzkaller.appspotmail.com
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
Cc: <stable@vger.kernel.org> # v4.19+
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2019-09-09 03:15:18 +00:00
|
|
|
/** Lock protecting accesses to members of this structure */
|
|
|
|
spinlock_t lock;
|
|
|
|
|
2015-07-01 14:26:01 +00:00
|
|
|
/** Readers of the connection are waiting on this */
|
|
|
|
wait_queue_head_t waitq;
|
|
|
|
|
|
|
|
/** The next unique request id */
|
|
|
|
u64 reqctr;
|
|
|
|
|
|
|
|
/** The list of pending requests */
|
|
|
|
struct list_head pending;
|
|
|
|
|
|
|
|
/** Pending interrupts */
|
|
|
|
struct list_head interrupts;
|
|
|
|
|
|
|
|
/** Queue of pending forgets */
|
|
|
|
struct fuse_forget_link forget_list_head;
|
|
|
|
struct fuse_forget_link *forget_list_tail;
|
|
|
|
|
|
|
|
/** Batching of FORGET requests (positive indicates FORGET batch) */
|
|
|
|
int forget_batch;
|
|
|
|
|
|
|
|
/** O_ASYNC requests */
|
|
|
|
struct fasync_struct *fasync;
|
2018-06-18 14:53:19 +00:00
|
|
|
|
|
|
|
/** Device-specific callbacks */
|
|
|
|
const struct fuse_iqueue_ops *ops;
|
|
|
|
|
|
|
|
/** Device-specific state */
|
|
|
|
void *priv;
|
2015-07-01 14:26:01 +00:00
|
|
|
};
|
|
|
|
|
2018-09-11 10:12:14 +00:00
|
|
|
#define FUSE_PQ_HASH_BITS 8
|
|
|
|
#define FUSE_PQ_HASH_SIZE (1 << FUSE_PQ_HASH_BITS)
|
|
|
|
|
2015-07-01 14:26:04 +00:00
|
|
|
struct fuse_pqueue {
|
2015-07-01 14:26:04 +00:00
|
|
|
/** Connection established */
|
|
|
|
unsigned connected;
|
|
|
|
|
2015-07-01 14:26:06 +00:00
|
|
|
/** Lock protecting accessess to members of this structure */
|
|
|
|
spinlock_t lock;
|
|
|
|
|
2018-09-11 10:12:14 +00:00
|
|
|
/** Hash table of requests being processed */
|
|
|
|
struct list_head *processing;
|
2015-07-01 14:26:04 +00:00
|
|
|
|
|
|
|
/** The list of requests under I/O */
|
|
|
|
struct list_head io;
|
|
|
|
};
|
|
|
|
|
2015-07-01 14:26:08 +00:00
|
|
|
/**
|
|
|
|
* Fuse device instance
|
|
|
|
*/
|
|
|
|
struct fuse_dev {
|
|
|
|
/** Fuse connection for this device */
|
|
|
|
struct fuse_conn *fc;
|
|
|
|
|
2015-07-01 14:26:09 +00:00
|
|
|
/** Processing queue */
|
|
|
|
struct fuse_pqueue pq;
|
|
|
|
|
2015-07-01 14:26:08 +00:00
|
|
|
/** list entry on fc->devices */
|
|
|
|
struct list_head entry;
|
|
|
|
};
|
|
|
|
|
2021-11-25 07:05:25 +00:00
|
|
|
enum fuse_dax_mode {
|
|
|
|
FUSE_DAX_INODE_DEFAULT, /* default */
|
|
|
|
FUSE_DAX_ALWAYS, /* "-o dax=always" */
|
|
|
|
FUSE_DAX_NEVER, /* "-o dax=never" */
|
|
|
|
FUSE_DAX_INODE_USER, /* "-o dax=inode" */
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline bool fuse_is_inode_dax_mode(enum fuse_dax_mode mode)
|
|
|
|
{
|
|
|
|
return mode == FUSE_DAX_INODE_DEFAULT || mode == FUSE_DAX_INODE_USER;
|
|
|
|
}
|
|
|
|
|
2018-06-13 09:23:04 +00:00
|
|
|
struct fuse_fs_context {
|
|
|
|
int fd;
|
2021-08-05 03:57:27 +00:00
|
|
|
struct file *file;
|
2018-06-13 09:23:04 +00:00
|
|
|
unsigned int rootmode;
|
|
|
|
kuid_t user_id;
|
|
|
|
kgid_t group_id;
|
|
|
|
bool is_bdev:1;
|
|
|
|
bool fd_present:1;
|
|
|
|
bool rootmode_present:1;
|
|
|
|
bool user_id_present:1;
|
|
|
|
bool group_id_present:1;
|
|
|
|
bool default_permissions:1;
|
|
|
|
bool allow_other:1;
|
2019-08-29 09:01:20 +00:00
|
|
|
bool destroy:1;
|
2019-05-06 19:35:43 +00:00
|
|
|
bool no_control:1;
|
|
|
|
bool no_force_umount:1;
|
2020-08-19 22:19:45 +00:00
|
|
|
bool legacy_opts_show:1;
|
2021-11-25 07:05:25 +00:00
|
|
|
enum fuse_dax_mode dax_mode;
|
2018-06-13 09:23:04 +00:00
|
|
|
unsigned int max_read;
|
|
|
|
unsigned int blksize;
|
|
|
|
const char *subtype;
|
|
|
|
|
2020-08-19 22:19:47 +00:00
|
|
|
/* DAX device, may be NULL */
|
|
|
|
struct dax_device *dax_dev;
|
|
|
|
|
2018-06-13 09:23:04 +00:00
|
|
|
/* fuse_dev pointer to fill in, should contain NULL on entry */
|
|
|
|
void **fudptr;
|
|
|
|
};
|
|
|
|
|
2021-09-01 10:39:02 +00:00
|
|
|
struct fuse_sync_bucket {
|
|
|
|
/* count is a possible scalability bottleneck */
|
|
|
|
atomic_t count;
|
|
|
|
wait_queue_head_t waitq;
|
|
|
|
struct rcu_head rcu;
|
|
|
|
};
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/**
|
|
|
|
* A Fuse connection.
|
|
|
|
*
|
2020-05-06 15:44:12 +00:00
|
|
|
* This structure is created, when the root filesystem is mounted, and
|
|
|
|
* is destroyed, when the client device is closed and the last
|
|
|
|
* fuse_mount is destroyed.
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
*/
|
|
|
|
struct fuse_conn {
|
2006-04-11 05:54:55 +00:00
|
|
|
/** Lock protecting accessess to members of this structure */
|
|
|
|
spinlock_t lock;
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/** Refcount */
|
2017-03-03 09:04:05 +00:00
|
|
|
refcount_t count;
|
2006-06-25 12:48:51 +00:00
|
|
|
|
2015-07-01 14:26:09 +00:00
|
|
|
/** Number of fuse_dev's */
|
|
|
|
atomic_t dev_count;
|
|
|
|
|
2013-10-04 01:21:39 +00:00
|
|
|
struct rcu_head rcu;
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/** The user id for this mount */
|
2012-02-08 00:26:03 +00:00
|
|
|
kuid_t user_id;
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
|
2005-09-09 20:10:34 +00:00
|
|
|
/** The group id for this mount */
|
2012-02-08 00:26:03 +00:00
|
|
|
kgid_t group_id;
|
2005-09-09 20:10:34 +00:00
|
|
|
|
2014-07-02 21:29:19 +00:00
|
|
|
/** The pid namespace for this mount */
|
|
|
|
struct pid_namespace *pid_ns;
|
|
|
|
|
2018-02-21 17:18:07 +00:00
|
|
|
/** The user namespace for this mount */
|
|
|
|
struct user_namespace *user_ns;
|
|
|
|
|
2005-09-09 20:10:33 +00:00
|
|
|
/** Maximum read size */
|
|
|
|
unsigned max_read;
|
|
|
|
|
2005-09-09 20:10:35 +00:00
|
|
|
/** Maximum write size */
|
|
|
|
unsigned max_write;
|
|
|
|
|
2021-03-18 13:52:23 +00:00
|
|
|
/** Maximum number of pages that can be used in a single request */
|
fuse: add max_pages to init_out
Replace FUSE_MAX_PAGES_PER_REQ with the configurable parameter max_pages to
improve performance.
Old RFC with detailed description of the problem and many fixes by Mitsuo
Hayasaka (mitsuo.hayasaka.hu@hitachi.com):
- https://lkml.org/lkml/2012/7/5/136
We've encountered performance degradation and fixed it on a big and complex
virtual environment.
Environment to reproduce degradation and improvement:
1. Add lag to user mode FUSE
Add nanosleep(&(struct timespec){ 0, 1000 }, NULL); to xmp_write_buf in
passthrough_fh.c
2. patch UM fuse with configurable max_pages parameter. The patch will be
provided latter.
3. run test script and perform test on tmpfs
fuse_test()
{
cd /tmp
mkdir -p fusemnt
passthrough_fh -o max_pages=$1 /tmp/fusemnt
grep fuse /proc/self/mounts
dd conv=fdatasync oflag=dsync if=/dev/zero of=fusemnt/tmp/tmp \
count=1K bs=1M 2>&1 | grep -v records
rm fusemnt/tmp/tmp
killall passthrough_fh
}
Test results:
passthrough_fh /tmp/fusemnt fuse.passthrough_fh \
rw,nosuid,nodev,relatime,user_id=0,group_id=0 0 0
1073741824 bytes (1.1 GB) copied, 1.73867 s, 618 MB/s
passthrough_fh /tmp/fusemnt fuse.passthrough_fh \
rw,nosuid,nodev,relatime,user_id=0,group_id=0,max_pages=256 0 0
1073741824 bytes (1.1 GB) copied, 1.15643 s, 928 MB/s
Obviously with bigger lag the difference between 'before' and 'after'
will be more significant.
Mitsuo Hayasaka, in 2012 (https://lkml.org/lkml/2012/7/5/136),
observed improvement from 400-550 to 520-740.
Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2018-09-06 12:37:06 +00:00
|
|
|
unsigned int max_pages;
|
|
|
|
|
2021-03-18 13:52:22 +00:00
|
|
|
/** Constrain ->max_pages to this value during feature negotiation */
|
|
|
|
unsigned int max_pages_limit;
|
|
|
|
|
2015-07-01 14:26:01 +00:00
|
|
|
/** Input queue */
|
|
|
|
struct fuse_iqueue iq;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** The next unique kernel file handle */
|
2019-01-24 09:40:17 +00:00
|
|
|
atomic64_t khctr;
|
2008-11-26 11:03:55 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** rbtree of fuse_files waiting for poll events indexed by ph */
|
|
|
|
struct rb_root polled_files;
|
|
|
|
|
2009-07-02 00:28:41 +00:00
|
|
|
/** Maximum number of outstanding background requests */
|
|
|
|
unsigned max_background;
|
|
|
|
|
|
|
|
/** Number of background requests at which congestion starts */
|
|
|
|
unsigned congestion_threshold;
|
|
|
|
|
2006-04-11 05:54:59 +00:00
|
|
|
/** Number of requests currently in the background */
|
|
|
|
unsigned num_background;
|
|
|
|
|
2008-02-06 09:38:39 +00:00
|
|
|
/** Number of background requests currently queued for userspace */
|
|
|
|
unsigned active_background;
|
|
|
|
|
|
|
|
/** The list of background requests set aside for later queuing */
|
|
|
|
struct list_head bg_queue;
|
|
|
|
|
2018-08-27 15:29:46 +00:00
|
|
|
/** Protects: max_background, congestion_threshold, num_background,
|
|
|
|
* active_background, bg_queue, blocked */
|
|
|
|
spinlock_t bg_lock;
|
|
|
|
|
2013-03-21 14:02:15 +00:00
|
|
|
/** Flag indicating that INIT reply has been received. Allocating
|
|
|
|
* any fuse request will be suspended until the flag is set */
|
|
|
|
int initialized;
|
|
|
|
|
2006-04-11 05:54:59 +00:00
|
|
|
/** Flag indicating if connection is blocked. This will be
|
|
|
|
the case before the INIT reply is received, and if there
|
|
|
|
are too many outstading backgrounds requests */
|
|
|
|
int blocked;
|
|
|
|
|
|
|
|
/** waitq for blocked connection */
|
|
|
|
wait_queue_head_t blocked_waitq;
|
2007-10-17 06:31:00 +00:00
|
|
|
|
2006-01-17 06:14:41 +00:00
|
|
|
/** Connection established, cleared on umount, connection
|
|
|
|
abort and device release */
|
2006-01-17 06:14:52 +00:00
|
|
|
unsigned connected;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
2017-11-09 20:23:35 +00:00
|
|
|
/** Connection aborted via sysfs */
|
|
|
|
bool aborted;
|
|
|
|
|
2006-01-17 06:14:52 +00:00
|
|
|
/** Connection failed (version mismatch). Cannot race with
|
|
|
|
setting other bitfields since it is only set once in INIT
|
|
|
|
reply, before any other request, and never cleared */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned conn_error:1;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2006-12-07 04:35:52 +00:00
|
|
|
/** Connection successful. Only set in INIT */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned conn_init:1;
|
2006-12-07 04:35:52 +00:00
|
|
|
|
2022-03-24 01:29:04 +00:00
|
|
|
/** Do readahead asynchronously? Only set in INIT */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned async_read:1;
|
2006-02-01 11:04:40 +00:00
|
|
|
|
2017-11-09 20:23:35 +00:00
|
|
|
/** Return an unique read error after abort. Only set in INIT */
|
|
|
|
unsigned abort_err:1;
|
|
|
|
|
2007-10-18 10:07:02 +00:00
|
|
|
/** Do not send separate SETATTR request before open(O_TRUNC) */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned atomic_o_trunc:1;
|
2007-10-18 10:07:02 +00:00
|
|
|
|
2008-07-25 08:49:02 +00:00
|
|
|
/** Filesystem supports NFS exporting. Only set in INIT */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned export_support:1;
|
2008-07-25 08:49:02 +00:00
|
|
|
|
2013-10-10 13:10:30 +00:00
|
|
|
/** write-back cache policy (default is write-through) */
|
|
|
|
unsigned writeback_cache:1;
|
|
|
|
|
2016-06-30 11:10:49 +00:00
|
|
|
/** allow parallel lookups and readdir (default is serialized) */
|
|
|
|
unsigned parallel_dirops:1;
|
|
|
|
|
2016-10-01 05:32:32 +00:00
|
|
|
/** handle fs handles killing suid/sgid/cap on write/chown/trunc */
|
|
|
|
unsigned handle_killpriv:1;
|
|
|
|
|
2018-10-11 15:17:00 +00:00
|
|
|
/** cache READLINK responses in page cache */
|
|
|
|
unsigned cache_symlinks:1;
|
|
|
|
|
2020-08-19 22:19:45 +00:00
|
|
|
/* show legacy mount options */
|
|
|
|
unsigned int legacy_opts_show:1;
|
|
|
|
|
2020-10-09 18:15:07 +00:00
|
|
|
/*
|
|
|
|
* fs kills suid/sgid/cap on write/chown/trunc. suid is killed on
|
|
|
|
* write/trunc only if caller did not have CAP_FSETID. sgid is killed
|
|
|
|
* on write/truncate only if caller did not have CAP_FSETID as well as
|
|
|
|
* file has group execute permission.
|
|
|
|
*/
|
|
|
|
unsigned handle_killpriv_v2:1;
|
|
|
|
|
2006-01-17 06:14:52 +00:00
|
|
|
/*
|
|
|
|
* The following bitfields are only for optimization purposes
|
|
|
|
* and hence races in setting them will not cause malfunction
|
|
|
|
*/
|
|
|
|
|
2013-11-05 15:05:52 +00:00
|
|
|
/** Is open/release not implemented by fs? */
|
|
|
|
unsigned no_open:1;
|
|
|
|
|
2019-01-08 00:53:17 +00:00
|
|
|
/** Is opendir/releasedir not implemented by fs? */
|
|
|
|
unsigned no_opendir:1;
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** Is fsync not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_fsync:1;
|
2005-09-09 20:10:30 +00:00
|
|
|
|
2005-09-09 20:10:38 +00:00
|
|
|
/** Is fsyncdir not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_fsyncdir:1;
|
2005-09-09 20:10:38 +00:00
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** Is flush not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_flush:1;
|
2005-09-09 20:10:30 +00:00
|
|
|
|
2005-09-09 20:10:31 +00:00
|
|
|
/** Is setxattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_setxattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
2021-03-25 15:18:22 +00:00
|
|
|
/** Does file server support extended setxattr */
|
|
|
|
unsigned setxattr_ext:1;
|
|
|
|
|
2005-09-09 20:10:31 +00:00
|
|
|
/** Is getxattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_getxattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
|
|
|
/** Is listxattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_listxattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
|
|
|
/** Is removexattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_removexattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
2011-08-08 14:08:08 +00:00
|
|
|
/** Are posix file locking primitives not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_lock:1;
|
2006-06-25 12:48:52 +00:00
|
|
|
|
2005-11-07 08:59:50 +00:00
|
|
|
/** Is access not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_access:1;
|
2005-11-07 08:59:50 +00:00
|
|
|
|
2005-11-07 08:59:51 +00:00
|
|
|
/** Is create not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_create:1;
|
2005-11-07 08:59:51 +00:00
|
|
|
|
2006-06-25 12:48:54 +00:00
|
|
|
/** Is interrupt not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_interrupt:1;
|
2006-06-25 12:48:54 +00:00
|
|
|
|
2006-12-07 04:35:51 +00:00
|
|
|
/** Is bmap not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_bmap:1;
|
2006-12-07 04:35:51 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** Is poll not implemented by fs? */
|
|
|
|
unsigned no_poll:1;
|
|
|
|
|
2008-05-12 21:02:32 +00:00
|
|
|
/** Do multi-page cached writes */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned big_writes:1;
|
2008-05-12 21:02:32 +00:00
|
|
|
|
2009-06-30 18:12:23 +00:00
|
|
|
/** Don't apply umask to creation modes */
|
|
|
|
unsigned dont_mask:1;
|
|
|
|
|
2011-08-08 14:08:08 +00:00
|
|
|
/** Are BSD file locking primitives not implemented by fs? */
|
|
|
|
unsigned no_flock:1;
|
|
|
|
|
2012-04-26 08:56:36 +00:00
|
|
|
/** Is fallocate not implemented by fs? */
|
|
|
|
unsigned no_fallocate:1;
|
|
|
|
|
2014-04-28 14:43:44 +00:00
|
|
|
/** Is rename with flags implemented by fs? */
|
|
|
|
unsigned no_rename2:1;
|
|
|
|
|
2012-07-16 19:23:48 +00:00
|
|
|
/** Use enhanced/automatic page cache invalidation. */
|
|
|
|
unsigned auto_inval_data:1;
|
|
|
|
|
2021-03-26 01:16:42 +00:00
|
|
|
/** Filesystem is fully responsible for page cache invalidation. */
|
fuse: allow filesystems to have precise control over data cache
On networked filesystems file data can be changed externally. FUSE
provides notification messages for filesystem to inform kernel that
metadata or data region of a file needs to be invalidated in local page
cache. That provides the basis for filesystem implementations to invalidate
kernel cache explicitly based on observed filesystem-specific events.
FUSE has also "automatic" invalidation mode(*) when the kernel
automatically invalidates data cache of a file if it sees mtime change. It
also automatically invalidates whole data cache of a file if it sees file
size being changed.
The automatic mode has corresponding capability - FUSE_AUTO_INVAL_DATA.
However, due to probably historical reason, that capability controls only
whether mtime change should be resulting in automatic invalidation or
not. A change in file size always results in invalidating whole data cache
of a file irregardless of whether FUSE_AUTO_INVAL_DATA was negotiated(+).
The filesystem I write[1] represents data arrays stored in networked
database as local files suitable for mmap. It is read-only filesystem -
changes to data are committed externally via database interfaces and the
filesystem only glues data into contiguous file streams suitable for mmap
and traditional array processing. The files are big - starting from
hundreds gigabytes and more. The files change regularly, and frequently by
data being appended to their end. The size of files thus changes
frequently.
If a file was accessed locally and some part of its data got into page
cache, we want that data to stay cached unless there is memory pressure, or
unless corresponding part of the file was actually changed. However current
FUSE behaviour - when it sees file size change - is to invalidate the whole
file. The data cache of the file is thus completely lost even on small size
change, and despite that the filesystem server is careful to accurately
translate database changes into FUSE invalidation messages to kernel.
Let's fix it: if a filesystem, through new FUSE_EXPLICIT_INVAL_DATA
capability, indicates to kernel that it is fully responsible for data cache
invalidation, then the kernel won't invalidate files data cache on size
change and only truncate that cache to new size in case the size decreased.
(*) see 72d0d248ca "fuse: add FUSE_AUTO_INVAL_DATA init flag",
eed2179efe "fuse: invalidate inode mapping if mtime changes"
(+) in writeback mode the kernel does not invalidate data cache on file
size change, but neither it allows the filesystem to set the size due to
external event (see 8373200b12 "fuse: Trust kernel i_size only")
[1] https://lab.nexedi.com/kirr/wendelin.core/blob/a50f1d9f/wcfs/wcfs.go#L20
Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2019-03-27 11:14:15 +00:00
|
|
|
unsigned explicit_inval_data:1;
|
|
|
|
|
2013-02-06 22:29:01 +00:00
|
|
|
/** Does the filesystem support readdirplus? */
|
2012-08-19 12:53:23 +00:00
|
|
|
unsigned do_readdirplus:1;
|
|
|
|
|
2013-02-06 22:29:01 +00:00
|
|
|
/** Does the filesystem want adaptive readdirplus? */
|
|
|
|
unsigned readdirplus_auto:1;
|
|
|
|
|
2013-05-01 12:37:21 +00:00
|
|
|
/** Does the filesystem support asynchronous direct-IO submission? */
|
|
|
|
unsigned async_dio:1;
|
|
|
|
|
2015-06-30 18:10:22 +00:00
|
|
|
/** Is lseek not implemented by fs? */
|
|
|
|
unsigned no_lseek:1;
|
|
|
|
|
2016-08-29 13:46:37 +00:00
|
|
|
/** Does the filesystem support posix acls? */
|
|
|
|
unsigned posix_acl:1;
|
|
|
|
|
2016-10-01 05:32:32 +00:00
|
|
|
/** Check permissions based on the file mode or not? */
|
|
|
|
unsigned default_permissions:1;
|
|
|
|
|
|
|
|
/** Allow other than the mounter user to access the filesystem ? */
|
|
|
|
unsigned allow_other:1;
|
|
|
|
|
2018-08-21 12:36:31 +00:00
|
|
|
/** Does the filesystem support copy_file_range? */
|
|
|
|
unsigned no_copy_file_range:1;
|
|
|
|
|
2019-09-10 13:04:09 +00:00
|
|
|
/* Send DESTROY request */
|
|
|
|
unsigned int destroy:1;
|
|
|
|
|
2018-08-15 15:42:34 +00:00
|
|
|
/* Delete dentries that have gone stale */
|
|
|
|
unsigned int delete_stale:1;
|
|
|
|
|
2019-05-06 19:35:43 +00:00
|
|
|
/** Do not create entry in fusectl fs */
|
|
|
|
unsigned int no_control:1;
|
|
|
|
|
|
|
|
/** Do not allow MNT_FORCE umount */
|
|
|
|
unsigned int no_force_umount:1;
|
|
|
|
|
2020-04-21 12:47:15 +00:00
|
|
|
/* Auto-mount submounts announced by the server */
|
|
|
|
unsigned int auto_submounts:1;
|
|
|
|
|
2021-05-20 15:46:54 +00:00
|
|
|
/* Propagate syncfs() to server */
|
|
|
|
unsigned int sync_fs:1;
|
|
|
|
|
fuse: send security context of inode on file
When a new inode is created, send its security context to server along with
creation request (FUSE_CREAT, FUSE_MKNOD, FUSE_MKDIR and FUSE_SYMLINK).
This gives server an opportunity to create new file and set security
context (possibly atomically). In all the configurations it might not be
possible to set context atomically.
Like nfs and ceph, use security_dentry_init_security() to dermine security
context of inode and send it with create, mkdir, mknod, and symlink
requests.
Following is the information sent to server.
fuse_sectx_header, fuse_secctx, xattr_name, security_context
- struct fuse_secctx_header
This contains total number of security contexts being sent and total
size of all the security contexts (including size of
fuse_secctx_header).
- struct fuse_secctx
This contains size of security context which follows this structure.
There is one fuse_secctx instance per security context.
- xattr name string
This string represents name of xattr which should be used while setting
security context.
- security context
This is the actual security context whose size is specified in
fuse_secctx struct.
Also add the FUSE_SECURITY_CTX flag for the `flags` field of the
fuse_init_out struct. When this flag is set the kernel will append the
security context for a newly created inode to the request (create, mkdir,
mknod, and symlink). The server is responsible for ensuring that the inode
appears atomically (preferrably) with the requested security context.
For example, If the server is using SELinux and backed by a "real" linux
file system that supports extended attributes it can write the security
context value to /proc/thread-self/attr/fscreate before making the syscall
to create the inode.
This patch is based on patch from Chirantan Ekbote <chirantan@chromium.org>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2021-11-11 14:32:49 +00:00
|
|
|
/* Initialize security xattrs when creating a new inode */
|
|
|
|
unsigned int init_security:1;
|
|
|
|
|
2022-11-10 14:46:33 +00:00
|
|
|
/* Add supplementary group info when creating a new inode */
|
|
|
|
unsigned int create_supp_group:1;
|
|
|
|
|
2021-11-25 07:05:28 +00:00
|
|
|
/* Does the filesystem support per inode DAX? */
|
|
|
|
unsigned int inode_dax:1;
|
|
|
|
|
2022-09-24 05:00:00 +00:00
|
|
|
/* Is tmpfile not implemented by fs? */
|
|
|
|
unsigned int no_tmpfile:1;
|
|
|
|
|
2023-08-01 08:06:46 +00:00
|
|
|
/* relax restrictions in FOPEN_DIRECT_IO mode */
|
|
|
|
unsigned int direct_io_relax:1;
|
|
|
|
|
2023-08-10 10:45:05 +00:00
|
|
|
/* Is statx not implemented by fs? */
|
|
|
|
unsigned int no_statx:1;
|
|
|
|
|
2006-01-17 06:14:38 +00:00
|
|
|
/** The number of requests waiting for completion */
|
|
|
|
atomic_t num_waiting;
|
|
|
|
|
2006-01-06 08:19:36 +00:00
|
|
|
/** Negotiated minor version */
|
|
|
|
unsigned minor;
|
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/** Entry on the fuse_mount_list */
|
2006-06-25 12:48:51 +00:00
|
|
|
struct list_head entry;
|
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/** Device ID from the root super block */
|
2008-04-30 07:54:34 +00:00
|
|
|
dev_t dev;
|
2006-06-25 12:48:51 +00:00
|
|
|
|
|
|
|
/** Dentries in the control filesystem */
|
|
|
|
struct dentry *ctl_dentry[FUSE_CTL_NUM_DENTRIES];
|
|
|
|
|
|
|
|
/** number of dentries used in the above array */
|
|
|
|
int ctl_ndents;
|
2006-04-11 05:54:52 +00:00
|
|
|
|
2006-06-25 12:48:55 +00:00
|
|
|
/** Key for lock owner ID scrambling */
|
|
|
|
u32 scramble_key[4];
|
2006-12-07 04:35:52 +00:00
|
|
|
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
/** Version counter for attribute changes */
|
2018-11-09 10:33:17 +00:00
|
|
|
atomic64_t attr_version;
|
2008-11-26 11:03:56 +00:00
|
|
|
|
|
|
|
/** Called on final put */
|
|
|
|
void (*release)(struct fuse_conn *);
|
2009-05-31 15:13:57 +00:00
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/**
|
|
|
|
* Read/write semaphore to hold when accessing the sb of any
|
|
|
|
* fuse_mount belonging to this connection
|
|
|
|
*/
|
2009-05-31 15:13:57 +00:00
|
|
|
struct rw_semaphore killsb;
|
2015-07-01 14:26:08 +00:00
|
|
|
|
|
|
|
/** List of device instances belonging to this connection */
|
|
|
|
struct list_head devices;
|
2020-08-19 22:19:47 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_FUSE_DAX
|
2021-11-25 07:05:25 +00:00
|
|
|
/* Dax mode */
|
|
|
|
enum fuse_dax_mode dax_mode;
|
|
|
|
|
2020-08-19 22:19:47 +00:00
|
|
|
/* Dax specific conn data, non-NULL if DAX is enabled */
|
|
|
|
struct fuse_conn_dax *dax;
|
|
|
|
#endif
|
2020-05-06 15:44:12 +00:00
|
|
|
|
|
|
|
/** List of filesystems using this connection */
|
|
|
|
struct list_head mounts;
|
2021-09-01 10:39:02 +00:00
|
|
|
|
|
|
|
/* New writepages go into this bucket */
|
|
|
|
struct fuse_sync_bucket __rcu *curr_bucket;
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
};
|
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/*
|
|
|
|
* Represents a mounted filesystem, potentially a submount.
|
|
|
|
*
|
|
|
|
* This object allows sharing a fuse_conn between separate mounts to
|
|
|
|
* allow submounts with dedicated superblocks and thus separate device
|
|
|
|
* IDs.
|
|
|
|
*/
|
|
|
|
struct fuse_mount {
|
|
|
|
/* Underlying (potentially shared) connection to the FUSE server */
|
|
|
|
struct fuse_conn *fc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Super block for this connection (fc->killsb must be held when
|
|
|
|
* accessing this).
|
|
|
|
*/
|
|
|
|
struct super_block *sb;
|
|
|
|
|
|
|
|
/* Entry on fc->mounts */
|
|
|
|
struct list_head fc_entry;
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct fuse_mount *get_fuse_mount_super(struct super_block *sb)
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
{
|
2006-01-17 06:14:29 +00:00
|
|
|
return sb->s_fs_info;
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
}
|
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
static inline struct fuse_conn *get_fuse_conn_super(struct super_block *sb)
|
|
|
|
{
|
2020-11-11 16:22:32 +00:00
|
|
|
return get_fuse_mount_super(sb)->fc;
|
2020-05-06 15:44:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct fuse_mount *get_fuse_mount(struct inode *inode)
|
|
|
|
{
|
|
|
|
return get_fuse_mount_super(inode->i_sb);
|
|
|
|
}
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
static inline struct fuse_conn *get_fuse_conn(struct inode *inode)
|
|
|
|
{
|
2020-11-11 16:22:32 +00:00
|
|
|
return get_fuse_mount_super(inode->i_sb)->fc;
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct fuse_inode *get_fuse_inode(struct inode *inode)
|
|
|
|
{
|
|
|
|
return container_of(inode, struct fuse_inode, inode);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u64 get_node_id(struct inode *inode)
|
|
|
|
{
|
|
|
|
return get_fuse_inode(inode)->nodeid;
|
|
|
|
}
|
|
|
|
|
2018-09-28 14:43:23 +00:00
|
|
|
static inline int invalid_nodeid(u64 nodeid)
|
|
|
|
{
|
|
|
|
return !nodeid || nodeid == FUSE_ROOT_ID;
|
|
|
|
}
|
|
|
|
|
2018-11-09 10:33:17 +00:00
|
|
|
static inline u64 fuse_get_attr_version(struct fuse_conn *fc)
|
|
|
|
{
|
|
|
|
return atomic64_read(&fc->attr_version);
|
|
|
|
}
|
|
|
|
|
2021-06-21 11:03:53 +00:00
|
|
|
static inline bool fuse_stale_inode(const struct inode *inode, int generation,
|
|
|
|
struct fuse_attr *attr)
|
|
|
|
{
|
|
|
|
return inode->i_generation != generation ||
|
|
|
|
inode_wrong_type(inode, attr->mode);
|
|
|
|
}
|
|
|
|
|
2020-12-10 14:33:14 +00:00
|
|
|
static inline void fuse_make_bad(struct inode *inode)
|
|
|
|
{
|
2021-03-04 09:09:12 +00:00
|
|
|
remove_inode_hash(inode);
|
2020-12-10 14:33:14 +00:00
|
|
|
set_bit(FUSE_I_BAD, &get_fuse_inode(inode)->state);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool fuse_is_bad(struct inode *inode)
|
|
|
|
{
|
|
|
|
return unlikely(test_bit(FUSE_I_BAD, &get_fuse_inode(inode)->state));
|
|
|
|
}
|
|
|
|
|
2021-04-07 12:36:45 +00:00
|
|
|
static inline struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags,
|
|
|
|
struct fuse_page_desc **desc)
|
|
|
|
{
|
|
|
|
struct page **pages;
|
|
|
|
|
|
|
|
pages = kzalloc(npages * (sizeof(struct page *) +
|
|
|
|
sizeof(struct fuse_page_desc)), flags);
|
|
|
|
*desc = (void *) (pages + npages);
|
|
|
|
|
|
|
|
return pages;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void fuse_page_descs_length_init(struct fuse_page_desc *descs,
|
|
|
|
unsigned int index,
|
|
|
|
unsigned int nr_pages)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = index; i < index + nr_pages; i++)
|
|
|
|
descs[i].length = PAGE_SIZE - descs[i].offset;
|
|
|
|
}
|
|
|
|
|
2021-09-01 10:39:02 +00:00
|
|
|
static inline void fuse_sync_bucket_dec(struct fuse_sync_bucket *bucket)
|
|
|
|
{
|
|
|
|
/* Need RCU protection to prevent use after free after the decrement */
|
|
|
|
rcu_read_lock();
|
|
|
|
if (atomic_dec_and_test(&bucket->count))
|
|
|
|
wake_up(&bucket->waitq);
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** Device operations */
|
2006-03-28 09:56:42 +00:00
|
|
|
extern const struct file_operations fuse_dev_operations;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2009-02-20 05:59:13 +00:00
|
|
|
extern const struct dentry_operations fuse_dentry_operations;
|
2016-10-18 13:36:48 +00:00
|
|
|
extern const struct dentry_operations fuse_root_dentry_operations;
|
2008-07-25 08:49:00 +00:00
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
|
|
|
* Get a filled in inode
|
|
|
|
*/
|
2008-04-30 07:54:44 +00:00
|
|
|
struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
int generation, struct fuse_attr *attr,
|
|
|
|
u64 attr_valid, u64 attr_version);
|
2005-09-09 20:10:28 +00:00
|
|
|
|
2016-07-21 02:34:44 +00:00
|
|
|
int fuse_lookup_name(struct super_block *sb, u64 nodeid, const struct qstr *name,
|
2008-07-25 08:49:02 +00:00
|
|
|
struct fuse_entry_out *outarg, struct inode **inode);
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
|
|
|
* Send FORGET command
|
|
|
|
*/
|
2010-12-07 19:16:56 +00:00
|
|
|
void fuse_queue_forget(struct fuse_conn *fc, struct fuse_forget_link *forget,
|
|
|
|
u64 nodeid, u64 nlookup);
|
|
|
|
|
|
|
|
struct fuse_forget_link *fuse_alloc_forget(void);
|
2005-09-09 20:10:28 +00:00
|
|
|
|
2019-06-05 19:50:43 +00:00
|
|
|
struct fuse_forget_link *fuse_dequeue_forget(struct fuse_iqueue *fiq,
|
|
|
|
unsigned int max,
|
|
|
|
unsigned int *countp);
|
|
|
|
|
2019-09-10 13:04:10 +00:00
|
|
|
/*
|
2006-01-17 06:14:45 +00:00
|
|
|
* Initialize READ or READDIR request
|
2005-09-09 20:10:36 +00:00
|
|
|
*/
|
2019-09-10 13:04:10 +00:00
|
|
|
struct fuse_io_args {
|
|
|
|
union {
|
|
|
|
struct {
|
|
|
|
struct fuse_read_in in;
|
|
|
|
u64 attr_ver;
|
|
|
|
} read;
|
|
|
|
struct {
|
|
|
|
struct fuse_write_in in;
|
|
|
|
struct fuse_write_out out;
|
fuse: fix write deadlock
There are two modes for write(2) and friends in fuse:
a) write through (update page cache, send sync WRITE request to userspace)
b) buffered write (update page cache, async writeout later)
The write through method kept all the page cache pages locked that were
used for the request. Keeping more than one page locked is deadlock prone
and Qian Cai demonstrated this with trinity fuzzing.
The reason for keeping the pages locked is that concurrent mapped reads
shouldn't try to pull possibly stale data into the page cache.
For full page writes, the easy way to fix this is to make the cached page
be the authoritative source by marking the page PG_uptodate immediately.
After this the page can be safely unlocked, since mapped/cached reads will
take the written data from the cache.
Concurrent mapped writes will now cause data in the original WRITE request
to be updated; this however doesn't cause any data inconsistency and this
scenario should be exceedingly rare anyway.
If the WRITE request returns with an error in the above case, currently the
page is not marked uptodate; this means that a concurrent read will always
read consistent data. After this patch the page is uptodate between
writing to the cache and receiving the error: there's window where a cached
read will read the wrong data. While theoretically this could be a
regression, it is unlikely to be one in practice, since this is normal for
buffered writes.
In case of a partial page write to an already uptodate page the locking is
also unnecessary, with the above caveats.
Partial write of a not uptodate page still needs to be handled. One way
would be to read the complete page before doing the write. This is not
possible, since it might break filesystems that don't expect any READ
requests when the file was opened O_WRONLY.
The other solution is to serialize the synchronous write with reads from
the partial pages. The easiest way to do this is to keep the partial pages
locked. The problem is that a write() may involve two such pages (one head
and one tail). This patch fixes it by only locking the partial tail page.
If there's a partial head page as well, then split that off as a separate
WRITE request.
Reported-by: Qian Cai <cai@lca.pw>
Link: https://lore.kernel.org/linux-fsdevel/4794a3fa3742a5e84fb0f934944204b55730829b.camel@lca.pw/
Fixes: ea9b9907b82a ("fuse: implement perform_write")
Cc: <stable@vger.kernel.org> # v2.6.26
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2020-10-21 20:12:49 +00:00
|
|
|
bool page_locked;
|
2019-09-10 13:04:10 +00:00
|
|
|
} write;
|
|
|
|
};
|
|
|
|
struct fuse_args_pages ap;
|
|
|
|
struct fuse_io_priv *io;
|
|
|
|
struct fuse_file *ff;
|
|
|
|
};
|
|
|
|
|
|
|
|
void fuse_read_args_fill(struct fuse_io_args *ia, struct file *file, loff_t pos,
|
|
|
|
size_t count, int opcode);
|
|
|
|
|
2005-09-09 20:10:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Send OPEN or OPENDIR request
|
|
|
|
*/
|
2009-04-28 14:56:37 +00:00
|
|
|
int fuse_open_common(struct inode *inode, struct file *file, bool isdir);
|
2005-09-09 20:10:36 +00:00
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
struct fuse_file *fuse_file_alloc(struct fuse_mount *fm);
|
2005-11-07 08:59:51 +00:00
|
|
|
void fuse_file_free(struct fuse_file *ff);
|
2009-04-28 14:56:37 +00:00
|
|
|
void fuse_finish_open(struct inode *inode, struct file *file);
|
2005-11-07 08:59:51 +00:00
|
|
|
|
2021-04-07 12:36:45 +00:00
|
|
|
void fuse_sync_release(struct fuse_inode *fi, struct fuse_file *ff,
|
|
|
|
unsigned int flags);
|
2007-10-17 06:31:00 +00:00
|
|
|
|
2005-09-09 20:10:36 +00:00
|
|
|
/**
|
|
|
|
* Send RELEASE or RELEASEDIR request
|
|
|
|
*/
|
2018-12-10 18:54:52 +00:00
|
|
|
void fuse_release_common(struct file *file, bool isdir);
|
2005-09-09 20:10:36 +00:00
|
|
|
|
2005-09-09 20:10:38 +00:00
|
|
|
/**
|
|
|
|
* Send FSYNC or FSYNCDIR request
|
|
|
|
*/
|
2011-07-17 00:44:56 +00:00
|
|
|
int fuse_fsync_common(struct file *file, loff_t start, loff_t end,
|
2018-12-03 09:14:43 +00:00
|
|
|
int datasync, int opcode);
|
2005-09-09 20:10:38 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/**
|
|
|
|
* Notify poll wakeup
|
|
|
|
*/
|
|
|
|
int fuse_notify_poll_wakeup(struct fuse_conn *fc,
|
|
|
|
struct fuse_notify_poll_wakeup_out *outarg);
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize file operations on a regular file
|
2005-09-09 20:10:30 +00:00
|
|
|
*/
|
fuse: enable per inode DAX
DAX may be limited in some specific situation. When the number of usable
DAX windows is under watermark, the recalim routine will be triggered to
reclaim some DAX windows. It may have a negative impact on the
performance, since some processes may need to wait for DAX windows to be
recalimed and reused then. To mitigate the performance degradation, the
overall DAX window need to be expanded larger.
However, simply expanding the DAX window may not be a good deal in some
scenario. To maintain one DAX window chunk (i.e., 2MB in size), 32KB
(512 * 64 bytes) memory footprint will be consumed for page descriptors
inside guest, which is greater than the memory footprint if it uses
guest page cache when DAX disabled. Thus it'd better disable DAX for
those files smaller than 32KB, to reduce the demand for DAX window and
thus avoid the unworthy memory overhead.
Per inode DAX feature is introduced to address this issue, by offering a
finer grained control for dax to users, trying to achieve a balance
between performance and memory overhead.
The FUSE_ATTR_DAX flag in FUSE_LOOKUP reply is used to indicate whether
DAX should be enabled or not for corresponding file. Currently the state
whether DAX is enabled or not for the file is initialized only when
inode is instantiated.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2021-11-25 07:05:27 +00:00
|
|
|
void fuse_init_file_inode(struct inode *inode, unsigned int flags);
|
2005-09-09 20:10:30 +00:00
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize inode operations on regular files and special files
|
2005-09-09 20:10:28 +00:00
|
|
|
*/
|
|
|
|
void fuse_init_common(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize inode and file operations on a directory
|
2005-09-09 20:10:28 +00:00
|
|
|
*/
|
|
|
|
void fuse_init_dir(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize inode operations on a symlink
|
2005-09-09 20:10:28 +00:00
|
|
|
*/
|
|
|
|
void fuse_init_symlink(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Change attributes of an inode
|
|
|
|
*/
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
void fuse_change_attributes(struct inode *inode, struct fuse_attr *attr,
|
2023-08-10 10:45:05 +00:00
|
|
|
struct fuse_statx *sx,
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
u64 attr_valid, u64 attr_version);
|
2005-09-09 20:10:28 +00:00
|
|
|
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
void fuse_change_attributes_common(struct inode *inode, struct fuse_attr *attr,
|
2023-08-10 10:45:05 +00:00
|
|
|
struct fuse_statx *sx,
|
2021-10-22 15:03:03 +00:00
|
|
|
u64 attr_valid, u32 cache_mask);
|
|
|
|
|
|
|
|
u32 fuse_get_cache_mask(struct inode *inode);
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/**
|
|
|
|
* Initialize the client device
|
|
|
|
*/
|
|
|
|
int fuse_dev_init(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Cleanup the client device
|
|
|
|
*/
|
|
|
|
void fuse_dev_cleanup(void);
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
int fuse_ctl_init(void);
|
2014-04-23 16:14:42 +00:00
|
|
|
void __exit fuse_ctl_cleanup(void);
|
2006-06-25 12:48:51 +00:00
|
|
|
|
2014-12-12 08:49:05 +00:00
|
|
|
/**
|
|
|
|
* Simple request sending that does request allocation and freeing
|
|
|
|
*/
|
2020-05-06 15:44:12 +00:00
|
|
|
ssize_t fuse_simple_request(struct fuse_mount *fm, struct fuse_args *args);
|
|
|
|
int fuse_simple_background(struct fuse_mount *fm, struct fuse_args *args,
|
2019-09-10 13:04:10 +00:00
|
|
|
gfp_t gfp_flags);
|
2014-12-12 08:49:05 +00:00
|
|
|
|
2018-06-21 08:33:40 +00:00
|
|
|
/**
|
|
|
|
* End a finished request
|
|
|
|
*/
|
2020-04-20 15:59:34 +00:00
|
|
|
void fuse_request_end(struct fuse_req *req);
|
2018-06-21 08:33:40 +00:00
|
|
|
|
2006-04-26 08:48:55 +00:00
|
|
|
/* Abort all requests */
|
2019-01-24 09:40:16 +00:00
|
|
|
void fuse_abort_conn(struct fuse_conn *fc);
|
2018-07-26 14:13:11 +00:00
|
|
|
void fuse_wait_aborted(struct fuse_conn *fc);
|
2006-01-17 06:14:41 +00:00
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
|
|
|
* Invalidate inode attributes
|
|
|
|
*/
|
2021-10-22 15:03:02 +00:00
|
|
|
|
|
|
|
/* Attributes possibly changed on data modification */
|
|
|
|
#define FUSE_STATX_MODIFY (STATX_MTIME | STATX_CTIME | STATX_BLOCKS)
|
|
|
|
|
|
|
|
/* Attributes possibly changed on data and/or size modification */
|
|
|
|
#define FUSE_STATX_MODSIZE (FUSE_STATX_MODIFY | STATX_SIZE)
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
void fuse_invalidate_attr(struct inode *inode);
|
2021-10-22 15:03:02 +00:00
|
|
|
void fuse_invalidate_attr_mask(struct inode *inode, u32 mask);
|
2006-06-25 12:48:51 +00:00
|
|
|
|
2008-07-25 08:49:00 +00:00
|
|
|
void fuse_invalidate_entry_cache(struct dentry *entry);
|
|
|
|
|
2013-11-05 11:55:43 +00:00
|
|
|
void fuse_invalidate_atime(struct inode *inode);
|
|
|
|
|
2023-08-10 10:45:05 +00:00
|
|
|
u64 fuse_time_to_jiffies(u64 sec, u32 nsec);
|
|
|
|
#define ATTR_TIMEOUT(o) \
|
|
|
|
fuse_time_to_jiffies((o)->attr_valid, (o)->attr_valid_nsec)
|
|
|
|
|
2018-09-28 14:43:23 +00:00
|
|
|
void fuse_change_entry_timeout(struct dentry *entry, struct fuse_entry_out *o);
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/**
|
|
|
|
* Acquire reference to fuse_conn
|
|
|
|
*/
|
|
|
|
struct fuse_conn *fuse_conn_get(struct fuse_conn *fc);
|
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/**
|
|
|
|
* Initialize fuse_conn
|
|
|
|
*/
|
2020-05-06 15:44:12 +00:00
|
|
|
void fuse_conn_init(struct fuse_conn *fc, struct fuse_mount *fm,
|
|
|
|
struct user_namespace *user_ns,
|
2018-06-18 14:53:19 +00:00
|
|
|
const struct fuse_iqueue_ops *fiq_ops, void *fiq_priv);
|
2008-11-26 11:03:55 +00:00
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/**
|
|
|
|
* Release reference to fuse_conn
|
|
|
|
*/
|
|
|
|
void fuse_conn_put(struct fuse_conn *fc);
|
|
|
|
|
2019-03-06 21:51:40 +00:00
|
|
|
struct fuse_dev *fuse_dev_alloc_install(struct fuse_conn *fc);
|
|
|
|
struct fuse_dev *fuse_dev_alloc(void);
|
|
|
|
void fuse_dev_install(struct fuse_dev *fud, struct fuse_conn *fc);
|
2015-07-01 14:26:08 +00:00
|
|
|
void fuse_dev_free(struct fuse_dev *fud);
|
2020-05-06 15:44:12 +00:00
|
|
|
void fuse_send_init(struct fuse_mount *fm);
|
2015-07-01 14:26:08 +00:00
|
|
|
|
2018-06-13 09:23:04 +00:00
|
|
|
/**
|
|
|
|
* Fill in superblock and initialize fuse connection
|
|
|
|
* @sb: partially-initialized superblock to fill in
|
|
|
|
* @ctx: mount context
|
|
|
|
*/
|
|
|
|
int fuse_fill_super_common(struct super_block *sb, struct fuse_fs_context *ctx);
|
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/*
|
|
|
|
* Remove the mount from the connection
|
2019-08-29 09:01:20 +00:00
|
|
|
*
|
2020-05-06 15:44:12 +00:00
|
|
|
* Returns whether this was the last mount
|
|
|
|
*/
|
|
|
|
bool fuse_mount_remove(struct fuse_mount *fm);
|
|
|
|
|
2021-06-04 16:11:53 +00:00
|
|
|
/*
|
|
|
|
* Setup context ops for submounts
|
|
|
|
*/
|
|
|
|
int fuse_init_fs_context_submount(struct fs_context *fsc);
|
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/*
|
|
|
|
* Shut down the connection (possibly sending DESTROY request).
|
2019-08-29 09:01:20 +00:00
|
|
|
*/
|
2020-05-06 15:44:12 +00:00
|
|
|
void fuse_conn_destroy(struct fuse_mount *fm);
|
2019-08-29 09:01:20 +00:00
|
|
|
|
2021-10-21 08:01:38 +00:00
|
|
|
/* Drop the connection and free the fuse mount */
|
|
|
|
void fuse_mount_destroy(struct fuse_mount *fm);
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/**
|
|
|
|
* Add connection to control filesystem
|
|
|
|
*/
|
|
|
|
int fuse_ctl_add_conn(struct fuse_conn *fc);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Remove connection from control filesystem
|
|
|
|
*/
|
|
|
|
void fuse_ctl_remove_conn(struct fuse_conn *fc);
|
2007-04-08 23:04:00 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Is file type valid?
|
|
|
|
*/
|
|
|
|
int fuse_valid_type(int m);
|
2007-10-18 10:06:58 +00:00
|
|
|
|
2019-11-12 10:49:04 +00:00
|
|
|
bool fuse_invalid_attr(struct fuse_attr *attr);
|
|
|
|
|
2007-10-18 10:06:58 +00:00
|
|
|
/**
|
2013-01-15 06:30:00 +00:00
|
|
|
* Is current process allowed to perform filesystem operation?
|
2007-10-18 10:06:58 +00:00
|
|
|
*/
|
fuse: Rearrange fuse_allow_current_process checks
This is a followup to a previous commit of mine [0], which added the
allow_sys_admin_access && capable(CAP_SYS_ADMIN) check. This patch
rearranges the order of checks in fuse_allow_current_process without
changing functionality.
Commit 9ccf47b26b73 ("fuse: Add module param for CAP_SYS_ADMIN access
bypassing allow_other") added allow_sys_admin_access &&
capable(CAP_SYS_ADMIN) check to the beginning of the function, with the
reasoning that allow_sys_admin_access should be an 'escape hatch' for users
with CAP_SYS_ADMIN, allowing them to skip any subsequent checks.
However, placing this new check first results in many capable() calls when
allow_sys_admin_access is set, where another check would've also returned
1. This can be problematic when a BPF program is tracing capable() calls.
At Meta we ran into such a scenario recently. On a host where
allow_sys_admin_access is set but most of the FUSE access is from processes
which would pass other checks - i.e. they don't need CAP_SYS_ADMIN 'escape
hatch' - this results in an unnecessary capable() call for each fs op. We
also have a daemon tracing capable() with BPF and doing some data
collection, so tracing these extraneous capable() calls has the potential
to regress performance for an application doing many FUSE ops.
So rearrange the order of these checks such that CAP_SYS_ADMIN 'escape
hatch' is checked last. Add a small helper, fuse_permissible_uidgid, to
make the logic easier to understand. Previously, if allow_other is set on
the fuse_conn, uid/git checking doesn't happen as current_in_userns result
is returned. These semantics are maintained here: fuse_permissible_uidgid
check only happens if allow_other is not set.
Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2022-10-25 16:10:17 +00:00
|
|
|
bool fuse_allow_current_process(struct fuse_conn *fc);
|
2007-10-18 10:07:04 +00:00
|
|
|
|
|
|
|
u64 fuse_lock_owner_id(struct fuse_conn *fc, fl_owner_t id);
|
2007-11-29 00:21:59 +00:00
|
|
|
|
2021-10-22 15:03:01 +00:00
|
|
|
void fuse_flush_time_update(struct inode *inode);
|
2016-08-29 13:46:36 +00:00
|
|
|
void fuse_update_ctime(struct inode *inode);
|
|
|
|
|
2021-10-22 15:03:03 +00:00
|
|
|
int fuse_update_attributes(struct inode *inode, struct file *file, u32 mask);
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
|
|
|
void fuse_flush_writepages(struct inode *inode);
|
|
|
|
|
|
|
|
void fuse_set_nowrite(struct inode *inode);
|
|
|
|
void fuse_release_nowrite(struct inode *inode);
|
2008-04-30 07:54:43 +00:00
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
/**
|
|
|
|
* Scan all fuse_mounts belonging to fc to find the first where
|
|
|
|
* ilookup5() returns a result. Return that result and the
|
|
|
|
* respective fuse_mount in *fm (unless fm is NULL).
|
|
|
|
*
|
|
|
|
* The caller must hold fc->killsb.
|
|
|
|
*/
|
|
|
|
struct inode *fuse_ilookup(struct fuse_conn *fc, u64 nodeid,
|
|
|
|
struct fuse_mount **fm);
|
|
|
|
|
2009-05-31 15:13:57 +00:00
|
|
|
/**
|
|
|
|
* File-system tells the kernel to invalidate cache for the given node id.
|
|
|
|
*/
|
2020-05-06 15:44:12 +00:00
|
|
|
int fuse_reverse_inval_inode(struct fuse_conn *fc, u64 nodeid,
|
2009-05-31 15:13:57 +00:00
|
|
|
loff_t offset, loff_t len);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* File-system tells the kernel to invalidate parent attributes and
|
|
|
|
* the dentry matching parent/name.
|
2011-12-06 20:50:06 +00:00
|
|
|
*
|
|
|
|
* If the child_nodeid is non-zero and:
|
|
|
|
* - matches the inode number for the dentry matching parent/name,
|
|
|
|
* - is not a mount point
|
|
|
|
* - is a file or oan empty directory
|
|
|
|
* then the dentry is unhashed (d_delete()).
|
2009-05-31 15:13:57 +00:00
|
|
|
*/
|
2020-05-06 15:44:12 +00:00
|
|
|
int fuse_reverse_inval_entry(struct fuse_conn *fc, u64 parent_nodeid,
|
2022-10-28 12:25:21 +00:00
|
|
|
u64 child_nodeid, struct qstr *name, u32 flags);
|
2009-05-31 15:13:57 +00:00
|
|
|
|
2020-05-06 15:44:12 +00:00
|
|
|
int fuse_do_open(struct fuse_mount *fm, u64 nodeid, struct file *file,
|
2009-04-14 01:54:53 +00:00
|
|
|
bool isdir);
|
2013-10-10 13:12:05 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* fuse_direct_io() flags
|
|
|
|
*/
|
|
|
|
|
|
|
|
/** If set, it is WRITE; otherwise - READ */
|
|
|
|
#define FUSE_DIO_WRITE (1 << 0)
|
|
|
|
|
|
|
|
/** CUSE pass fuse_direct_io() a file which f_mapping->host is not from FUSE */
|
|
|
|
#define FUSE_DIO_CUSE (1 << 1)
|
|
|
|
|
2014-03-16 19:50:47 +00:00
|
|
|
ssize_t fuse_direct_io(struct fuse_io_priv *io, struct iov_iter *iter,
|
|
|
|
loff_t *ppos, int flags);
|
2009-04-14 01:54:53 +00:00
|
|
|
long fuse_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg,
|
|
|
|
unsigned int flags);
|
2011-12-13 10:58:49 +00:00
|
|
|
long fuse_ioctl_common(struct file *file, unsigned int cmd,
|
|
|
|
unsigned long arg, unsigned int flags);
|
2017-07-03 05:02:18 +00:00
|
|
|
__poll_t fuse_file_poll(struct file *file, poll_table *wait);
|
2009-04-14 01:54:53 +00:00
|
|
|
int fuse_dev_release(struct inode *inode, struct file *file);
|
|
|
|
|
2021-10-22 15:03:02 +00:00
|
|
|
bool fuse_write_update_attr(struct inode *inode, loff_t pos, ssize_t written);
|
2013-12-26 15:51:11 +00:00
|
|
|
|
2014-04-28 12:19:24 +00:00
|
|
|
int fuse_flush_times(struct inode *inode, struct fuse_file *ff);
|
2014-04-28 12:19:23 +00:00
|
|
|
int fuse_write_inode(struct inode *inode, struct writeback_control *wbc);
|
2010-07-12 12:41:40 +00:00
|
|
|
|
2016-05-26 15:12:41 +00:00
|
|
|
int fuse_do_setattr(struct dentry *dentry, struct iattr *attr,
|
2012-12-18 10:05:08 +00:00
|
|
|
struct file *file);
|
|
|
|
|
2015-01-06 09:45:35 +00:00
|
|
|
void fuse_set_initialized(struct fuse_conn *fc);
|
|
|
|
|
2018-07-26 14:13:11 +00:00
|
|
|
void fuse_unlock_inode(struct inode *inode, bool locked);
|
|
|
|
bool fuse_lock_inode(struct inode *inode);
|
2016-06-30 11:10:49 +00:00
|
|
|
|
2016-08-29 13:46:37 +00:00
|
|
|
int fuse_setxattr(struct inode *inode, const char *name, const void *value,
|
2021-03-25 15:18:22 +00:00
|
|
|
size_t size, int flags, unsigned int extra_flags);
|
2016-08-29 13:46:37 +00:00
|
|
|
ssize_t fuse_getxattr(struct inode *inode, const char *name, void *value,
|
|
|
|
size_t size);
|
2016-08-29 13:46:36 +00:00
|
|
|
ssize_t fuse_listxattr(struct dentry *entry, char *list, size_t size);
|
2016-08-29 13:46:37 +00:00
|
|
|
int fuse_removexattr(struct inode *inode, const char *name);
|
2023-09-30 05:00:15 +00:00
|
|
|
extern const struct xattr_handler * const fuse_xattr_handlers[];
|
2016-08-29 13:46:37 +00:00
|
|
|
|
|
|
|
struct posix_acl;
|
2023-01-20 11:55:04 +00:00
|
|
|
struct posix_acl *fuse_get_inode_acl(struct inode *inode, int type, bool rcu);
|
2023-02-20 19:53:11 +00:00
|
|
|
struct posix_acl *fuse_get_acl(struct mnt_idmap *idmap,
|
2023-01-20 11:55:04 +00:00
|
|
|
struct dentry *dentry, int type);
|
2023-02-20 19:53:11 +00:00
|
|
|
int fuse_set_acl(struct mnt_idmap *, struct dentry *dentry,
|
2021-01-21 13:19:43 +00:00
|
|
|
struct posix_acl *acl, int type);
|
2018-09-28 14:43:23 +00:00
|
|
|
|
|
|
|
/* readdir.c */
|
|
|
|
int fuse_readdir(struct file *file, struct dir_context *ctx);
|
|
|
|
|
2018-06-21 08:34:25 +00:00
|
|
|
/**
|
|
|
|
* Return the number of bytes in an arguments list
|
|
|
|
*/
|
|
|
|
unsigned int fuse_len_args(unsigned int numargs, struct fuse_arg *args);
|
|
|
|
|
2018-06-22 12:48:30 +00:00
|
|
|
/**
|
|
|
|
* Get the next unique ID for a request
|
|
|
|
*/
|
|
|
|
u64 fuse_get_unique(struct fuse_iqueue *fiq);
|
2019-08-29 09:01:20 +00:00
|
|
|
void fuse_free_conn(struct fuse_conn *fc);
|
2018-06-22 12:48:30 +00:00
|
|
|
|
2020-08-19 22:19:47 +00:00
|
|
|
/* dax.c */
|
|
|
|
|
2020-08-19 22:19:51 +00:00
|
|
|
#define FUSE_IS_DAX(inode) (IS_ENABLED(CONFIG_FUSE_DAX) && IS_DAX(inode))
|
|
|
|
|
|
|
|
ssize_t fuse_dax_read_iter(struct kiocb *iocb, struct iov_iter *to);
|
|
|
|
ssize_t fuse_dax_write_iter(struct kiocb *iocb, struct iov_iter *from);
|
|
|
|
int fuse_dax_mmap(struct file *file, struct vm_area_struct *vma);
|
virtiofs: serialize truncate/punch_hole and dax fault path
Currently in fuse we don't seem have any lock which can serialize fault
path with truncate/punch_hole path. With dax support I need one for
following reasons.
1. Dax requirement
DAX fault code relies on inode size being stable for the duration of
fault and want to serialize with truncate/punch_hole and they explicitly
mention it.
static vm_fault_t dax_iomap_pmd_fault(struct vm_fault *vmf, pfn_t *pfnp,
const struct iomap_ops *ops)
/*
* Check whether offset isn't beyond end of file now. Caller is
* supposed to hold locks serializing us with truncate / punch hole so
* this is a reliable test.
*/
max_pgoff = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
2. Make sure there are no users of pages being truncated/punch_hole
get_user_pages() might take references to page and then do some DMA
to said pages. Filesystem might truncate those pages without knowing
that a DMA is in progress or some I/O is in progress. So use
dax_layout_busy_page() to make sure there are no such references
and I/O is not in progress on said pages before moving ahead with
truncation.
3. Limitation of kvm page fault error reporting
If we are truncating file on host first and then removing mappings in
guest lateter (truncate page cache etc), then this could lead to a
problem with KVM. Say a mapping is in place in guest and truncation
happens on host. Now if guest accesses that mapping, then host will
take a fault and kvm will either exit to qemu or spin infinitely.
IOW, before we do truncation on host, we need to make sure that guest
inode does not have any mapping in that region or whole file.
4. virtiofs memory range reclaim
Soon I will introduce the notion of being able to reclaim dax memory
ranges from a fuse dax inode. There also I need to make sure that
no I/O or fault is going on in the reclaimed range and nobody is using
it so that range can be reclaimed without issues.
Currently if we take inode lock, that serializes read/write. But it does
not do anything for faults. So I add another semaphore fuse_inode->i_mmap_sem
for this purpose. It can be used to serialize with faults.
As of now, I am adding taking this semaphore only in dax fault path and
not regular fault path because existing code does not have one. May
be existing code can benefit from it as well to take care of some
races, but that we can fix later if need be. For now, I am just focussing
only on DAX path which is new path.
Also added logic to take fuse_inode->i_mmap_sem in
truncate/punch_hole/open(O_TRUNC) path to make sure file truncation and
fuse dax fault are mutually exlusive and avoid all the above problems.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2020-08-19 22:19:54 +00:00
|
|
|
int fuse_dax_break_layouts(struct inode *inode, u64 dmap_start, u64 dmap_end);
|
2021-11-25 07:05:25 +00:00
|
|
|
int fuse_dax_conn_alloc(struct fuse_conn *fc, enum fuse_dax_mode mode,
|
|
|
|
struct dax_device *dax_dev);
|
2020-08-19 22:19:47 +00:00
|
|
|
void fuse_dax_conn_free(struct fuse_conn *fc);
|
2020-08-19 22:19:51 +00:00
|
|
|
bool fuse_dax_inode_alloc(struct super_block *sb, struct fuse_inode *fi);
|
fuse: enable per inode DAX
DAX may be limited in some specific situation. When the number of usable
DAX windows is under watermark, the recalim routine will be triggered to
reclaim some DAX windows. It may have a negative impact on the
performance, since some processes may need to wait for DAX windows to be
recalimed and reused then. To mitigate the performance degradation, the
overall DAX window need to be expanded larger.
However, simply expanding the DAX window may not be a good deal in some
scenario. To maintain one DAX window chunk (i.e., 2MB in size), 32KB
(512 * 64 bytes) memory footprint will be consumed for page descriptors
inside guest, which is greater than the memory footprint if it uses
guest page cache when DAX disabled. Thus it'd better disable DAX for
those files smaller than 32KB, to reduce the demand for DAX window and
thus avoid the unworthy memory overhead.
Per inode DAX feature is introduced to address this issue, by offering a
finer grained control for dax to users, trying to achieve a balance
between performance and memory overhead.
The FUSE_ATTR_DAX flag in FUSE_LOOKUP reply is used to indicate whether
DAX should be enabled or not for corresponding file. Currently the state
whether DAX is enabled or not for the file is initialized only when
inode is instantiated.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2021-11-25 07:05:27 +00:00
|
|
|
void fuse_dax_inode_init(struct inode *inode, unsigned int flags);
|
2020-08-19 22:19:51 +00:00
|
|
|
void fuse_dax_inode_cleanup(struct inode *inode);
|
2021-11-25 07:05:29 +00:00
|
|
|
void fuse_dax_dontcache(struct inode *inode, unsigned int flags);
|
2020-08-19 22:19:49 +00:00
|
|
|
bool fuse_dax_check_alignment(struct fuse_conn *fc, unsigned int map_alignment);
|
2020-08-19 22:19:56 +00:00
|
|
|
void fuse_dax_cancel_work(struct fuse_conn *fc);
|
2020-08-19 22:19:47 +00:00
|
|
|
|
2021-04-07 12:36:45 +00:00
|
|
|
/* ioctl.c */
|
|
|
|
long fuse_file_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
|
|
|
|
long fuse_file_compat_ioctl(struct file *file, unsigned int cmd,
|
|
|
|
unsigned long arg);
|
2021-04-08 09:11:19 +00:00
|
|
|
int fuse_fileattr_get(struct dentry *dentry, struct fileattr *fa);
|
2023-01-13 11:49:21 +00:00
|
|
|
int fuse_fileattr_set(struct mnt_idmap *idmap,
|
2021-04-08 09:11:19 +00:00
|
|
|
struct dentry *dentry, struct fileattr *fa);
|
2021-04-07 12:36:45 +00:00
|
|
|
|
2021-04-07 12:36:45 +00:00
|
|
|
/* file.c */
|
|
|
|
|
|
|
|
struct fuse_file *fuse_file_open(struct fuse_mount *fm, u64 nodeid,
|
|
|
|
unsigned int open_flags, bool isdir);
|
|
|
|
void fuse_file_release(struct inode *inode, struct fuse_file *ff,
|
|
|
|
unsigned int open_flags, fl_owner_t id, bool isdir);
|
|
|
|
|
2008-10-16 14:08:57 +00:00
|
|
|
#endif /* _FS_FUSE_I_H */
|