Lucid SRU commit b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df

[Colin Ian King]

Hi there,

While running a bunch of exhaustive eCryptfs tests this evening I found 
that one of the recent commits in Lucid master-next was causing a 
regression.  I bisected this down to the offending problem - the 
regression is in lucid master-next because of commit 
b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df

Now, the patch I sent to the mailing list on the 15th March effectively 
modified the dir_fops as follows:

diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
index 4e25328..d8adc51 100644
--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -327,7 +327,6 @@ const struct file_operations ecryptfs_dir_fops = {
  #ifdef CONFIG_COMPAT
  	.compat_ioctl = ecryptfs_compat_ioctl,
  #endif
-	.mmap = generic_file_mmap,
  	.open = ecryptfs_open,
  	.flush = ecryptfs_flush,
  	.release = ecryptfs_release,

However, the patch applied to lucid master next is different:

diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
index 502b09f..49129f4 100644
--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -348,7 +348,6 @@ const struct file_operations ecryptfs_main_fops = {
  #ifdef CONFIG_COMPAT
         .compat_ioctl = ecryptfs_compat_ioctl,
  #endif
-       .mmap = generic_file_mmap,
         .open = ecryptfs_open,
         .flush = ecryptfs_flush,
         .release = ecryptfs_release,


which explains the regression I'm seeing where I can't mmap a file on 
ecryptfs. Pulling out this commit makes the regression go away.

So..

Can we revert b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df and apply my 
original patch and make sure it correctly modifies ecryptfs_dir_fops.

Since it's now 1:56am I'm not really awake to figure out why the patch 
didn't apply correctly.  I can't believe git am failed like this.

Colin