lkml.org 
[lkml]   [2006]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 2.6.17-rc5-mm3: bad unlock ordering (reiser4?)

* 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 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2006-06-05 08:58    [W:0.105 / U:5.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site