Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1342743 > unrolled thread
| Started by | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| First post | 2016-02-25 04:20 +0100 |
| Last post | 2016-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.
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
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Date | 2016-02-25 04:20 +0100 |
| Subject | Re: [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]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-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]
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Date | 2016-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