On Mon, 27 Mar 2006, Ingo Molnar wrote:
>
> * Esben Nielsen <[email protected]> wrote:
>
> > Hi,
> > I got the patch I mentioned earlier to run. It passes my userspace
> > testscripts as well as all the scripts for Thomas's rtmutex-tester on a UP
> > machine.
> >
> > The idea is to avoid the deadlocks by releasing all locks before going
> > to the next lock in the chain. I use get_/put_task_struct to avoid the
> > task disappearing during the iteration.
>
> but we lose reliable deadlock detection ...
>
> how do you guarantee that some other CPU doesnt send us on some
> goose-chase?
>
How should another CPU suddenly be able to insert stuff into a lock chain?
Only the tasks themselves can do that and they are blocked on some lock -
at least when we tested in some previous iteration. Ofcourse, they can
have been signalled or timed out since, such they are already unblocked
when the deadlock is reported. But that is not an error since the locks at
some point actually were in a deadlock situation.
I do put in a limit of 100 (can be changed with sysctl) iterations. But
that is to avoid looping forever when a new task blocks on a lock already
part of a deadlock.
> Ingo
>
Esben
-
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]
