Am 12.11.2014 um 01:36 schrieb Linus Torvalds: > On Tue, Nov 11, 2014 at 4:33 PM, Linus Torvalds > <torva...@linux-foundation.org> wrote: >> >> I guess as a workaround it is fine, as long as we don't lose sight of >> trying to eventually do a better job. > > Oh, and when it comes to the actual gcc bug - do you have any reason > to believe that it's somehow triggered more easily by something > particular in the arch/s390/kvm/gaccess.c code?
Yes there are reasons. First of all the bug if SRA removes the volatile tag, but that does not mean that this breaks things. As long as the operation is simple enough things will be mostly ok. If things are not simple like in gaccess things get more complicated. Lets look at the ipte lock. The lock itself consists of 3 parts: k (1 bit:locked), kh(31bit counter for the host) and kg(32 bit counter for the millicode when doing specific guest instructions). There are 3 valid states 1. k=0, kh=0; kg=0 2. k=1, kh!=0, kg=0 3. k=1, kh=0, kg!=0 So the host code must check if the guest counter is zero and can then set the k bit to one and increase the counter. (for unlock it has to decrement kh and if that becomes zero also zero the k bit) That means that we have multiple accesses to subcomponents. As the host counter is bit 1-31 (ibm speak, linux speak bit 32-62) gcc wants to use the load thirty one bit instruction. So far so good. The ticket lock is also not a trivial set/clear bit. Now: In gcc the memory costs for s390 are modeled to have the same costs as register accesses (TARGET_MEMORY_MOVE_COST==1, TARGET_REGISTER_MOVE_COST=1) So for gcc a re-loading of a part of the lock from memory costs the same as loading it from a register. That probably triggered that bug. Christian > > IOW, why does this problem not hit the x86 spinlocks that also use > volatile pointers to aggregate types? Or does it? I think we would have noticed if that hits. But there are certainly cases where this bug triggers also on x86, see the initial bug report of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 This bug is certainly different, (instead of transforming one load into multiple loads , it combines multiple write into one) but it shows, that a volatile marker is removed. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
