Rusty Russell wrote:
On Sat, 2007-01-06 at 12:55 -0800, Zachary Amsden wrote:
Rusty Russell wrote:
+int paravirt_write_msr(unsigned int msr, u64 val);
If binary modules using debug registers makes us nervous, the
reprogramming MSRs is also similarly bad.
Yes, but this is simply from experience. Several modules wrote msrs
(you can take out the EXPORT_SYMBOL and find them quite quickly).
Several in tree, GPL'd modules did so. I'm not aware of out of tree
modules that do that, and if they do, they are misbehaving.
Reprogramming MTRR memory regions under the kernel's nose is not a
proper way to behave, and this is the most benign use I can think of for
write access to MSRs. If this really breaks any code out there, then
there should be a proper, controlled API to do this so the kernel can
manage it.
+void raw_safe_halt(void);
+void halt(void);
These shouldn't be done by modules, ever. Only the scheduler should
decide to halt.
Several modules implement alternate halt loops. I guess being in a
module for specific CPUs makes sense...
Yes, but halting is a behavior that can easily introduce critical, grind
to a halt problems because of race conditions. I have no problems
having modules implement alternative halt loops. I think there is a
serious debuggability issue with binary modules invoking halt directly.
Zach
-
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/
