lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Jul 2012 12:59:41 +0300
From:	Or Gerlitz <ogerlitz@...lanox.com>
To:	David Miller <davem@...emloft.net>, <eric.dumazet@...il.com>
CC:	<roland@...nel.org>, <netdev@...r.kernel.org>, <ali@...lanox.com>,
	<sean.hefty@...el.com>, <erezsh@...lanox.co.il>
Subject: Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF

On 7/11/2012 11:19 AM, David Miller wrote:
> handle_ing() goes into the packet scheduler and qdisc layer, the qdisc 
> layer uses skb->cb[] via struct qdisc_skb_cb

Oh, I knew that the qdisc layer touches skb->cb[] but thought it only 
happens on the TX flow...

Here, the flow Eric pointed on relates to skb which was received by 
IPoIB and is soon going
to be consumed by the eIPoIB driver once the rx handler planted by it is 
executed on the skb.

So even in this "simple" flow we can't assume that qdisc will not 
interfere (why)?

if indeed this is case - I understand that we still can deploy the 
practice used by
ipoib_hard_header which uses struct ipoib_cb, or in other words we can 
use 20 out
of the 48 bytes of the cb, starting from offset of 28 bytes, correct?

Or.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists