Re: d_splice_alias() problem.

[Greg Banks]

Neil Brown wrote:
> 
> On Tuesday May 4, gnb@xxxxxxxxxxxxxxxxx wrote:
> > > >
> > Ok, how about this...it's portable, and not racy, but may perturb the
> > logic slightly by also taking dentries off the unused list in the case
> > where they already had d_count>=1.  I'm not sure how significant that is.
> > In any case this also passes my tests.
> 
> I think this patch is good and needed.
> 
> I think the race can happen if:
>        dentry->d_count == 1, not on list
> 
>    thread 1                       thread 2
>    enter __dget_locked            enter dput
>    atomic_inc(d_count) (now 2)
>                                   atomic_dec_and_lock(d_count...) (now 1)
>    if(atomic_read(d_count)==1 ....
>          remove from list
> 
> This will remove it from the unused list when it isn't
> on, and will decrement nr_unused which, as you say, is bad.

This is precisely the race that my tracing indicated was happening
during my tests.

> [...]  Possibly that patch should update the
> d_lookup comment to add __dget_locked to the set of functions that
> clean up after it.

Ok, updated patch below.


--- linux.orig/fs/dcache.c	2004-05-10 13:38:09.000000000 +1000
+++ linux/fs/dcache.c	2004-05-10 14:45:44.000000000 +1000
@@ -257,7 +257,7 @@
 static inline struct dentry * __dget_locked(struct dentry *dentry)
 {
 	atomic_inc(&dentry->d_count);
-	if (atomic_read(&dentry->d_count) == 1) {
+	if (!list_empty(&dentry->d_lru)) {
 		dentry_stat.nr_unused--;
 		list_del_init(&dentry->d_lru);
 	}
@@ -940,8 +942,9 @@
  * lookup is going on.
  *
  * dentry_unused list is not updated even if lookup finds the required dentry
- * in there. It is updated in places such as prune_dcache, shrink_dcache_sb and
- * select_parent. This laziness saves lookup from dcache_lock acquisition.
+ * in there. It is updated in places such as prune_dcache, shrink_dcache_sb,
+ * select_parent and __dget_locked. This laziness saves lookup from dcache_lock
+ * acquisition.
  *
  * d_lookup() is protected against the concurrent renames in some unrelated
  * directory using the seqlockt_t rename_lock.


Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/