Re: [parisc-linux] 2.4.0-test6 lack of speed

[Richard Hirst <rhirst@linuxcare.com>]

On Tue, Aug 29, 2000 at 05:23:08PM -0400, Matthew Wilcox wrote:
> My attempt at fixing this in a sane manner led me to create:
> 
> #define user_fdc(addr) asm volatile("fdc 0(%%sr3,%0)" : : "r" (addr))
> (...)
> 
> and
> 
> #define kernel_fdc(addr) asm volatile("fdc 0(%%sr0,%0)" : : "r" (addr))
> (...)
> 
> however, the resulting kernel wouldn't boot.  So let's take this a

I tried something similar, with the same result.

What do you make of arch/parisc/lib/usercopy.c

unsigned long
__generic_copy_to_user(void *to, const void *from, unsigned long n)
{
        if (access_ok(VERIFY_WRITE, to, n)) {
                __flush_dcache_range((unsigned long)from, n);
                lcopy_to_user(to,from,n);
                __flush_dcache_range((unsigned long)to, n);
        }
        return 0;
}


Typically 'from' would be a kernel virtual address, and 'to' would
be a user virtual address, yes?  So, that is expecting __flush_dcache_range()
to know which space register to use.  But then sometimes these functions
for accessing user space are redirected at kernel space by set_fs().
In that case both addresses are kernel virtual addresses.

lcopy_to_user() claims to modify %sr1 to get the right space in %sr1,
based on a flag in the task struct.

See copy_strings_kernel() in fs/exec.c for an example of where
copy_from_user( is used to copy from kernel space.

Richard