We had a size mismatch for the return value, leading to EIOCBQUEUED
getting interpreted as a return size instead of an error code.
Test: generic/467, generic/013, and fuse_test
Bug: 217570523
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I64f9d5263f8b37d3c0e286467f9351997b294cc2
Allocates the iocb we create for asynchronous IO from a cache instead of
a regular kzalloc
Test: generic/467 and fuse_test
Bug: 217570523
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I27dcec89cd585835f6a8e80e1ae30c503f4038c8
The current name is a bit confusing. iocb_fuse could refer to the iocb
passed to fuse or created by fuse. The new name unambiguously refers to
the one passed in to fuse.
Test: compiles, behavior unchanged
Bug: 217570523
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I955500eb8a3186252427fd06ca6e99b4fec469b6
Existing fixattr was adjusting the same node twice.
Bug: 226655982
Test: generic/241 generic/269
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I4b1cb6d626ee6bd9010012ac126b78f14d6157d0
Fuse uses generic_file_llseek, so we must account for that in readdir to
ensure we read from the correct offset in the lower filesystem.
Bug: 226655281
Test: generic/257, fuse_test
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Ie752c1c645e95b7c03ef9497562758a5c42b514a
Properly handle the async case. The existing bpf operations will likely
need to be reworked. Given that they don't allow altering anything as
is, this change just incrementally moves us in the right direction.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Test: generic/467 and fuse_test
Bug: 217570523
Change-Id: I31c0b48bf3d674efecad4bff4ea8b482c4e7da45
This doesn't cause any behavior changes and will be used by overlay async
IO implementation.
Remove 'kiocb_clone' from passthrough.c as this is the proper upstream
commit which adds the function.
Change-Id: Ic3d0ebd5cc2d945358f7295697ae02a829e2e919
Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Adds support for lseek via fuse-bpf
Bug: 224855060
Test: bpf_test_lseek
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Ic282940d53b9bb44a291cb3a5dfe09847b4e5c9a
Ensure finalize has access to the returned error code, if it had one.
Test: generic/377
Bug: 217570523
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Id9a0aca10c3158f8b414e0cbc2dd1282bb5ef16b
This moves the backing/fd files to their own space, instead of reusing
the userspace provided fds.
Bug: 222619123
Test: fuse_test passes, on cuttlefish CtsCameraTestCases passes
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I5d3b1ea8299f249ef5adc1ce2b7f45404a041208
Bug: 222497969
Test: idle kingdom launches sucessfully with no mediaprovider crashes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ia5f842fd4a0bf9a21d7c88874b13b84d42ab2c4d
Bug: 222619123
Test: fuse_test passes, on cuttlefish CtsCameraTestCases passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I54c148206b5ad5ae5737939bcb076cbe6c40129c
If the lower filesystem has deleted a file or folder behind our back, we
should drop it as well.
Bug: 221093504
Test: atest android.hardware.cts.CameraTest#testJpegThumbnailSize
several times in a row
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Ibd92dea83a82dd7ab21269ae5d2533e4826f5fb7
In the backing case, we initially want to call out to the fuse-bpf
implementation, and only fall back to userspace if that requests it.
Otherwise we end up making requests to userspace that the daemon may not
be equiped to respond to.
Change-Id: If3780aa8b7c45558717a9efba0b1781e8d63a3c0
Bug: 217570523
Test: generic/099
Signed-off-by: Daniel Rosenberg <drosen@google.com>
This is useful for testing fuse-bpf directly on a backing folder.
Bug: 217570523
Test: mount -t fuse [DEVNAME] [mntpoint] -o user_id=0,group_id=0,rootmode=0040000,
no_daemon,root_dir=[backingfd]
Change-Id: I9ac13c3f707d71cbb74dba10eda5778bf3e83233
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Adds support for FUSE_STATFS, needed to run various filesystem tests
Bug: 217570523
Test: bpf_test_statfs
Change-Id: I5ee13e880118c5c79c4ca17bb2e902a3e17a7eb8
Signed-off-by: Daniel Rosenberg <drosen@google.com>
filldir used strcpy, potentially leading to writing the ending null past
the current page. fuse_dirents are not null terminated, so we switch to
using memcpy to avoid adding an extraneous null, which would be
overwritten if the name was already byte aligned.
Bug: 217570523
Test: generic/027
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Ic5d1f1887a113e1a3319998bad47cfbac3d90baa
If we hit an error during fuse_create_open, some variables will be
undefined during the finalize, so check that they were actually
initialized before accessing.
Bug: 217570523
Test: attempt to over fill disk
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I094564b83e49eec2a6bac5bd050b4f7327b0c979
Maps would crash every second launch. This was caused by maps receiving
an incorrect file size after truncate, then mapping the file.
Bug: 215486645
Test: fuse_test + launch maps 100 times & look for native crashes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I13b0211330fb48592864ab53f8ffff60c19aab11
We should only apply the mask ourselves if we're not
using POSIX acls
Bug: 215212818
Test: com.android.cts.externalstorageapp.CommonExternalStorageTest
#testAllPackageDirsWritable, verify files and cache permissions
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: If105afe62a60b93cbce1ca5ab5caf11f008aa7db
In a move operation, if the FROM file has a backing inode associated and
is handled in backing, it might happen that the TO file does not have a
backing path associated (yet), maybe because the FUSE daemon didn't have
the chance to traverse it.
Thus this special case would mistakenly trigger EBADF, while EXDEV is
more appropriate.
Bug: 202785178
Test: mv /storage/emulated/0/Android/data/<pkg>/file /sdcard/DCIM
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: I513c0e17c128ed9181a6b96fbf9f0b950e78be77
Setattr implementation was mixing up some flags, and missing some of
them.
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Bug: 202785178
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Id41fa30881766faad5858b658f5b6871c0ae46b3
Fixes: ANDROID: fuse-bpf: Fix perms on readdir
Test: Builds with and without CONFIG_FUSE_BPF
Bug: 202785178
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: If8b4603dd6f4bd159bfd68fc61c377dcb62ebcd0
Add checks for both fuse accesses and backing fs accesses
Bug: 202785178
Test: fuse_test passes, also atest ScopedStorageDeviceTest passes
Change-Id: Ida7d90e14ca36588a8cc19453e0d40b4f6f41aa9
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Uses lookup_one_len if given dentry is still negative/unlocked after
mkdir is called
Bug: 202785178
Test: atest android.scopedstorage.cts.device.ScopedStorageDeviceTest#testCreateAndDeleteEmptyDir
Change-Id: Id5c7dfd303c242d6966fab82d96712d289676857
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 202785178
Test: fuse_test runs, no leak on Android
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: If3c8dbe680f21c646e98f66140b842869c2c5abf
This will simply pass all mapping operations to the backing file if it
exists. This is sufficient for our needs in Android13, but must be
extended in the future.
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 202785178
Test: fuse_test passes
Change-Id: I3c51ef62415633ff0db039f25bfed1adf14e1e80
Bug: 202785178
Test: test_fuse passes on linux, feature works on cuttlefish
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I987684b799b07391ccde350e98fde7976f5601aa
Contains squash of this commit:
Author: Nathan Chancellor <nathan@kernel.org>
Date: Fri Jan 20 09:40:12 2023 -0700
ANDROID: fuse: Restore upstream type of bitfields in fuse_args
Commit 88b7179fcdb59 ("ANDROID: fuse: Move functions in preparation for
fuse-bpf") changed the type of these bitfields from the upstream type of
'bool' to 'int', which causes several warnings with recent versions of
clang:
/builds/linux/fs/fuse/dir.c:168:19: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bi
t-bitfield-constant-conversion]
args->out_argvar = true;
^ ~~~~
/builds/linux/fs/fuse/dir.c:492:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bi
t-bitfield-constant-conversion]
args.out_argvar = 1;
^ ~
/builds/linux/fs/fuse/dir.c:1649:20: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-b
it-bitfield-constant-conversion]
ap.args.out_pages = true;
^ ~~~~
/builds/linux/fs/fuse/dir.c:1650:21: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-b
it-bitfield-constant-conversion]
ap.args.out_argvar = true;
^ ~~~~
/builds/linux/fs/fuse/dir.c:1651:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-b
it-bitfield-constant-conversion]
ap.args.page_zeroing = true;
^ ~~~~
5 errors generated.
When fuse_args was moved back to the internal implementation in commit
9a5023967b4d2 ("ANDROID: fuse-bpf: Use fuse_bpf_args in uapi"), the type
was not restored. Do so now to fix the warnings and reduce the delta
with upstream.
Bug: 265200230
Change-Id: I4d51f331d842a1faff9a937140f0275130e70d73
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Bug: 202785178
Test: test_fuse passes on linux, feature works on cuttlefish
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Ie738893a821d1f5f252c4c6e86274d55a6f09965
commit 15db16837a35d8007cb8563358787412213db25e upstream.
Server responds to LOOKUP and other ops (READDIRPLUS/CREATE/MKNOD/...)
with ourarg containing nodeid and generation.
If a fuse inode is found in inode cache with the same nodeid but different
generation, the existing fuse inode should be unhashed and marked "bad" and
a new inode with the new generation should be hashed instead.
This can happen, for example, with passhrough fuse filesystem that returns
the real filesystem ino/generation on lookup and where real inode numbers
can get recycled due to real files being unlinked not via the fuse
passthrough filesystem.
With current code, this situation will not be detected and an old fuse
dentry that used to point to an older generation real inode, can be used to
access a completely new inode, which should be accessed only via the new
dentry.
Note that because the FORGET message carries the nodeid w/o generation, the
server should wait to get FORGET counts for the nlookup counts of the old
and reused inodes combined, before it can free the resources associated to
that nodeid.
Stable backport notes:
* This is not a regression. The bug has been in fuse forever, but only
a certain class of low level fuse filesystems can trigger this bug
* Because there is no way to check if this fix is applied in runtime,
libfuse test_examples.py tests this fix with hardcoded check for
kernel version >= 5.14
* After backport to stable kernel(s), the libfuse test can be updated
to also check minimal stable kernel version(s)
* Depends on "fuse: fix bad inode" which is already applied to stable
kernels v5.4.y and v5.10.y
* Required backporting helper inode_wrong_type()
Change-Id: I5f92158bc8ccdb50627fb035bb28d3ade51820b3
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/linux-fsdevel/CAOQ4uxi8DymG=JO_sAU+wS8akFdzh+PuXwW3Ebgahd2Nwnh7zA@mail.gmail.com/
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6e3e2c4362e41a2f18e3f7a5ad81bd2f49a47b85 upstream.
inode_wrong_type(inode, mode) returns true if setting inode->i_mode
to given value would've changed the inode type. We have enough of
those checks open-coded to make a helper worthwhile.
Change-Id: I346cb7a2d1cec2ca16096962d8adc9d7f848fc94
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4a9ccdd1c03b3dc58214874399d24331ea0a3ab upstream.
We don't set the SB_BORN flag on submounts. This is wrong as these
superblocks are then considered as partially constructed or dying
in the rest of the code and can break some assumptions.
One such case is when you have a virtiofs filesystem with submounts
and you try to mount it again : virtio_fs_get_tree() tries to obtain
a superblock with sget_fc(). The logic in sget_fc() is to loop until
it has either found an existing matching superblock with SB_BORN set
or to create a brand new one. It is assumed that a superblock without
SB_BORN is transient and the loop is restarted. Forgetting to set
SB_BORN on submounts hence causes sget_fc() to retry forever.
Setting SB_BORN requires special care, i.e. a write barrier for
super_cache_count() which can check SB_BORN without taking any lock.
We should call vfs_get_tree() to deal with that but this requires
to have a proper ->get_tree() implementation for submounts, which
is a bigger piece of work. Go for a simple bug fix in the meatime.
Fixes: bf109c64040f ("fuse: implement crossmounts")
Cc: stable@vger.kernel.org # v5.10+
Change-Id: I709931fa4fc72c0a72707eae03b1de93a630ddf6
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3a43f2a95393000778f8f302d48795add2fc4a8 upstream.
As soon as fuse_dentry_automount() does up_write(&sb->s_umount), the
superblock can theoretically be killed. If this happens before the
submount was added to the &fc->mounts list, fuse_mount_remove() later
crashes in list_del_init() because it assumes the submount to be
already there.
Add the submount before dropping sb->s_umount to fix the inconsistency.
It is okay to nest fc->killsb under sb->s_umount, we already do this
on the ->kill_sb() path.
Change-Id: I5fb3786f86b7a7f1492f557284dd05d67bc8dce0
Signed-off-by: Greg Kurz <groug@kaod.org>
Fixes: bf109c64040f ("fuse: implement crossmounts")
Cc: stable@vger.kernel.org # v5.10+
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d92d88f0568e97c437eeb79d9c9609bd8277406f upstream.
If fuse_fill_super_submount() returns an error, the error path
triggers a crash:
[ 26.206673] BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
[ 26.226362] RIP: 0010:__list_del_entry_valid+0x25/0x90
[...]
[ 26.247938] Call Trace:
[ 26.248300] fuse_mount_remove+0x2c/0x70 [fuse]
[ 26.248892] virtio_kill_sb+0x22/0x160 [virtiofs]
[ 26.249487] deactivate_locked_super+0x36/0xa0
[ 26.250077] fuse_dentry_automount+0x178/0x1a0 [fuse]
The crash happens because fuse_mount_remove() assumes that the FUSE
mount was already added to list under the FUSE connection, but this
only done after fuse_fill_super_submount() has returned success.
This means that until fuse_fill_super_submount() has returned success,
the FUSE mount isn't actually owned by the superblock. We should thus
reclaim ownership by clearing sb->s_fs_info, which will skip the call
to fuse_mount_remove(), and perform rollback, like virtio_fs_get_tree()
already does for the root sb.
Fixes: bf109c64040f ("fuse: implement crossmounts")
Cc: stable@vger.kernel.org # v5.10+
Change-Id: Ie395b453a703cf3f1dda2c825c7de0fe4bd62d04
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 0a7419c68a45d2d066b996be5087aa2d07ce80eb ]
get_user_ns() is done twice (once in virtio_fs_get_tree() and once in
fuse_conn_init()), resulting in a reference leak.
Also looks better to use fsc->user_ns (which *should* be the
current_user_ns() at this point).
Change-Id: If41a5cefac82bc65e880ad14ed90f1adca9271ae
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3466958beb31a8e9d3a1441a34228ed088b84f3e ]
In fuse when a direct/write-through write happens we invalidate attrs
because that might have updated mtime/ctime on server and cached
mtime/ctime will be stale.
What about page writeback path. Looks like we don't invalidate attrs
there. To be consistent, invalidate attrs in writeback path as well. Only
exception is when writeback_cache is enabled. In that case we strust local
mtime/ctime and there is no need to invalidate attrs.
Recently users started experiencing failure of xfstests generic/080,
geneirc/215 and generic/614 on virtiofs. This happened only newer "stat"
utility and not older one. This patch fixes the issue.
So what's the root cause of the issue. Here is detailed explanation.
generic/080 test does mmap write to a file, closes the file and then checks
if mtime has been updated or not. When file is closed, it leads to
flushing of dirty pages (and that should update mtime/ctime on server).
But we did not explicitly invalidate attrs after writeback finished. Still
generic/080 passed so far and reason being that we invalidated atime in
fuse_readpages_end(). This is called in fuse_readahead() path and always
seems to trigger before mmaped write.
So after mmaped write when lstat() is called, it sees that atleast one of
the fields being asked for is invalid (atime) and that results in
generating GETATTR to server and mtime/ctime also get updated and test
passes.
But newer /usr/bin/stat seems to have moved to using statx() syscall now
(instead of using lstat()). And statx() allows it to query only ctime or
mtime (and not rest of the basic stat fields). That means when querying
for mtime, fuse_update_get_attr() sees that mtime is not invalid (only
atime is invalid). So it does not generate a new GETATTR and fill stat
with cached mtime/ctime. And that means updated mtime is not seen by
xfstest and tests start failing.
Invalidating attrs after writeback completion should solve this problem in
a generic manner.
Change-Id: I867c795d35306e17445d5e849676b31b2103c762
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fuse could use get_user_pages_fast by iov_iter_get_pages at
fuse_copy_fill so close the false positive by attributing
it by put_user_page.
Page pinned via pid 670, ts 4554195916 ns
PFN 83125 Block 162 type Movable Flags 0xfffffc008001e(referenced|uptodate|dirty|lru|swapbacked)
try_grab_compound_head+0x1e8/0x240
internal_get_user_pages_fast+0x66d/0xca0
iov_iter_get_pages+0xd4/0x3a0
fuse_copy_fill+0x197/0x200
fuse_copy_one+0x6e/0xf0
fuse_dev_do_read.constprop.0+0x435/0x7e0
fuse_dev_read+0x5d/0x90
new_sync_read+0x115/0x1a0
vfs_read+0xf4/0x180
ksys_read+0x5f/0xe0
do_syscall_64+0x33/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Re-name put_user_page -> put_page
Bug: 183414571
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Idc80d4a34b546f25e8f6dbc68313d39586e914d9
[ Upstream commit 3f9b9efd82a84f27e95d0414f852caf1fa839e83 ]
Right now "mount -t virtiofs -o dax myfs /mnt/virtiofs" succeeds even
if filesystem deivce does not have a cache window and hence DAX can't
be supported.
This gives a false sense to user that they are using DAX with virtiofs
but fact of the matter is that they are not.
Fix this by returning error if dax can't be supported and user has asked
for it.
Change-Id: Ibbf05e0c354ae47b6fd897f454d0712b202e0a34
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 66ab33bf6d4341574f88b511e856a73f6f2a921e ]
This can be triggered for example by adding the "-omand" mount option,
which will be rejected and virtio_fs_fill_super() will return an error.
In such a case the allocations for fuse_conn and fuse_mount will leak due
to s_root not yet being set and so ->put_super() not being called.
Fixes: a62a8ef9d9 ("virtio-fs: add virtiofs filesystem")
Change-Id: I1a25fd72aaf8348e8bd1ca29b59df712d789e3f7
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
virtiofs currently maps various buffers in scatter gather list and it looks
at number of pages (ap->pages) and assumes that same number of pages will
be used both for input and output (sg_count_fuse_req()), and calculates
total number of scatterlist elements accordingly.
But looks like this assumption is not valid in all the cases. For example,
Cai Qian reported that trinity, triggers warning with virtiofs sometimes.
A closer look revealed that if one calls ioctl(fd, 0x5a004000, buf), it
will trigger following warning.
WARN_ON(out_sgs + in_sgs != total_sgs)
In this case, total_sgs = 8, out_sgs=4, in_sgs=3. Number of pages is 2
(ap->pages), but out_sgs are using both the pages but in_sgs are using
only one page. In this case, fuse_do_ioctl() sets different size values
for input and output.
args->in_args[args->in_numargs - 1].size == 6656
args->out_args[args->out_numargs - 1].size == 4096
So current method of calculating how many scatter-gather list elements
will be used is not accurate. Make calculations more precise by parsing
size and ap->descs.
Reported-by: Qian Cai <cai@redhat.com>
Change-Id: I1ccdbce4b946a016a4a8faea234de0cb470825ac
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Link: https://lore.kernel.org/linux-fsdevel/5ea77e9f6cb8c2db43b09fbd4158ab2d8c066a0a.camel@redhat.com/
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Re-add lost removal of fc from fuse_conn_list and the control filesystem.
Reported-by: kernel test robot <rong.a.chen@intel.com>
Fixes: fcee216beb9c ("fuse: split fuse_mount off of fuse_conn")
Change-Id: Icaaee7958947461b80a10d42a38ff5a3078e268a
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
FUSE servers can indicate crossmount points by setting FUSE_ATTR_SUBMOUNT
in fuse_attr.flags. The inode will then be marked as S_AUTOMOUNT, and the
.d_automount implementation creates a new submount at that location, so
that the submount gets a distinct st_dev value.
Note that all submounts get a distinct superblock and a distinct st_dev
value, so for virtio-fs, even if the same filesystem is mounted more than
once on the host, none of its mount points will have the same st_dev. We
need distinct superblocks because the superblock points to the root node,
but the different host mounts may show different trees (e.g. due to
submounts in some of them, but not in others).
Right now, this behavior is only enabled when fuse_conn.auto_submounts is
set, which is the case only for virtio-fs.
Change-Id: I455ddae7b02f28968cf78018b771d0c12d03bacd
Signed-off-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Set up a readahead size by default, as very few users have a good
reason to change it. This means code, ecryptfs, and orangefs now
set up the values while they were previously missing it, while ubifs,
mtd and vboxsf manually set it to 0 to avoid readahead.
Change-Id: I2394fea47e8685f26aee9cc52c72018cd2715741
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Acked-by: David Sterba <dsterba@suse.com> [btrfs]
Acked-by: Richard Weinberger <richard@nod.at> [ubifs, mtd]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
