From patchwork Wed Mar 14 01:59:30 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Colin Ian King X-Patchwork-Id: 146517 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id E29BDB6F62 for ; Wed, 14 Mar 2012 12:59:46 +1100 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1S7dV0-0005wS-ED; Wed, 14 Mar 2012 01:59:34 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1S7dUx-0005wN-VF for kernel-team@lists.ubuntu.com; Wed, 14 Mar 2012 01:59:31 +0000 Received: from cpc19-craw6-2-0-cust5.croy.cable.virginmedia.com ([77.102.228.6] helo=[192.168.1.13]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1S7dUx-0005w9-PS; Wed, 14 Mar 2012 01:59:31 +0000 Message-ID: <4F5FFB82.9070106@canonical.com> Date: Wed, 14 Mar 2012 01:59:30 +0000 From: Colin Ian King User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120309 Thunderbird/11.0 MIME-Version: 1.0 To: Kernel team list Subject: Lucid SRU commit b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com 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,