at 8:51 PM, Andy Lutomirski <l...@amacapital.net> wrote: > On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit <na...@vmware.com> wrote: >> at 6:22 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> >>>> On Oct 17, 2018, at 5:54 PM, Nadav Amit <na...@vmware.com> wrote: >>>> >>>> It is sometimes beneficial to prevent preemption for very few >>>> instructions, or prevent preemption for some instructions that precede >>>> a branch (this latter case will be introduced in the next patches). >>>> >>>> To provide such functionality on x86-64, we use an empty REX-prefix >>>> (opcode 0x40) as an indication that preemption is disabled for the >>>> following instruction. >>> >>> Nifty! >>> >>> That being said, I think you have a few bugs. First, you can’t just ignore >>> a rescheduling interrupt, as you introduce unbounded latency when this >>> happens — you’re effectively emulating preempt_enable_no_resched(), which >>> is not a drop-in replacement for preempt_enable(). To fix this, you may >>> need to jump to a slow-path trampoline that calls schedule() at the end or >>> consider rewinding one instruction instead. Or use TF, which is only a >>> little bit terrifying… >> >> Yes, I didn’t pay enough attention here. For my use-case, I think that the >> easiest solution would be to make synchronize_sched() ignore preemptions >> that happen while the prefix is detected. It would slightly change the >> meaning of the prefix.
So thinking about it further, rewinding the instruction seems the easiest and most robust solution. I’ll do it. >>> You also aren’t accounting for the case where you get an exception that >>> is, in turn, preempted. >> >> Hmm.. Can you give me an example for such an exception in my use-case? I >> cannot think of an exception that might be preempted (assuming #BP, #MC >> cannot be preempted). > > Look for cond_local_irq_enable(). I looked at it. Yet, I still don’t see how exceptions might happen in my use-case, but having said that - this can be fixed too. To be frank, I paid relatively little attention to this subject. Any feedback about the other parts and especially on the high-level approach? Is modifying the retpolines in the proposed manner (assembly macros) acceptable? Thanks, Nadav
