Yes, I was wondering how you could say in the last mail it works (unless it
was on UP).
But anyway, I don't think it is a good idea to put this stuff into the
uaccess routines themselves. It is easy solution, yes, but will put a lot of
bloat into the kernel. It is common to do several copy_from_user or to_user
calls in a row (in that case it would for each one lock/unlock the
kernel_lock), or it is common to do them outside of kernel lock guarded code
(in which case it is really bloat - two additional conditionals, two memory
settings and several bytes especially for the spinlock/unlock code).
What I'd propose is moving as much uaccess stuff as possible before the
kernel lock guarded areas (many syscalls could be changed like that without
much pain IMHO - e.g. if we provide two additional namei/lnamei calls which
take the in-kernel argument only (ie. acquired by getname() already), then a
lot of syscalls which start like
lock_kernel();
namei();
could be changed to
x = getname();
lock_kernel();
namei_without_getname();
and so you would not have to go back and forth with acquiring/releasing
kernel master lock.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.3.1 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/