Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1504487

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

From Jarod Wilson <jarod@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers
Date 2016-10-20 05:20 +0200
Message-ID <suc3D-1Vt-9@gated-at.bofh.it> (permalink)
References <stOXn-2Tk-9@gated-at.bofh.it> <stOXo-2Tk-35@gated-at.bofh.it> <su1Bg-3zK-29@gated-at.bofh.it> <su7Ql-7ys-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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:
> > [...]
> > > diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
> > > index 309311b..b5f125c 100644
> > > --- a/drivers/firewire/net.c
> > > +++ b/drivers/firewire/net.c
> > > @@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct net_device *net)
> > >  	return NETDEV_TX_OK;
> > >  }
> > >  
> > > -static int fwnet_change_mtu(struct net_device *net, int new_mtu)
> > > -{
> > > -	if (new_mtu < 68)
> > > -		return -EINVAL;
> > > -
> > > -	net->mtu = new_mtu;
> > > -	return 0;
> > > -}
> > > -  
> > 
> > This doesn't do any upper bound checking.
> 
> I need to check more closely, but I think the RFC 2734 encapsulation spec
> and our implementation do not impose a particular upper limit.  Though I
> guess it's bad to let userland set arbitrarily large values here.

In which case, that would suggest using IP_MAX_MTU (65535) here.

> > >  static const struct ethtool_ops fwnet_ethtool_ops = {
> > >  	.get_link	= ethtool_op_get_link,
> > >  };
> > > @@ -1366,7 +1357,6 @@ static const struct net_device_ops fwnet_netdev_ops = {
> > >  	.ndo_open       = fwnet_open,
> > >  	.ndo_stop	= fwnet_stop,
> > >  	.ndo_start_xmit = fwnet_tx,
> > > -	.ndo_change_mtu = fwnet_change_mtu,
> > >  };
> > >  
> > >  static void fwnet_init_dev(struct net_device *net)
> > > @@ -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?

> PS:
> If the IP packet plus encapsulation header fits into IEEE 1394 packet
> payload, it is transported without link fragmentation.  If it does not
> fit, link fragmentation occurs (which reduces bandwidth a bit and
> consumes additional buffering resources at the transmitter and the
> receiver).
> 
> Broadcast and multicast packets are transmitted via IEEE 1394 asynchronous
> stream packets at a low bus speed (because our code does not attempt to
> find the maximum speed and size that is supported by all potential
> listeners).  This limits the payload to 512 bytes.
> 
> Unicast packets are transmitted via IEEE 1394 asynchronous write request
> packets at optimum speed.  In most cases, this means that 2048 bytes
> payload is possible, in some cases 4096 bytes.  Many CardBus FireWire
> cards support only 1024 bytes payload of these packets though.
> Furthermore, some low-speed long-haul cablings may cap the bus speed and
> thereby the payload size to 1024 or 512 bytes, but this is uncommon in
> practice.

Thorough as always, Stefan! :)

-- 
Jarod Wilson
jarod@redhat.com

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH net-next 0/6] net: use core MTU range checking everywhere Jarod Wilson <jarod@redhat.com> - 2016-10-19 04:40 +0200
  [PATCH net-next 6/6] net: use core MTU range checking in misc drivers Jarod Wilson <jarod@redhat.com> - 2016-10-19 04:40 +0200
    Re: [PATCH net-next 6/6] net: use core MTU range checking in misc drivers Robin Holt <robinmholt@gmail.com> - 2016-10-19 16:40 +0200
    Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Sabrina Dubroca <sd@queasysnail.net> - 2016-10-19 18:10 +0200
      Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-20 00:50 +0200
        Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 05:20 +0200
          Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 11:40 +0200
            Re: [PATCH net-next 6/6] net: use core MTU range checking in misc  drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 21:00 +0200
  Re: [PATCH net-next 0/6] net: use core MTU range checking  everywhere David Miller <davem@davemloft.net> - 2016-10-19 21:20 +0200
    Re: [PATCH net-next 0/6] net: use core MTU range checking everywhere Jarod Wilson <jarod@redhat.com> - 2016-10-19 21:30 +0200
  [PATCH net-next v2 9/9] ipv4/6: use core net MTU range checking Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
  [PATCH net-next v2 3/9] net: use core MTU range checking in wireless drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    Re: [PATCH net-next v2 3/9] net: use core MTU range checking in  wireless drivers Johannes Berg <johannes@sipsolutions.net> - 2016-10-20 20:30 +0200
      Re: [PATCH net-next v2 3/9] net: use core MTU range checking in  wireless drivers David Miller <davem@davemloft.net> - 2016-10-20 20:50 +0200
  [PATCH net-next v2 1/9] ethernet: use net core MTU range checking in more drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
  [PATCH net-next v2 4/9] net: use core MTU range checking in WAN drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
  [PATCH net-next v2 2/9] net: use core MTU range checking in USB NIC drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
  [PATCH net-next v2 0/9] net: use core MTU range checking everywhere Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    [PATCH net-next v2 5/9] net: use core MTU range checking in core net infra Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
      RE: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers Haiyang Zhang <haiyangz@microsoft.com> - 2016-10-20 20:10 +0200
        RE: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers "Kershner, David A" <David.Kershner@unisys.com> - 2016-10-20 22:50 +0200
      Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers "Michael S. Tsirkin" <mst@redhat.com> - 2016-10-20 22:30 +0200
        Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers Jarod Wilson <jarod@redhat.com> - 2016-10-21 04:40 +0200
          Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers "Michael S. Tsirkin" <mst@redhat.com> - 2016-10-21 05:40 +0200
            Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers Aaron Conole <aconole@bytheb.org> - 2016-10-21 15:30 +0200
      Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt  drivers Wei Liu <wei.liu2@citrix.com> - 2016-10-21 12:10 +0200
    [PATCH net-next v2 8/9] s390/net: use net core MTU range checking Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
    [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers Jarod Wilson <jarod@redhat.com> - 2016-10-20 20:00 +0200
      Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers Rémi Denis-Courmont <remi@remlab.net> - 2016-10-21 09:00 +0200
      Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc  drivers Sebastian Reichel <sre@kernel.org> - 2016-10-21 18:30 +0200
      Re: [net-next,v2,7/9] net: use core MTU range checking in misc drivers Sven Eckelmann <sven@narfation.org> - 2016-10-22 09:30 +0200
      Re: [PATCH net-next v2 7/9] net: use core MTU range checking in  misc drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 21:20 +0200
        Re: [PATCH net-next v2 7/9] net: use core MTU range checking in  misc drivers Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-22 21:30 +0200
          Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc  drivers Jarod Wilson <jarod@redhat.com> - 2016-10-23 03:20 +0200
            [PATCH net-next 1/2] firewire: net: fix maximum possible MTU Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-23 16:30 +0200
              [PATCH net-next 2/2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-23 16:40 +0200
                Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Jarod Wilson <jarod@redhat.com> - 2016-10-24 04:00 +0200
                [PATCH net-next 2/2 v2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-10-24 14:30 +0200
                Re: [PATCH net-next 2/2 v2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards Jarod Wilson <jarod@redhat.com> - 2016-10-25 05:10 +0200
                Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500  unconditionally, fix IPv6 on some CardBus cards David Miller <davem@davemloft.net> - 2016-10-26 23:40 +0200
              Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU Jarod Wilson <jarod@redhat.com> - 2016-10-24 04:00 +0200
              Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU David Miller <davem@davemloft.net> - 2016-10-26 23:40 +0200
    Re: [PATCH net-next v2 0/9] net: use core MTU range checking  everywhere David Miller <davem@davemloft.net> - 2016-10-20 21:00 +0200

csiph-web