All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Brandenburg <martin@omnibond.com>
To: hubcap@omnibond.com, devel@lists.orangefs.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Martin Brandenburg <martin@omnibond.com>
Subject: [PATCH 14/18] orangefs: implement direct_IO for the read case
Date: Tue, 12 Dec 2017 13:34:20 -0500	[thread overview]
Message-ID: <20171212183424.26406-15-martin@martinbrandenburg.com> (raw)
In-Reply-To: <20171212183424.26406-1-martin@martinbrandenburg.com>

From: Martin Brandenburg <martin@omnibond.com>

Since orangefs_file_read_iter now calls generic_file_read_iter, O_DIRECT
now goes through direct_IO in the read case.  In the write case,
orangefs_file_write_iter never calls direct_IO, but handles the direct
write manually.

Signed-off-by: Martin Brandenburg <martin@omnibond.com>
---
 fs/orangefs/file.c | 21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c
index 1c30e9abb8cb..0223a0351d11 100644
--- a/fs/orangefs/file.c
+++ b/fs/orangefs/file.c
@@ -787,22 +787,17 @@ static int orangefs_releasepage(struct page *page, gfp_t foo)
 	return 0;
 }
 
-/*
- * Having a direct_IO entry point in the address_space_operations
- * struct causes the kernel to allows us to use O_DIRECT on
- * open. Nothing will ever call this thing, but in the future we
- * will need to be able to use O_DIRECT on open in order to support
- * AIO. Modeled after NFS, they do this too.
- */
-
 static ssize_t orangefs_direct_IO(struct kiocb *iocb,
 				  struct iov_iter *iter)
 {
-	gossip_debug(GOSSIP_INODE_DEBUG,
-		     "orangefs_direct_IO: %pD\n",
-		     iocb->ki_filp);
-
-	return -EINVAL;
+	struct file *file = iocb->ki_filp;
+	loff_t pos = *(&iocb->ki_pos);
+	/*
+	 * This cannot happen until write_iter becomes
+	 * generic_file_write_iter.
+	 */
+	BUG_ON(iov_iter_rw(iter) != READ);
+	return do_readv_writev(ORANGEFS_IO_READ, file, &pos, iter);
 }
 
 /** ORANGEFS2 implementation of address space operations */
-- 
2.15.1

  parent reply	other threads:[~2017-12-12 18:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 18:34 [PATCH 00/18] orangefs: page cache Martin Brandenburg
2017-12-12 18:34 ` [PATCH 01/18] orangefs: open code short single-use functions Martin Brandenburg
2017-12-12 18:34 ` [PATCH 02/18] orangefs: implement vm_ops->fault Martin Brandenburg
2017-12-12 18:34 ` [PATCH 03/18] orangefs: do not invalidate attributes on inode create Martin Brandenburg
2017-12-12 18:34 ` [PATCH 04/18] orangefs: do not invalidate attribute cache on setattr Martin Brandenburg
2017-12-12 18:34 ` [PATCH 05/18] orangefs: reverse sense of revalidate is-inode-stale test Martin Brandenburg
2017-12-12 18:34 ` [PATCH 06/18] orangefs: move orangefs_address_operations to file.c Martin Brandenburg
2017-12-12 18:34 ` [PATCH 07/18] orangefs: remove orangefs_readpages Martin Brandenburg
2017-12-12 18:34 ` [PATCH 08/18] orangefs: make orangefs_inode_read static Martin Brandenburg
2017-12-12 18:34 ` [PATCH 09/18] orangefs: only set a_ops for regular files Martin Brandenburg
2017-12-12 18:34 ` [PATCH 10/18] orangefs: BUG_ON if i_mode invalid Martin Brandenburg
2017-12-12 18:34 ` [PATCH 11/18] orangefs: remove mapping_nrpages macro Martin Brandenburg
2017-12-12 18:34 ` [PATCH 12/18] orangefs: set up and use backing_dev_info Martin Brandenburg
2017-12-12 18:34 ` [PATCH 13/18] orangefs: inodes linger in cache Martin Brandenburg
2017-12-12 18:34 ` Martin Brandenburg [this message]
2017-12-12 18:34 ` [PATCH 15/18] orangefs: call generic_file_read_iter Martin Brandenburg
2017-12-12 18:34 ` [PATCH 16/18] orangefs: implement write through the page cache Martin Brandenburg
2017-12-12 18:34 ` [PATCH 17/18] orangefs: no more explicit setattr Martin Brandenburg
2017-12-12 18:34 ` [PATCH 18/18] orangefs: implement xattr cache Martin Brandenburg

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=20171212183424.26406-15-martin@martinbrandenburg.com \
    --to=martin@omnibond.com \
    --cc=devel@lists.orangefs.org \
    --cc=hubcap@omnibond.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.