linux-kernel - Re: [PATCH] debugfs: fix potential infinite loop in debugfs_remove

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <83c9114d-c704-1683-0558-327b9e49f5fc@huawei.com>
Date:   Fri, 15 Nov 2019 10:13:10 +0800
From:   "yukuai (C)" <yukuai3@...wei.com>
To:     Steven Rostedt <rostedt@...dmis.org>
CC:     <gregkh@...uxfoundation.org>, <rafael@...nel.org>,
        <oleg@...hat.com>, <jack@...e.cz>, <linux-kernel@...r.kernel.org>,
        <zhengbin13@...wei.com>, <yi.zhang@...wei.com>,
        <chenxiang66@...ilicon.com>, <xiexiuqi@...wei.com>,
        "Al Viro" <viro@...IV.linux.org.uk>
Subject: Re: [PATCH] debugfs: fix potential infinite loop in
 debugfs_remove_recursive



在 2019/11/15 9:53, Steven Rostedt 写道:
> On Fri, 15 Nov 2019 09:47:38 +0800
> "yukuai (C)" <yukuai3@...wei.com> wrote:
> 
>> On 2019/11/14 22:34, Steven Rostedt wrote:
>>> On Thu, 14 Nov 2019 14:59:04 +0800
>>> "yukuai (C)" <yukuai3@...wei.com> wrote:
>>>    
>>>>> Have you tried this patch with lockdep enabled and tried to hit this
>>>>> code path?
>>>>>   
>>>    
>>>>>       
>>>> You are right, I get the results with lockdep enabled:
>>>
>>> That was what I was afraid of :-(
>>>    
>>>> [   64.314748] ============================================
>>>> [   64.315568] WARNING: possible recursive locking detected
>>>> [   64.316549] 5.4.0-rc7-dirty #5 Tainted: G           O
>>>> [   64.317398] --------------------------------------------
>>>> [   64.318230] rmmod/2607 is trying to acquire lock:
>>>    
>>>>
>>>> The warning will disappeare by adding
>>>> lockdep_set_novalidate_class(&child->d_lock) before calling
>>>> simple_empty(child). But I'm not sure It's the right modfication.
>>>
>>> I'm wondering if we should add a simple_empty_unlocked() that does
>>> simple_empty() without taking the lock, to allow us to call
>>> spin_lock_nested() on the child. Of course, I don't know how much
>>> nesting we allow as it calls the nesting too.
>> Do you think we can do this:
>> 1. add a new enum type for dentry_d_lock_class:
>> enum dentry_d_lock_class
>> {
>> 	DENTRY_D_LOCK_NORMAL, /* implicitly used by plain spin_lock() APIs. */
>> 	DENTRY_D_LOCK_NESTED
>> 	DENTRY_D_LOCK_NESTED_1 /* maybe another name */
>> };
>> 2. use the new enum type in simple_empty
>> int simple_empty(struct dentry *dentry)
>> {
>> 	spin_lock(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
>> 	list_for_each_entry(child, &dentry->d_subdirs, d_child) {
>> 		spin_lock_nested(&child->d_lock, DENTRY_D_LOCK_NESTED_1);
>> }
>>
>> If you agree, I'll try to send a patch or patchset(with modification in
>> debugfs_remove_recursive).
>>
> 
> It sounds fine to me, but I think the decision needs to be with the
> debugfs and vfs maintainers.
> 
> -- Steve
> 
> .
> 
Thank you very much! I'll have a try.
Yu Kuai