All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Andrea Parri <parri.andrea@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] swait: add missing barrier to swake_up
Date: Fri, 1 Sep 2017 07:34:01 -0700	[thread overview]
Message-ID: <20170901143401.GR4431@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170901195529.6edca064@roar.ozlabs.ibm.com>

On Fri, Sep 01, 2017 at 07:55:29PM +1000, Nicholas Piggin wrote:
> On Fri, 1 Sep 2017 11:23:22 +0200
> Andrea Parri <parri.andrea@gmail.com> wrote:
> 
> > On Fri, Sep 01, 2017 at 04:14:50PM +1000, Nicholas Piggin wrote:
> > > swake_up and swake_up_all test the swaitqueue outside the lock,
> > > but they are missing the barrier that would ensure visibility
> > > of a previous store that sets the wakeup condition with the
> > > load that tests the swaitqueue. This could lead to a lost wakeup
> > > if there is memory reordering. Fix this as prescribed by the
> > > waitqueue_active comments.
> > > 
> > > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > > --
> > > I noticed this when chasing down that rcu hang bug (which
> > > turned out to not be anything of the sort). I might be missing
> > > something here and it's safe somehow, but if so then it should
> > > have a comment where it diverges from normal waitqueues.
> > > 
> > > It looks like there's a few callers which are also testing
> > > swait_active before swake_up without a barrier which look wrong,
> > > so I must be missing something but I'm not sure what.  
> > 
> > Hi Nicholas. I noticed
> > 
> >   35a2897c2a306cca344ca5c0b43416707018f434
> >   ("sched/wait: Remove the lockless swait_active() check in swake_up*()")
> > 
> > in tip:locking/core.
> 
> Oh thanks, I missed that. Should be in 4.14/stable IMO.

This might well have been helpful to me -- I had forgotten about that
fix and am testing without it -- and suffering what look to be lost
timeouts/wakeups.  :-/

							Thanx, Paul

  reply	other threads:[~2017-09-01 14:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-01  6:14 [PATCH] swait: add missing barrier to swake_up Nicholas Piggin
2017-09-01  9:23 ` Andrea Parri
2017-09-01  9:55   ` Nicholas Piggin
2017-09-01 14:34     ` Paul E. McKenney [this message]
2017-09-01 11:16 ` Peter Zijlstra

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=20170901143401.GR4431@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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.