linux-kernel - Re: [PATCH v3] net:Add sysctl_max_skb

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]

Message-Id: <20160209.043055.1381002982048946744.davem@davemloft.net>
Date:	Tue, 09 Feb 2016 04:30:55 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	hans.westgaard.ry@...cle.com
Cc:	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, tom@...bertland.com, pablo@...filter.org,
	edumazet@...gle.com, fw@...len.de, jiri@...nulli.us,
	alexander.h.duyck@...hat.com, mhocko@...e.com,
	linus.luessing@...3.blue, hannes@...essinduktion.org,
	herbert@...dor.apana.org.au, tj@...nel.org,
	akpm@...ux-foundation.org, alexey.kodanev@...cle.com,
	haakon.bugge@...cle.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH v3] net:Add sysctl_max_skb_frags

From: Hans Westgaard Ry <hans.westgaard.ry@...cle.com>
Date: Wed,  3 Feb 2016 09:26:57 +0100

> Devices may have limits on the number of fragments in an skb they support.
> Current codebase uses a constant as maximum for number of fragments one
> skb can hold and use.
> When enabling scatter/gather and running traffic with many small messages
> the codebase uses the maximum number of fragments and may thereby violate
> the max for certain devices.
> The patch introduces a global variable as max number of fragments.
> 
> Signed-off-by: Hans Westgaard Ry <hans.westgaard.ry@...cle.com>
> Reviewed-by: Håkon Bugge <haakon.bugge@...cle.com>

I know some people don't like this patch, but no better solution exists
at this time.

Like others, I'd personally would rather this be a per-device attribute
but that currently would not work at all.

The device that TCP and other elements see when the build packets is
not necessarily the one that is going to send the frame.  Encapsulation
and other structures hide the truely transmitting device.

And we lack a foolproof way to propagate attributes like this through
the stack of devices up to the top.

So for now this is what we have to use, as unfortunate as it may be.

If someone is suitably angry about this state of affairs, I encourage
them to direct that energy at a better long term solution :-)

Applied and queued up for -stable, thanks.