Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1342743 > unrolled thread

Re: [PATCH] signals: work around random wakeups in sigsuspend()

Started byAl Viro <viro@ZenIV.linux.org.uk>
First post2016-02-25 04:20 +0100
Last post2016-02-25 18:40 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] signals: work around random wakeups in sigsuspend() Al Viro <viro@ZenIV.linux.org.uk> - 2016-02-25 04:20 +0100
    Re: [PATCH] signals: work around random wakeups in sigsuspend() Peter Zijlstra <peterz@infradead.org> - 2016-02-25 09:20 +0100
      Re: [PATCH] signals: work around random wakeups in sigsuspend() Al Viro <viro@ZenIV.linux.org.uk> - 2016-02-25 18:40 +0100

#1342743 — Re: [PATCH] signals: work around random wakeups in sigsuspend()

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-02-25 04:20 +0100
SubjectRe: [PATCH] signals: work around random wakeups in sigsuspend()
Message-ID<r5UD8-6ag-31@gated-at.bofh.it>
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@oracle.com>
> 
> Acked-by: Oleg Nesterov <oleg@redhat.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?

[toc] | [next] | [standalone]


#1342955

FromPeter Zijlstra <peterz@infradead.org>
Date2016-02-25 09:20 +0100
Message-ID<r5Zjs-XU-17@gated-at.bofh.it>
In reply to#1342743
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@oracle.com>
> > 
> > Acked-by: Oleg Nesterov <oleg@redhat.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@mail.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")

[toc] | [prev] | [next] | [standalone]


#1343351

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-02-25 18:40 +0100
Message-ID<r683o-78A-17@gated-at.bofh.it>
In reply to#1342955
On Thu, Feb 25, 2016 at 09:11:44AM +0100, Peter Zijlstra wrote:

> > 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.

They are, which makes any code that doesn't expect them in such situations
buggy.

> See: lkml.kernel.org/r/CA+55aFwHkOo+YGWKYROmce1-H_uG3KfEUmCkJUerTj=ojY2H6Q@mail.gmail.com

I know.  The question is not whether the code must take them into account
(it must; it's a bug not to), it's what's a good way to trigger such bugs.
IOW, how to stress-test for such bugs?

PTRACE_KILL used to be a convenient way to arrange for a wakeup delivered
to victim engaged in something we want to stress; it doesn't do blind
wake_up_process() anymore, so that trick is gone.  Is there anything
similar?

Suppose I have a dodgy waitqueue code (pardon the redundancy) in some
filesystem.  I have some idea how to maneuver a process into such-and-such
part of that code; is there any convenient way to turn that into "... OK,
now let's add bombing it with stray wakeups"?

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web