All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
	syzbot <syzbot+46f513c3033d592409d2@syzkaller.appspotmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Pirko <jiri@resnulli.us>
Subject: Re: [Patch net] net_sched: add a temporary refcnt for struct tcindex_data
Date: Mon, 30 Mar 2020 19:30:10 -0700	[thread overview]
Message-ID: <20200331023009.GI19865@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <CAM_iQpUu6524ZyZDBu=nkuhpubyGBTHEJ-HK8qrpCW=EEKGujw@mail.gmail.com>

On Mon, Mar 30, 2020 at 04:24:42PM -0700, Cong Wang wrote:
> On Mon, Mar 30, 2020 at 2:35 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Sat, Mar 28, 2020 at 12:12:59PM -0700, Cong Wang wrote:
> > > Although we intentionally use an ordered workqueue for all tc
> > > filter works, the ordering is not guaranteed by RCU work,
> > > given that tcf_queue_work() is esstenially a call_rcu().
> > >
> > > This problem is demostrated by Thomas:
> > >
> > >   CPU 0:
> > >     tcf_queue_work()
> > >       tcf_queue_work(&r->rwork, tcindex_destroy_rexts_work);
> > >
> > >   -> Migration to CPU 1
> > >
> > >   CPU 1:
> > >      tcf_queue_work(&p->rwork, tcindex_destroy_work);
> > >
> > > so the 2nd work could be queued before the 1st one, which leads
> > > to a free-after-free.
> > >
> > > Enforcing this order in RCU work is hard as it requires to change
> > > RCU code too. Fortunately we can workaround this problem in tcindex
> > > filter by taking a temporary refcnt, we only refcnt it right before
> > > we begin to destroy it. This simplifies the code a lot as a full
> > > refcnt requires much more changes in tcindex_set_parms().
> > >
> > > Reported-by: syzbot+46f513c3033d592409d2@syzkaller.appspotmail.com
> > > Fixes: 3d210534cc93 ("net_sched: fix a race condition in tcindex_destroy()")
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Paul E. McKenney <paulmck@kernel.org>
> > > Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> > > Cc: Jiri Pirko <jiri@resnulli.us>
> > > Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> >
> > Looks plausible, but what did you do to verify that the structures
> > were in fact being freed?  See below for more detail.
> 
> I ran the syzbot reproducer for about 20 minutes, there was no
> memory leak reported after scanning.

And if you (say) set the initial reference count to two instead of one,
there is a memory leak reported, correct?

							Thanx, Paul

  reply	other threads:[~2020-03-31  2:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-28 19:12 [Patch net] net_sched: add a temporary refcnt for struct tcindex_data Cong Wang
2020-03-30 21:35 ` Paul E. McKenney
2020-03-30 23:24   ` Cong Wang
2020-03-31  2:30     ` Paul E. McKenney [this message]
2020-03-31  2:54       ` Cong Wang
2020-03-31 13:30         ` Paul E. McKenney
2020-04-01 18:07 ` David Miller

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=20200331023009.GI19865@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=syzbot+46f513c3033d592409d2@syzkaller.appspotmail.com \
    --cc=tglx@linutronix.de \
    --cc=xiyou.wangcong@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 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.