Messages in this thread | | | Date | Sat, 22 May 1999 20:19:45 +0200 | From | Jakub Jelinek <> | Subject | Re: [patch] releasing kernel lock during copy_from/to_user [Re: 2.3.3_andrea2 & 2.2.9_andrea1 [was Re: Bad apache perfomance wtih linux SMP]] |
| |
> My patch was wrong... it was deadlocking in reaquire_kernel_lock if for > some reason there would be a fault during the copy_from/to_user (I > easily catched the deadlock by disassembling the .text.lock region).
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/
| |