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] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 23 Sep 2007 12:55:19 -0500
From:	Steve Wise <>
To:	Evgeniy Polyakov <>
Subject: Re: pktgen question

Evgeniy Polyakov wrote:
> Hi Steve.
> On Sun, Sep 23, 2007 at 11:12:12AM -0500, Steve Wise ( wrote:
>> The pktgen module provides a way to "clone" the skb its using for 
>> transmission, and allows passing N clones of the originally created skb 
>> to the driver under test.    However, it doesn't really use skb_clone(), 
>> but rather it just bumps the skb->users count for each "clone" and 
>> passes the same skb ptr to the driver.
>> Q: Is that a valid use of skb->users or should pktgen really be cloning 
>> the skbuff?
> It's a hack, but since skb is owned by pktgen only (no copies in some
> outside queues or some other access) it is allowed just to bump reference
> counter (i.e. 'share' skb in usual notation).

Its a hack that breaks cxgb3 because cxgb3 uses the skb->cb area for 
each skb passed down.  So cxgb3 is at fault then?  IE a driver cannot 
use the skb->cb field if the users count is > 1?  Or maybe a driver can 
_never_ use the cb field?


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