On Sun, Feb 03, 2019 at 05:30:39PM +0100, Thomas Gleixner wrote: > On Sat, 2 Feb 2019, Heiko Carstens wrote: > > I added a barrier between those two and now the code looks like this: > > > > 140: a5 1b 00 01 oill %r1,1 > > 144: e3 10 a0 e0 00 24 stg %r1,224(%r10) > > 14a: e5 48 a0 f0 00 00 mvghi 240(%r10),0 > > > > Looks like this was a one instruction race... > > Fun. JFYI, I said that I reversed the stores in glibc and on my x86 test VM > it took more than _3_ days to trigger. But the good news is, that the trace > looks exactly like the ones you provided. So it looks we are on the right > track. > > > I'll try to reproduce with the patch below (sprinkling compiler > > barriers just like the other files have). > > Looks about right.
The test case now runs since two days without failures. So it looks like you found the bug! Thank you for debugging this! My glibc patch missed at lease one place where I should have added another barrier, but the current version was good enough for the test case ;) Stefan Liebler is kind enough to take care that this will be fixed in glibc. Thanks!
