On Thu, 13 Nov 2014 23:57:22 -0500 Steven Rostedt <[email protected]> wrote:
> That assignment is what it is initialized to at boot up. I can't see > any optimization that would cause gcc to modify that. Especially since > we are hiding its accesses within the ACCESS_ONCE(). That alone should > confuse gcc enough to leave it a hell alone J. I'm actually wondering if the ACCESS_ONCE or volatile is even needed. static variables are used to maintain state, and that goes for recursive functions. gcc should not touch it. Now perhaps it can see that there is no recursion for logbuf_cpu to be set to the current cpu (which would be interesting since the smp_processor_id() call is also hidden from gcc), and it might optimize it out. But that would not protect us from NMIs doing a printk(). Although this code doesn't protect us from that anyway if an NMI were to come in right after taking the logbuf_lock and before setting logbuf_cpu. In that case, logbuf_cpu will not be set to this_cpu and a deadlock can still occur. This code only makes the race window smaller. I'm thinking the correct change is to nuke all of it. Perhaps the only reason using volatile here was not a bug is because volatile wasn't needed in the first place! -- Steve -- 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/
