On Wed, Oct 21, 2015 at 11:18:09AM +0200, Petr Mladek wrote: > There are few situations when we reinitialize (zap) ticket spinlocks. It > typically happens when the system is going down after an error and we > want to avoid deadlock in some important services. For example, > zap_locks() in printk.c and ioapic_zap_locks().
So there's a few problems here. On x86 the code you patch is dead code, x86 no longer uses ticket locks. Other archs might still. And I entirely detest adding instructions to any lock path, be it the utmost fast path or not, for something that will _never_ happen (on a healthy system). I would still very much recommend getting rid of the need for zap_locks() in the first place. What I did back when is punt on the whole printk buffer madness and dump things to early_printk() without any locking. I think that as long as the printk buffer has locks you have to accept to loose some data when really bad stuff goes down. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
