netdev - Re: sit: Set SKB_GSO_SIT bit when performing 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: <20150720061459.GA12023@gondor.apana.org.au>
Date:	Mon, 20 Jul 2015 14:14:59 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Wolfgang Walter <linux@...m.de>
Cc:	netdev@...r.kernel.org, Tom Herbert <tom@...bertland.com>
Subject: Re: sit: Set SKB_GSO_SIT bit when performing GRO

On Fri, Jul 17, 2015 at 05:38:30PM +0200, Wolfgang Walter wrote:
>
> eth1 stops sending with the patch after some time
> disabling gro on eth0 helps
> disabling tso or gso on eth0 and/or eth1 or both does not help
> 
> eth0 and eth1 are both intel I350.

What does ethtool -k eth1 say?

Can you confirm that disabling tso on eth1 does not help?

Because the most plausible explanation is that we're feeding
some bogus TSO packet to the hardware causing a tx lockup.

But in any case if it is a hardware lockup then it's no longer
just a pure software bug.  No matter what we do in the stack
the hardware should not lock up (unless of course we're feeding
it something that's completely bogus).

If we can't figure this out then the safest solution would be
to disable tunnel GRO completely because it's broken as it stands.

Cheers,
-- 
Email: Herbert Xu <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