All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jérôme Pouiller" <jerome.pouiller@silabs.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 15:29:34 +0200	[thread overview]
Message-ID: <5203347.001cLfkWmS@pc-42> (raw)
In-Reply-To: <20201010124034.GA1701199@kroah.com>

On Saturday 10 October 2020 14:40:34 CEST Greg Kroah-Hartman wrote:
> 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.

Totally agree. I initially did that. However, the device is a field of
wvif which is NULL in this case.

I could have changed the code to get the real pointer to the device. But
I didn't want to clutter the code just for a debug message (and also
because I was a bit lazy).

-- 
Jérôme Pouiller



  reply	other threads:[~2020-10-10 23:15 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
2020-10-10 13:29         ` Jérôme Pouiller [this message]
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=5203347.001cLfkWmS@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.