On Fri, Jun 07, 2019 at 03:22:22PM -0700, Palmer Dabbelt wrote: > The comment describes why in detail. This was found because QEMU never > gives up load reservations, the issue is unlikely to manifest on real > hardware. > > Thanks to Carlos Eduardo for finding the bug!
> @@ -330,6 +330,17 @@ ENTRY(__switch_to) > add a3, a0, a4 > add a4, a1, a4 > REG_S ra, TASK_THREAD_RA_RA(a3) > + /* > + * The Linux ABI allows programs to depend on load reservations being > + * broken on context switches, but the ISA doesn't require that the > + * hardware ever breaks a load reservation. The only way to break a > + * load reservation is with a store conditional, so we emit one here. > + * Since nothing ever takes a load reservation on TASK_THREAD_RA_RA we > + * know this will always fail, but just to be on the safe side this > + * writes the same value that was unconditionally written by the > + * previous instruction. > + */ I suspect that you need to do the same as 32-bit ARM, and clear this in your exception return path, rather than in __switch_to, since handlers for interrupts and other exceptions could leave a dangling reservation. For ARM, the architecture permits a store-exclusive to succeed even if the address differed from the load-exclusive. I don't know if the same applies here, but regardless I believe the case above applies if an IRQ is taken from kernel context, since the handler can manipulate the same variable as the interrupted code. Thanks, Mark.
