Messages in this thread | | | From | Seiji Aguchi <> | Subject | RE: [PATCH] Avoid dead lock of console related locks in panic case | Date | Fri, 30 Nov 2012 22:59:13 +0000 |
| |
Thank you for giving me the comment.
> - Makes the logic in this area even more twisty and complex, when > what we need to do is to simplify it > > - Reinitialises in-use locks > > - Gives the boolean variable "yes" three states, but didn't rename > that variable to something appropriate.
I understand "yes" is odd. I just wanted to know if an idea reinitializing locks is acceptable. But now I understand I have to take another approach.
> > - Passes yes==2 into s390's unsuspecting bust_spinlocks() implementation. >
Sorry. I missed the code.
> > Let's step back a bit. Please identify with great specificity the code sites which are stopping other CPUs before taking locks which > those other CPUs might have been holding. > > Then let's see what we can do to fix up the callers, instead of trying to tidy up after they have made this mess.
OK. I will update my patch without adding complexity. The logic will be as follows, if I understand your comment correctly.
- take console related locks (logbuf_lock, console_sem) - stop other cpus - release those locks
Seiji
| |