Re: [PATCH 4.4 08/56] ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode
From: Ben Hutchings
Date: Thu Jun 07 2018 - 11:50:05 EST
On Thu, 2018-06-07 at 17:22 +0530, Sriram R wrote:
> Hi Ben,
>
> On 2018-06-04 23:22, Ben Hutchings wrote:
> > On Mon, 2018-05-14 at 08:48 +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.ÂÂIf anyone has any objections, please let meÂ
> > > know.
> > >
> > > ------------------
> > >
> > > From: Vasanthakumar Thiagarajan <vthiagar@xxxxxxxxxxxxxxxx>
> > >
> > > commit 2f38c3c01de945234d23dd163e3528ccb413066d upstream.
> > >
> > > Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
> > > rx_hdr_status is not padded to align in 4-byte boundary. Define a
> > > new hw_params field to handle different alignment behaviour between
> > > different hw. This patch fixes improper retrieval of rfc1042 header
> > > with QCA4019. This patch along with "ath10k: Properly remove padding
> > > from the start of rx payload" will fix traffic failure in ethernet
> > > decap mode for QCA4019.
> > >
> > > Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Kalle Valo <kvalo@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Sriram R <srirrama@xxxxxxxxxxxxxx>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> >
> > [...]
> >
> > I'm curious as to why this backport doesn't include the change to
> > ath10k_htt_rx_h_find_rfc1042().ÂÂI understand that the addition of the
> > new field is a dependency for the following patch, but shouldn't the
> > fix included in the upstream commit also be applied to 4.4?
> >
>
> ÂÂÂOur main intention with this patchset [1] was to provide fix forÂ
> replay detection security issue seen in ath10k driver which needed to beÂ
> in the stable releases.
>
> And, as per stable tree guidelines we wanted the patchset to have onlyÂ
> one and this important fix .
OK, I think the problem here is that the rules say "must" when what's
really meant is "should". So the rule "It must fix only one thing."
really means that commits that each make a single logical change are
strongly preferred.
It does not mean that upstream commits should be trimmed down to
conform to this. Greg generally considers it more important to avoid
changes to the upstream commit, where possible. Right, Greg?
And speaking only for myself, I particularly dislike stable backports
that are significantly different from the original upstream commit but
don't mention this difference in the commit message.
Ben.
> Also we felt the change in ath10k_htt_rx_h_find_rfc1042() is currentlyÂ
> notÂÂa must-have fix in 4.4 stable tree .
>
> [1]
> https://patchwork.kernel.org/patch/10370863/
> https://patchwork.kernel.org/patch/10370865/
>
> Thanks and Regards,
> Sriram.R
>
> > Ben.
>
>
--
Ben Hutchings, Software Developer  Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom