mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Cc: anton@au1.ibm.com, benh@kernel.crashing.org,
	michael@ellerman.id.au, linux-kernel@vger.kernel.org,
	linuxppc-dev@vger.kernel.org
Subject: Re: [PATCH] ibmveth: Fix off-by-one error in ibmveth_change_mtu()
Date: Thu, 16 Apr 2015 15:15:11 +1000	[thread overview]
Message-ID: <20150416051511.GA3632@voom.redhat.com> (raw)
In-Reply-To: <552D333E.8050406@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

On Tue, Apr 14, 2015 at 10:33:18AM -0500, Thomas Falcon wrote:
> On 04/13/2015 12:39 AM, David Gibson wrote:
> > AFAIK the PAPR document which defines the virtual device interface used by
> > the ibmveth driver doesn't specify a specific maximum MTU.  So, in the
> > ibmveth driver, the maximum allowed MTU is determined by the maximum
> > allocated buffer size of 64k (corresponding to one page in the common case)
> > minus the per-buffer overhead IBMVETH_BUFF_OH (which has value 22 for 14
> > bytes of ethernet header, plus 8 bytes for an opaque handle).
> >
> > This suggests a maximum allowable MTU of 65514 bytes, but in fact the
> > driver only permits a maximum MTU of 65513.  This is because there is a <
> > instead of an <= in ibmveth_change_mtu(), which only permits an MTU which
> > is strictly smaller than the buffer size, rather than allowing the buffer
> > to be completely filled.
> >
> > This patch fixes the buglet.
> 
> 
> The same expression is made using < just a few lines above.  Shouldn't this be changed to <= too?
> 
> @@ -1238,7 +1238,7 @@ static int ibmveth_change_mtu(struct net_device *dev, int new_mtu)
>                 return -EINVAL;
>  
>         for (i = 0; i < IBMVETH_NUM_BUFF_POOLS; i++)
> -               if (new_mtu_oh < adapter->rx_buff_pool[i].buff_size)
> +               if (new_mtu_oh <= adapter->rx_buff_pool[i].buff_size)
>                         break;
>  
>         if (i == IBMVETH_NUM_BUFF_POOLS)

Yes, yes it should.

Good catch, thanks.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2015-04-16  5:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13  5:39 David Gibson
2015-04-14 15:33 ` Thomas Falcon
2015-04-16  5:15   ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150416051511.GA3632@voom.redhat.com \
    --to=david@gibson.dropbear.id.au \
    --cc=anton@au1.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@vger.kernel.org \
    --cc=michael@ellerman.id.au \
    --cc=tlfalcon@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome