<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/fs/fuse/file.c, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-06-11T10:19:16Z</updated>
<entry>
<title>fuse: fix copy_file_range() in the writeback case</title>
<updated>2019-06-11T10:19:16Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2019-05-28T11:22:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=62fc9aae41bd9f2f5da55847c5e30be838106e90'/>
<id>urn:sha1:62fc9aae41bd9f2f5da55847c5e30be838106e90</id>
<content type='text'>
commit a2bc92362941006830afa3dfad6caec1f99acbf5 upstream.

Prior to sending COPY_FILE_RANGE to userspace filesystem, we must flush all
dirty pages in both the source and destination files.

This patch adds the missing flush of the source file.

Tested on libfuse-3.5.0 with:

  libfuse/example/passthrough_ll /mnt/fuse/ -o writeback
  libfuse/test/test_syscalls /mnt/fuse/tmp/test

Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()")
Cc: &lt;stable@vger.kernel.org&gt; # v4.20
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fuse: fallocate: fix return with locked inode</title>
<updated>2019-06-11T10:19:16Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2019-05-27T09:42:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dbe54b432a013431c8557716acdb15b364a10d85'/>
<id>urn:sha1:dbe54b432a013431c8557716acdb15b364a10d85</id>
<content type='text'>
commit 35d6fcbb7c3e296a52136347346a698a35af3fda upstream.

Do the proper cleanup in case the size check fails.

Tested with xfstests:generic/228

Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Fixes: 0cbade024ba5 ("fuse: honor RLIMIT_FSIZE in fuse_file_fallocate")
Cc: Liu Bo &lt;bo.liu@linux.alibaba.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v3.5
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fuse: Add FOPEN_STREAM to use stream_open()</title>
<updated>2019-05-25T16:16:47Z</updated>
<author>
<name>Kirill Smelkov</name>
<email>kirr@nexedi.com</email>
</author>
<published>2019-04-24T07:13:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5bb2a758f2ed58df37d589f69bcb1400bd43ed89'/>
<id>urn:sha1:5bb2a758f2ed58df37d589f69bcb1400bd43ed89</id>
<content type='text'>
commit bbd84f33652f852ce5992d65db4d020aba21f882 upstream.

Starting from commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per
POSIX") files opened even via nonseekable_open gate read and write via lock
and do not allow them to be run simultaneously. This can create read vs
write deadlock if a filesystem is trying to implement a socket-like file
which is intended to be simultaneously used for both read and write from
filesystem client.  See commit 10dce8af3422 ("fs: stream_open - opener for
stream-like files so that read and write can run simultaneously without
deadlock") for details and e.g. commit 581d21a2d02a ("xenbus: fix deadlock
on writes to /proc/xen/xenbus") for a similar deadlock example on
/proc/xen/xenbus.

To avoid such deadlock it was tempting to adjust fuse_finish_open to use
stream_open instead of nonseekable_open on just FOPEN_NONSEEKABLE flags,
but grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE,
and in particular GVFS which actually uses offset in its read and write
handlers

	https://codesearch.debian.net/search?q=-%3Enonseekable+%3D
	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1080
	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1247-1346
	https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1399-1481

so if we would do such a change it will break a real user.

Add another flag (FOPEN_STREAM) for filesystem servers to indicate that the
opened handler is having stream-like semantics; does not use file position
and thus the kernel is free to issue simultaneous read and write request on
opened file handle.

This patch together with stream_open() should be added to stable kernels
starting from v3.14+. This will allow to patch OSSPD and other FUSE
filesystems that provide stream-like files to return FOPEN_STREAM |
FOPEN_NONSEEKABLE in open handler and this way avoid the deadlock on all
kernel versions. This should work because fuse_finish_open ignores unknown
open flags returned from a filesystem and so passing FOPEN_STREAM to a
kernel that is not aware of this flag cannot hurt. In turn the kernel that
is not aware of FOPEN_STREAM will be &lt; v3.14 where just FOPEN_NONSEEKABLE
is sufficient to implement streams without read vs write deadlock.

Cc: stable@vger.kernel.org # v3.14+
Signed-off-by: Kirill Smelkov &lt;kirr@nexedi.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fuse: honor RLIMIT_FSIZE in fuse_file_fallocate</title>
<updated>2019-05-25T16:16:34Z</updated>
<author>
<name>Liu Bo</name>
<email>bo.liu@linux.alibaba.com</email>
</author>
<published>2019-04-17T20:04:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=62b91cdf1f9a63f46772766b58f5297b8a448599'/>
<id>urn:sha1:62b91cdf1f9a63f46772766b58f5297b8a448599</id>
<content type='text'>
commit 0cbade024ba501313da3b7e5dd2a188a6bc491b5 upstream.

fstests generic/228 reported this failure that fuse fallocate does not
honor what 'ulimit -f' has set.

This adds the necessary inode_newsize_ok() check.

Signed-off-by: Liu Bo &lt;bo.liu@linux.alibaba.com&gt;
Fixes: 05ba1f082300 ("fuse: add FALLOCATE operation")
Cc: &lt;stable@vger.kernel.org&gt; # v3.5
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fuse: fix writepages on 32bit</title>
<updated>2019-05-25T16:16:34Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2019-04-24T15:05:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5ff78d234cd170972b3a9061e2cae6bdfc637f41'/>
<id>urn:sha1:5ff78d234cd170972b3a9061e2cae6bdfc637f41</id>
<content type='text'>
commit 9de5be06d0a89ca97b5ab902694d42dfd2bb77d2 upstream.

Writepage requests were cropped to i_size &amp; 0xffffffff, which meant that
mmaped writes to any file larger than 4G might be silently discarded.

Fix by storing the file size in a properly sized variable (loff_t instead
of size_t).

Reported-by: Antonio SJ Musumeci &lt;trapexit@spawn.link&gt;
Fixes: 6eaf4782eb09 ("fuse: writepages: crop secondary requests")
Cc: &lt;stable@vger.kernel.org&gt; # v3.13
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fuse: cache readdir calls if filesystem opts out of opendir</title>
<updated>2019-02-13T12:15:15Z</updated>
<author>
<name>Chad Austin</name>
<email>chadaustin@fb.com</email>
</author>
<published>2019-01-29T00:34:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fabf7e0262d0bd57739d29aeac94c44b0542ff1f'/>
<id>urn:sha1:fabf7e0262d0bd57739d29aeac94c44b0542ff1f</id>
<content type='text'>
If a filesystem returns ENOSYS from opendir and thus opts out of
opendir and releasedir requests, it almost certainly would also like
readdir results cached. Default open_flags to FOPEN_KEEP_CACHE and
FOPEN_CACHE_DIR in that case.

With this patch, I've measured recursive directory enumeration across
large FUSE mounts to be faster than native mounts.

Signed-off-by: Chad Austin &lt;chadaustin@fb.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
</content>
</entry>
<entry>
<title>fuse: support clients that don't implement 'opendir'</title>
<updated>2019-02-13T12:15:15Z</updated>
<author>
<name>Chad Austin</name>
<email>chadaustin@fb.com</email>
</author>
<published>2019-01-08T00:53:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d9a9ea94f748f47b1d75c6c5e33edcf74476c445'/>
<id>urn:sha1:d9a9ea94f748f47b1d75c6c5e33edcf74476c445</id>
<content type='text'>
Allow filesystems to return ENOSYS from opendir, preventing the kernel from
sending opendir and releasedir messages in the future. This avoids
userspace transitions when filesystems don't need to keep track of state
per directory handle.

A new capability flag, FUSE_NO_OPENDIR_SUPPORT, parallels
FUSE_NO_OPEN_SUPPORT, indicating the new semantics for returning ENOSYS
from opendir.

Signed-off-by: Chad Austin &lt;chadaustin@fb.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
</content>
</entry>
<entry>
<title>fuse: lift bad inode checks into callers</title>
<updated>2019-02-13T12:15:15Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2019-01-24T09:40:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2f7b6f5bed01a3fd2abcc20d2c85b7c532eb95cd'/>
<id>urn:sha1:2f7b6f5bed01a3fd2abcc20d2c85b7c532eb95cd</id>
<content type='text'>
Bad inode checks were done  done in various places, and move them into
fuse_file_{read|write}_iter().

Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
</content>
</entry>
<entry>
<title>fuse: multiplex cached/direct_io file operations</title>
<updated>2019-02-13T12:15:15Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2019-01-24T09:40:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=55752a3aba1387887afa024a0732f8ae52fb0645'/>
<id>urn:sha1:55752a3aba1387887afa024a0732f8ae52fb0645</id>
<content type='text'>
This is cleanup, as well as allowing switching between I/O modes while the
file is open in the future.

Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
</content>
</entry>
<entry>
<title>fuse add copy_file_range to direct io fops</title>
<updated>2019-02-13T12:15:14Z</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2019-01-24T09:40:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d4136d60751a5f45f47f1c3a77f6e8bafa11be1f'/>
<id>urn:sha1:d4136d60751a5f45f47f1c3a77f6e8bafa11be1f</id>
<content type='text'>
Nothing preventing copy_file_range to work on files opened with
FOPEN_DIRECT_IO.

Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()")
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
</content>
</entry>
</feed>
