eCryptfs: Flush file in vma close

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(-)

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.