lkml.org 
[lkml]   [2006]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/6] lightweight robust futexes: -V3 - Why in userspace?
On Fri, 17 Feb 2006, Ingo Molnar wrote:

>
> * Esben Nielsen <simlo@phys.au.dk> wrote:
>
> > > this is racy - we cannot know whether the PID wrapped around.
> > >
> > What about adding more bits to check on? The PID to lookup the task_t
> > and then some extra bits to uniquely identify the actual task.
>
> which would just be a fancy name for a wider PID space, and would thus
> still not protect against PID reuse :-)
>
Can it really be correct there is no way to uniquely identify a thread in
the uptime of the system? It could be done with BigIntegers :-)


> > > nor does this method offer any solution for the case where there are
> > > already waiters pending: they might be hung forever.
> >
> > It was for this case I suggested maintaining a list of waiters within
> > the kernel on each task_t. The adding has to be done FUTEX_WAIT so the
> > adding operation needs to be protected.
>
> i'm not sure i follow - what list is this and how would it be
> maintained?
>

At the FUTEX_WAIT operation add the waiter to a list of waiters on the
owner's task_t. At FUTEX_WAKE remove the waiter. At task exit wake up the
waiters.

> > > With our solution
> > > one of those waiters gets woken up and notice that the lock is dead.
> > > (and in the unlikely even of that thread dying too while trying to
> > > recover the data, the kernel will do yet another wakeup, of the next
> > > waiter.)
> > >
> > I admit your solution is a good one. The only drawback - besides being
> > untraditional - is that memory corruption can leave futexes locked at
> > exit.
>
> so? Memory corruption can overwrite the futex value anyway, and can thus
> cause the wrong owner to be identified - causing a locked futex. This
> patch does not protect against bad effects of memory corruption -
> there's really no way to keep userspace from breaking itself.
>

At least you could wake up those who are already blocked in the kernel...

Esben

> Ingo
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-17 01:23    [W:1.232 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site