lkml.org 
[lkml]   [1998]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: global kernel lock
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.749 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site