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: <1365759801.15783.11.camel@zakaz.uk.xensource.com>
Date:	Fri, 12 Apr 2013 10:43:21 +0100
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Wei Liu <wei.liu2@...rix.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	David Vrabel <david.vrabel@...rix.com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
	"annie.li@...cle.com" <annie.li@...cle.com>,
	"wdauchy@...il.com" <wdauchy@...il.com>
Subject: Re: [PATCH 5/7] xen-netfront: reduce gso_max_size to account for
 ethernet header

On Fri, 2013-04-12 at 10:34 +0100, Wei Liu wrote:
> On Fri, Apr 12, 2013 at 09:57:15AM +0100, Ian Campbell wrote:
> > On Fri, 2013-04-12 at 09:48 +0100, Wei Liu wrote:
> > > On Fri, Apr 12, 2013 at 09:18:04AM +0100, Ian Campbell wrote:
> > > > On Thu, 2013-04-11 at 21:04 +0100, Wei Liu wrote:
> > > > > On Tue, Apr 09, 2013 at 12:07:33PM +0100, Wei Liu wrote:
> > > > > > The maximum packet including ethernet header that can be handled by netfront /
> > > > > > netback wire format is 65535. Reduce gso_max_size accordingly.
> > > > > > 
> > > > > > Drop skb and print warning when skb->len > 65535. This can 1) save the effort
> > > > > > to send malformed packet to netback, 2) help spotting misconfiguration of
> > > > > > netfront in the future.
> > > > > > 
> > > > > 
> > > > > Any opinion on how much space should be reserved? From a previous thread
> > > > > Ben seemed to suggest 90 (Ethernet + VLAN tag + IPv6 + TCP + timestamp
> > > > > option = 90 bytes).
> > > > 
> > > > I trust Ben and that seems as good as anything to me.
> > > > 
> > > > Is this the sort of limit others might be interested in, should we have
> > > > a global #define?
> > > > 
> > > 
> > > We shall have a global define in this case.
> > > 
> > > #define XEN_NETFRONT_MAX_HEADER ? I'm bad at naming things.
> > 
> > I meant an include/linux/skbuff.h (or some suitable header) #define
> > SKB_MAX_FOO type thing...
> > 
> 
> But we don't have handle on this. If I understand correctly the
> discussion in other thread, 90 is empirical value, not something
> documented.

My original question was effectively "is anyone else going to be
interested in this empirical value", if so then it seems like it would
be useful to have it centrally defined.

Ian.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ