public inbox for linux-staging@lists.linux.dev
 help / color / mirror / Atom feed
From: Dan Carpenter <error27@gmail.com>
To: Martin Kaiser <martin@kaiser.cx>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	Phillip Potter <phil@philpotter.co.uk>,
	Michael Straube <straube.linux@gmail.com>,
	Pavel Skripkin <paskripkin@gmail.com>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: r8188eu: fix NULL check for rcu pointer
Date: Wed, 1 Feb 2023 08:06:31 +0300	[thread overview]
Message-ID: <Y9nzV1CSCh3PvDt9@kadam> (raw)
In-Reply-To: <20230131171613.mubqpogkk5e6lnrk@viti.kaiser.cx>

On Tue, Jan 31, 2023 at 06:16:13PM +0100, Martin Kaiser wrote:
> Hello Greg and all,
> 
> Thus wrote Greg Kroah-Hartman (gregkh@linuxfoundation.org):
> 
> > On Tue, Jan 31, 2023 at 10:00:57AM +0100, Martin Kaiser wrote:
> > > Fix the NULL check for padapter->pnetdev->rx_handler_data.
> 
> > > The current code calls rcu_dereference while it holds the rcu read lock
> > > and checks the pointer after releasing the lock. An rcu pointer may only be
> > > used between calls to rcu_read_lock and rcu_read_unlock.
> 
> > > Replace the check with rcu_access_pointer. My understanding is that this
> > > function returns the value of the pointer and needs no locking. We can
> > > then check the pointer but we must not dereference it.
> 
> > > Signed-off-by: Martin Kaiser <martin@kaiser.cx>
> 
> > What commit id does this fix?
> 
> the code that checks br_port has been around since the driver was
> imported into staging.
> 
> If the patch is considered as a fix, it should have
> 
> Fixes: 15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver")

I don't think it is a fix as we discuss later in the thread.

But if it were then it's still really useful to record that.  I normally
don't record when Fixes are from before the git era because one time,
ten years ago, one person said not to do that.  But really even there I
personally think Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") is useful.

It tells the tools how far to backport things.  It tells us if most of
our bugs come from the very start or if we're introducing them later.

regards,
dan carpenter


  reply	other threads:[~2023-02-01  5:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31  9:00 [PATCH] staging: r8188eu: fix NULL check for rcu pointer Martin Kaiser
2023-01-31 15:09 ` Greg Kroah-Hartman
2023-01-31 17:16   ` Martin Kaiser
2023-02-01  5:06     ` Dan Carpenter [this message]
2023-01-31 15:19 ` Dan Carpenter
2023-01-31 17:23   ` Martin Kaiser

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=Y9nzV1CSCh3PvDt9@kadam \
    --to=error27@gmail.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=martin@kaiser.cx \
    --cc=paskripkin@gmail.com \
    --cc=phil@philpotter.co.uk \
    --cc=straube.linux@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