[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20111207160822.706775702@clark.kroah.org>
Date: Wed, 07 Dec 2011 08:06:21 -0800
From: Greg KH <gregkh@...e.de>
To: <linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>
Cc: <torvalds@...ux-foundation.org>, <akpm@...ux-foundation.org>,
<alan@...rguk.ukuu.org.uk>, Tyler Hicks <tyhicks@...onical.com>
Subject: [01/80] eCryptfs: Flush file in vma close
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Hicks <tyhicks@...onical.com>
commit 32001d6fe9ac6b0423e674a3093aa56740849f3b upstream.
Dirty pages weren't being written back when an mmap'ed eCryptfs file was
closed before the mapping was unmapped. Since f_ops->flush() is not
called by the munmap() path, the lower file was simply being released.
This patch flushes the eCryptfs file in the vm_ops->close() path.
https://launchpad.net/bugs/870326
Signed-off-by: Tyler Hicks <tyhicks@...onical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
fs/ecryptfs/file.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -139,6 +139,27 @@ out:
return rc;
}
+static void ecryptfs_vma_close(struct vm_area_struct *vma)
+{
+ filemap_write_and_wait(vma->vm_file->f_mapping);
+}
+
+static const struct vm_operations_struct ecryptfs_file_vm_ops = {
+ .close = ecryptfs_vma_close,
+ .fault = filemap_fault,
+};
+
+static int ecryptfs_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ int rc;
+
+ rc = generic_file_mmap(file, vma);
+ if (!rc)
+ vma->vm_ops = &ecryptfs_file_vm_ops;
+
+ return rc;
+}
+
struct kmem_cache *ecryptfs_file_info_cache;
/**
@@ -348,7 +369,7 @@ const struct file_operations ecryptfs_ma
#ifdef CONFIG_COMPAT
.compat_ioctl = ecryptfs_compat_ioctl,
#endif
- .mmap = generic_file_mmap,
+ .mmap = ecryptfs_file_mmap,
.open = ecryptfs_open,
.flush = ecryptfs_flush,
.release = ecryptfs_release,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists