Alan Cox wrote:
On Iau, 2006-03-16 at 00:37 +0100, Pavel Machek wrote:
This code used to work when ran as root:
Unless it page faulted, or was on SMP, or ....
Actually, quite interestingly, I believe you can take page faults in
this scenario - you might end up getting rescheduled and lose the effect
disabling interrupts, but I think the kernel lives on just fine - as
long as it doesn't BUG_ON about this. On SMP, clearly you can't
disabled IRQs on all processors with it. But I really think the point
is to try to eliminate IRQs on a single processor during some critical
timing sensitive region. One thing you definitely can't do safely is
make sysenter based syscalls off the vsyscall page - you will notice
that you always come back with interrupts enabled.
I just really don't think that is a good idea to do in userspace, when
writing a kernel module to accomplish this safely is actually really
quite easy. I would argue that the various CMOS timer update utilities
in userspace that do this same thing, really should be moved into the
kernel as fast as possible - they could race against other CPUs in
kernel mode that are doing the same thing, and there is no locking
discipline here whatsoever.
I'm not sure how will X like this.
X has not used this ability for many years.
Good to know. I thought some piece of xinit still used it to do
dot-clock probing - but I could be wrong. We really don't care about
getting accurate information here, since the dot-clocks don't actually
exist in a VM. We simulate virtual SVGA hardware instead of passing
through any installed card.
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/
[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]
