Re: i486 emu in mainline?

[Nathanael Nerode]

Some thread necromancy...

On Sun, 23 May 2004 02:20:58 +0000, Andrew Morton wrote:
>Willy Tarreau <willy <at> w.ods.org> wrote:
>>
>>  On Sun, May 23, 2004 at 09:13:20AM +0200, Arjan van de Ven wrote:
>>  > on first look it seems to be missing a bunch of get_user() calls and
>>  > does direct access instead....
>> 
>>  It was intentional for speed purpose. The areas are checked once with
>>  verify_area() when we need to access memory, then data is copied directly
>>  from/to memory. I don't think there's any risk, but I can be wrong.
>
>verify_area() simply checks that the address is a legal one for a userspace
>access (it's not a chunk of kernel memory).  But the kernel can still take
>a pagefault when accessing the address, so you need to use the uaccess
>functions which will handle the fault appropriately.
>
>That's put_user(), get_user(), copy_*_user(), etc.  Those functions
>internally perform verify_area(), so if you've already done a verify_area()
>you can use __put_user(), __get_user(), etc which skip the verify_area()
>but which still know how to deal with user address faults.

After reviewing the thread, this seems to be the most important reason
why this patch can't be included.  So I thought, "Hey, I'll fix that."

But put_user, get_user, etc. may sleep (of course).
They're also "user context only".

This is a hardware trap handler.  What sort of context is that?  Is
it really "user context"?  Worse, we're attempting to emulate an
*atomic* instruction (CMPXCHG).

So how do I guarantee:
(1) the original process doesn't get resumed during the sleep
(perhaps this is guaranteed by other things?)
(2) nobody else messes with the data we're messing with, so that this is
actually atomic.  (Note that we're assuming there's no SMP, because this
is an i386 and there are no known i386 SMP machines supported by Linux.
So the only problem is stuff woken during sleep.)  Basically, this means
no other process which might share the memory can be woken up during the
sleep either.  :-P

Is this possible, or hopelessly difficult?

-- 
This space intentionally left blank.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/