From: Christoph Hellwig <h...@infradead.org>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 1f90ee27461e31a1c18e5d819f6ea6f5c7304b16 upstream.
i_dio_count is used to protect dio access against truncate. We want
to make sure there are no dio reads pending either when doing a
truncate. I suspect on plain NFS things might work even without
this, but once we use a pnfs layout driver that access backing devices
directly things will go bad without the proper synchronization.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Signed-off-by: Trond Myklebust <trond.mykleb...@primarydata.com>
Signed-off-by: Jiri Slaby <jsl...@suse.cz>
---
fs/nfs/direct.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 2adc0094cde8..af5f3ffcb157 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -236,10 +236,10 @@ static void nfs_direct_complete(struct nfs_direct_req
*dreq, bool write)
spin_unlock(&inode->i_lock);
}
- if (write) {
+ if (write)
nfs_zap_mapping(inode, inode->i_mapping);
- inode_dio_done(inode);
- }
+
+ inode_dio_done(inode);
if (dreq->iocb) {
long res = (long) dreq->error;
@@ -420,6 +420,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct
nfs_direct_req *dreq,
loff_t pos, bool uio)
{
struct nfs_pageio_descriptor desc;
+ struct inode *inode = dreq->inode;
ssize_t result = -EINVAL;
size_t requested_bytes = 0;
unsigned long seg;
@@ -428,6 +429,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct
nfs_direct_req *dreq,
&nfs_direct_read_completion_ops);
get_dreq(dreq);
desc.pg_dreq = dreq;
+ atomic_inc(&inode->i_dio_count);
for (seg = 0; seg < nr_segs; seg++) {
const struct iovec *vec = &iov[seg];
@@ -447,6 +449,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct
nfs_direct_req *dreq,
* generic layer handle the completion.
*/
if (requested_bytes == 0) {
+ inode_dio_done(inode);
nfs_direct_req_release(dreq);
return result < 0 ? result : -EIO;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
