Re: [B.A.T.M.A.N.] [PATCH 2/2] batman-adv: Add KernelDoc for soft-interface lockdep functions

2012-09-09 Thread Marek Lindner
On Monday, August 27, 2012 16:53:51 Sven Eckelmann wrote: e27bb6fa916451e9eaced16e7c21d5b71a3b7f30 (batman-adv: Set special lockdep classes to avoid lockdep warning) added new functions, but no new documentation for these functions. Signed-off-by: Sven Eckelmann s...@narfation.org ---

Re: [B.A.T.M.A.N.] [PATCH 1/2] batman-adv: Write lockdep xmit class in late initialization phase

2012-09-09 Thread Marek Lindner
On Monday, August 27, 2012 16:53:50 Sven Eckelmann wrote: e27bb6fa916451e9eaced16e7c21d5b71a3b7f30 (batman-adv: Set special lockdep classes to avoid lockdep warning) introduced a lockdep class for the tx queue, but did not set it in the correct initialization phase. The batman-adv specific

[B.A.T.M.A.N.] [PATCH] batman-adv: substitute tt_poss_change with a per-tt_entry flag

2012-09-09 Thread Antonio Quartulli
tt_poss_change is a node-wide flag which tells whether the node is in a roaming state (a client recently moved to/away from it) in order to let it apply special re-routing rules. However this flag does not give a clear idea of the current state because it is not possible to understand *which

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: roaming re-routing mechanism redesign

2012-09-09 Thread Marek Lindner
On Thursday, August 30, 2012 23:04:24 Antonio Quartulli wrote: The roaming re-routing procedure has been slightly revised in order to get rid of the tt_poss_change variable that was not clearly representing the node/client states. Now the code directly relies on the TT_CLIENT_ROAM flag that

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: don't rely on positions in struct for hashing

2012-09-09 Thread Marek Lindner
On Friday, August 31, 2012 00:22:27 Simon Wunderlich wrote: The hash functions in the bridge loop avoidance code expects the VLAN vid to be right after the mac address, but this is not guaranteed. Fix this by explicitly hashing over the right fields of the struct. Reported-by: Marek

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: fix wrong spinlock inline comment

2012-09-09 Thread Marek Lindner
On Monday, September 03, 2012 01:00:38 Antonio Quartulli wrote: Signed-off-by: Antonio Quartulli or...@autistici.org --- types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied in revision 85f416e. Thanks, Marek

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: roaming re-routing mechanism redesign

2012-09-09 Thread Antonio Quartulli
On Sun, Sep 09, 2012 at 04:29:57PM +0800, Marek Lindner wrote: On Thursday, August 30, 2012 23:04:24 Antonio Quartulli wrote: The roaming re-routing procedure has been slightly revised in order to get rid of the tt_poss_change variable that was not clearly representing the node/client

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: make batadv_test_bit() return 0 or 1 only

2012-09-09 Thread Marek Lindner
On Tuesday, September 04, 2012 04:20:31 Linus Lüssing wrote: On some architectures test_bit() can return other values than 0 or 1: With a generic x86 OpenWrt image in a kvm setup (batadv_)test_bit() frequently returns -1 for me, leading to batadv_iv_ogm_update_seqnos() wrongly signaling a

[B.A.T.M.A.N.] [PATCHv2] batman-adv: prevent using any virtual device created on batman-adv as hard-interface

2012-09-09 Thread Antonio Quartulli
Any virtual device created on top of a batman-adv mesh interface must be prevented to be used to create a new mesh network (this would lead to an unwanted batman-over-batman configuration) Signed-off-by: Antonio Quartulli or...@autistici.org --- v2: - added check for !parent_dev with WARN_ON()

Re: [B.A.T.M.A.N.] [PATCH 2/2] batman-adv: allow bla traffic only after first worker period

2012-09-09 Thread Marek Lindner
On Sunday, September 09, 2012 00:02:54 Simon Wunderlich wrote: + /* request_sent is only set after creation to avoid +* problems when we are not yet known as backbone gw +* in the backbone. +* +

[B.A.T.M.A.N.] [PATCHv2 2/2] batman-adv: allow bla traffic only after first worker period

2012-09-09 Thread Simon Wunderlich
When adding a backbone gateway for the first time, it might not yet be known in the backbone, and therefore we should not forward broadcasts yet. This behaviour is the same as when sending a request to another backbone gw because of a CRC mismatch. The backbone gw will operate normal after the