linux-kernel - Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers

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: <20161022205157.0b89a013@kant>
Date:   Sat, 22 Oct 2016 20:51:57 +0200
From:   Stefan Richter <stefanr@...6.in-berlin.de>
To:     Jarod Wilson <jarod@...hat.com>
Cc:     Sabrina Dubroca <sd@...asysnail.net>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, Faisal Latif <faisal.latif@...el.com>,
        linux-rdma@...r.kernel.org, Cliff Whickman <cpw@....com>,
        Robin Holt <robinmholt@...il.com>,
        Jes Sorensen <jes@...ined-monkey.org>,
        Marek Lindner <mareklindner@...mailbox.ch>,
        Simon Wunderlich <sw@...onwunderlich.de>,
        Antonio Quartulli <a@...table.cc>
Subject: Re: [PATCH net-next 6/6] net: use core MTU range checking in misc
 drivers

On Oct 22 Stefan Richter wrote:
> On Oct 19 Jarod Wilson wrote:
> > On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:  
> > > On Oct 19 Sabrina Dubroca wrote:  
> > > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
[...]
> > > > > @@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
> > > > >  	max_mtu = (1 << (card->max_receive + 1))
> > > > >  		  - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
> > > > >  	net->mtu = min(1500U, max_mtu);
> > > > > +	net->min_mtu = ETH_MIN_MTU;
> > > > > +	net->max_mtu = net->mtu;    
> > > > 
> > > > But that will now prevent increasing the MTU above the initial value?  
> > > 
> > > Indeed, therefore NAK.  
> > 
> > However, there's an explicit calculation for 'max_mtu' right there that I
> > glazed right over. It would seem perhaps *that* should be used for
> > net->max_mtu here, no?  
> 
> No.  This 'max_mtu' here is not the absolute maximum.  It is only an
> initial MTU which has the property that link fragmentation is not
> going to happen (if all other peers will at least as capable as this
> node).

Besides, card->max_receive is about what the card can receive (at the IEEE
1394 link layer), not about what the card can send.
-- 
Stefan Richter
-======----- =-=- =-==-
http://arcgraph.de/sr/