Messages in this thread | | | Date | Tue, 31 Jan 2023 11:56:59 +0100 | From | Andrea Parri <> | Subject | Re: [PATCH] riscv: kprobe: Optimize kprobe with accurate atomicity |
| |
> > It's the concurrent modification that I was referring to (removing > > stop_machine()). You're saying "it'll always work", I'm saying "I'm not > > so sure". :-) E.g., writing c.ebreak on an 32b insn. Can you say that > Software must ensure write c.ebreak on the head of an 32b insn. > > That means IFU only see: > - c.ebreak + broken/illegal insn. > or > - origin insn > > Even in the worst case, such as IFU fetches instructions one by one: > If the IFU gets the origin insn, it will skip the broken/illegal insn. > If the IFU gets the c.ebreak + broken/illegal insn, then an ebreak > exception is raised. > > Because c.ebreak would raise an exception, I don't see any problem.
That's the problem, this discussion is:
Reviewer: "I'm not sure, that's not written in our spec" Submitter: "I said it, it's called -accurate atomicity-"
Andrea
| |