From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Jérôme Pouiller" <jerome.pouiller@silabs.com>
Cc: Kalle Valo <kvalo@codeaurora.org>,
devel@driverdev.osuosl.org, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
"David S . Miller" <davem@davemloft.net>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH 3/8] staging: wfx: standardize the error when vif does not exist
Date: Sat, 10 Oct 2020 14:40:34 +0200 [thread overview]
Message-ID: <20201010124034.GA1701199@kroah.com> (raw)
In-Reply-To: <2632043.z0MBYUB4Ha@pc-42>
On Sat, Oct 10, 2020 at 02:22:13PM +0200, Jérôme Pouiller wrote:
> On Friday 9 October 2020 20:52:47 CEST Kalle Valo wrote:
> > Jerome Pouiller <Jerome.Pouiller@silabs.com> writes:
> >
> > > From: Jérôme Pouiller <jerome.pouiller@silabs.com>
> > >
> > > Smatch complains:
> > >
> > > drivers/staging/wfx/hif_rx.c:177 hif_scan_complete_indication() warn: potential NULL parameter dereference 'wvif'
> > > drivers/staging/wfx/data_tx.c:576 wfx_flush() warn: potential NULL parameter dereference 'wvif'
> > >
> > > Indeed, if the vif id returned by the device does not exist anymore,
> > > wdev_to_wvif() could return NULL.
> > >
> > > In add, the error is not handled uniformly in the code, sometime a
> > > WARN() is displayed but code continue, sometime a dev_warn() is
> > > displayed, sometime it is just not tested, ...
> > >
> > > This patch standardize that.
> > >
> > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> > > ---
> > > drivers/staging/wfx/data_tx.c | 5 ++++-
> > > drivers/staging/wfx/hif_rx.c | 34 ++++++++++++++++++++++++----------
> > > drivers/staging/wfx/sta.c | 4 ++++
> > > 3 files changed, 32 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
> > > index b4d5dd3d2d23..8db0be08daf8 100644
> > > --- a/drivers/staging/wfx/data_tx.c
> > > +++ b/drivers/staging/wfx/data_tx.c
> > > @@ -431,7 +431,10 @@ static void wfx_skb_dtor(struct wfx_vif *wvif, struct sk_buff *skb)
> > > sizeof(struct hif_req_tx) +
> > > req->fc_offset;
> > >
> > > - WARN_ON(!wvif);
> > > + if (!wvif) {
> > > + pr_warn("%s: vif associated with the skb does not exist anymore\n", __func__);
> > > + return;
> > > + }
> >
> > I'm not really a fan of using function names in warning or error
> > messages as it clutters the log. In debug messages I think they are ok.
>
> In the initial code, I used WARN() that far more clutters the log (I
> have stated that a backtrace won't provide any useful information, so
> pr_warn() was better suited).
>
> In add, in my mind, these warnings are debug messages. If they appears,
> the user should probably report a bug.
>
> Finally, in this patch, I use the same message several times (ok, not
> this particular one). So the function name is a way to differentiate
> them.
You should use dev_*() for these, that way you can properly determine
the exact device as well.
thanks,
greg k-h
next prev parent reply other threads:[~2020-10-10 22:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 17:12 [PATCH 0/8] staging: wfx: fix issues reported by Smatch Jerome Pouiller
2020-10-09 17:13 ` [PATCH 1/8] staging: wfx: improve error handling of hif_join() Jerome Pouiller
2020-10-09 17:13 ` [PATCH 2/8] staging: wfx: check memory allocation Jerome Pouiller
2020-10-09 18:51 ` Kalle Valo
2020-10-10 12:07 ` Jérôme Pouiller
2020-10-10 13:18 ` Dan Carpenter
2020-10-10 13:54 ` Dan Carpenter
2020-10-09 17:13 ` [PATCH 3/8] staging: wfx: standardize the error when vif does not exist Jerome Pouiller
2020-10-09 18:52 ` Kalle Valo
2020-10-10 12:22 ` Jérôme Pouiller
2020-10-10 12:40 ` Greg Kroah-Hartman [this message]
2020-10-10 13:29 ` Jérôme Pouiller
2020-10-09 17:13 ` [PATCH 4/8] staging: wfx: wfx_init_common() returns NULL on error Jerome Pouiller
2020-10-09 17:13 ` [PATCH 5/8] staging: wfx: increase robustness of hif_generic_confirm() Jerome Pouiller
2020-10-09 17:13 ` [PATCH 6/8] staging: wfx: gpiod_get_value() can return an error Jerome Pouiller
2020-10-09 17:13 ` [PATCH 7/8] staging: wfx: drop unicode characters from strings Jerome Pouiller
2020-10-09 17:13 ` [PATCH 8/8] staging: wfx: improve robustness of wfx_get_hw_rate() Jerome Pouiller
2020-10-16 1:50 ` Nathan Chancellor
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=20201010124034.GA1701199@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=devel@driverdev.osuosl.org \
--cc=jerome.pouiller@silabs.com \
--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.