| Message ID | 20190925001556.12827-1-palmer@sifive.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | RISC-V: Clear load reservations while restoring hart contexts | expand |
On Tue, Sep 24, 2019 at 05:15:56PM -0700, Palmer Dabbelt wrote: > This is almost entirely a comment. The bug is unlikely to manifest on > existing hardware because there is a timeout on load reservations, but > manifests on QEMU because there is no timeout. Given how many different lines of RISC-V hardware are around how do you know it doesn't affect any existing hardware? Except for that the patch looks fine to me: Reviewed-by: Christoph Hellwig <hch@lst.de>
On Tue, 24 Sep 2019, Palmer Dabbelt wrote: > This is almost entirely a comment. The bug is unlikely to manifest on > existing hardware because there is a timeout on load reservations, but > manifests on QEMU because there is no timeout. > > Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Thanks, queued for v5.4-rc. - Paul
diff --git a/arch/riscv/include/asm/asm.h b/arch/riscv/include/asm/asm.h index 5a02b7d50940..9c992a88d858 100644 --- a/arch/riscv/include/asm/asm.h +++ b/arch/riscv/include/asm/asm.h @@ -22,6 +22,7 @@ #define REG_L __REG_SEL(ld, lw) #define REG_S __REG_SEL(sd, sw) +#define REG_SC __REG_SEL(sc.d, sc.w) #define SZREG __REG_SEL(8, 4) #define LGREG __REG_SEL(3, 2) diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 74ccfd464071..9fbb256da55d 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -98,7 +98,26 @@ _save_context: */ .macro RESTORE_ALL REG_L a0, PT_SSTATUS(sp) - REG_L a2, PT_SEPC(sp) + /* + * The current load reservation is effectively part of the processor's + * state, in the sense that load reservations cannot be shared between + * different hart contexts. We can't actually save and restore a load + * reservation, so instead here we clear any existing reservation -- + * it's always legal for implementations to clear load reservations at + * any point (as long as the forward progress guarantee is kept, but + * we'll ignore that here). + * + * Dangling load reservations can be the result of taking a trap in the + * middle of an LR/SC sequence, but can also be the result of a taken + * forward branch around an SC -- which is how we implement CAS. As a + * result we need to clear reservations between the last CAS and the + * jump back to the new context. While it is unlikely the store + * completes, implementations are allowed to expand reservations to be + * arbitrarily large. + */ + REG_L a2, PT_SEPC(sp) + REG_SC x0, a2, PT_SEPC(sp) + csrw CSR_SSTATUS, a0 csrw CSR_SEPC, a2
This is almost entirely a comment. The bug is unlikely to manifest on existing hardware because there is a timeout on load reservations, but manifests on QEMU because there is no timeout. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> --- arch/riscv/include/asm/asm.h | 1 + arch/riscv/kernel/entry.S | 21 ++++++++++++++++++++- 2 files changed, 21 insertions(+), 1 deletion(-)