All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>,
	linux-fsdevel@vger.kernel.org, Bernd Schubert <bschubert@ddn.com>
Subject: [PATCH v3 2/9] fuse: Create helper function if DIO write needs exclusive lock
Date: Thu,  8 Feb 2024 19:05:56 +0200	[thread overview]
Message-ID: <20240208170603.2078871-3-amir73il@gmail.com> (raw)
In-Reply-To: <20240208170603.2078871-1-amir73il@gmail.com>

From: Bernd Schubert <bschubert@ddn.com>

This makes the code a bit easier to read and allows to more
easily add more conditions when an exclusive lock is needed.

Signed-off-by: Bernd Schubert <bschubert@ddn.com>
---
 fs/fuse/file.c | 64 +++++++++++++++++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 19 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 243f469cac07..a64ee1392c77 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1299,6 +1299,45 @@ static ssize_t fuse_perform_write(struct kiocb *iocb, struct iov_iter *ii)
 	return res;
 }
 
+static bool fuse_io_past_eof(struct kiocb *iocb, struct iov_iter *iter)
+{
+	struct inode *inode = file_inode(iocb->ki_filp);
+
+	return iocb->ki_pos + iov_iter_count(iter) > i_size_read(inode);
+}
+
+/*
+ * @return true if an exclusive lock for direct IO writes is needed
+ */
+static bool fuse_dio_wr_exclusive_lock(struct kiocb *iocb, struct iov_iter *from)
+{
+	struct file *file = iocb->ki_filp;
+	struct fuse_file *ff = file->private_data;
+	struct inode *inode = file_inode(iocb->ki_filp);
+
+	/* server side has to advise that it supports parallel dio writes */
+	if (!(ff->open_flags & FOPEN_PARALLEL_DIRECT_WRITES))
+		return true;
+
+	/* append will need to know the eventual eof - always needs an
+	 * exclusive lock
+	 */
+	if (iocb->ki_flags & IOCB_APPEND)
+		return true;
+
+	/* combination opf page access and direct-io difficult, shared
+	 * locks actually introduce a conflict.
+	 */
+	if (get_fuse_conn(inode)->direct_io_allow_mmap)
+		return true;
+
+	/* parallel dio beyond eof is at least for now not supported */
+	if (fuse_io_past_eof(iocb, from))
+		return true;
+
+	return false;
+}
+
 static ssize_t fuse_cache_write_iter(struct kiocb *iocb, struct iov_iter *from)
 {
 	struct file *file = iocb->ki_filp;
@@ -1558,26 +1597,12 @@ static ssize_t fuse_direct_read_iter(struct kiocb *iocb, struct iov_iter *to)
 	return res;
 }
 
-static bool fuse_direct_write_extending_i_size(struct kiocb *iocb,
-					       struct iov_iter *iter)
-{
-	struct inode *inode = file_inode(iocb->ki_filp);
-
-	return iocb->ki_pos + iov_iter_count(iter) > i_size_read(inode);
-}
-
 static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from)
 {
 	struct inode *inode = file_inode(iocb->ki_filp);
-	struct file *file = iocb->ki_filp;
-	struct fuse_file *ff = file->private_data;
 	struct fuse_io_priv io = FUSE_IO_PRIV_SYNC(iocb);
 	ssize_t res;
-	bool exclusive_lock =
-		!(ff->open_flags & FOPEN_PARALLEL_DIRECT_WRITES) ||
-		get_fuse_conn(inode)->direct_io_allow_mmap ||
-		iocb->ki_flags & IOCB_APPEND ||
-		fuse_direct_write_extending_i_size(iocb, from);
+	bool exclusive_lock = fuse_dio_wr_exclusive_lock(iocb, from);
 
 	/*
 	 * Take exclusive lock if
@@ -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_io_past_eof(iocb, from)) {
 			inode_unlock_shared(inode);
 			inode_lock(inode);
 			exclusive_lock = true;
@@ -2468,7 +2493,8 @@ static int fuse_file_mmap(struct file *file, struct vm_area_struct *vma)
 		return fuse_dax_mmap(file, vma);
 
 	if (ff->open_flags & FOPEN_DIRECT_IO) {
-		/* Can't provide the coherency needed for MAP_SHARED
+		/*
+		 * Can't provide the coherency needed for MAP_SHARED
 		 * if FUSE_DIRECT_IO_ALLOW_MMAP isn't set.
 		 */
 		if ((vma->vm_flags & VM_MAYSHARE) && !fc->direct_io_allow_mmap)
-- 
2.34.1


  parent reply	other threads:[~2024-02-08 17:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 17:05 [PATCH v3 0/9] fuse: inode IO modes and mmap + parallel dio Amir Goldstein
2024-02-08 17:05 ` [PATCH v3 1/9] fuse: Fix VM_MAYSHARE and direct_io_allow_mmap Amir Goldstein
2024-02-08 17:05 ` Amir Goldstein [this message]
2024-02-09  9:50   ` [PATCH v3 2/9] fuse: Create helper function if DIO write needs exclusive lock Miklos Szeredi
2024-02-08 17:05 ` [PATCH v3 3/9] fuse: Add fuse_dio_lock/unlock helper functions Amir Goldstein
2024-02-08 17:05 ` [PATCH v3 4/9] fuse: factor out helper fuse_truncate_update_attr() Amir Goldstein
2024-02-08 17:05 ` [PATCH v3 5/9] fuse: allocate ff->release_args only if release is needed Amir Goldstein
2024-02-09  9:57   ` Miklos Szeredi
2024-02-09 11:26     ` Bernd Schubert
2024-02-08 17:06 ` [PATCH v3 6/9] fuse: break up fuse_open_common() Amir Goldstein
2024-02-09  9:59   ` Miklos Szeredi
2024-02-08 17:06 ` [PATCH v3 7/9] fuse: prepare for failing open response Amir Goldstein
2024-02-08 17:06 ` [PATCH v3 8/9] fuse: introduce inode io modes Amir Goldstein
2024-02-09 10:21   ` Miklos Szeredi
2024-02-09 10:35     ` Amir Goldstein
2024-02-09 10:56       ` Miklos Szeredi
2024-02-09 11:50         ` Amir Goldstein
2024-02-08 17:06 ` [PATCH v3 9/9] fuse: allow parallel dio writes with FUSE_DIRECT_IO_ALLOW_MMAP Amir Goldstein
2024-02-09 10:50   ` Miklos Szeredi
2024-02-09 11:21     ` Bernd Schubert
2024-02-09 11:48       ` Bernd Schubert
2024-02-09 12:12         ` Amir Goldstein
2024-02-09 12:19           ` Amir Goldstein
2024-02-09 12:19           ` Bernd Schubert
2024-02-09 13:26           ` Miklos Szeredi
2024-02-09 15:28             ` Amir Goldstein
2024-03-17 13:54               ` Amir Goldstein
2024-03-17 19:31                 ` Miklos Szeredi
2024-03-17 20:00                   ` Amir Goldstein
2024-03-17 20:02                     ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240208170603.2078871-3-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=bschubert@ddn.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.