Hi Richard:

I've made the change to increase BUF_HEADROOM to 24 bytes, but I'm now
coming to the conclusion that this isn't going to be all that is
required to support the gianfar driver.  While increasing BUF_HEADROOM
ensures that any sk_buff allocated by TIPC has enough headroom, we also
have be prepared to handle an sk_buff that was received from an Ethernet
driver and is now being routed to another node.  In particular, I'm
worried that TIPC may receive a message via a "standard" Ethernet driver
and then need to send it out through a gianfar driver, in which case the
available headroom may be insufficient.

So, to be on the safe side, I've modified TIPC's Ethernet media send
routine to do the same sort of headroom size checking and extending as
is done in the IP output code.  [I had said that I didn't want to do
this in an earlier email, but it seems to be unavoidable ...]  I've done
some basic sanity checking on my setup here, but I was hoping you could
also take a few minutes to try it out to see that it works "for real"
with the gianfar driver.  In particular, could you try running this
modified code on your setup with BUF_HEADROOM set to 20 , rather than
24?  If this works (instead of causing the skb_under_panic() that you
originally reported) we'll have some good evidence that the headroom
expansion logic is working properly.

I've attached a patch file containing the change I made, as well as the
revised version of net/tipc/tipc_eth_media.c; you can either apply the
patch or just replace the file, whichever is easier for you.

Thanks,
Al



From nobody Mon Sep 17 00:00:00 2001
From: Allan Stephens <[EMAIL PROTECTED]>
Date: Thu, 6 Sep 2007 16:36:28 -0400
Subject: [PATCH] Ensure outgoing messages on Ethernet have sufficient headroom

This patch adds code to expand the headroom of an outgoing
TIPC message if the sk_buff has insufficient room to hold the
header for the associated Ethernet device.  This change is
necessary to ensure that messages TIPC does not create itself
(eg. incoming messages that are being routed to another node)
do not cause problems, since TIPC has no control over the amount
of headroom available in such messages.

Signed-off-by: Allan Stephens <[EMAIL PROTECTED]>

---

 net/tipc/tipc_eth_media.c |   30 ++++++++++++++++++++----------
 1 files changed, 20 insertions(+), 10 deletions(-)

ec4f70cd659d974e555fe40f02f7372fbde5687c
diff --git a/net/tipc/tipc_eth_media.c b/net/tipc/tipc_eth_media.c
index be96d03..e568bbb 100644
--- a/net/tipc/tipc_eth_media.c
+++ b/net/tipc/tipc_eth_media.c
@@ -109,18 +109,28 @@ static void eth_media_addr_init(struct t
 static int send_msg(struct sk_buff *buf, struct tipc_bearer *tb_ptr, 
                    struct tipc_media_addr *dest)
 {
-       struct sk_buff *clone;
+       struct sk_buff *buf_clone;
        struct net_device *dev;
-
-       clone = skb_clone(buf, GFP_ATOMIC);
-       if (clone) {
-               clone->nh.raw = clone->data;
-               dev = ((struct eth_bearer *)(tb_ptr->usr_handle))->dev;
-               clone->dev = dev;
-               dev->hard_header(clone, dev, ETH_P_TIPC, &dest->value[4],
-                                dev->dev_addr, clone->len);
-               dev_queue_xmit(clone);
+       int delta;
+
+       buf_clone = skb_clone(buf, GFP_ATOMIC);
+       if (buf_clone == NULL)
+               return TIPC_OK;
+       
+       dev = ((struct eth_bearer *)(tb_ptr->usr_handle))->dev;
+       delta = dev->hard_header_len - skb_headroom(buf);
+
+       if ((delta > 0) && 
+           pskb_expand_head(buf_clone, SKB_DATA_ALIGN(delta), 0, GFP_ATOMIC)) {
+               kfree_skb(buf_clone);
+               return TIPC_OK;
        }
+
+       buf_clone->nh.raw = buf_clone->data;
+       buf_clone->dev = dev;
+       dev->hard_header(buf_clone, dev, ETH_P_TIPC, &dest->value[4],
+                        dev->dev_addr, buf_clone->len);
+       dev_queue_xmit(buf_clone);
        return TIPC_OK;
 }
 
-- 
1.3.3

Attachment: tipc_eth_media.c
Description: tipc_eth_media.c

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to