Re: [PATCH 4.4 08/56] ath10k: fix rfc1042 header retrieval in QCA4019 with eth decap mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2018-06-07 at 18:16 +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 07, 2018 at 04:49:57PM +0100, Ben Hutchings wrote:
> > 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.
> 
> I _STRONGLY_ dislike backports that are different than what is in
> Linus's tree and normally I catch it when someone tries to do that.  I
> missed this one here, and that's not ok on my part for missing that, and
> for the authors part in doing that :(
> 
> So, what to do here, should I revert this series and take a fixed-up
> one?  What exactly is the stable tree now missing because of this
> mistake?

If you apply the attached patch, that should complete the backporting
of commit 2f38c3c01de9.  I'm not able to test the driver but the change
looks reasonable and it builds OK.

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom
From 89166b7bbc5a50ca22abf2215eed74c788cae286 Mon Sep 17 00:00:00 2001
From: Vasanthakumar Thiagarajan <vthiagar@xxxxxxxxxxxxxxxx>
Date: Mon, 26 Sep 2016 21:56:24 +0300
Subject: [PATCH] ath10k: fix rfc1042 header retrieval in QCA4019 with eth
 decap mode

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>
[bwh: This just adds the part that was left out of the previous backport,
 commit b88fb9ea475a.]
Signed-off-by: Ben Hutchings <ben.hutchings@xxxxxxxxxxxxxxx>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index d26cb37b1fbd..b32c47fe926d 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1166,6 +1166,7 @@ static void *ath10k_htt_rx_h_find_rfc1042(struct ath10k *ar,
 	size_t hdr_len, crypto_len;
 	void *rfc1042;
 	bool is_first, is_last, is_amsdu;
+	int bytes_aligned = ar->hw_params.decap_align_bytes;
 
 	rxd = (void *)msdu->data - sizeof(*rxd);
 	hdr = (void *)rxd->rx_hdr_status;
@@ -1182,8 +1183,8 @@ static void *ath10k_htt_rx_h_find_rfc1042(struct ath10k *ar,
 		hdr_len = ieee80211_hdrlen(hdr->frame_control);
 		crypto_len = ath10k_htt_rx_crypto_param_len(ar, enctype);
 
-		rfc1042 += round_up(hdr_len, 4) +
-			   round_up(crypto_len, 4);
+		rfc1042 += round_up(hdr_len, bytes_aligned) +
+			   round_up(crypto_len, bytes_aligned);
 	}
 
 	if (is_amsdu)
-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom


[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux