Re: [tipc-discussion] [RFC: 2.6 patch] net/tipc/: possible cleanups

Adrian Bunk wrote: This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 unused functions Thanks. I think most of those were due for our next release, anyway. But we'll get it in, one way or another. - remove all EXPORT_SYMBOL's My

Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC

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(_table_lock); if (tipc_ref_table.first_free)

Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC

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)

Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC

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

Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC

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

Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC

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:

Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC

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:

<    1   2