* Esben Nielsen <[email protected]> wrote:
> The point is: It does not matter that is another chain!
>
> It will _not_ boost any task which doesn't need boosting, because it
> is not boosting according to current->prio but always
> task->pi_waiters. So all it does is to fix the priorities on some
> tasks. There is absolutely nothing wrong with that. [...]
doh, you are right, i missed that. All the state to do the boosting is
contained in a single entry along the chain, so no prior information is
needed.
the problem with deadlock detection remains though. Can we live with
deadlock detection being a bit statistical? I think we can: deadlock
detection is for _bugs_, no application should rely on it to provide
actual functionality. (if it still does it will still work fine, but we
dont design for them.) Also, if we walk long enough (say 1024 entries)
the probability of a false positive ought to be pretty low. So i think
the following type of deadlock detection ought to be pretty OK:
- check whether we get back to 'current'.
- check whether we exceed a configurable limit of steps
most 'sane' deadlocks will be detected quickly: they'll lead back to
'current' and the kernel returns. On the off chance of the chain-walking
getting lured into a completely unrelated chain the limit will catch it.
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]
