- 05 Mar, 2011 27 commits
-
-
Sven Eckelmann authored
When trying to associate a net_device with another net_device which already exists, batman-adv assumes that this interface is a fully initialized batman mesh interface without checking it. The behaviour when accessing data behind netdev_priv of a random net_device is undefined and potentially dangerous. Reported-by:
Linus Lüssing <linus.luessing@ascom.ch> Signed-off-by:
Marek Lindner <lindner_marek@yahoo.de>
-
Linus Lüssing authored
Signed-off-by:
-
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Batman-adv works with "hard interfaces" as well as "soft interfaces". The new name should better make clear which kind of interfaces this list stores. Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
It might be possible that 2 threads access the same data in the same rcu grace period. The first thread calls call_rcu() to decrement the refcount and free the data while the second thread increases the refcount to use the data. To avoid this race condition all refcount operations have to be atomic. Reported-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
-
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Note: The function compare_ether_addr() provided by the Linux kernel requires aligned memory. Signed-off-by: -
Linus Lüssing authored
When printing the soft interface table the number of entries in the softif neigh list are first being counted and a fitting buffer allocated. After that the softif neigh list gets locked again and the buffer printed - which has the following two issues: For one thing, the softif neigh list might have grown when reacquiring the rcu lock, which results in writing outside of the allocated buffer. Furthermore 31 Bytes are not enough for printing an entry with a vid of more than 2 digits. The manual buffering is unnecessary, we can safely print to the seq directly during the rcu_read_lock(). Signed-off-by:
-
Linus Lüssing authored
When unicast_send_skb() is increasing the orig_node's refcount another thread might have been freeing this orig_node already. We need to increase the refcount in the rcu read lock protected area to avoid that. Signed-off-by:
-
Linus Lüssing authored
The rcu protected macros rcu_dereference() and rcu_assign_pointer() for the bat_priv->curr_gw need to be used, as well as spin/rcu locking. Otherwise we might end up using a curr_gw pointer pointing to already freed memory. Reported-by:
-
Marek Lindner authored
Batman-adv could receive several payload broadcasts at the same time that would trigger access to the broadcast seqno sliding window to determine whether this is a new broadcast or not. If these incoming broadcasts are accessing the sliding window simultaneously it could be left in an inconsistent state. Therefore it is necessary to make sure this access is atomic. Reported-by:
Linus Lüssing <linus.luessing@web.de> Signed-off-by:
-
Marek Lindner authored
Reported-by:
Linus Lüssing <linus.luessing@saxnet.de> Signed-off-by:
-
Marek Lindner authored
It might be possible that 2 threads access the same data in the same rcu grace period. The first thread calls call_rcu() to decrement the refcount and free the data while the second thread increases the refcount to use the data. To avoid this race condition all refcount operations have to be atomic. Reported-by:
-
Marek Lindner authored
It might be possible that 2 threads access the same data in the same rcu grace period. The first thread calls call_rcu() to decrement the refcount and free the data while the second thread increases the refcount to use the data. To avoid this race condition all refcount operations have to be atomic. Reported-by:
-
Marek Lindner authored
It might be possible that 2 threads access the same data in the same rcu grace period. The first thread calls call_rcu() to decrement the refcount and free the data while the second thread increases the refcount to use the data. To avoid this race condition all refcount operations have to be atomic. Reported-by:
-
Marek Lindner authored
It might be possible that 2 threads access the same data in the same rcu grace period. The first thread calls call_rcu() to decrement the refcount and free the data while the second thread increases the refcount to use the data. To avoid this race condition all refcount operations have to be atomic. Reported-by:
-
Simon Wunderlich authored
bonding / alternating candidates need to be secured by rcu locks as well. This patch therefore converts the bonding list from a plain pointer list to a rcu securable lists and references the bonding candidates. Signed-off-by:
Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by:
-
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
hardif_disable_interface() calls purge_orig_ref() to immediately free all neighbors associated with the interface that is going down. purge_orig_neighbors() checked if the interface status is IF_INACTIVE which is set to IF_NOT_IN_USE shortly before calling purge_orig_ref(). Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Signed-off-by: -
Marek Lindner authored
Signed-off-by:
-
- 14 Feb, 2011 1 commit
-
-
Jesper Juhl authored
Remove duplicate inclusion of "send.h" and "routing.h" from net/batman-adv/soft-interface.c Signed-off-by:
Jesper Juhl <jj@chaosbits.net> Signed-off-by:
-
- 11 Feb, 2011 3 commits
-
-
Linus Lüssing authored
For a host in the mesh network, the batman layer should be transparent. However, we had one exception, data packets within the mesh network which have the same destination as a originator are being routed to that node, although there is no host that node's bat0 interface and therefore gets dropped anyway. This commit removes this exception. Signed-off-by:
-
Linus Lüssing authored
types.h is included by main.h, which is included at the beginning of any other c-file anyway. Therefore this commit removes those duplicate inclussions. Signed-off-by:
-
Marek Lindner authored
Multiple variable declarations in a single statements over multiple lines can be split into multiple variable declarations without changing the actual behavior. Signed-off-by:
-
- 10 Feb, 2011 1 commit
-
-
Sven Eckelmann authored
The two fragments of an unicast packet must have successive sequence numbers to allow the receiver side to detect matching fragments and merge them again. The current implementation doesn't provide that property because a sequence of two atomic_inc_return may be interleaved with another sequence which also changes the variable. The access to the fragment sequence number pool has either to be protected by correct locking or it has to reserve two sequence numbers in a single fetch. The latter one can easily be done by increasing the value of the last used sequence number by 2 in a single step. The generated window of two currently unused sequence numbers can now be scattered across the two fragments. Reported-by:
-
- 31 Jan, 2011 8 commits
-
-
Sven Eckelmann authored
Signed-off-by: -
Sven Eckelmann authored
Signed-off-by: -
Sven Eckelmann authored
Signed-off-by: -
Sven Eckelmann authored
batman_skb_recv can be defined in hard-interface.c as static because it is never used outside of that file. Signed-off-by: -
Sven Eckelmann authored
Signed-off-by: -
Sven Eckelmann authored
Signed-off-by: -
Simon Wunderlich authored
Some function parameters are obsolete now and can be removed. Reported-by:
-
Sven Eckelmann authored
The routing algorithm must be able to decide if a fragment can be merged with the missing part and still be passed to a forwarding interface. The fragments can only differ by one byte in case that the original payload had an uneven length. In that situation the sender has to inform all possible receivers that the tail is one byte longer using the flag UNI_FRAG_LARGETAIL. The combination of UNI_FRAG_LARGETAIL and UNI_FRAG_HEAD flag makes it possible to calculate the correct length for even and uneven sized payloads. The original formula missed to add the unicast header at all and forgot to remove the fragment header of the second fragment. This made the results highly unreliable and only useful for machines with large differences between the configured MTUs. Reported-by:
Russell Senior <russell@personaltelco.net> Reported-by:
-
