> Now my first reaction would be, if that is the scenario, why couldn't cpuA > release the lock within one second. Because if cpuA is stuck > talking with firmware, then your patch to force the unlock is probably going > to trip over the same problems. > (those problems include dealing with resetting a firmware state machine) > > IOW, your patch is just one of many minefields you will have to cross in > order to be successful.
I agree that I need to fix the platform driver's deadlocking as well to make an overall system workable. (I just wanted to fix the deadlocking problems step by step.) > > Without any testing to show that you have cleared all those minefields, I am > leaning against your patch for now. I would rather have a > complete patchset that fixes all the problems in this path. Thanks. I will try to make the complete patchset. > > If you did have to go this route, why not take the 'reason' variable and pass > it to some function 'in_panic_path(reason)' that tells you if > you are panicing or not. Then you can change the 'if in_nmi()' to 'if > in_nmi() || in_panic'. > > The panic path already disables irqs for you, not sure you need to do it > again. Unless you have some other path you are trying to > protect in mind. Thank you for the suggestion. I will update my patch in accordance with your comment if anyone else disagree that. > > Cheers, > Don -- 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/
