lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 13 Oct 2007 04:04:26 -0400
From:	jamal <>
To:	Herbert Xu <>
Subject: Re: tc_verd vs. skb_clone

On Fri, 2007-12-10 at 22:00 +0800, Herbert Xu wrote:
> Hi Jamal:
> I was wondering why we're not copying tc_verd as is in skb_clone.
> In particular, this makes pskb_copy behave differently compared
> to skb_clone and I can't find a justificatino for it.
> Any ideas?

In the case of an action branching (from a graph), they clone. In the
case they want to trample on an skb, they copy; otherwise it continues
processing in the graph with none of the above. In the clone case,
certain metadata needs reseting (like the "it is ok to munge on this
packet" to "it is _not_ ok to munge on it" etc). We allow the copy case 
leeway to do whatever it wants since it is going to tranple on the skb
and therefore reset nothing.
Would something more verbose in Documentation/net help to make this

If it is causing trouble, then one idea would be to move the resetting
to a wrapper function which calls clone first and then resets the other
fields. All actions currently cloning would need to be mod-ed to use
that call.

> Also we don't seem to copy iif in copy_skb_header.

I cant think of a good reason why it shouldnt be copied or recall
whether thats how its been from the begining. The reason probably it
hasnt mattered so far is everything that needs to write the iif never


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists