fuse: inode IO modes and mmap

There were multiple issues with direct_io_allow_mmap:
- fuse_link_write_file() was missing, resulting in warnings in fuse_write_file_get() and EIO from msync()
- "vma->vm_ops = &fuse_file_vm_ops" was not set, but especially fuse_page_mkwrite is needed.

The semantics of invalidate_inode_pages2() is so far not clearly defined in fuse_file_mmap. It dates back to
commit 3121bfe76311 ("fuse: fix "direct_io" private mmap") Though, as direct_io_allow_mmap is a new feature, that was for MAP_PRIVATE only. As invalidate_inode_pages2() is calling into fuse_launder_folio() and writes out dirty pages, it should be safe to call invalidate_inode_pages2 for MAP_PRIVATE and MAP_SHARED as well.

Quoted 7 lines · Bernd Schubert

There were multiple issues with direct_io_allow_mmap:
- fuse_link_write_file() was missing, resulting in warnings in fuse_write_file_get() and EIO from msync()
- "vma->vm_ops = &fuse_file_vm_ops" was not set, but especially fuse_page_mkwrite is needed.

Quoted 7 lines

The semantics of invalidate_inode_pages2() is so far not clearly defined in fuse_file_mmap. It dates back to
commit 3121bfe76311 ("fuse: fix "direct_io" private mmap") Though, as direct_io_allow_mmap is a new feature, that was for MAP_PRIVATE only. As invalidate_inode_pages2() is calling into fuse_launder_folio() and writes out dirty pages, it should be safe to call invalidate_inode_pages2 for MAP_PRIVATE and MAP_SHARED as well.

Did you test with fsx (various versions can be found in LTP/xfstests)?
It's very good at finding mapped vs. non-mapped bugs.

Quoted 16 lines · Miklos Szeredi

Quoted 14 lines · Bernd Schubert

There were multiple issues with direct_io_allow_mmap:
- fuse_link_write_file() was missing, resulting in warnings in fuse_write_file_get() and EIO from msync()
- "vma->vm_ops = &fuse_file_vm_ops" was not set, but especially fuse_page_mkwrite is needed.

The semantics of invalidate_inode_pages2() is so far not clearly defined in fuse_file_mmap. It dates back to
commit 3121bfe76311 ("fuse: fix "direct_io" private mmap") Though, as direct_io_allow_mmap is a new feature, that was for MAP_PRIVATE only. As invalidate_inode_pages2() is calling into fuse_launder_folio() and writes out dirty pages, it should be safe to call invalidate_inode_pages2 for MAP_PRIVATE and MAP_SHARED as well.

Quoted 2 lines

Did you test with fsx (various versions can be found in LTP/xfstests)?
It's very good at finding mapped vs. non-mapped bugs.

I tested with xfstest, but not with fsx yet. I can look into that. Do you have by any chance an exact command I should run?

Quoted 20 lines · Bernd Schubert

Quoted 16 lines · Miklos Szeredi

Quoted 14 lines · Bernd Schubert

There were multiple issues with direct_io_allow_mmap:
- fuse_link_write_file() was missing, resulting in warnings in fuse_write_file_get() and EIO from msync()
- "vma->vm_ops = &fuse_file_vm_ops" was not set, but especially fuse_page_mkwrite is needed.

The semantics of invalidate_inode_pages2() is so far not clearly defined in fuse_file_mmap. It dates back to
commit 3121bfe76311 ("fuse: fix "direct_io" private mmap") Though, as direct_io_allow_mmap is a new feature, that was for MAP_PRIVATE only. As invalidate_inode_pages2() is calling into fuse_launder_folio() and writes out dirty pages, it should be safe to call invalidate_inode_pages2 for MAP_PRIVATE and MAP_SHARED as well.

Quoted 5 lines

Quoted 2 lines

Did you test with fsx (various versions can be found in LTP/xfstests)?
It's very good at finding mapped vs. non-mapped bugs.

I tested with xfstest, but not with fsx yet. I can look into that. Do you have by any chance an exact command I should run?

Just specifying a filename should be good. Make sure you test with various open modes.

Given
-N numops: total # operations to do (default infinity)

How long do you think I should run it? Maybe something like 3 hours (--duration=$(3 * 60 * 60))?

Quoted 5 lines · Bernd Schubert

Given
-N numops: total # operations to do (default infinity)

How long do you think I should run it? Maybe something like 3 hours (--duration=$(3 * 60 * 60))?

I used -N1000000. If there were any issues they usually triggered much earlier.

Quoted 11 lines · Miklos Szeredi

Quoted 5 lines · Bernd Schubert

Given
-N numops: total # operations to do (default infinity)

How long do you think I should run it? Maybe something like 3 hours (--duration=$(3 * 60 * 60))?

I used -N1000000. If there were any issues they usually triggered much earlier.

Note that at least these fstests run fsx in several configurations:

$ grep begin `git grep -l run_fsx tests/generic/`
tests/generic/091:_begin_fstest rw auto quick
tests/generic/263:_begin_fstest rw auto quick
tests/generic/469:_begin_fstest auto quick punch zero prealloc
tests/generic/521:_begin_fstest soak long_rw smoketest
tests/generic/522:_begin_fstest soak long_rw smoketest
tests/generic/616:_begin_fstest auto rw io_uring stress soak
tests/generic/617:_begin_fstest auto rw io_uring stress soak

Bernd, you've probably already ran them if you are running auto, quick or rw test groups.

Possibly you want to try and run also the -g soak.long_rw tests.

They use nr_ops=$((1000000 * TIME_FACTOR))

Quoted 5 lines · Bernd Schubert

Given
-N numops: total # operations to do (default infinity)

How long do you think I should run it? Maybe something like 3 hours (--duration=$(3 * 60 * 60))?

I used -N1000000. If there were any issues they usually triggered much earlier.

fs/fuse/file.c static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from) · line 1622

Quoted 11 lines · Bernd Schubert

fs/fuse/file.c +3 -3

@@ -1591,10 +1616,10 @@ static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from)
 	else {
 		inode_lock_shared(inode);
 
-		/* A race with truncate might have come up as the decision for
-		 * the lock type was done without holding the lock, check again.
+		/*
+		 * Previous check was without any lock and might have raced.
 		 */
-		if (fuse_direct_write_extending_i_size(iocb, from)) {
+		if (fuse_dio_wr_exclusive_lock(iocb, from)) {

			^

The overall is good. Maybe fuse_io_past_eof() is better to make it a solely cleanup or refactoring. Actually it's already changed back to fuse_io_past_eof() in patch 3/5.

Quoted 12 lines · Jingbo Xu

Quoted 9 lines · Bernd Schubert

fs/fuse/file.c +2 -2

@@ -1591,10 +1616,10 @@ static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from)
 	else {
 		inode_lock_shared(inode);
 
-		/* A race with truncate might have come up as the decision for
-		 * the lock type was done without holding the lock, check again.
+		/*
+		 * Previous check was without any lock and might have raced.
 		 */

Quoted 3 lines

fs/fuse/file.c static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from) · line 1622

Quoted 2 lines

fs/fuse/file.c +1 -1

-		if (fuse_direct_write_extending_i_size(iocb, from)) {
+		if (fuse_dio_wr_exclusive_lock(iocb, from)) {

			^

Quoted 17 lines · Bernd Schubert

Quoted 12 lines · Jingbo Xu

Quoted 9 lines · Bernd Schubert

fs/fuse/file.c +2 -2

@@ -1591,10 +1616,10 @@ static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from)
 	else {
 		inode_lock_shared(inode);
 
-		/* A race with truncate might have come up as the decision for
-		 * the lock type was done without holding the lock, check again.
+		/*
+		 * Previous check was without any lock and might have raced.
 		 */

Quoted 3 lines

Quoted 3 lines

fs/fuse/file.c static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from) · line 1622

Quoted 2 lines

fs/fuse/file.c +1 -1

-		if (fuse_direct_write_extending_i_size(iocb, from)) {
+		if (fuse_dio_wr_exclusive_lock(iocb, from)) {

			^

I mean, in patch 2/5

Review

Quoted 2 lines

(quoted diff) +1 -1

-		if (fuse_direct_write_extending_i_size(iocb, from)) {
+		if (fuse_io_past_eof(iocb, from)) {

is better, otherwise it's not an equivalent change.

Quoted 24 lines · Jingbo Xu

Quoted 17 lines · Bernd Schubert

Quoted 12 lines · Jingbo Xu

Quoted 9 lines · Bernd Schubert

fs/fuse/file.c +2 -2

@@ -1591,10 +1616,10 @@ static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from)
 	else {
 		inode_lock_shared(inode);
 
-		/* A race with truncate might have come up as the decision for
-		 * the lock type was done without holding the lock, check again.
+		/*
+		 * Previous check was without any lock and might have raced.
 		 */

Quoted 3 lines

Quoted 3 lines

fs/fuse/file.c static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from) · line 1622

Quoted 2 lines

fs/fuse/file.c +1 -1

-		if (fuse_direct_write_extending_i_size(iocb, from)) {
+		if (fuse_dio_wr_exclusive_lock(iocb, from)) {

			^

Quoted 6 lines

I mean, in patch 2/5

Review

Quoted 2 lines

(quoted diff) +1 -1

-		if (fuse_direct_write_extending_i_size(iocb, from)) {
+		if (fuse_io_past_eof(iocb, from)) {

is better, otherwise it's not an equivalent change.

Ah thanks, good catch! Now I see what you mean. Yeah, we can switch to fuse_io_past_eof() here. And yeah, 3/5 changes it back. Fortunately there is actually not much harm, as fuse_dio_wr_exclusive_lock also calls into fuse_io_past_eof.

From: Amir Goldstein <[email protected]>

In preparation for inode io modes, a server open response could fail due to conflicting inode io modes.

Allow returning an error from fuse_finish_open() and handle the error in the callers. fuse_dir_open() can now call fuse_sync_release(), so handle the isdir case correctly.

Quoted 6 lines · Bernd Schubert

From: Amir Goldstein <[email protected]>

In preparation for inode io modes, a server open response could fail due to conflicting inode io modes.

Quoted 3 lines

Allow returning an error from fuse_finish_open() and handle the error in the callers. fuse_dir_open() can now call fuse_sync_release(), so handle the isdir case correctly.

While that's true, it may be better to just decouple the dir/regular paths completely, since there isn't much sharing anyway and becoming even less.

fs/fuse/dir.c static int fuse_create_open(struct inode *dir, struct dentry *entry, · line 698

Quoted 13 lines

fs/fuse/dir.c +4 -1

index d19cbf34c634..d45d4a678351 100644
@@ -692,13 +692,15 @@ static int fuse_create_open(struct inode *dir, struct dentry *entry,
        d_instantiate(entry, inode);
        fuse_change_entry_timeout(entry, &outentry);
        fuse_dir_changed(dir);
-       err = finish_open(file, entry, generic_file_open);
+       err = generic_file_open(inode, file);
+       if (!err) {
+               file->private_data = ff;
+               err = finish_open(file, entry, fuse_finish_open);

Need to be careful with moving fuse_finish_open() call inside finish_open() since various fields will be different.

In particular O_TRUNC in f_flags will not be cleared and in this case it looks undesirable.

I can look into it, but for now the fix to fuse_sync_release() is a simple one liner, so I would rather limit the changes in this series.

Is fuse_finish_open() supposed to be called after clearing O_TRUNC in fuse_create_open()?

I realize that this is what the code is doing in upstream, but it does not look correct.

Quoted 2 lines · Amir Goldstein

I can look into it, but for now the fix to fuse_sync_release() is a simple one liner, so I would rather limit the changes in this series.

Not urgent, but it might be a good idea to add a cleanup patch as a prep, which would make this patch just that one line less complex.

Quoted 2 lines

Is fuse_finish_open() supposed to be called after clearing O_TRUNC in fuse_create_open()?

This will invalidate size/modification time, which we've just updated with the correct post open values.

Quoted 2 lines

I realize that this is what the code is doing in upstream, but it does not look correct.

I think it's correct, because it deals with the effect of FUSE_OPEN/O_TRUNC on attributes that weren't refreshed in contrast to fuse_create_open() where the attributes were refreshed.

Thanks,
Miklos

I was considering splitting fuse_finish_open() to the first part that can fail and the "finally" part that deals with attributes, but seeing that this entire chunk of atomic_o_trunc code in fuse_finish_open() is never relevant to atomic_open(), I'd rather just move it out into fuse_open_common() which has loads of other code related to atomic_o_trunc anyway?

Quoted 6 lines · Amir Goldstein

I was considering splitting fuse_finish_open() to the first part that can fail and the "finally" part that deals with attributes, but seeing that this entire chunk of atomic_o_trunc code in fuse_finish_open() is never relevant to atomic_open(), I'd rather just move it out into fuse_open_common() which has loads of other code related to atomic_o_trunc anyway?

Yep.

Quoted 11 lines · Miklos Szeredi

Quoted 6 lines · Amir Goldstein

I was considering splitting fuse_finish_open() to the first part that can fail and the "finally" part that deals with attributes, but seeing that this entire chunk of atomic_o_trunc code in fuse_finish_open() is never relevant to atomic_open(), I'd rather just move it out into fuse_open_common() which has loads of other code related to atomic_o_trunc anyway?

Yep.

FWIW, I pushed some cleanups to:

https://github.com/amir73il/linux/commits/fuse_io_mode-wip/

* e71b0c0356c8 - (github/fuse_io_mode-wip) fuse: introduce inode io modes
* 081ddd63a9ff - fuse: prepare for failing open response
* 437b84a47a8a - fuse: allocate ff->release_args only if release is needed
* e2df18f9a3d6 - fuse: factor out helper fuse_truncate_update_attr()

e2df18f9a3d6 is the O_TRUNC change discussed above. 437b84a47a8a gets rid of the isdir argument to fuse_file_put(), so this one liner that you disliked is gone.

I will see if I can also get the opendir separation cleanup done.

static int fuse_dir_open(struct inode *inode, struct file *file) {

(quoted diff) +6 -1

-       return fuse_open_common(inode, file, true);
+       struct fuse_mount *fm = get_fuse_mount(inode);
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       int err;
+
+       if (fuse_is_bad(inode))
+               return -EIO;

From: Amir Goldstein <[email protected]>

In preparation for inode io modes, a server open response could fail due to conflicting inode io modes.

Allow returning an error from fuse_finish_open() and handle the error in the callers. fuse_dir_open() can now call fuse_sync_release(), so handle the isdir case correctly.

Quoted 6 lines · Bernd Schubert

From: Amir Goldstein <[email protected]>

In preparation for inode io modes, a server open response could fail due to conflicting inode io modes.

Quoted 3 lines

Allow returning an error from fuse_finish_open() and handle the error in the callers. fuse_dir_open() can now call fuse_sync_release(), so handle the isdir case correctly.

Another question: will fuse_finish_open() fail for any reason other than due to an interrupted wait?

From: Amir Goldstein <[email protected]>

The fuse inode io mode is determined by the mode of its open files/mmaps and parallel dio.

- caching io mode - files open in caching mode or mmap on direct_io file
- direct io mode - no files open in caching mode and no files mmaped
- parallel dio mode - direct io mode with parallel dio in progress

0 -> caching io

We use a new FOPEN_CACHE_IO flag to explicitly mark a file that was open in caching mode.

direct_io mmap uses page cache, so first mmap will mark the file as FOPEN_DIRECT_IO|FOPEN_CACHE_IO (i.e. mixed mode) and inode will enter the caching io mode.

If the server opens the file with flags FOPEN_DIRECT_IO|FOPEN_CACHE_IO, the inode enters caching io mode already on open.

This allows executing parallel dio when inode is not in caching mode even if shared mmap is allowed, but no mmaps have been performed on the inode in question.

An open in caching mode and mmap on direct_io file now waits for all in-progress parallel dio writes to complete, so paralle dio writes together with FUSE_DIRECT_IO_ALLOW_MMAP is enabled by this commit.

Signed-off-by Bernd Schubert <[email protected]>

Signed-off-by Amir Goldstein <[email protected]>

---
 fs/fuse/file.c            | 215 ++++++++++++++++++++++++++++++++++++--
 fs/fuse/fuse_i.h          |  79 +++++++++++++-
 include/uapi/linux/fuse.h |   2 +
 3 files changed, 286 insertions(+), 10 deletions(-)

fs/fuse/file.c +0 -0

index 7d2f4b0eb36a..eb9929ff9f60 100644

fs/fuse/file.c +20 -0

+
+/*
+ * Wait for cached io to be allowed -
+ * Blocks new parallel dio writes and waits for the in-progress parallel dio
+ * writes to complete.
+ */
+static int fuse_inode_wait_for_cached_io(struct fuse_inode *fi)
+{
+       int err = 0;
+
+       assert_spin_locked(&fi->lock);
+
+       while (!err && !fuse_inode_get_io_cache(fi)) {
+               /*
+                * Setting the bit advises new direct-io writes
+                * to use an exclusive lock - without it the wait below
+                * might be forever.
+                */
+               set_bit(FUSE_I_CACHE_IO_MODE, &fi->state);
+               spin_unlock(&fi->lock);

fs/fuse/file.c +52 -0

+
+/* Start cached io mode where parallel dio writes are not allowed */
+static int fuse_file_cached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       int err;
+
+       spin_lock(&fi->lock);
+       err = fuse_inode_wait_for_cached_io(fi);
+       spin_unlock(&fi->lock);
+       return err;
+}
+
+static void fuse_file_cached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+
+       spin_lock(&fi->lock);
+       fuse_inode_put_io_cache(get_fuse_inode(inode));
+       spin_unlock(&fi->lock);
+}
+
+/* Start strictly uncached io mode where cache access is not allowed */
+static int fuse_file_uncached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool ok;
+
+       spin_lock(&fi->lock);
+       ok = fuse_inode_deny_io_cache(fi);
+       spin_unlock(&fi->lock);
+       return ok ? 0 : -ETXTBSY;
+}
+
+static void fuse_file_uncached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool allow_cached_io;
+
+       spin_lock(&fi->lock);
+       allow_cached_io = fuse_inode_allow_io_cache(fi);
+       spin_unlock(&fi->lock);
+       if (allow_cached_io)
+               wake_up(&fi->direct_io_waitq);
+}
+
+/* Open flags to determine regular file io mode */
+#define FOPEN_IO_MODE_MASK \
+       (FOPEN_DIRECT_IO | FOPEN_CACHE_IO)
+
+/* Request access to submit new io to inode via open file */
+static int fuse_file_io_open(struct file *file, struct inode *inode)

Quoted 9 lines · Bernd Schubert

From: Amir Goldstein <[email protected]>

The fuse inode io mode is determined by the mode of its open files/mmaps and parallel dio.

- caching io mode - files open in caching mode or mmap on direct_io file
- direct io mode - no files open in caching mode and no files mmaped
- parallel dio mode - direct io mode with parallel dio in progress

Specifically if iocachectr is:

Quoted 1 line

0 -> caching io

== 0 -> direct io
< 0 -> parallel io

Quoted 1 line

Quoted 2 lines

We use a new FOPEN_CACHE_IO flag to explicitly mark a file that was open in caching mode.

This is really confusing. FOPEN_CACHE_IO is apparently an internally used flag, but it's defined on the userspace API.

a) what is the meaning of this flag on the external API?
b) what is the purpose of this flag internally?

Quoted 13 lines

direct_io mmap uses page cache, so first mmap will mark the file as FOPEN_DIRECT_IO|FOPEN_CACHE_IO (i.e. mixed mode) and inode will enter the caching io mode.

If the server opens the file with flags FOPEN_DIRECT_IO|FOPEN_CACHE_IO, the inode enters caching io mode already on open.

This allows executing parallel dio when inode is not in caching mode even if shared mmap is allowed, but no mmaps have been performed on the inode in question.

Quoted 3 lines

An open in caching mode and mmap on direct_io file now waits for all in-progress parallel dio writes to complete, so paralle dio writes together with FUSE_DIRECT_IO_ALLOW_MMAP is enabled by this commit.

I think the per file state is wrong, the above can be done with just the per-inode state.

Quoted 18 lines

Signed-off-by Bernd Schubert <[email protected]>

Signed-off-by Amir Goldstein <[email protected]>

---
 fs/fuse/file.c            | 215 ++++++++++++++++++++++++++++++++++++--
 fs/fuse/fuse_i.h          |  79 +++++++++++++-
 include/uapi/linux/fuse.h |   2 +
 3 files changed, 286 insertions(+), 10 deletions(-)

fs/fuse/file.c +0 -0

index 7d2f4b0eb36a..eb9929ff9f60 100644
@@ -105,10 +105,177 @@ static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args,
        kfree(ra);
 }
 

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 113

Quoted 6 lines

fs/fuse/file.c +6 -0

+static bool fuse_file_is_direct_io(struct file *file)
+{
+       struct fuse_file *ff = file->private_data;
+
+       return ff->open_flags & FOPEN_DIRECT_IO || file->f_flags & O_DIRECT;
+}

This is one of the issues with the per-file state. O_DIRECT can be changed with fcntl(fd, F_SETFL, ...), so state calculated at open can go stale.

Quoted 25 lines

fs/fuse/file.c +25 -0

+
+/*
+ * Wait for cached io to be allowed -
+ * Blocks new parallel dio writes and waits for the in-progress parallel dio
+ * writes to complete.
+ */
+static int fuse_inode_wait_for_cached_io(struct fuse_inode *fi)
+{
+       int err = 0;
+
+       assert_spin_locked(&fi->lock);
+
+       while (!err && !fuse_inode_get_io_cache(fi)) {
+               /*
+                * Setting the bit advises new direct-io writes
+                * to use an exclusive lock - without it the wait below
+                * might be forever.
+                */
+               set_bit(FUSE_I_CACHE_IO_MODE, &fi->state);
+               spin_unlock(&fi->lock);
+               err = wait_event_killable(fi->direct_io_waitq,
+                                         fuse_is_io_cache_allowed(fi));
+               spin_lock(&fi->lock);
+       }
+       /* Clear FUSE_I_CACHE_IO_MODE flag if failed to enter caching mode */

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 143

Quoted 5 lines

fs/fuse/file.c +5 -0

+       if (err && fi->iocachectr <= 0)
+               clear_bit(FUSE_I_CACHE_IO_MODE, &fi->state);
+
+       return err;
+}

I suggest moving all infrastructure, including the inline helpers in fuse_i.h into a separate source file.

Quoted 56 lines

fs/fuse/file.c +56 -0

+
+/* Start cached io mode where parallel dio writes are not allowed */
+static int fuse_file_cached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       int err;
+
+       spin_lock(&fi->lock);
+       err = fuse_inode_wait_for_cached_io(fi);
+       spin_unlock(&fi->lock);
+       return err;
+}
+
+static void fuse_file_cached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+
+       spin_lock(&fi->lock);
+       fuse_inode_put_io_cache(get_fuse_inode(inode));
+       spin_unlock(&fi->lock);
+}
+
+/* Start strictly uncached io mode where cache access is not allowed */
+static int fuse_file_uncached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool ok;
+
+       spin_lock(&fi->lock);
+       ok = fuse_inode_deny_io_cache(fi);
+       spin_unlock(&fi->lock);
+       return ok ? 0 : -ETXTBSY;
+}
+
+static void fuse_file_uncached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool allow_cached_io;
+
+       spin_lock(&fi->lock);
+       allow_cached_io = fuse_inode_allow_io_cache(fi);
+       spin_unlock(&fi->lock);
+       if (allow_cached_io)
+               wake_up(&fi->direct_io_waitq);
+}
+
+/* Open flags to determine regular file io mode */
+#define FOPEN_IO_MODE_MASK \
+       (FOPEN_DIRECT_IO | FOPEN_CACHE_IO)
+
+/* Request access to submit new io to inode via open file */
+static int fuse_file_io_open(struct file *file, struct inode *inode)
+{
+       struct fuse_file *ff = file->private_data;
+       int iomode_flags = ff->open_flags & FOPEN_IO_MODE_MASK;
+       int err;

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 205

Quoted 6 lines

fs/fuse/file.c +6 -0

+
+       err = -EBUSY;
+       if (WARN_ON(ff->io_opened))
+               goto fail;
+
+       if (!S_ISREG(inode->i_mode) || FUSE_IS_DAX(inode)) {

This S_ISREG check can also go away with separating the directory opens.

Quoted 19 lines · Miklos Szeredi

Quoted 9 lines · Bernd Schubert

From: Amir Goldstein <[email protected]>

The fuse inode io mode is determined by the mode of its open files/mmaps and parallel dio.

- caching io mode - files open in caching mode or mmap on direct_io file
- direct io mode - no files open in caching mode and no files mmaped
- parallel dio mode - direct io mode with parallel dio in progress

Specifically if iocachectr is:

Quoted 1 line

0 -> caching io

== 0 -> direct io
< 0 -> parallel io

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

We use a new FOPEN_CACHE_IO flag to explicitly mark a file that was open in caching mode.

This is really confusing. FOPEN_CACHE_IO is apparently an internally used flag, but it's defined on the userspace API.

a) what is the meaning of this flag on the external API?
b) what is the purpose of this flag internally?

The purpose is to annotate the state of direct io file that was mmaped as FOPEN_DIRECT_IO | FOPEN_CACHE_IO.
An fd like this puts inode in caching mode and its release may get inode out of caching mode.

I did not manage to do refcoutning with fuse_vma_close(), because those calls are not balances with fuse_file_mmap() calls.

The first mmap() of an FOPEN_DIRECT_IO file may incur wait for completion of parallel dio.

The only use of exporting FOPEN_CACHE_IO to the server is that it could force incurring this wait at open() time instead of mmap() time.

I also considered for servers that advertise FUSE_PASSTHROUGH capability to not allow open without specifying an explicit io mode, that is one of FOPEN_DIRECT_IO | FOPEN_CACHE_IO | FOPEN_PASSTHROUGH, but I did not actually implement those semantics ATM.

Quoted 13 lines

Quoted 13 lines

direct_io mmap uses page cache, so first mmap will mark the file as FOPEN_DIRECT_IO|FOPEN_CACHE_IO (i.e. mixed mode) and inode will enter the caching io mode.

If the server opens the file with flags FOPEN_DIRECT_IO|FOPEN_CACHE_IO, the inode enters caching io mode already on open.

This allows executing parallel dio when inode is not in caching mode even if shared mmap is allowed, but no mmaps have been performed on the inode in question.

Quoted 7 lines

Quoted 3 lines

An open in caching mode and mmap on direct_io file now waits for all in-progress parallel dio writes to complete, so paralle dio writes together with FUSE_DIRECT_IO_ALLOW_MMAP is enabled by this commit.

I think the per file state is wrong, the above can be done with just the per-inode state.

The per-file state is to taint the file is "has been mmaped". I did not find another way of doing this.
Please suggest another way.

Quoted 18 lines

Quoted 18 lines

Signed-off-by Bernd Schubert <[email protected]>

Signed-off-by Amir Goldstein <[email protected]>

---
  fs/fuse/file.c            | 215 ++++++++++++++++++++++++++++++++++++--
  fs/fuse/fuse_i.h          |  79 +++++++++++++-
  include/uapi/linux/fuse.h |   2 +
  3 files changed, 286 insertions(+), 10 deletions(-)

fs/fuse/file.c +0 -0

index 7d2f4b0eb36a..eb9929ff9f60 100644
@@ -105,10 +105,177 @@ static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args,
         kfree(ra);
  }
 

Quoted 11 lines

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 113

Quoted 6 lines

fs/fuse/file.c +6 -0

+static bool fuse_file_is_direct_io(struct file *file)
+{
+       struct fuse_file *ff = file->private_data;
+
+       return ff->open_flags & FOPEN_DIRECT_IO || file->f_flags & O_DIRECT;
+}

This is one of the issues with the per-file state. O_DIRECT can be changed with fcntl(fd, F_SETFL, ...), so state calculated at open can go stale.

Ouch!
Actually, it may not matter much if we just ignore O_DIRECT completely for the purpose of io modes.

The io mode could be determined solely from FMODE_* flags.

Worst case is that if the server opens an O_DIRECT file without FOPEN_DIRECT_IO, then this inode cannot do parallel dio and this inode cannot be opened in passthrough mode. I don't think that is such a big problem.

Bernd, what do you think?

BTW, server can and probably should open O_DIRECT files with FOPEN_PASSTHROUGH and that means something completely different than O_DIRECT && FOPEN_DIRECT_IO - it means that io is passed through to the backing file without doing buffered io on the backing file.

Quoted 25 lines

Quoted 25 lines

fs/fuse/file.c +25 -0

+
+/*
+ * Wait for cached io to be allowed -
+ * Blocks new parallel dio writes and waits for the in-progress parallel dio
+ * writes to complete.
+ */
+static int fuse_inode_wait_for_cached_io(struct fuse_inode *fi)
+{
+       int err = 0;
+
+       assert_spin_locked(&fi->lock);
+
+       while (!err && !fuse_inode_get_io_cache(fi)) {
+               /*
+                * Setting the bit advises new direct-io writes
+                * to use an exclusive lock - without it the wait below
+                * might be forever.
+                */
+               set_bit(FUSE_I_CACHE_IO_MODE, &fi->state);
+               spin_unlock(&fi->lock);
+               err = wait_event_killable(fi->direct_io_waitq,
+                                         fuse_is_io_cache_allowed(fi));
+               spin_lock(&fi->lock);
+       }
+       /* Clear FUSE_I_CACHE_IO_MODE flag if failed to enter caching mode */

Quoted 9 lines

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 143

Quoted 5 lines

fs/fuse/file.c +5 -0

+       if (err && fi->iocachectr <= 0)
+               clear_bit(FUSE_I_CACHE_IO_MODE, &fi->state);
+
+       return err;
+}

I suggest moving all infrastructure, including the inline helpers in fuse_i.h into a separate source file.

OK. I can make those changes.

Quoted 56 lines

Quoted 56 lines

fs/fuse/file.c +56 -0

+
+/* Start cached io mode where parallel dio writes are not allowed */
+static int fuse_file_cached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       int err;
+
+       spin_lock(&fi->lock);
+       err = fuse_inode_wait_for_cached_io(fi);
+       spin_unlock(&fi->lock);
+       return err;
+}
+
+static void fuse_file_cached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+
+       spin_lock(&fi->lock);
+       fuse_inode_put_io_cache(get_fuse_inode(inode));
+       spin_unlock(&fi->lock);
+}
+
+/* Start strictly uncached io mode where cache access is not allowed */
+static int fuse_file_uncached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool ok;
+
+       spin_lock(&fi->lock);
+       ok = fuse_inode_deny_io_cache(fi);
+       spin_unlock(&fi->lock);
+       return ok ? 0 : -ETXTBSY;
+}
+
+static void fuse_file_uncached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool allow_cached_io;
+
+       spin_lock(&fi->lock);
+       allow_cached_io = fuse_inode_allow_io_cache(fi);
+       spin_unlock(&fi->lock);
+       if (allow_cached_io)
+               wake_up(&fi->direct_io_waitq);
+}
+
+/* Open flags to determine regular file io mode */
+#define FOPEN_IO_MODE_MASK \
+       (FOPEN_DIRECT_IO | FOPEN_CACHE_IO)
+
+/* Request access to submit new io to inode via open file */
+static int fuse_file_io_open(struct file *file, struct inode *inode)
+{
+       struct fuse_file *ff = file->private_data;
+       int iomode_flags = ff->open_flags & FOPEN_IO_MODE_MASK;
+       int err;

Quoted 8 lines

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 205

Quoted 6 lines

fs/fuse/file.c +6 -0

+
+       err = -EBUSY;
+       if (WARN_ON(ff->io_opened))
+               goto fail;
+
+       if (!S_ISREG(inode->i_mode) || FUSE_IS_DAX(inode)) {

This S_ISREG check can also go away with separating the directory opens.

OK. I will see if I can make that cleanup as well.

Quoted 104 lines · Amir Goldstein

Quoted 19 lines · Miklos Szeredi

Quoted 9 lines · Bernd Schubert

From: Amir Goldstein <[email protected]>

The fuse inode io mode is determined by the mode of its open files/mmaps and parallel dio.

- caching io mode - files open in caching mode or mmap on direct_io file
- direct io mode - no files open in caching mode and no files mmaped
- parallel dio mode - direct io mode with parallel dio in progress

Specifically if iocachectr is:

Quoted 1 line

0 -> caching io

== 0 -> direct io
< 0 -> parallel io

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

We use a new FOPEN_CACHE_IO flag to explicitly mark a file that was open in caching mode.

This is really confusing. FOPEN_CACHE_IO is apparently an internally used flag, but it's defined on the userspace API.

a) what is the meaning of this flag on the external API?
b) what is the purpose of this flag internally?

The purpose is to annotate the state of direct io file that was mmaped as FOPEN_DIRECT_IO | FOPEN_CACHE_IO.
An fd like this puts inode in caching mode and its release may get inode out of caching mode.

I did not manage to do refcoutning with fuse_vma_close(), because those calls are not balances with fuse_file_mmap() calls.

The first mmap() of an FOPEN_DIRECT_IO file may incur wait for completion of parallel dio.

The only use of exporting FOPEN_CACHE_IO to the server is that it could force incurring this wait at open() time instead of mmap() time.

I also considered for servers that advertise FUSE_PASSTHROUGH capability to not allow open without specifying an explicit io mode, that is one of FOPEN_DIRECT_IO | FOPEN_CACHE_IO | FOPEN_PASSTHROUGH, but I did not actually implement those semantics ATM.

Quoted 13 lines

Quoted 13 lines

direct_io mmap uses page cache, so first mmap will mark the file as FOPEN_DIRECT_IO|FOPEN_CACHE_IO (i.e. mixed mode) and inode will enter the caching io mode.

If the server opens the file with flags FOPEN_DIRECT_IO|FOPEN_CACHE_IO, the inode enters caching io mode already on open.

This allows executing parallel dio when inode is not in caching mode even if shared mmap is allowed, but no mmaps have been performed on the inode in question.

Quoted 7 lines

Quoted 3 lines

An open in caching mode and mmap on direct_io file now waits for all in-progress parallel dio writes to complete, so paralle dio writes together with FUSE_DIRECT_IO_ALLOW_MMAP is enabled by this commit.

I think the per file state is wrong, the above can be done with just the per-inode state.

The per-file state is to taint the file is "has been mmaped". I did not find another way of doing this.
Please suggest another way.

Quoted 18 lines

Quoted 18 lines

Signed-off-by Bernd Schubert <[email protected]>

Signed-off-by Amir Goldstein <[email protected]>

---
  fs/fuse/file.c            | 215 ++++++++++++++++++++++++++++++++++++--
  fs/fuse/fuse_i.h          |  79 +++++++++++++-
  include/uapi/linux/fuse.h |   2 +
  3 files changed, 286 insertions(+), 10 deletions(-)

fs/fuse/file.c +0 -0

index 7d2f4b0eb36a..eb9929ff9f60 100644
@@ -105,10 +105,177 @@ static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args,
         kfree(ra);
  }
 

Quoted 11 lines

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 113

Quoted 6 lines

fs/fuse/file.c +6 -0

+static bool fuse_file_is_direct_io(struct file *file)
+{
+       struct fuse_file *ff = file->private_data;
+
+       return ff->open_flags & FOPEN_DIRECT_IO || file->f_flags & O_DIRECT;
+}

This is one of the issues with the per-file state. O_DIRECT can be changed with fcntl(fd, F_SETFL, ...), so state calculated at open can go stale.

Quoted 3 lines

Ouch!
Actually, it may not matter much if we just ignore O_DIRECT completely for the purpose of io modes.

I had also missed that fcntl option :/

Quoted 8 lines

The io mode could be determined solely from FMODE_* flags.

Worst case is that if the server opens an O_DIRECT file without FOPEN_DIRECT_IO, then this inode cannot do parallel dio and this inode cannot be opened in passthrough mode. I don't think that is such a big problem.

Quoted 1 line

Bernd, what do you think?

Yeah, currently FOPEN_PARALLEL_DIRECT_WRITES does not have an effect without FOPEN_DIRECT_IO. In my fuse-dio consolidation branch that changes. For me it is ok that parallel dio requires FOPEN_DIRECT_IO, easy enough to set on the server side in open methods when O_DIRECT is set. We should just document it in fuse.h.

Quoted 42 lines

BTW, server can and probably should open O_DIRECT files with FOPEN_PASSTHROUGH and that means something completely different than O_DIRECT && FOPEN_DIRECT_IO - it means that io is passed through to the backing file without doing buffered io on the backing file.

Quoted 34 lines

Quoted 20 lines

fs/fuse/file.c +20 -0

+
+/*
+ * Wait for cached io to be allowed -
+ * Blocks new parallel dio writes and waits for the in-progress parallel dio
+ * writes to complete.
+ */
+static int fuse_inode_wait_for_cached_io(struct fuse_inode *fi)
+{
+       int err = 0;
+
+       assert_spin_locked(&fi->lock);
+
+       while (!err && !fuse_inode_get_io_cache(fi)) {
+               /*
+                * Setting the bit advises new direct-io writes
+                * to use an exclusive lock - without it the wait below
+                * might be forever.
+                */
+               set_bit(FUSE_I_CACHE_IO_MODE, &fi->state);
+               spin_unlock(&fi->lock);

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 143

Quoted 10 lines

fs/fuse/file.c +10 -0

+               err = wait_event_killable(fi->direct_io_waitq,
+                                         fuse_is_io_cache_allowed(fi));
+               spin_lock(&fi->lock);
+       }
+       /* Clear FUSE_I_CACHE_IO_MODE flag if failed to enter caching mode */
+       if (err && fi->iocachectr <= 0)
+               clear_bit(FUSE_I_CACHE_IO_MODE, &fi->state);
+
+       return err;
+}

I suggest moving all infrastructure, including the inline helpers in fuse_i.h into a separate source file.

Quoted 2 lines

OK. I can make those changes.

Quoted 65 lines

Quoted 64 lines

Quoted 52 lines

fs/fuse/file.c +52 -0

+
+/* Start cached io mode where parallel dio writes are not allowed */
+static int fuse_file_cached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       int err;
+
+       spin_lock(&fi->lock);
+       err = fuse_inode_wait_for_cached_io(fi);
+       spin_unlock(&fi->lock);
+       return err;
+}
+
+static void fuse_file_cached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+
+       spin_lock(&fi->lock);
+       fuse_inode_put_io_cache(get_fuse_inode(inode));
+       spin_unlock(&fi->lock);
+}
+
+/* Start strictly uncached io mode where cache access is not allowed */
+static int fuse_file_uncached_io_start(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool ok;
+
+       spin_lock(&fi->lock);
+       ok = fuse_inode_deny_io_cache(fi);
+       spin_unlock(&fi->lock);
+       return ok ? 0 : -ETXTBSY;
+}
+
+static void fuse_file_uncached_io_end(struct inode *inode)
+{
+       struct fuse_inode *fi = get_fuse_inode(inode);
+       bool allow_cached_io;
+
+       spin_lock(&fi->lock);
+       allow_cached_io = fuse_inode_allow_io_cache(fi);
+       spin_unlock(&fi->lock);
+       if (allow_cached_io)
+               wake_up(&fi->direct_io_waitq);
+}
+
+/* Open flags to determine regular file io mode */
+#define FOPEN_IO_MODE_MASK \
+       (FOPEN_DIRECT_IO | FOPEN_CACHE_IO)
+
+/* Request access to submit new io to inode via open file */
+static int fuse_file_io_open(struct file *file, struct inode *inode)

fs/fuse/file.c static void fuse_release_end(struct fuse_mount *fm, struct fuse_args *args, · line 205

Quoted 10 lines

fs/fuse/file.c +10 -0

+{
+       struct fuse_file *ff = file->private_data;
+       int iomode_flags = ff->open_flags & FOPEN_IO_MODE_MASK;
+       int err;
+
+       err = -EBUSY;
+       if (WARN_ON(ff->io_opened))
+               goto fail;
+
+       if (!S_ISREG(inode->i_mode) || FUSE_IS_DAX(inode)) {

This S_ISREG check can also go away with separating the directory opens.

Quoted 1 line

OK. I will see if I can make that cleanup as well.

Quoted 19 lines · Miklos Szeredi

Quoted 9 lines · Bernd Schubert

From: Amir Goldstein <[email protected]>

The fuse inode io mode is determined by the mode of its open files/mmaps and parallel dio.

- caching io mode - files open in caching mode or mmap on direct_io file
- direct io mode - no files open in caching mode and no files mmaped
- parallel dio mode - direct io mode with parallel dio in progress

Specifically if iocachectr is:

Quoted 1 line

0 -> caching io

== 0 -> direct io
< 0 -> parallel io

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

We use a new FOPEN_CACHE_IO flag to explicitly mark a file that was open in caching mode.

This is really confusing. FOPEN_CACHE_IO is apparently an internally used flag, but it's defined on the userspace API.

a) what is the meaning of this flag on the external API?
b) what is the purpose of this flag internally?

The purpose is to annotate the state of direct io file that was mmaped as FOPEN_DIRECT_IO | FOPEN_CACHE_IO.
An fd like this puts inode in caching mode and its release may get inode out of caching mode.

I did not manage to do refcoutning with fuse_vma_close(), because those calls are not balances with fuse_file_mmap() calls.

The first mmap() of an FOPEN_DIRECT_IO file may incur wait for completion of parallel dio.

The only use of exporting FOPEN_CACHE_IO to the server is that it could force incurring this wait at open() time instead of mmap() time.

I have played with this rebranding of
FOPEN_CACHE_IO => FOPEN_NO_PARALLEL_DIO_WRITES

The meaning of the rebranded flag is:
Prevent parallel dio on inode for as long as this file is kept open.

The io modes code sets this flag implicitly on the first shared mmap.

Let me know if this makes the external flag easier to swallow. Of course I can make this flag internal and not and FOPEN_ flag at all, but IMO, the code is easier to understand when the type of iocachectl refcount held by any file is specified by its FOPEN_ flags.

Quoted 6 lines · Amir Goldstein

I have played with this rebranding of
FOPEN_CACHE_IO => FOPEN_NO_PARALLEL_DIO_WRITES

The meaning of the rebranded flag is:
Prevent parallel dio on inode for as long as this file is kept open.

Quoted 6 lines

The io modes code sets this flag implicitly on the first shared mmap.

Let me know if this makes the external flag easier to swallow. Of course I can make this flag internal and not and FOPEN_ flag at all, but IMO, the code is easier to understand when the type of iocachectl refcount held by any file is specified by its FOPEN_ flags.

If there's no clear use case that would benefit from having this flag on the userspace interface, then I'd recommend not to export it for now.

I understand the need for clarifying the various states that the kernel can be, but I think that's a bigger project involving e.g. data and metadata cache validity, where the current rules are pretty convoluted.

So for now I'd just stick with the implicit state change by mmap.

BTW, I started looking at the fuse-backing-fd branch and really hope we can get this into shape for the next merge window.

This series is mostly about mmap, direct-IO and inode IO modes. (new in this series is FOPEN_CACHE_IO).
It brings back the shared lock for FOPEN_DIRECT_IO when FUSE_DIRECT_IO_ALLOW_MMAP is set and is also preparation work for Amirs work on fuse-passthrough and also for

shared lock O_DIRECT and direct-IO code consolidation I have patches for.

Patch 1/5 was already posted before
https://patchwork.kernel.org/project/linux-fsdevel/patch/[email protected]/
but is included here again, as especially patch 5/5 has a dependency on it. Amir has also spotted a typo in the commit message of the initial patch, which is corrected here.

Patches 2/5 and 3/5 add helper functions, which are needed by the main patch (5/5) in this series and are be also needed by another fuse direct-IO series. That series needs the helper functions in fuse_cache_write_iter, thus, these new helpers are above that function.

Patch 4/5 allows to fail fuse_finish_open and is a preparation to handle conflicting IO modes from the server side and will also be needed for fuse passthrough.

Patch 5/5 is the main patch in the series, which adds inode IO modes, which is needed to re-enable shared DIO writes locks when FUSE_DIRECT_IO_ALLOW_MMAP is set. Furthermore, these IO modes are also needed by Amirs WIP fuse passthrough work.

The conflict of FUSE_DIRECT_IO_ALLOW_MMAP and FOPEN_PARALLEL_DIRECT_WRITES was detected by xfstest generic/095. This patch series was tested by running a loop of that test and also by multiple runs of the complete xfstest suite. For testing with libfuse a version is needed that includes this pull request
https://github.com/libfuse/libfuse/pull/870

Quoted 6 lines · Bernd Schubert

This series is mostly about mmap, direct-IO and inode IO modes. (new in this series is FOPEN_CACHE_IO).
It brings back the shared lock for FOPEN_DIRECT_IO when FUSE_DIRECT_IO_ALLOW_MMAP is set and is also preparation work for Amirs work on fuse-passthrough and also for

For the interested:
https://github.com/amir73il/linux/commits/fuse-backing-fd-010224/

Bernd,

Can you push this series to your v2 branch so that I can rebase my branch on top of it?

Quoted 25 lines

shared lock O_DIRECT and direct-IO code consolidation I have patches for.

Patch 1/5 was already posted before
https://patchwork.kernel.org/project/linux-fsdevel/patch/[email protected]/
but is included here again, as especially patch 5/5 has a dependency on it. Amir has also spotted a typo in the commit message of the initial patch, which is corrected here.

Patches 2/5 and 3/5 add helper functions, which are needed by the main patch (5/5) in this series and are be also needed by another fuse direct-IO series. That series needs the helper functions in fuse_cache_write_iter, thus, these new helpers are above that function.

Patch 4/5 allows to fail fuse_finish_open and is a preparation to handle conflicting IO modes from the server side and will also be needed for fuse passthrough.

Patch 5/5 is the main patch in the series, which adds inode IO modes, which is needed to re-enable shared DIO writes locks when FUSE_DIRECT_IO_ALLOW_MMAP is set. Furthermore, these IO modes are also needed by Amirs WIP fuse passthrough work.

Quoted 7 lines

The conflict of FUSE_DIRECT_IO_ALLOW_MMAP and FOPEN_PARALLEL_DIRECT_WRITES was detected by xfstest generic/095. This patch series was tested by running a loop of that test and also by multiple runs of the complete xfstest suite. For testing with libfuse a version is needed that includes this pull request
https://github.com/libfuse/libfuse/pull/870

Heh, this is already merged :)

For the record, I understand that you ran this test with passthrough_hp. In which configurations --direct-io? --nocache? only default?

Thanks for pushing this through!

Hi Amir,

sorry for a bit late reply (*).

Quoted 11 lines · Amir Goldstein

Quoted 6 lines · Bernd Schubert

This series is mostly about mmap, direct-IO and inode IO modes. (new in this series is FOPEN_CACHE_IO).
It brings back the shared lock for FOPEN_DIRECT_IO when FUSE_DIRECT_IO_ALLOW_MMAP is set and is also preparation work for Amirs work on fuse-passthrough and also for

For the interested:
https://github.com/amir73il/linux/commits/fuse-backing-fd-010224/

Quoted 4 lines

Bernd,

Can you push this series to your v2 branch so that I can rebase my branch on top of it?

Do you mind if I push this to a different branch to keep the branch clean?

Quoted 19 lines · Bernd Schubert

Hi Amir,

sorry for a bit late reply (*).

Quoted 13 lines · Amir Goldstein

Quoted 6 lines · Bernd Schubert

This series is mostly about mmap, direct-IO and inode IO modes. (new in this series is FOPEN_CACHE_IO).
It brings back the shared lock for FOPEN_DIRECT_IO when FUSE_DIRECT_IO_ALLOW_MMAP is set and is also preparation work for Amirs work on fuse-passthrough and also for

For the interested:
https://github.com/amir73il/linux/commits/fuse-backing-fd-010224/

Bernd,

Quoted 5 lines

Quoted 2 lines

Can you push this series to your v2 branch so that I can rebase my branch on top of it?

Do you mind if I push this to a different branch to keep the branch clean?

I don't mind, I just thought that it would be nice if the branch fuse_io_mode-v2 actually contained the patches that were posted as V2 to the mailing list...