From: Kalle Valo <kvalo@kernel.org>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Ping-Ke Shih <pkshih@realtek.com>,
"linux-wireless\@vger.kernel.org"
<linux-wireless@vger.kernel.org>, Neo Jou <neojou@gmail.com>,
Hans Ulli Kroll <linux@ulli-kroll.de>,
Yan-Hsuan Chuang <tony0620emma@gmail.com>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
"kernel\@pengutronix.de" <kernel@pengutronix.de>,
Johannes Berg <johannes@sipsolutions.net>,
Alexander Hochbaum <alex@appudo.com>, Da Xue <da@libre.computer>,
Bernie Huang <phhuang@realtek.com>,
Viktor Petrenko <g0000ga@gmail.com>,
neo_jou <neo_jou@realtek.com>
Subject: Re: [PATCH v3 07/11] rtw88: Add common USB chip support
Date: Mon, 28 Nov 2022 15:41:32 +0200 [thread overview]
Message-ID: <87k03f5h83.fsf@kernel.org> (raw)
In-Reply-To: <20221128103000.GC29728@pengutronix.de> (Sascha Hauer's message of "Mon, 28 Nov 2022 11:30:00 +0100")
Sascha Hauer <s.hauer@pengutronix.de> writes:
>> > +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;
>> > +
>> > + while (true) {
>>
>> Is it possible to have a hard limit to prevent unexpected infinite loop?
>
> Yes, that would be possible, but do you think it's necessary?
It's a common advice to have a limit for loops in kernel.
> Each *txcb is used only once, It's allocated in rtw_usb_tx_agg_skb() and
> &txcb->tx_ack_queue is filled with a limited number of skbs there. These
> skbs is then iterated over in rtw_usb_write_port_tx_complete(), so I don't
> see a way how we could end up in an infinite loop here.
Everyone always say that their code is bugfree ;) More seriously though,
even if it would be bugfree now someone else can add buggy code later.
So much better to have a limit for the loop.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2022-11-28 13:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 14:52 [PATCH v3 00/11] RTW88: Add support for USB variants Sascha Hauer
2022-11-22 14:52 ` [PATCH v3 01/11] rtw88: print firmware type in info message Sascha Hauer
2022-11-25 8:27 ` Ping-Ke Shih
2022-11-22 14:52 ` [PATCH v3 02/11] rtw88: Call rtw_fw_beacon_filter_config() with rtwdev->mutex held Sascha Hauer
2022-11-25 8:27 ` Ping-Ke Shih
2022-11-22 14:52 ` [PATCH v3 03/11] rtw88: Drop rf_lock Sascha Hauer
2022-11-25 8:29 ` Ping-Ke Shih
2022-11-22 14:52 ` [PATCH v3 04/11] rtw88: Drop h2c.lock Sascha Hauer
2022-11-22 14:52 ` [PATCH v3 05/11] rtw88: Drop coex mutex Sascha Hauer
2022-11-22 14:52 ` [PATCH v3 06/11] rtw88: iterate over vif/sta list non-atomically Sascha Hauer
2022-11-25 8:50 ` Ping-Ke Shih
2022-11-22 14:52 ` [PATCH v3 07/11] rtw88: Add common USB chip support Sascha Hauer
2022-11-28 2:00 ` Ping-Ke Shih
2022-11-28 10:30 ` Sascha Hauer
2022-11-28 13:41 ` Kalle Valo [this message]
2022-11-22 14:52 ` [PATCH v3 08/11] rtw88: Add rtw8821cu chipset support Sascha Hauer
2022-11-28 2:13 ` Ping-Ke Shih
2022-11-22 14:52 ` [PATCH v3 09/11] rtw88: Add rtw8822bu " Sascha Hauer
2022-11-28 5:39 ` Ryan Finnie
2022-11-22 14:52 ` [PATCH v3 10/11] rtw88: Add rtw8822cu " Sascha Hauer
2022-11-22 14:52 ` [PATCH v3 11/11] rtw88: Add rtw8723du " Sascha Hauer
2022-11-22 14:55 ` [PATCH v3 00/11] RTW88: Add support for USB variants Sascha Hauer
2022-11-24 6:48 ` Ping-Ke Shih
2022-11-24 8:21 ` Sascha Hauer
2022-11-24 8:26 ` Ping-Ke Shih
2022-11-24 8:36 ` Sascha Hauer
2022-11-24 8:33 ` Kalle Valo
2022-11-24 9:20 ` Sascha Hauer
2022-11-28 3:45 ` Ping-Ke Shih
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k03f5h83.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=alex@appudo.com \
--cc=da@libre.computer \
--cc=g0000ga@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@ulli-kroll.de \
--cc=martin.blumenstingl@googlemail.com \
--cc=neo_jou@realtek.com \
--cc=neojou@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=phhuang@realtek.com \
--cc=pkshih@realtek.com \
--cc=s.hauer@pengutronix.de \
--cc=tony0620emma@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).