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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
