|
From: Seiji A. <sei...@hd...> - 2012-11-30 23:00:13
|
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 |