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_fr
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 w
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 prob
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
> >
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:
t
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] ===
