All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: rcu@vger.kernel.org
Subject: Re: [bug report] rcutorture: Add races with task-exit processing
Date: Wed, 29 Apr 2020 20:43:07 +0300	[thread overview]
Message-ID: <20200429174307.GC1992@kadam> (raw)
In-Reply-To: <20200429154421.GA7560@paulmck-ThinkPad-P72>

On Wed, Apr 29, 2020 at 08:44:21AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 29, 2020 at 04:24:02PM +0300, Dan Carpenter wrote:
> > Hello Paul E. McKenney,
> > 
> > The patch e02882cd57e3: "rcutorture: Add races with task-exit
> > processing" from Apr 24, 2020, leads to the following static checker
> > warning:
> > 
> > 	kernel/rcu/rcutorture.c:2429 rcu_torture_read_exit()
> > 	warn: 'rep' was already freed.
> 
> Ah, good catch, will fix!
> 
> > kernel/rcu/rcutorture.c
> >   2369  static int rcu_torture_read_exit(void *unused)
> >   2370  {
> >   2371          int count = 0;
> >   2372          bool errexit = false;
> >   2373          int i;
> >   2374          struct task_struct **rep;
> >   2375          struct torture_random_state *trsp;
> >   2376  
> >   2377          // Allocate and initialize.
> >   2378          set_user_nice(current, MAX_NICE);
> >   2379          rep = kcalloc(read_exit, sizeof(*rep), GFP_KERNEL);
> >   2380          trsp = kcalloc(read_exit, sizeof(*trsp), GFP_KERNEL);
> >   2381          if (rep && trsp) {
> >   2382                  for (i = 0; i < read_exit; i++)
> >   2383                          torture_random_init(&trsp[i]);
> >   2384                  VERBOSE_TOROUT_STRING("rcu_torture_read_exit: Start of test");
> >   2385          } else {
> >   2386                  kfree(rep);
> >                               ^^^
> >   2387                  kfree(trsp);
> >                               ^^^^
> > Freed.
> 
> And setting both rep and trsp to NULL here takes care of this, correct?
> As in kfree(NULL) is a no-op.  Or is your tool more strict?

Yes, yes.  Setting it to NULL works.  I thought about that, or returning
and I wasn't sure which was prefered.

regards,
dan carpenter


  reply	other threads:[~2020-04-29 17:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 13:24 [bug report] rcutorture: Add races with task-exit processing Dan Carpenter
2020-04-29 15:44 ` Paul E. McKenney
2020-04-29 17:43   ` Dan Carpenter [this message]
2020-04-29 17:47     ` Paul E. McKenney

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=20200429174307.GC1992@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@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.