lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 17 Jan 2022 12:54:17 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan@...r.kernel.org
Cc:     netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>
Subject: [PATCH v3 18/41] net: ieee802154: atusb: Call the complete helper when a transmission is over

ieee802154_xmit_complete() is the right helper to call when a
transmission is over. The fact that it completed or not is not really a
question, but drivers must tell the core that the completion is over,
even if it was canceled. Do not call ieee802154_wake_queue() manually,
in order to let full control of this task to the core.

Here the skb is freed with a particular helper because it is done in irq
context. It is not necessary to do that as the *_xmit_complete() helper
will handle it properly anyway.

Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
---
 drivers/net/ieee802154/atusb.c | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
index 1a56073c1c52..4bc7b2dcbdd2 100644
--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -262,19 +262,16 @@ static void atusb_tx_done(struct atusb *atusb, u8 seq)
 	u8 expect = atusb->tx_ack_seq;
 
 	dev_dbg(&usb_dev->dev, "%s (0x%02x/0x%02x)\n", __func__, seq, expect);
-	if (seq == expect) {
-		/* TODO check for ifs handling in firmware */
-		ieee802154_xmit_complete(atusb->hw, atusb->tx_skb, false);
-	} else {
-		/* TODO I experience this case when atusb has a tx complete
-		 * irq before probing, we should fix the firmware it's an
-		 * unlikely case now that seq == expect is then true, but can
-		 * happen and fail with a tx_skb = NULL;
-		 */
-		ieee802154_wake_queue(atusb->hw);
-		if (atusb->tx_skb)
-			dev_kfree_skb_irq(atusb->tx_skb);
-	}
+
+	/* TODO:
+	 * seq == expect: Check for ifs handling in firmware.
+	 * seq != expect: I experience this case when atusb has a tx complete
+	 * irq before probing, we should fix the firmware it's an unlikely case
+	 * now that seq == expect is then true, but can happen and fail with a
+	 * tx_skb = NULL;
+	 */
+
+	ieee802154_xmit_complete(atusb->hw, atusb->tx_skb, false);
 }
 
 static void atusb_in_good(struct urb *urb)
-- 
2.27.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ