netdev - Re: skb->frag_list != NULL in start_xmit for device without NETIF_F

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 3 Mar 2011 18:12:31 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Paul Durrant <Paul.Durrant@...rix.com>, dev@...nvswitch.org
Subject: Re: skb->frag_list != NULL in start_xmit for device without NETIF_F_FRAGLIST

On Wed, Mar 2, 2011 at 9:42 AM, Ian Campbell <Ian.Campbell@...rix.com> wrote:
> On Wed, 2011-03-02 at 13:14 +0000, Ian Campbell wrote:
>> On Wed, 2011-03-02 at 13:12 +0000, Ian Campbell wrote:
>> >
>> > > I believe that not much has changed in this regard between 2.6.32
>> > and net-next.
>> >
>> > It turns out I cannot reproduce with either 2.6.32 (pvops xen.git) or
>> > a more recent ((26.38-rc) kernel. The kernel where we see this is the
>> > XCP kernel which is a 2.6.32 based thing derived from SLES11SP1 + XCP
>> > specific updates.
>>
>> Paul reminded me that his XCP system where we see this is running
>> openvswitch not bridging (all my own tests were with bridging), is this
>> something which could be caused by vswitch at all? I don't see any
>> interesting ->frag_list usage in openvswitch.git.
>>
>> Anyway I'm going to see if I can repro with vswitch.
>
> It seems that was the key.
>
> Using openvswitch.git aae3743bf24cd0e14be726c774a0be49ff0459d7 on top of
> 2.6.38-rc7 (+ some Xen stuff from linux-next and my netback branch). I
> added:
>        WARN_ONCE(skb_shinfo(skb)->frag_list, "skb %p has a frag list\n", skb)
> to netback's start_xmit and saw it trigger (full trace below).

Open vSwitch shouldn't create or use frag_lists in the normal packet
processing path.  However, it does pull more data into the linear data
area compared to the Linux bridge, which affects the skb geometry.  In
fact, looking at the lengths that you previously sent, the linear data
area contains 64 bytes, which is the default amount that we pull in.
It sounds like the original packet that was received was small, GRO
attached a larger one to it with a frag_list, and Open vSwitch pulled
data across, screwing up the layout.  It's a little surprising that
the first packet would be so small but it's possible.

Regardless, it seems like this is a valid operation and something that
skb_segment() should be able to handle.
--
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