Lucid SRU commit b3214b2a5dcee0d3ba0bd28dc3dd9ca472f3d6df

Stefan Bader stefan.bader at canonical.com
Wed Mar 14 08:39:53 UTC 2012


On 14.03.2012 04:08, 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 ?
> 
> rtg
> 
This had happened to me once in the past, just with an addition instead of a
removal. If the hunk modified is not differing enough in context (or in this
case there is another place that fits as well), it is possible to not detect an
already applied patch.
And this one does and we had it before and after. So probably the simplest is to
rebase the second (wrong) one out of existence.

-Stefan




More information about the kernel-team mailing list