Jarek Poplawski wrote:
If you are sure there is no circular locking possible
between these two functions and this entry-lock here
isn't endangered by other functions, you could try to
make lockdep silent like this:
write_lock_bh(ref_table_lock);
if (tipc_ref_table.first_free)
On Wed, Jan 03, 2007 at 11:16:59PM +, Jon Maloy wrote:
See my comments below.
Regards
///jon
Jarek Poplawski wrote:
..
Maybe I misinterpret this but, IMHO lockdep
complains about locks acquired in different
order: tipc_ref_acquire() gets ref_table_lock
and then
Regards
///jon
Jarek Poplawski wrote:
I know lockdep is sometimes
too careful but nevertheless some change is needed
to fix a real bug or give additional information
to lockdep.
I don't know lockdep well enough yet, but I will try to find out if that
is possible.
Btw. there is a
On Thu, Jan 04, 2007 at 04:16:20PM +, Jon Maloy wrote:
Regards
///jon
Jarek Poplawski wrote:
I know lockdep is sometimes
too careful but nevertheless some change is needed
to fix a real bug or give additional information
to lockdep.
I don't know lockdep well enough yet, but
See my comments below.
Regards
///jon
Jarek Poplawski wrote:
..
Maybe I misinterpret this but, IMHO lockdep
complains about locks acquired in different
order: tipc_ref_acquire() gets ref_table_lock
and then tipc_ret_table.entries[index]-lock,
but tipc_deleteport() inversely (with:
On 22-12-2006 15:28, Eric Sesterhenn wrote:
hi,
while running my usual stuff on 2.6.20-rc1-git5, sfuzz
(http://www.digitaldwarf.be/products/sfuzz.c)
did the following, to produce the lockdep warning below:
...
Here is the stacktrace:
[ 313.239556]
