lkml.org 
[lkml]   [2015]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] futex: Robustify wake_futex()

* Davidlohr Bueso <dave@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 real as the need for the
> redundant pi checks in wake_futex().
>
> These redundant checks are fine and past discussion
> indicates that they will stay. However, it does introduce
> this mismatch, thus it is better to robustify the
> function and avoid any assumptions that could bite us in
> the arse the future.

So can the current code crash or hang if the WARN()
triggers?

> kernel/futex.c | 45 +++++++++++++++++++++++++++++++++------------
> 1 file changed, 33 insertions(+), 12 deletions(-)

My counter argument is that we add quite a bit of pointless
complexity:

> - if (WARN(q->pi_state || q->rt_waiter, "refusing to wake PI futex\n"))
> - return;
> + if (unlikely(WARN(q->pi_state || q->rt_waiter,
> + "refusing to wake PI futex\n")))
> + return false;

> - wake_futex(this);
> + if (!wake_futex(this)) {
> + ret = -EINVAL;
> + break;
> + }

+ [ 4 more usage sites ]

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

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-02-18 18:41    [W:0.147 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site