Maciej W. Rozycki wrote:
Hello,
The following hunk of the 2.6.14 patch:
diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
index e3f362e..7a14fdf 100644
--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -313,16 +311,12 @@ void show_regs(struct pt_regs * regs)
printk(" DS: %04x ES: %04x\n",
0xffff & regs->xds,0xffff & regs->xes);
- __asm__("movl %%cr0, %0": "=r" (cr0));
- __asm__("movl %%cr2, %0": "=r" (cr2));
- __asm__("movl %%cr3, %0": "=r" (cr3));
- /* This could fault if %cr4 does not exist */
- __asm__("1: movl %%cr4, %0 \n"
- "2: \n"
- ".section __ex_table,\"a\" \n"
- ".long 1b,2b \n"
- ".previous \n"
- : "=r" (cr4): "0" (0));
+ cr0 = read_cr0();
+ cr2 = read_cr2();
+ cr3 = read_cr3();
+ if (current_cpu_data.x86 > 4) {
+ cr4 = read_cr4();
+ }
printk("CR0: %08lx CR2: %08lx CR3: %08lx CR4: %08lx\n", cr0, cr2, cr3, cr4);
show_trace(NULL, ®s->esp);
}
disables code to retrieve the actual value of CR4 on 486-class systems
(which may or may not implement the register, depending on the exact CPU
type and stepping). This seems suspicious to me, but I have to admit I
haven't followed the discussion on the issue if there was any.
This was deliberate. CR4 doesn't exist on standard 486 class systems,
and I'm not sure how you could make use of it anyway, since the features
used by Linux - machine check, page size extensions, time stamp counter,
global pages, are only available in Pentium and later class systems, and
identified by CPUID, which also doesn't exist on 486.
There may be some funky Cyrix or even Intel CPUs that have CR4
registers, but showing the output in a register dump seems very
useless. I would also not recommend using undocumented features in CR4
even if you have such a freaky processor - there were bugs and/or
missing functionality with the early large page and global page
extensions that were not ironed out until the features became
documented, IIRC. YMMV - please let me know if anyone has found ways to
make this useful.
If I am wrong, I am happy to correct this, but I would like to do so
properly by adding safe_read_cr4() or equivalent rather than using raw
inlines assembler to catch the fault.
Thanks,
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]