Lucid SRU commit b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df

Tim Gardner rtg.canonical at gmail.com
Wed Mar 14 03:08:55 UTC 2012


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 ?

rtg

-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list