netdev - Re: [PATCH 0/2] Disable forwarding of LRO skbs

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 May 2008 19:06:34 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Kieran Mansley <kmansley@...arflare.com>
Cc:	David Miller <davem@...emloft.net>, bhutchings@...arflare.com,
	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH 0/2] Disable forwarding of LRO skbs

On Thu, May 01, 2008 at 12:00:28PM +0100, Kieran Mansley wrote:
>
> As an aside, the gso_size field isn't the only one that has a slightly
> different meaning depending on whether the SKB was generated by a stack
> or a device.  The ip_summed field is I think another one, and would
> surely need special handling by  the bridge when forwarding packets.  If
> it's already doing this, there's a precedent for fixing things up there.

You would've been right about ip_summed in the past :)

As it stands I've made it specifically treat inbound/outbound
packets in the same way so this is no longer true.

As to gso_size, I think the crux of the problem is that we're
doing LRO on forwarded traffic at all.  Once you've done it
to a packet we might as well make the stack forward it since
what's done is done and forwarding it is going to be a hell
lot better than dropping it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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