From: "Jérôme Pouiller" <Jerome.Pouiller@silabs.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"David S . Miller" <davem@davemloft.net>,
Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [PATCH 3/5] staging: wfx: make warning about pending frame less scary
Date: Fri, 13 Mar 2020 15:34:43 +0000 [thread overview]
Message-ID: <6287924.ghGFUMk3OD@pc-42> (raw)
In-Reply-To: <20200312143019.GN11561@kadam>
On Thursday 12 March 2020 15:30:19 CET Dan Carpenter wrote:
> On Tue, Mar 10, 2020 at 11:13:54AM +0100, Jerome Pouiller wrote:
[...]
> So it really helps me if the commit message restates the subject. The
> truth is that I don't really even like the advice that Josh wrote in
> the howto about patch descriptions. I normally start by explaining the
> problem then how I solved it. But I try not to be a pedant, so long as
> I can understand the problem and the patch that's fine. So how I would
> write this commit message is:
>
> The warning message about releasing a station while Tx is in
> progress will trigger a stack trace, possibly a reboot depending
> on the configuration, and a syzbot email. It's not necessarily
> a big deal that transmission is still in process so let's make the
> warning less scary.
Indeed, my idea was the reviewers start by reading subjects and then read
the body of the commit. I will care now.
> > Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> > ---
> > drivers/staging/wfx/sta.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
> > index 03d0f224ffdb..010e13bcd33e 100644
> > --- a/drivers/staging/wfx/sta.c
> > +++ b/drivers/staging/wfx/sta.c
> > @@ -605,7 +605,9 @@ int wfx_sta_remove(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> > int i;
> >
> > for (i = 0; i < ARRAY_SIZE(sta_priv->buffered); i++)
> > - WARN(sta_priv->buffered[i], "release station while Tx is in progress");
> > + if (sta_priv->buffered[i])
> > + dev_warn(wvif->wdev->dev, "release station while %d pending frame on queue %d",
> > + sta_priv->buffered[i], i);
>
> Why print a warning message at all if this is a normal situation? Just
> delete the whole thing.
I saw cases where it happened and it seems harmless. In add, this code
is going to be released with 5.6. So, the WARN have to be removed.
However, I think it is not normal. Even if it is harmless, it is the
symptom of something unclean.
So, I think that dev_warn() is the correct level of notification.
(I should have included that in the commit log)
--
Jérôme Pouiller
next prev parent reply other threads:[~2020-03-13 15:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 10:13 [PATCH 0/5] staging: wfx: late fixes Jerome Pouiller
2020-03-10 10:13 ` [PATCH 1/5] staging: wfx: fix warning about freeing in-use mutex during device unregister Jerome Pouiller
2020-03-10 10:13 ` [PATCH 2/5] staging: wfx: fix lines ending with a comma instead of a semicolon Jerome Pouiller
2020-03-12 14:14 ` Dan Carpenter
2020-03-10 10:13 ` [PATCH 3/5] staging: wfx: make warning about pending frame less scary Jerome Pouiller
2020-03-12 14:30 ` Dan Carpenter
2020-03-13 15:34 ` Jérôme Pouiller [this message]
2020-03-10 10:13 ` [PATCH 4/5] staging: wfx: fix RCU usage in wfx_join_finalize() Jerome Pouiller
2020-03-10 10:13 ` [PATCH 5/5] staging: wfx: fix RCU usage between hif_join() and ieee80211_bss_get_ie() Jerome Pouiller
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=6287924.ghGFUMk3OD@pc-42 \
--to=jerome.pouiller@silabs.com \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.