Lucid SRU commit b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df

Andy Whitcroft apw at canonical.com
Wed Mar 14 09:19:18 UTC 2012


On Tue, Mar 13, 2012 at 09:08:55PM -0600, Tim Gardner wrote:
> On 03/13/2012 07:59 PM, Colin Ian King wrote:
> >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
> >
> 
> OK, this is a bit weird. lucid master-next
> a0a7873ea78a0c7331e59fe63f20f80c8131b3e8 does the right thing.
> However, a bit later b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df
> removes the same helper from ecryptfs_main_fops. That commit was
> part of the 2.6.32.58 stable update. I am totally baffled as to how
> that happened, but it kind of looks like a 'git am' failure.
> Upstream stable 2.6.32.y looks correct.
> 
> Do you think it sufficient to just revert
> b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df ?

Ok what happened here is that there are two places this patch can apply,
ie where the hunk context is identicle.  So colin's backport applied in
the right place, removing the first match.  When the upstream stable
version gets applied the original location does not match but the later
one matches exactly so it is applied with an offset, removing the wrong
one.

Tim, yes just reverting b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df should
sort things out, it is that fix which is now in error.

-apw




More information about the kernel-team mailing list