Hi!

> > By other words, this deadlock was there even before. Such
> > deadlocks are prevented by using printk_deferred() in
> > the sections guarded by the lock A.
> 
> Petr,
> 
> Please add this here:
> 
> ====
> 
> To demonstrate the issue, this module has been shown to lock up a
> system with 4 CPUs and a slow console (like a serial console). It is
> also able to lock up a 8 CPU system with only a fast (VGA) console, by
> passing in "loops=100". The changes in this commit prevent this module
> from locking up the system.
> 
> #include <linux/module.h>
> #include <linux/delay.h>
> #include <linux/sched.h>
> #include <linux/mutex.h>
> #include <linux/workqueue.h>
> #include <linux/hrtimer.h>

Programs in commit messages. Not preffered way to distribute code, I'd
say. What about putting it into kernel selftests directory or
something like that?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html