* Esben Nielsen <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
