netdev - Re: [PATCH] net: Check skb->rxhash in gro

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]

Message-ID: <1389752827.31367.314.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 14 Jan 2014 18:27:07 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	David Miller <davem@...emloft.net>, therbert@...gle.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: Check skb->rxhash in gro_receive

On Wed, 2014-01-15 at 01:31 +0000, Ben Hutchings wrote:

> When I investigated the scope of this for Debian, I tried sending a
> 'packet of death' to a VM and actually triggered the lockup in the TX
> path of the *host*, running Debian unstable with Linux 3.11.  I didn't
> track down exactly why that was but I think that libvirt's default
> networking configuration includes multiqueue devices that use flow
> dissector.

OK, I take that majority of debian hosts are running some VM then,
nice to know, time to update my hosts and usages I guess.

Anyway, current flow dissector needs care if we really use it in
unprotected areas.

Hostile packets can force flow dissection of MTU bytes,
bringing host to abysmal performance.

Once we fix all the issues, we'll see how expensive it is and
if it really can help.

Last year, my experiments were exactly using it in GRO, to
have a hash table instead of a single gro_list, unfortunately
this added a latency regression that I found not acceptable at that
time.

With TSO auto sizing, I might need to revisit the idea anyway...

--
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