* Davidlohr Bueso wrote:
> @@ -1674,13 +1689,19 @@ retry_private:
> }
>
> /*
> - * Wake nr_wake waiters. For requeue_pi, if we acquired the
> - * lock, we already woke the top_waiter. If not, it will be
> - * woken by
* Davidlohr Bueso d...@stgolabs.net wrote:
@@ -1674,13 +1689,19 @@ retry_private:
}
/*
- * Wake nr_wake waiters. For requeue_pi, if we acquired the
- * lock, we already woke the top_waiter. If not, it will be
- * woken
On Wed, 2015-02-18 at 18:07 +0100, Ingo Molnar wrote:
> while the WARN() already told the user that the kernel is
> broken.
>
> So what's the point? Does it avoid any real badness, state
> corruption, crash, hang, etc.?
Right, I mentioned the warn (redundant pi checks) being completely
* Davidlohr Bueso wrote:
> Current code assumes that wake_futex() will never fail,
> thus we are rather sloppy when incrementing the return
> value in wake related calls, accounting for the newly
> woken task. Of course this will never occur, thus not a
> problem. This bug is as real as the
* Davidlohr Bueso d...@stgolabs.net wrote:
Current code assumes that wake_futex() will never fail,
thus we are rather sloppy when incrementing the return
value in wake related calls, accounting for the newly
woken task. Of course this will never occur, thus not a
problem. This bug is as
On Wed, 2015-02-18 at 18:07 +0100, Ingo Molnar wrote:
while the WARN() already told the user that the kernel is
broken.
So what's the point? Does it avoid any real badness, state
corruption, crash, hang, etc.?
Right, I mentioned the warn (redundant pi checks) being completely
redundant -
Current code assumes that wake_futex() will never fail, thus
we are rather sloppy when incrementing the return value in wake
related calls, accounting for the newly woken task. Of course
this will never occur, thus not a problem. This bug is as real
as the need for the redundant pi checks in
Current code assumes that wake_futex() will never fail, thus
we are rather sloppy when incrementing the return value in wake
related calls, accounting for the newly woken task. Of course
this will never occur, thus not a problem. This bug is as real
as the need for the redundant pi checks in
8 matches
Mail list logo
