Messages in this thread | | | Subject | Re: 2.6.16-rc6-rt1 | From | Thomas Gleixner <> | Date | Tue, 14 Mar 2006 23:00:58 +0100 |
| |
On Tue, 2006-03-14 at 21:40 +0100, Esben Nielsen wrote: > The trick is: Maintain the unittest along with the code you are testing. > Unfortunately a lot of people haven't discovered that yet. As I said > before, the Linux kernel sould should have a tests/ directory in the main > directory and a "make tests". For any patch to be accepted, should "make > tests" should "build". Patches ofcouse include changes to the kernel code > and the tests/ directory as it is one distribution. Notice the tests are > run _without_ running the kernel! > That is how I do it at work: I have it all in one source repository and > the "tests" target is the first dependency of "all:" in the makefile.
I did not say that a unittester is bad. It just does not help much when it only works on your workstation.
> > The deadlock detection is done, when requested. So you _have_ to do it > > by following the lock chain. When the task goes to sleep, then there is > > no postmortem. When a futex requests deadlock detection you have to do > -------- > > it in the locking path, as you have to return that information to > > userspace. > > > > http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html > > > The point is that when deadlock detection isn't requested it ought not to > be forced on the application.
It is not forced. We break out of the loop, when it is not requested. This is just combined PI / deadlock detection code. And we do the check in the boosting path anyway to avoid deadlocking there. Given it works :)
> It happens before getting into that loop
Grmbl, you are right. Fix follows.
tglx
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |