Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 7 Feb 2021 18:39:36 +0800
From:   Kevin Hao <haokexin@gmail.com>
To:     Pavel Machek <pavel@ucw.cz>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Subbaraya Sundeep <sbhatta@marvell.com>,
        Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH 5.10 04/57] net: octeontx2: Make sure the buffer is 128
 byte aligned
Message-ID: <20210207103936.GD170970@pek-khao-d2.corp.ad.wrs.com>
References: <20210205140655.982616732@linuxfoundation.org>
 <20210205140656.168305608@linuxfoundation.org>
 <20210207092015.GA32297@amd>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="lc9FT7cWel8HagAv"
Content-Disposition: inline
In-Reply-To: <20210207092015.GA32297@amd>
Precedence: bulk


--lc9FT7cWel8HagAv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 07, 2021 at 10:20:15AM +0100, Pavel Machek wrote:
> Hi!
>=20
> > commit db2805150a0f27c00ad286a29109397a7723adad upstream.
> >=20
> > The octeontx2 hardware needs the buffer to be 128 byte aligned.
> > But in the current implementation of napi_alloc_frag(), it can't
> > guarantee the return address is 128 byte aligned even the request size
> > is a multiple of 128 bytes, so we have to request an extra 128 bytes and
> > use the PTR_ALIGN() to make sure that the buffer is aligned correctly.
> >=20
> > +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> > @@ -473,10 +473,11 @@ dma_addr_t __otx2_alloc_rbuf(struct otx2
> >  	dma_addr_t iova;
> >  	u8 *buf;
> > =20
> > -	buf =3D napi_alloc_frag(pool->rbsize);
> > +	buf =3D napi_alloc_frag(pool->rbsize + OTX2_ALIGN);
> >  	if (unlikely(!buf))
> >  		return -ENOMEM;
> > =20
> > +	buf =3D PTR_ALIGN(buf, OTX2_ALIGN);
>=20
> So we allocate a buffer, then change it, and then pass modified
> pointer to the page_frag_free(buf); in the error path. That... can't
> be right, right?

It doesn't matter. It will work as far as the address we passed to page_fra=
g_free()
is in the range of buf ~ (buf + rbsize).

>=20
> >  	iova =3D dma_map_single_attrs(pfvf->dev, buf, pool->rbsize,
> >  				    DMA_FROM_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
> >  	if (unlikely(dma_mapping_error(pfvf->dev, iova))) {
>=20
> BTW otx2_alloc_rbuf and __otx2_alloc_rbuf should probably return s64,
> as they return negative error code...

It does seem buggy to return dma_addr_t for these two functions, I will coo=
k up
a patch to fix this issue.

Thanks,
Kevin

>=20
> Best regards,
> 							Pavel
>=20
> --=20
> http://www.livejournal.com/~pavelmachek


--lc9FT7cWel8HagAv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEHc6qFoLCZqgJD98Zk1jtMN6usXEFAmAfw2gACgkQk1jtMN6u
sXGDYQf/Y6Lodxjvr+c0ps/RsUBkxfoJSRHOD/tsQlq6GDCpqyRgpF3rIpqVXtzZ
WWYhqa5AbxtM5sep/tkQLKIO60zFiqMqpY219DaogN4a5K14sBrXEGIF88dBXIJ2
6BYcE/2ICZyZGht3oQ/ExbqQee3g3Z132RGpmmRJlQrarB12hjEFtag4pS39UiD0
ik1tAsRupeI6PhIlcsb3xZE8pfeu/eggdV+VJwIccapQBW/4SaHJnTZ/PIxbXOu6
ZF0kkQz9RY25xee1kwYZmiLNH1/8lQ98pLOyONJWpPQAZE4sT4i6JeMlryyi8JU4
ht0hFU2t+PNrPfNoMt3BveSPts19iA==
=H+c6
-----END PGP SIGNATURE-----

--lc9FT7cWel8HagAv--