* Esben Nielsen <[email protected]> wrote:
> > we are observing a non-time-coherent snapshot of the locking graph.
> > There is no guarantee that due to timeouts or signals the chain we
> > observe isnt artificially long - while if a time-coherent snapshot is
> > taken it is always fine. E.g. lets take dentry locks as an example:
> > their locking is ordered by the dentry (kernel-pointer) address. We
> > could in theory have a 'chain' of subsequent locking dependencies
> > related to 10,000 dentries, which are nicely ordered and create a
> > 10,000-entry 'chain' if looked at in a non-time-coherent form. I.e. your
> > code could detect a deadlock where there's none. The more CPUs there
> > are, the larger the likelyhood is that other CPUs 'lure us' into a long
> > chain.
>
> I don't quite understand you examble: Are all 10,000 held at once?
no.
> If no, how are they all going to suddenly put into the lock chain due
> to signals or timeouts? Those things unlocks locks and therefore
> breaks the chain.
the core problem with your approach is that for each step in the
'boosting chain' (which can be quite long in theory), all that we are
holding is a task reference get get_task_struct(), to a task that was
blocked before. We then make ourselves preemptible - and once get get
back and continue the boosting chain, there is no guarantee that the
boosting makes any sense! Normally that task will probably still be
blocked, and we continue with our boosting. But the task could have
gotten unblocked, it could have gotten re-blocked, and we'd continue
doing the boosting.
in short: wow do you ensure that the boosting is still part of the same
dependency chain where it started off?
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]
