Messages in this thread | | | Date | Fri, 17 Feb 2006 00:39:52 +0100 | From | Ingo Molnar <> | Subject | Re: [patch 0/6] lightweight robust futexes: -V3 - Why in userspace? |
| |
* 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 :-)
> > 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?
> > 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.
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/
| |