* Esben Nielsen <[email protected]> wrote:
> However, I notice it re-introduces long latencies :-( The problem is
> that the time need in adjust_prio_chain is proportional to the lock
> depth and the function is called with two raw spinlocks held. This is
> no problem when the locks are in the kernel and thus not very deeply
> nested, but when it is exposed to futexes there is a problem as Joe
> user can increase the task latency of the system by crafting deep
> locking structures in userspace.
i dont think that's a problem. For userspace futexes we'll (have to)
introduce some sensible locking depth anyway.
> I will be on paternity leave soonish. I might get time solve it as I
> originally suggested some months back when my daughter is asleep. The
> solution I suggested last fall, includes releasing _all_ locks at each
> iteration in the loop in adjust_prio_chain such that higher priority
> tasks gets a chance to run. To avoid having tasks released in the
> middle get/put_tast_struct() are needed. That will cost extra atomic
> instructions compared to the present implementation. Are people
> prepared to pay that price? I am not talking about the scheduler based
> solution; just doing the PI iteration in a little different (and
> slightly more epensive) way.
well, we'd have to see the code for that, but i'm afraid this would be
fundamentally racy. What if another CPU changes one of the data
structures along the way?
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]
