Messages in this thread | | | Subject | Re: global kernel lock | From | Andi Kleen <> | Date | 13 Nov 1998 21:28:09 +0100 |
| |
In article <199811131746.JAA18220@dm.cobaltmicro.com>, "David S. Miller" <davem@dm.cobaltmicro.com> writes: > Date: Fri, 13 Nov 1998 16:29:50 +0000 > From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
> On Sat, Nov 14, 1998 at 02:08:25AM +1100, Richard Gooch wrote: >> - - does anyone have removing this on their ToDo for 2.3?
> I noticed things like lock_kernel() in munmap for example, and in the > page fault handler of some architectures (but not i386). Given the > semaphores and so there do seem to be more lock_kernel()s than I'd expect.
> I removed them from the sparc page fault handlers a few weeks ago, and > I merged that into 2.1.127 I thought, if not the next merge will get > that.
> They were certainly in there by mistake, and if other ports still have > them the maintainers should follow the lead of x86/sparc/etc.
I think the generic page fault handling has one lock_kernel too much:
mm/memory.c:
static int do_no_page ... { if (!vma->vm_ops || !vma->vm_ops->nopage) { unlock_kernel(); return do_anonymous_page(tsk, vma, page_table, write_access); }
static inline int handle_pte_fault ... { lock_kernel(); entry = *pte;
if (!pte_present(entry)) { if (pte_none(entry)) return do_no_page(tsk, vma, address, write_access, pte);
The mm semaphore should serialize access to the pte already so the lock_kernel should not be needed in this common case. Or do I miss something here?
-Andi
- 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/
| |