[BUG] netpoll is unable to handle skb's using packet split

[BUG] netpoll is unable to handle skb's using packet split

[Jeff Kirsher]

When using packet split, netpoll times out when doing a netdump.

Server logs:
--netdump[14973]: Got too many timeouts in handshaking, ignoring
client 172.0.2.250
--netdump[14973]: Got too many timeouts waiting for SHOW_STATUS for
client 172.0.2.250, rebooting it.

When packet split is not used, netpoll dumps correctly.  This was
reproduced using the initial setup:

HP DL380G3 (Server)
RHEL4 U1
7170 NIC
e1000 driver

HP DL380G4 (Client)
RHEL3 U5
7170 NIC
e1000 driver

We also tested using the latest RHEL4 U2 on the client, with the same results.

Netpoll does not appear to be able to handle skb's using packet split,
a possible resolution would be to test for packet split and to use
skb_linearize() in netpoll to resolve the issue.

--
Cheers,
Jeff

Re: [BUG] netpoll is unable to handle skb's using packet split

[Matt Mackall]

On Mon, Nov 14, 2005 at 01:15:38PM -0800, Jeff Kirsher wrote:
> When using packet split, netpoll times out when doing a netdump.

What is "packet split" in this context? You ought to cc: the netdump
people as well, as it's not part of the mainline kernel.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [BUG] netpoll is unable to handle skb's using packet split

[David S. Miller]

From: Matt Mackall <mpm@selenic.com>
Date: Mon, 14 Nov 2005 21:23:58 -0800

> What is "packet split" in this context?

It's a mode of buffering used by the e1000 driver.

Re: [BUG] netpoll is unable to handle skb's using packet split

[David S. Miller]

From: "David S. Miller" <davem@davemloft.net>
Date: Mon, 14 Nov 2005 21:39:22 -0800 (PST)

> From: Matt Mackall <mpm@selenic.com>
> Date: Mon, 14 Nov 2005 21:23:58 -0800
> 
> > What is "packet split" in this context?
> 
> It's a mode of buffering used by the e1000 driver.

BTW, the issue is that in packet split mode, the e1000 driver is
feeding paged based non-linear SKBs into the stack on receive which is
completely legal but aparently netpoll or something parsing netpoll RX
packets does not handle it properly.

That's why the reporter suggested that perhaps an skb_linearize()
call could be added to fix the problem, but it is unknown whether
that call can be made in the context in which it would be needed.

Re: [BUG] netpoll is unable to handle skb's using packet split

[Matt Mackall]

On Mon, Nov 14, 2005 at 09:41:30PM -0800, David S. Miller wrote:
> From: "David S. Miller" <davem@davemloft.net>
> Date: Mon, 14 Nov 2005 21:39:22 -0800 (PST)
> 
> > From: Matt Mackall <mpm@selenic.com>
> > Date: Mon, 14 Nov 2005 21:23:58 -0800
> > 
> > > What is "packet split" in this context?
> > 
> > It's a mode of buffering used by the e1000 driver.
> 
> BTW, the issue is that in packet split mode, the e1000 driver is
> feeding paged based non-linear SKBs into the stack on receive which is
> completely legal but aparently netpoll or something parsing netpoll RX
> packets does not handle it properly.

The bug is in netpoll. It's non-linear ignorant. We probably can't
call skb_linearize because it wants to kmalloc, but we probably can
follow the fragment. Or, worst case, we can manually linearize into an
SKB in our private pool.

Can we make any assumptions about the size and position of fragments.
For instance, will the first N data bytes of a UDP packet all be in
the same fragment?

-- 
Mathematics is the supreme nostalgia of our time.

Re: [BUG] netpoll is unable to handle skb's using packet split

[David S. Miller]

From: Matt Mackall <mpm@selenic.com>
Date: Mon, 14 Nov 2005 22:29:47 -0800

> Can we make any assumptions about the size and position of fragments.
> For instance, will the first N data bytes of a UDP packet all be in
> the same fragment?

Nope, they can be fragmented any way possible.

For packet parsing, you don't need any of this anyways.
Just use the things that the normal network input stack
uses, for example you could use something like
skb_header_pointer(), or pskb_may_pull().

For example, a clean way to parse a UDP header at the
front of an SKB is:

	struct udphdr *uh, _tmp;

	uh = skb_header_pointer(skb, 0, sizeof(_tmp), &_tmp);
	if (uh->sport = foo && uh->dport == bar)
		...

The UDP input path uses:

	struct udphdr *uh;

	if (!pskb_may_pull(skb, sizeof(struct udphdr)))
		goto header_error;

	uh = skb->h.uh;

Unfortunately, pskb_may_pull() may need to call __pskb_pull_tail()
which in turn might do a pskb_expand_head() and thus a GFP_ATOMIC
memory allocation.