Message ID | 1322121584-31566-1-git-send-email-tyhicks@canonical.com |
---|---|
State | New |
Headers | show |
On Thu, Nov 24, 2011 at 01:59:44AM -0600, Tyler Hicks wrote: > 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@canonical.com> > --- Ack. Just needs "BugLink:" before URL when applying to oneiric, and a "(cherry-picked from 32001d6fe9ac6b0423e674a3093aa56740849f3b)" in the commit log message. > > Upstream: 32001d6fe9ac6b0423e674a3093aa56740849f3b > Discussion: https://lkml.org/lkml/2011/11/23/495 > > This is the upstream commit applied to ubuntu-oneiric/master-next. Linus wasn't > entirely happy with the patch, but he did take it in. I agree with his > criticism of the patch but this is a minimal fix to a critical bug and > implementing his suggestions will take a little more time. > > I've been testing the patch (and using it daily) over the last week and have > had 0 issues. > > fs/ecryptfs/file.c | 23 ++++++++++++++++++++++- > 1 files changed, 22 insertions(+), 1 deletions(-) > > diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c > index 4ec9eb0..0c1a652 100644 > --- 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_main_fops = { > #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, > -- > 1.7.5.4
On 24.11.2011 08:59, Tyler Hicks wrote: > 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@canonical.com> > --- > > Upstream: 32001d6fe9ac6b0423e674a3093aa56740849f3b > Discussion: https://lkml.org/lkml/2011/11/23/495 > > This is the upstream commit applied to ubuntu-oneiric/master-next. Linus wasn't > entirely happy with the patch, but he did take it in. I agree with his > criticism of the patch but this is a minimal fix to a critical bug and > implementing his suggestions will take a little more time. > > I've been testing the patch (and using it daily) over the last week and have > had 0 issues. > > fs/ecryptfs/file.c | 23 ++++++++++++++++++++++- > 1 files changed, 22 insertions(+), 1 deletions(-) > > diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c > index 4ec9eb0..0c1a652 100644 > --- 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_main_fops = { > #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, Patch ok, message body also needs cleanup before applying.
diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c index 4ec9eb0..0c1a652 100644 --- 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_main_fops = { #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,
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@canonical.com> --- Upstream: 32001d6fe9ac6b0423e674a3093aa56740849f3b Discussion: https://lkml.org/lkml/2011/11/23/495 This is the upstream commit applied to ubuntu-oneiric/master-next. Linus wasn't entirely happy with the patch, but he did take it in. I agree with his criticism of the patch but this is a minimal fix to a critical bug and implementing his suggestions will take a little more time. I've been testing the patch (and using it daily) over the last week and have had 0 issues. fs/ecryptfs/file.c | 23 ++++++++++++++++++++++- 1 files changed, 22 insertions(+), 1 deletions(-)