netdev - Re: [PATCH net-next 3/9] IB/ipoib: Add support for acting as VIF

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]

Message-ID: <4FFD4E8D.7040608@mellanox.com>
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