All of lore.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Ingo Molnar <mingo@elte.hu>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -rt] Fix TASKLET_STATE_SCHED WARN_ON()
Date: Fri, 15 Jun 2007 14:51:11 -0700	[thread overview]
Message-ID: <1181944271.5998.15.camel@localhost.localdomain> (raw)
In-Reply-To: <20070615155231.GA345@tv-sign.ru>

On Fri, 2007-06-15 at 19:52 +0400, Oleg Nesterov wrote:
> john stultz wrote:
> >
> > The following additional patch should correct this issue. Although since
> > we weren't actually hitting it, the issue is a bit theoretical, so I've
> > not been able to prove it really fixes anything.
> 
> Could you please look at the message below? I sent it privately near a month
> ago, but I think these problems are not fixed yet.

Hmm. Maybe you sent it to others on the cc list, as I can't find it in
my box. But apologies anyway.


> ---------------------------------------------------------------------------
> 
> > +__tasklet_action(struct softirq_action *a, struct tasklet_struct *list)
> > +{
> > +	int loops = 1000000;
> >  
> >  	while (list) {
> >  		struct tasklet_struct *t = list;
> >  
> >  		list = list->next;
> > +		/*
> > +		 * Should always succeed - after a tasklist got on the
> > +		 * list (after getting the SCHED bit set from 0 to 1),
> > +		 * nothing but the tasklet softirq it got queued to can
> > +		 * lock it:
> > +		 */
> > +		if (!tasklet_trylock(t)) {
> > +			WARN_ON(1);
> > +			continue;
> > +		}
> > +
> > +		t->next = NULL;
> > +
> > +		/*
> > +		 * If we cannot handle the tasklet because it's disabled,
> > +		 * mark it as pending. tasklet_enable() will later
> > +		 * re-schedule the tasklet.
> > +		 */
> > +		if (unlikely(atomic_read(&t->count))) {
> > +out_disabled:
> > +			/* implicit unlock: */
> > +			wmb();
> > +			t->state = TASKLET_STATEF_PENDING;
> 
> What if tasklet_enable() happens just before this line ?
> 
> After the next schedule_tasklet() we have all bits set: SCHED, RUN, PENDING.
> The next invocation of __tasklet_action() clears SCHED, but tasklet_tryunlock()
> below can never succeed because of PENDING.

Yep. I've only been focusing on races in schedule/action, as I've been
hunting issues w/ rcu. But I'll agree that the other state changes look
problematic. I know Paul McKenney was looking at some of the other state
changes and was seeing some potential problems as well.

thanks
-john


  reply	other threads:[~2007-06-15 21:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-15 15:52 [PATCH -rt] Fix TASKLET_STATE_SCHED WARN_ON() Oleg Nesterov
2007-06-15 21:51 ` john stultz [this message]
2007-06-15 23:59   ` Oleg Nesterov
  -- strict thread matches above, loose matches on Subject: below --
2007-06-06  2:17 john stultz
2007-06-06  9:45 ` Ingo Molnar
2007-06-06 17:39   ` john stultz
2007-06-06 10:31 ` Jesper Juhl
2007-06-14 21:20 ` john stultz

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=1181944271.5998.15.camel@localhost.localdomain \
    --to=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.