From: jamal <hadi@cyberus.ca>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jiri Pirko <jpirko@redhat.com>,
netdev@vger.kernel.org, davem@davemloft.net, kaber@trash.net
Subject: Re: Question about an assignment in handle_ing()
Date: Thu, 03 Jun 2010 08:43:50 -0400 [thread overview]
Message-ID: <1275569030.3445.49.camel@bigi> (raw)
In-Reply-To: <20100603080130.GA29709@gondor.apana.org.au>
On Thu, 2010-06-03 at 18:01 +1000, Herbert Xu wrote:
> On Sun, May 30, 2010 at 09:29:10AM -0400, jamal wrote:
> > The packet path is:
> > -->eth0-->tcpdump eth0-->pedit-->mirror to dummy0-->tcpdump dummy0
>
> Well this doesn't guarantee a cloned packet at all. Once af_packet
> receives the packet it'll wake up any listeners like tcpdump, if
> tcpdump gets to it before pedit runs then the packet won't be
> cloned anymore.
I may be misreading, but:
This is the point i have been trying to make, Herbert;-> There is no
_guarantee_ that the first tcpdump will see the packet that came out of
eth0 instead of seeing the packet that came out the pedit part of the
pipeline. I need to see the correct packet. I know with my check
this is guaranteed.
> Anyway, I don't see why actions are special. Everybody else lives
> by the rule that cloned skbs are not writeable.
Yes, if skb_cloned() is true but it is not as i said in my earlier
email.
> So if this was
> indeed buggy as you say it would have shown up a long time ago.
Things may have been buggy - I dont know; you just validated to me that
it _may_ happen. I will be more than happy to remove it if i can get a
guarantee.
So how do we fix this?
Does af_packet need to always clone? That way i can depend on it. I have
a feeling someone will be unhappy with that. I am avoiding to clone
every packet on my part because afaik this problem doesnt exist if i
dont use tcpdump/af_packet...
> Case in point, we had a bug in certain NIC drivers where they
> modified cloned skbs for TSO. This quickly showed up as bogus
> packets in tcpdump and we fixed it.
I think this is different.
cheers,
jamal
next prev parent reply other threads:[~2010-06-03 12:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-24 11:22 Question about an assignment in handle_ing() Jiri Pirko
2010-05-25 9:51 ` jamal
2010-05-25 10:26 ` Herbert Xu
2010-05-25 12:03 ` jamal
2010-05-25 12:12 ` Herbert Xu
2010-05-25 12:20 ` jamal
2010-05-25 12:46 ` Herbert Xu
2010-05-25 13:13 ` jamal
2010-05-25 23:13 ` Herbert Xu
2010-05-26 11:38 ` jamal
2010-05-30 13:29 ` jamal
2010-06-03 8:01 ` Herbert Xu
2010-06-03 12:43 ` jamal [this message]
2010-06-03 12:47 ` Herbert Xu
2010-06-03 12:53 ` jamal
2010-06-03 12:56 ` Herbert Xu
2010-06-03 12:58 ` Herbert Xu
2010-06-03 12:58 ` jamal
2010-06-03 13:00 ` Herbert Xu
2010-06-03 13:01 ` jamal
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=1275569030.3445.49.camel@bigi \
--to=hadi@cyberus.ca \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=jpirko@redhat.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).