On 2019/11/15 15:20, Greg KH wrote:
On Fri, Nov 15, 2019 at 04:12:43AM +0000, Al Viro wrote:
On Fri, Nov 15, 2019 at 11:27:59AM +0800, Greg KH wrote:
On Fri, Nov 15, 2019 at 11:27:50AM +0800, yu kuai wrote:
'dentry_d_lock_class' can be used for spin_lock_nested in case lockdep
confused about two different dentry take the 'd_lock'.
However, a single 'DENTRY_D_LOCK_NESTED' may not be enough if more than
two dentry are involed. So, and in 'DENTRY_D_LOCK_NESTED_2'
Signed-off-by: yu kuai <yukuai3@xxxxxxxxxx>
---
include/linux/dcache.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index 10090f1..8eb84ef 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -129,7 +129,8 @@ struct dentry {
enum dentry_d_lock_class
{
DENTRY_D_LOCK_NORMAL, /* implicitly used by plain spin_lock() APIs. */
- DENTRY_D_LOCK_NESTED
+ DENTRY_D_LOCK_NESTED,
+ DENTRY_D_LOCK_NESTED_2
You should document this, as "_2" does not make much sense to anyone
only looking at the code :(
Or rename it better.
FWIW, I'm not sure it's a good solution. What are the rules for callers
of that thing, anyway? If it can be called when somebody is creating
more files in that subtree, we almost certainly will have massive
problems with the lifetimes of underlying objects...
Could somebody familiar with debugfs explain how is that thing actually
used and what is required from/promised to its callers? I can try and
grep through the tree and guess what the rules are, but I've way too
much on my platter right now and I don't want to get sidetracked into yet
another tree-wide search and analysis session ;-/
Yu wants to use simple_empty() in debugfs_remove_recursive() instead of
manually checking:
if (!list_empty(&child->d_subdirs)) {
See patch 3 of this series for that change and why they feel it is
needed:
https://lore.kernel.org/lkml/1573788472-87426-4-git-send-email-yukuai3@xxxxxxxxxx/
As to if patch 3 really is needed, I'll leave that up to Yu given that I
thought we had resolved these types of issues already a year or so ago.
thanks,
greg k-h
.
The main purpose of this patchset is to fix the infinite loop in
debugfs_remove_recursive. Steven point out that simple replace
list_empty with simple_empty will cause a splat with lockdep enabled.
We try to fix it with the first two patch, do you think it's appropriate?
Thanks,
Yu Kuai
