Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 21 Apr 2002 16:56:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 21 Apr 2002 16:56:18 -0400 Received: from holly.csn.ul.ie ([136.201.105.4]:36357 "HELO holly.csn.ul.ie") by vger.kernel.org with SMTP id ; Sun, 21 Apr 2002 16:56:16 -0400 Date: Sun, 21 Apr 2002 21:54:59 +0100 (IST) From: Mel X-X-Sender: mel@skynet To: Anton Blanchard Cc: linux-kernel@vger.kernel.org Subject: Re: vmalloc comments patch In-Reply-To: <20020420234752.GA26727@krispykreme> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 21 Apr 2002, Anton Blanchard wrote: > > + * To give a safety margin, the linear address starts about 8MB after the end > > + * of physical memory at VMALLOC_START. This is to try and catch memory > > + * overruns. > > Thats architecture dependent. On ppc64 for example the kernel text > starts at 0xC000000000000000 and the vmalloc region starts at > 0xD000000000000000, 2^60 bits apart. > Changed to * These are the functions for assigning a block of linear addresses for pages. * To give a safety margin, the linear address starts at VMALLOC_START. * This is at PAGE_OFFSET + VMALLOC_OFFSET which are all arch dependant * values Is that ok? > > spin_unlock(&init_mm.page_table_lock); > > page = alloc_page(gfp_mask); > > spin_lock(&init_mm.page_table_lock); > > Since alloc_page can sleep we must drop the spinlock. > Changed to /* The page table lock has to be released because alloc_page * could sleep if memory is low */ All good? Mel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/