Re: [PATCH] get rid of s_files and files_lock

[Wang Kai <morgan.wang@huawei.com>]

On 2015/4/30 12:49, Zefan Li wrote:
> On 2015/4/30 12:39, Wang Kai wrote:
>> On 2015/4/30 11:24, Zefan Li wrote:
>>> On 2015/4/29 19:00, Wang Kai wrote:
>>>> From: Al Viro <viro@zeniv.linux.org.uk>
>>>>
>>>> commit eee5cc2702929fd41cce28058dc6d6717f723f87 upstream.
>>>>
>>>> The only thing we need it for is alt-sysrq-r (emergency remount r/o)
>>>> and these days we can do just as well without going through the
>>>> list of files.
>>>>
>>>> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>>>> [wangkai: backport to 3.10
>>>>  - address CVE-2014-8172
>>>>  - adjust context
>>>>  - leave fu.fu_list as still used in 3.10]
>>>
>>> This doesn't sound right to me. We're removing operations on fu_list like
>>> init/add/del, so how can it still be used?
>>
>> Thanks for review, Zefan.
>>
>> The fix commit eee5cc2702 comes after 4f5e65a1cc90, which replace
>> fu_list with fu_llist for avoiding lock.
>> So, if we don't backport 4f5e65a1cc90, we should leave fu_list there.
>>
>> Or, should we backport 4f5e65a1cc90 too?
> 
> Not necessary, but is better. my 2 cents.
OK, I will send a v2 soon.

> 
>> IMO, as it's NOT bugfix, and just backport this one will NOT make
>> work easier(cherry-picked), so looks unnecessary.
>>
>> Another question, this bugfix will change kernel's header files(API),
>> how LTS handle with this, OK with that?
>>
> 
> Documentation/stable_api_nonsense.txt
> 
> 
> .
>