[Lucid, Karmic, Hardy] Fix regression caused by CVE-2010-2943 fix

[Stefan Bader]

On 02/23/2011 11:24 PM, Tim Gardner wrote:
> On 02/23/2011 09:22 AM, Stefan Bader wrote:
>> SRU Justification:
>>
>> Impact: The patches backported to fix CVE-2010-2943 caused a regressioni
>>          for xfsdump.
>>
>> Fix: Backporting one more patch from upstream is fixing the issue.
>>
>> Testcase:
>>   1. create an xfs filesystem with data (>~100MB). There is a compressed
>>      archive provided in comment #14.
>>   2. run "xfsdump -p10 -Ltest -Mdump -f outfile<mount>"
>>       Note: Hardy and earlier seem to require the path to the device,
>>       while later releases can handle the mount point.
>> The xfsdump command aborts with SGI_FS_BULKSTAT errno = 22
>>
>> Note: the same changes were also backported to Dapper, but I have not
>> yet been able to verify the regression there. Instead I got the feeling
>> that xfs could be more broken in that release (I already get driver
>> crashes when transferring bigger amounts of data to the xfs file system
>> as a preparation). So I am tempted to leave the Dapper code as is. Even
>> more as it again so different from the Hardy code that a backport is not
>> simple.
>>
>> I will follow up with patches (hopefully) responding to this initial mail.
>>
>> -Stefan
>>
> 
> I'm inclined to leave Dapper alone as well. Was it even stable enough for
> production use in 2.6.15 ?
> 
> The commit log mentions using iget "which should be fast enough for normal use
> with the radix-tree based inode cache introduced a while ago". When was the
> radix-tree stuff introduced? Will this patch introduce a ginormous performance
> regression?
>

The radix tree based inode cache was added just with 2.6.24-rc1. So another
reason to leave Dapper alone.

> What about either reverting the original CVE patch, or finding a smaller fix for
> it?
> 
But I would stick with the backport we have plus this patch. Btw, the next
2.6.32.y release will have those 5 backported patches (4 we already have and
this additional one).

-Stefan
> rtg