[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160225081144.GX6357@twins.programming.kicks-ass.net>
Date: Thu, 25 Feb 2016 09:11:44 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Oleg Nesterov <oleg@...hat.com>,
Sasha Levin <sasha.levin@...cle.com>,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
mingo@...nel.org
Subject: Re: [PATCH] signals: work around random wakeups in sigsuspend()
On Thu, Feb 25, 2016 at 03:18:52AM +0000, Al Viro wrote:
> On Mon, Jan 25, 2016 at 08:09:15PM +0100, Oleg Nesterov wrote:
> > On 01/25, Sasha Levin wrote:
> > >
> > > A random wakeup can get us out of sigsuspend() without TIF_SIGPENDING
> > > being set.
> >
> > and TIF_RESTORE_SIGMASK is just wrong in this case. I'd say this is the
> > bugfix, not work-around ;)
> >
> > > Avoid that by making sure we were signaled, like sys_pause() does.
> > >
> > > Signed-off-by: Sasha Levin <sasha.levin@...cle.com>
> >
> > Acked-by: Oleg Nesterov <oleg@...hat.com>
> >
> > Thanks Sasha.
>
> Out of curiousity - where did that stray wakeup come from? PTRACE_KILL
> used to trigger those, but that got fixed. How does one trigger that
> kind of bugs on the current kernels?
Its a regular TASK_INTERRUPTIBLE sleep, for those spurious wakeups are
not a bug, they're pretty fundamentally allowed.
See: lkml.kernel.org/r/CA+55aFwHkOo+YGWKYROmce1-H_uG3KfEUmCkJUerTj=ojY2H6Q@...l.gmail.com
But they became a lot more common because we explicitly used the delayed
wakeup pattern described there with wake_q. See commits:
7675104990ed ("sched: Implement lockless wake-queues")
1d0dcb3ad9d3 ("futex: Implement lockless wakeups")
Powered by blists - more mailing lists