Hi,
I would like to propose following patch for net-2.6.git/2.6.38 which fixes a
possible kernel oops in the unicast fragmentation code.
thanks,
Sven
The following changes since commit 1181e1daace88018b2ff66592aa10a4791d705ff:
batman-adv: Make vis info stack traversal threadsafe (2011-01-30 10:32:08 +0100)
are available in the git repository at:
git://git.open-mesh.org/ecsv/linux-merge.git batman-adv/merge
Sven Eckelmann (1):
batman-adv: Linearize fragment packets before merge
net/batman-adv/unicast.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
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 <linus.luessing(a)ascom.ch>
---
unicast.c | 22 +++-------------------
1 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/batman-adv/unicast.c b/batman-adv/unicast.c
index 6a9ab61..9b13565 100644
--- a/batman-adv/unicast.c
+++ b/batman-adv/unicast.c
@@ -295,28 +295,12 @@ int unicast_send_skb(struct sk_buff *skb, struct bat_priv *bat_priv)
/* get routing information */
if (is_multicast_ether_addr(ethhdr->h_dest)) {
orig_node = (struct orig_node *)gw_get_selected(bat_priv);
- if (!orig_node)
- goto trans_search;
-
- kref_get(&orig_node->refcount);
- goto find_router;
- } else {
- rcu_read_lock();
- orig_node = ((struct orig_node *)hash_find(bat_priv->orig_hash,
- compare_orig,
- choose_orig,
- ethhdr->h_dest));
- if (!orig_node) {
- rcu_read_unlock();
- goto trans_search;
+ if (orig_node) {
+ kref_get(&orig_node->refcount);
+ goto find_router;
}
-
- kref_get(&orig_node->refcount);
- rcu_read_unlock();
- goto find_router;
}
-trans_search:
/* check for hna host - increases orig_node refcount */
orig_node = transtable_search(bat_priv, ethhdr->h_dest);
--
1.7.2.3
We access the data inside the skbs of two fragments directly using memmove
during the merge. The data of the skb could span over multiple skb pages. An
direct access without knowledge about the pages would lead to an invalid memory
access.
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
---
batman-adv/unicast.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/batman-adv/unicast.c b/batman-adv/unicast.c
index 6a9ab61..04b152c 100644
--- a/batman-adv/unicast.c
+++ b/batman-adv/unicast.c
@@ -50,6 +50,11 @@ static struct sk_buff *frag_merge_packet(struct list_head *head,
skb = tfp->skb;
}
+ if (skb_linearize(skb) < 0 || skb_linearize(tmp_skb) < 0) {
+ kfree_skb(tfp->skb);
+ return NULL;
+ }
+
skb_pull(tmp_skb, sizeof(struct unicast_frag_packet));
if (pskb_expand_head(skb, 0, tmp_skb->len, GFP_ATOMIC) < 0) {
/* free buffered skb, skb will be freed later */
--
1.7.2.3
Hi there,
I found an interesting paper today that covers mobility of some nodes in
a batman-adv network:
> Stefano Annese, Claudio Casetti, Carla F. Chiasserini, Paolo
> Cipollone, Andrea Ghittino, and Massimo Reineri. 2009. Assessing
> mobility support in mesh networks. In Proceedings of the 4th ACM
> international workshop on Experimental evaluation and
> characterization (WINTECH '09).
http://portal.acm.org/citation.cfm?id=1614297
Unfortunately, the paper is not freely available on the web. If you're
blessed with access to the ACM digital library by your school or
employer, you can download it free of charge; in other cases you'll have
to buy it for USD 15.
In the following, I will summarize relevant parts:
I) Weighting the local packet count
The authors found that when each entry in the sliding window is weighed
with the same weight as it is done in the current version of batman-adv,
routing loops can occur when mobility is present. They greatly improve
their results by weighting with the following function (i = 0..S-1 where
S is the window size; 0 means freshest packet):
weight(i) := max(1, floor(i * S / e^i))
This function seems to be suboptimal as it weights entry 0 with 1 while
the following few entries are boosted with a weight of up to 20 (see
attachment). Adding 1 to i should deal with this flaw.
However, this weighting function lead to big improvements in the
authors' simulations, so I think you are on the right track when
thinking about introducing some kind of weighting or moving average to
boost the weight of current packets.
Here's the Octave/Matlab code I used to create the plot (if you want to
do plots for other weighting functions that are discussed, just replace
the definition of w and don't forget to use .* and ./ instead of * and /
to enforce elementwise operations):
> x = 0:63
> w = max(1, x.*64./exp(x))
> stem(x,w)
> xlabel('age')
> ylabel('weight')
II) Optimizations for multi-interface nodes
The authors used nodes with 2 radios. They did roughly the following on
the mobile nodes (not on the fixed ones):
1) In regular intervals, scan the forwarding tables for each interface
to check if any neighbors are known. If an interface has no contact to
any neighbor, go to 2)
2) Use the interface without known neighbors to scan all channels except
the channel that the other interface is listening to. Don't send OGMs
but simply listen for OGMs from other stations. If a channel is found
that has a neighbor sending, stay on this channel and start to behave
like a normal batman-adv node (send OGMs etc.).
I'm not sure if this will be benefitial in other scenarios than in the
vehicular network scenario of the paper, but I wanted to share my
findings with you.
- Daniel
Sent from my HTC PURE™, a Windows® phone from AT&T
-----Original Message-----
From: Marek Lindner <lindner_marek(a)yahoo.de>
Sent: Wednesday, February 02, 2011 2:49 PM
To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n(a)lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCH] Re: batman-adv: Correct rcu refcounting for gw_node
On Wednesday 02 February 2011 18:37:18 Linus Lüssing wrote:
> So after some more discussions with Marek and Sven, it looks like we
> have to use the rcu protected macros rcu_dereference() and
> rcu_assign_pointer() for the bat_priv->curr_gw and curr_gw->orig_node.
>
> Changes here also include moving the kref_get() from unicast_send_skb()
> into gw_get_selected(). The orig_node could have been freed already at
> the time the kref_get() was called in unicast_send_skb().
I'd suggest you make a standalone patch because the patches address different
problems.
Thanks,
Marek