arch/i386 bugs (?)

Pavel Machek (pavel@atrey.karlin.mff.cuni.cz)
Sun, 4 May 1997 23:27:33 +0200


Hi!

a)
This is from uaccess.h

#if CPU > 386
#define __access_ok(type,addr,size) \
(__kernel_ok || __user_ok(addr,size))
#else
#define __access_ok(type,addr,size) \
(__kernel_ok || (__user_ok(addr,size) && \
((type) == VERIFY_READ || wp_works_ok || \
__verify_write((void *)(addr),(size)))))
#endif /* CPU */

-> if processor is 486+, wp_works_ok is ignored. (BTW I wonder why smp
people care about wp_works_ok in their structures. Did anyone ever
built smp machine from 386s?) But elsewhere, wp is tested on 486. It
is not tested on pentium or better, but is tested on 486s. This
probably should be applied on init.c. Otherwise, 486 machine with
broken wp bit is in REAL trouble. (Besides, it will help us detect WP
detection not working).

--- /usr/src/clean/arch/i386/mm/init.c Sat Apr 26 20:19:26 1997
+++ mm/init.c Sun May 4 22:43:15 1997
@@ -347,10 +358,14 @@
current->mm->mmap->vm_start -= PAGE_SIZE;
if (wp_works_ok < 0) {
wp_works_ok = 0;
- printk("No.\n");
+ printk("ignored.\n");
} else
printk("Ok.\n");
}
+#if CPU>386
+ if (!wp_works_ok)
+ panic( "WP bit does not work in supervisor && kernel designed for 486+!\n" );
+#endif
return;
}

b)
Some time ago I told that linux does not depend on timing loops. I was
wrong. This is from process.c.

void machine_restart(char * __unused)
{
..
for(j = 0; j < 100000 ; j++)
/* nothing */;
..
What is that? Could someone explain me what this thing is for, and
how was constant 100000 guessed? (This probably does not harm, as
it is rarely used code inside reset code. But anyway...)

c) Question: Currently linux (on 486+ with wp ok) comparess address
with 0xc0000000 to see if it is userland (unless __kernel_ok). What
about implementing this using segment registers? set_fs() would really
set fs once again, it would be different segment for kernel and for
user, and code might be smaller & faster. Is someone working on this?

--
I'm really pavel@atrey.karlin.mff.cuni.cz. 	   Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel ;-).