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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
