On Tue, 2006-08-22 at 15:02 -0700, Zachary Amsden wrote: > Well, I don't think anything is sufficient for a preemptible kernel. I > think that's just plain not going to work. You could have a kernel > thread that got preempted in a paravirt-op patch point Patching over the 6 native cases is actually not that bad: they're listed below (each one has trailing noops). cli sti push %eax; popf pushf; pop %eax pushf; pop %eax; cli iret sti; sysexit If you're at the first insn you don't have to do anything, since you're about to replace that code. If you're in the noops, you can just advance EIP to the end. You can't be preempted between sti and sysexit, since we only use that when interrupts are already disabled. And reversing either "push %eax" or "pushf; pop %eax" is fairly easy. Depending on your hypervisor, you might need to catch those threads who are currently doing the paravirt_ops function calls, as well. This introduces more (and more complex) cases. That all said, I've long speculated about a stop_machine which schedules all the preempted threads, to ensure every thread is in a happy unpreempt place. This would involve scheduler hacks, but would allow us to remove the preempt_disable() calls around try_module_get() and any other areas which use stop_machine as the write side of locking. Rusty. -- Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
