Re: 2.6.17-rc5-mm3: bad unlock ordering (reiser4?)

[Ingo Molnar]

* Barry K. Nathan <barryn@xxxxxxxxx> wrote:

> Assuming it's a false positive: Since this stops the tracer, it means 
> that if an actual deadlock possibility is detected later [I'm assuming 
> that detection of those doesn't get shut down by the bad-lock-ordering 
> detection either], useful information could be missing from 
> /proc/latency_trace, [...]

reporting the first one only is necessary, because the validator cannot 
trust a system's dependency info that it sees as incorrect. Deadlock 
possibilities are quite rare in a kernel that is "in balance". Right now 
we are not "in balance" yet, because the validator has only been added a 
couple of days ago. The flurry of initial fixes will die down quickly.

you can fix the reiser4 false positive (it's likely a false positive) by 
changing the spin_unlock() to spin_unlock_non_nested(). The patch below 
should do that for this specific instance.

Ob'Reiser4'Cleanup:

	spin_unlock(&(mgr->tmgr_lock));

why isnt that:

	spin_unlock(&mgr->tmgr_lock);

? fs/reiser4/*.c is infested with that, the string '(&(' occurs 199 (!) 
times.

also:

        if (atomic_read(&node->d_count) != 0) {
                return 0;
        }

why the braces, when on the next line it's not done:

        if (blocknr_is_fake(jnode_get_block(node)))
                return 0;

it looks quite inconsistent. Also, just a quick look at just about any 
file in reiser4/*.c shows alot of other coding style inconsistencies.

	Ingo

Index: linux/fs/reiser4/txnmgr.h
===================================================================
--- linux.orig/fs/reiser4/txnmgr.h
+++ linux/fs/reiser4/txnmgr.h
@@ -613,7 +613,7 @@ static inline void spin_unlock_txnmgr(tx
 	LOCK_CNT_DEC(spin_locked_txnmgr);
 	LOCK_CNT_DEC(spin_locked);
 
-	spin_unlock(&(mgr->tmgr_lock));
+	spin_unlock_non_nested(&(mgr->tmgr_lock));
 }
 
 typedef enum {
-
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/