Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756641AbbDPFPa (ORCPT ); Thu, 16 Apr 2015 01:15:30 -0400 Received: from ozlabs.org ([103.22.144.67]:59054 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752664AbbDPFPW (ORCPT ); Thu, 16 Apr 2015 01:15:22 -0400 Date: Thu, 16 Apr 2015 15:15:11 +1000 From: David Gibson To: Thomas Falcon 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() Message-ID: <20150416051511.GA3632@voom.redhat.com> References: <1428903586-21442-1-git-send-email-david@gibson.dropbear.id.au> <552D333E.8050406@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <552D333E.8050406@linux.vnet.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3006 Lines: 80 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 c= ase) > > 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 <=3D in ibmveth_change_mtu(), which only permits an MTU w= hich > > is strictly smaller than the buffer size, rather than allowing the buff= er > > to be completely filled. > > > > This patch fixes the buglet. >=20 >=20 > The same expression is made using < just a few lines above. Shouldn't th= is be changed to <=3D too? >=20 > @@ -1238,7 +1238,7 @@ static int ibmveth_change_mtu(struct net_device *de= v, int new_mtu) > return -EINVAL; > =20 > for (i =3D 0; i < IBMVETH_NUM_BUFF_POOLS; i++) > - if (new_mtu_oh < adapter->rx_buff_pool[i].buff_size) > + if (new_mtu_oh <=3D adapter->rx_buff_pool[i].buff_size) > break; > =20 > if (i =3D=3D IBMVETH_NUM_BUFF_POOLS) Yes, yes it should. Good catch, thanks. --=20 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 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVL0VeAAoJEGw4ysog2bOSH5MP/3akFWo2AnX9yEmyX5UVzE2m /uMzdG/zaZbK1ITc0CjEzHyP1U3q01JHCLiQAWhScsRWeO6GnwLCy7QtApXL0Nuc QWW+mcMj9/acSeJuKKlmVtu0Uxfh+6PJTTIAlJLncb9aObX/YFXuDsbo9fQC/Q9Y Ax0OsMplPxHV5oWL2A1wWz+YFTtIi/1e84XAdag1Gx2t7v0Z19oncpL049lgOjaS XI4hxgKMBezyuycL6lnyAcowuyyBoIrvhlaSPXwlWwjgaJNSs4fS3QFTtRpnyhq3 D3u0ondhcMFay/XgKMwbXD+NatEPDtapr65LY3bZQoc84znZp1l3y2BbSjFvx/pY IjbqLRV6trHVt/TAe9uo67lXftImxvxOqqKMsmEWNq6D+RBTL5neURYQ0TeXsvdf nkdW1MF+bM2oOtRyl7qUVcNrryLZ+R9heENTG76aerDcFWv7rIyGbH2EQGdIHZwM S6iLCJt5c0x9ZzIgm36E0grX7gihupMkt7vLxx+3sCvFEhzoeWGGWkoXC282ocTk GXCFoYrYrWhL5gBCtNs3zoiLDhrJyZqZnl8RBCUa0plDNrlPdgdWNtYChKrhaPEq 2fGzbKBB5QRr/EnHx5AMEuqOO4kaVx4TdMSlj8ZsuI0CEMgEJLtbuh8DBFlP6aQD /dWkMEHfiEhgLSaVA7bx =V9sJ -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/