[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191211073810.GA398293@kroah.com>
Date: Wed, 11 Dec 2019 08:38:10 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: "Daniel Walker (danielwa)" <danielwa@...co.com>
Cc: "Aviraj Cj (acj)" <acj@...co.com>,
"peppe.cavallaro@...com" <peppe.cavallaro@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"xe-linux-external(mailer list)" <xe-linux-external@...co.com>
Subject: Re: [PATCH 1/2] net: stmmac: use correct DMA buffer size in the RX
descriptor
On Tue, Dec 10, 2019 at 09:40:17PM +0000, Daniel Walker (danielwa) wrote:
> On Tue, Dec 10, 2019 at 09:55:42PM +0100, Greg KH wrote:
> > On Tue, Dec 10, 2019 at 09:06:58AM -0800, Aviraj CJ wrote:
> > > We always program the maximum DMA buffer size into the receive descriptor,
> > > although the allocated size may be less. E.g. with the default MTU size
> > > we allocate only 1536 bytes. If somebody sends us a bigger frame, then
> > > memory may get corrupted.
> > >
> > > Program DMA using exact buffer sizes.
> > >
> > > [Adopted based on upstream commit c13a936f46e3321ad2426443296571fab2feda44
> > > ("net: stmmac: use correct DMA buffer size in the RX descriptor")
> > > by Aaro Koskinen <aaro.koskinen@...ia.com> ]
> >
> > Adopted to what?
> >
> > What is this patch for, it looks just like the commit you reference
> > here.
> >
> > totally confused,
>
>
> We're using the patches on the v4.4 -stable branch. It doesn't have these patches and
> the backport had rejects.
Ok, but commit "c13a936f46e3321ad2426443296571fab2feda44" is not in
Linus's tree, and so I think you really mean 583e63614149 ("net: stmmac:
use correct DMA buffer size in the RX descriptor") which is only
included in 4.19 and newer kernels.
So why would this need to go to 4.4.y?
And if so, it needs to be explicitly stated as such, you all have read
the stable kernel rules file, right?
Please fix up and resend properly, as well as providing a version for
newer kernels also if you really want this in a 4.4.y release.
As David said, to not do so just causes a total waste of developer time
trying to figure out what you all are wanting to do here...
thanks,
greg k-h
Powered by blists - more mailing lists