Re: [PATCH] get rid of s_files and files_lock

[Zefan Li <lizefan@huawei.com>]

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.

> 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