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

Ingo Molnar
2006-06-05T06:55:23Z

* Barry K. Nathan <barryn@pobox.com> 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 {