From patchwork Wed Mar 14 01:59:30 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Lucid SRU commit b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df Date: Tue, 13 Mar 2012 15:59:30 -0000 From: Colin King X-Patchwork-Id: 146517 Message-Id: <4F5FFB82.9070106@canonical.com> To: Kernel team list 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: 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 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,