From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Changli Gao <xiaosuo@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: net: af_packet: skb_orphan should be avoided in TX path.
Date: Sun, 05 Sep 2010 20:08:45 +0200 [thread overview]
Message-ID: <4C83DCAD.5040602@hartkopp.net> (raw)
In-Reply-To: <AANLkTineDkP1EGsTn3GU+9cPO+JnaNc3ekoHyKQa=img@mail.gmail.com>
On 05.09.2010 19:51, Changli Gao wrote:
> On Mon, Sep 6, 2010 at 1:43 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Le lundi 06 septembre 2010 à 01:18 +0800, Changli Gao a écrit :
>>> af_packet uses tpacket_destruct_skb() to notify its user a frame is
>>> sent out through NIC, and the memory for that frame is available for
>>> the others. If the driver calls skb_orphan() before the frame is sent
>>> out successfully, and the user may fill other data into the space for
>>> this frame, this frame will be corrupted. It became more likely after
>>> skb_try_orphan() was added into dev_hard_start_xmit().
>>>
>>> Am I correct?
>>>
>>
>> Yes good catch. We might add a :
>>
>> SKBTX_NO_EARLY_ORPHAN = 1 << 4,
>>
>> so that skb_orphan_try() do not early orphan this kind of skb
>>
>
> It may solve the issue of skb_orphan_try(), but some NICs still call
> skb_orphan(). Maybe replacing skb_orphan() with skb_orphan_try() can
> work around this issue.
>
Hm - i'm not really sure if skb_orphan_try() helps on this level.
E.g. for drivers/net/can/dev.c the skb_orphan is used to handle the correct
order of echo'ed skbs. Other drivers may do similar things.
AFAIK skb_orphan_try() helps to increase the performance for usual network
traffic, as it allows the orphan on a 'higher' level inside the networking stack.
In some cases the skb needs to be untouched, and this can be indicated in the
shared tx_flags. IMO skb_orphan_try() on driver level would break the correct
behaviour in most cases.
Regards,
Oliver
> localhost linux # grep skb_orphan drivers/net/ -r
> drivers/net/can/dev.c: skb_orphan(skb);
> drivers/net/mlx4/en_tx.c: skb_orphan(skb);
> drivers/net/cxgb3/sge.c: skb_orphan(skb);
> drivers/net/cxgb4/sge.c: skb_orphan(skb);
> drivers/net/niu.c: skb_orphan(skb);
> drivers/net/cxgb4vf/sge.c: skb_orphan(skb);
> drivers/net/tun.c: skb_orphan(skb);
> drivers/net/virtio_net.c: skb_orphan(skb);
> drivers/net/loopback.c: skb_orphan(skb);
> drivers/net/wireless/mac80211_hwsim.c: skb_orphan(skb);
> drivers/net/wireless/libertas/tx.c: skb_orphan(skb);
>
next prev parent reply other threads:[~2010-09-05 18:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-05 17:18 net: af_packet: skb_orphan should be avoided in TX path Changli Gao
2010-09-05 17:43 ` Eric Dumazet
2010-09-05 17:51 ` Changli Gao
2010-09-05 18:08 ` Oliver Hartkopp [this message]
2010-09-06 10:35 ` Michael S. Tsirkin
2010-09-06 15:44 ` Eric Dumazet
2010-09-06 19:53 ` Michael S. Tsirkin
2010-09-06 20:11 ` David Miller
2010-09-08 17:39 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C83DCAD.5040602@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=xiaosuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.