I'm using r223407. Switching to a clean built on r223853, it still gives me: ldr x8, [x21,#8] stp x21, x8, [x19] dmb ishst ldr x8, [x19,#8] str x19, [x8] str x19, [x21,#8] Thanks, Chengyu> On Dec 9, 2014, at 6:32 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 9 December 2014 at 15:14, Chengyu Song <csong84 at gatech.edu> wrote: >> Errr. my fault. I patched the rcu_assign_pointer ... Let me try again. > > It's looking closer now, but I still can't trigger the bug I'm afraid. > Even disabling the load/store optimiser and fiddling with CPUs (to try > different schedulers) just gives me what I'd expect: > > ldr x8, [x21, #8] > str x21, [x19] > str x8, [x19, #8] > dmb ishst > ldr x8, [x19, #8] > str x19, [x8] > > I'm not aware of any big changes in this area recently. You don't have > any local LLVM patches or anything that could be causing the problem? > What revision of trunk did you get it to fail on? I could try checking > that one out. > > Cheers. > > Tim.
On 9 December 2014 at 16:01, Chengyu Song <csong84 at gatech.edu> wrote:> I'm using r223407.Just trying out this build now. Hopefully I'll be able to see the error too there.> Switching to a clean built on r223853, it still gives me: > > ldr x8, [x21,#8] > stp x21, x8, [x19] > dmb ishst > ldr x8, [x19,#8] > str x19, [x8] > str x19, [x21,#8]Isn't that correct though? The problematic "str" has been folded into the "stp" instruction, so "x19 + 8" is written before it gets read. Cheers. Tim.
>> Switching to a clean built on r223853, it still gives me: >> >> ldr x8, [x21,#8] >> stp x21, x8, [x19] >> dmb ishst >> ldr x8, [x19,#8] >> str x19, [x8] >> str x19, [x21,#8] > > Isn't that correct though? The problematic "str" has been folded into > the "stp" instruction, so "x19 + 8" is written before it gets read.Indeed. I didn't pay too much attention to the str -> stp change. Unfortunately, the trunk build crashes when compiling the kernel. Hope it will be fixed tomorrow, else I need to find a revision that gives me this fix. Thank you so much! Chengyu