[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f65e44cf7d14a228f03eb0ba3b018d7@realtek.com>
Date: Wed, 30 Nov 2022 08:35:57 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: Sascha Hauer <s.hauer@...gutronix.de>
CC: "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
Neo Jou <neojou@...il.com>,
Hans Ulli Kroll <linux@...i-kroll.de>,
Yan-Hsuan Chuang <tony0620emma@...il.com>,
Kalle Valo <kvalo@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Martin Blumenstingl" <martin.blumenstingl@...glemail.com>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
Johannes Berg <johannes@...solutions.net>,
Alexander Hochbaum <alex@...udo.com>,
Da Xue <da@...re.computer>,
"Bernie Huang" <phhuang@...ltek.com>,
Viktor Petrenko <g0000ga@...il.com>,
neo_jou <neo_jou@...ltek.com>
Subject: RE: [PATCH v4 07/11] wifi: rtw88: Add common USB chip support
> -----Original Message-----
> From: Sascha Hauer <s.hauer@...gutronix.de>
> Sent: Wednesday, November 30, 2022 4:13 PM
> To: Ping-Ke Shih <pkshih@...ltek.com>
> Cc: linux-wireless@...r.kernel.org; Neo Jou <neojou@...il.com>; Hans Ulli Kroll <linux@...i-kroll.de>;
> Yan-Hsuan Chuang <tony0620emma@...il.com>; Kalle Valo <kvalo@...nel.org>; netdev@...r.kernel.org;
> linux-kernel@...r.kernel.org; Martin Blumenstingl <martin.blumenstingl@...glemail.com>;
> kernel@...gutronix.de; Johannes Berg <johannes@...solutions.net>; Alexander Hochbaum <alex@...udo.com>;
> Da Xue <da@...re.computer>; Bernie Huang <phhuang@...ltek.com>; Viktor Petrenko <g0000ga@...il.com>;
> neo_jou <neo_jou@...ltek.com>
> Subject: Re: [PATCH v4 07/11] wifi: rtw88: Add common USB chip support
>
> On Wed, Nov 30, 2022 at 01:40:36AM +0000, Ping-Ke Shih wrote:
> >
> >
> > > -----Original Message-----
> > > From: Sascha Hauer <s.hauer@...gutronix.de>
> > > Sent: Tuesday, November 29, 2022 6:08 PM
> > > To: linux-wireless@...r.kernel.org
> > > Cc: Neo Jou <neojou@...il.com>; Hans Ulli Kroll <linux@...i-kroll.de>; Ping-Ke Shih
> <pkshih@...ltek.com>;
> > > Yan-Hsuan Chuang <tony0620emma@...il.com>; Kalle Valo <kvalo@...nel.org>; netdev@...r.kernel.org;
> > > linux-kernel@...r.kernel.org; Martin Blumenstingl <martin.blumenstingl@...glemail.com>;
> > > kernel@...gutronix.de; Johannes Berg <johannes@...solutions.net>; Alexander Hochbaum
> <alex@...udo.com>;
> > > Da Xue <da@...re.computer>; Bernie Huang <phhuang@...ltek.com>; Viktor Petrenko <g0000ga@...il.com>;
> > > Sascha Hauer <s.hauer@...gutronix.de>; neo_jou <neo_jou@...ltek.com>
> > > Subject: [PATCH v4 07/11] wifi: rtw88: Add common USB chip support
> > >
> > > Add the common bits and pieces to add USB support to the RTW88 driver.
> > > This is based on https://github.com/ulli-kroll/rtw88-usb.git which
> > > itself is first written by Neo Jou.
> > >
> > > Signed-off-by: neo_jou <neo_jou@...ltek.com>
> > > Signed-off-by: Hans Ulli Kroll <linux@...i-kroll.de>
> > > Signed-off-by: Sascha Hauer <s.hauer@...gutronix.de>
> > > ---
> >
> > > +static void rtw_usb_write_port_tx_complete(struct urb *urb)
> > > +{
> > > + struct rtw_usb_txcb *txcb = urb->context;
> > > + struct rtw_dev *rtwdev = txcb->rtwdev;
> > > + struct ieee80211_hw *hw = rtwdev->hw;
> > > + int max_iter = RTW_USB_MAX_XMITBUF_SZ;
> > > +
> > > + while (true) {
> > > + struct sk_buff *skb = skb_dequeue(&txcb->tx_ack_queue);
> > > + struct ieee80211_tx_info *info;
> > > + struct rtw_usb_tx_data *tx_data;
> > > +
> > > + if (!skb)
> > > + break;
> > > +
> > > + if (!--max_iter) {
> >
> > Don't you need to free 'skb'? or you should not dequeue skb in this situation?
>
> My first reaction here was to call skb_queue_purge(), but that is
> implemented as:
>
> while ((skb = skb_dequeue(list)) != NULL)
> kfree_skb(skb);
>
> So basically it brings us into the same endless loop we are trying to
> break out here.
>
> If it was me I would just remove this check. *txcb is allocated once
> in rtw_usb_tx_agg_skb(), &txcb->tx_ack_queue is added the number of skbs
> that fit into RTW_USB_MAX_XMITBUF_SZ and here we dequeue these skbs
> again. No other code even has the pointer to add skbs to this queue
> concurrently.
Agree with you after I trace the flow again. The number of skb is limited
and all skb(s) belong to this urb must be freed in one go, or we don't
have another chance to free them. Therefore, I think we can use this
chunk of v3.
Ping-Ke
Powered by blists - more mailing lists