From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kAN8p3uO026860 for ; Thu, 23 Nov 2006 08:51:03 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAN8rt812527258 for ; Thu, 23 Nov 2006 08:53:55 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAN8p3in010277 for ; Thu, 23 Nov 2006 08:51:03 GMT Received: from localhost (dyn-9-152-216-55.boeblingen.de.ibm.com [9.152.216.55]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAN8p3ke010253 for ; Thu, 23 Nov 2006 08:51:03 GMT Date: Thu, 23 Nov 2006 09:49:40 +0100 From: Heiko Carstens Subject: VMALLOC_END definition? Message-ID: <20061123084940.GA8009@osiris.boeblingen.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-mm@kvack.org Return-Path: To: linux-mm@kvack.org List-ID: Hi, I just stumbled across the VMALLOC_END definition: I'm not entirely sure what the meaning of this is: is it the last _valid_ address of the vmalloc area or is it the first address _after_ the vmalloc area? Reading the code in mm/vmalloc.c it seems to be the last valid address, which IMHO is the only thing that makes sense... how would one express the first address after 0xffffffff on a 32bit architecture? Whatever it is, it looks like half of the architectures got it wrong. We have a lot of these: e.g. powerpc: #define VMALLOC_START ASM_CONST(0xD000000000000000) #define VMALLOC_SIZE ASM_CONST(0x80000000000) #define VMALLOC_END (VMALLOC_START + VMALLOC_SIZE) but also a lot of these: e.g. x86_64 #define VMALLOC_START 0xffffc20000000000UL #define VMALLOC_END 0xffffe1ffffffffffUL -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45657B0D.3040207@shadowen.org> Date: Thu, 23 Nov 2006 10:42:21 +0000 From: Andy Whitcroft MIME-Version: 1.0 Subject: Re: VMALLOC_END definition? References: <20061123084940.GA8009@osiris.boeblingen.de.ibm.com> In-Reply-To: <20061123084940.GA8009@osiris.boeblingen.de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Heiko Carstens Cc: linux-mm@kvack.org List-ID: Heiko Carstens wrote: > Hi, > > I just stumbled across the VMALLOC_END definition: I'm not entirely sure > what the meaning of this is: is it the last _valid_ address of the > vmalloc area or is it the first address _after_ the vmalloc area? > > Reading the code in mm/vmalloc.c it seems to be the last valid address, > which IMHO is the only thing that makes sense... how would one express > the first address after 0xffffffff on a 32bit architecture? > Whatever it is, it looks like half of the architectures got it wrong. > > We have a lot of these: > > e.g. powerpc: > #define VMALLOC_START ASM_CONST(0xD000000000000000) > #define VMALLOC_SIZE ASM_CONST(0x80000000000) > #define VMALLOC_END (VMALLOC_START + VMALLOC_SIZE) > > but also a lot of these: > > e.g. x86_64 > > #define VMALLOC_START 0xffffc20000000000UL > #define VMALLOC_END 0xffffe1ffffffffffUL A quick grep shows that most architectures are assuming vmalloc space is VMALLOC_START >= addr < VMALLOC_END. x86_64 seems to be an odd one out with the following construct in architecture specific code: arch/x86_64/mm/fault.c: for (address = start; address <= VMALLOC_END; address += PGDIR_SIZE) { However, it also has this: arch/x86_64/mm/fault.c: ((address >= VMALLOC_START && address < VMALLOC_END))) { A couple of filesystems and sparsemem also appear to assume the VMALLOC_START >= addr < VMALLOC_END model. So it seems likely that the architectures not using this model are wrong. -apw -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kANBxIKJ131588 for ; Thu, 23 Nov 2006 11:59:18 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kANC29PD2412742 for ; Thu, 23 Nov 2006 12:02:09 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kANBxHtV031683 for ; Thu, 23 Nov 2006 11:59:17 GMT Date: Thu, 23 Nov 2006 12:58:01 +0100 From: Heiko Carstens Subject: Re: VMALLOC_END definition? Message-ID: <20061123115801.GB8009@osiris.boeblingen.de.ibm.com> References: <20061123084940.GA8009@osiris.boeblingen.de.ibm.com> <45657B0D.3040207@shadowen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45657B0D.3040207@shadowen.org> Sender: owner-linux-mm@kvack.org Return-Path: To: Andy Whitcroft Cc: linux-mm@kvack.org List-ID: On Thu, Nov 23, 2006 at 10:42:21AM +0000, Andy Whitcroft wrote: > Heiko Carstens wrote: > > I just stumbled across the VMALLOC_END definition: I'm not entirely sure > > what the meaning of this is: is it the last _valid_ address of the > > vmalloc area or is it the first address _after_ the vmalloc area? > > > > Reading the code in mm/vmalloc.c it seems to be the last valid address, > > which IMHO is the only thing that makes sense... how would one express > > the first address after 0xffffffff on a 32bit architecture? > > Whatever it is, it looks like half of the architectures got it wrong. > > A quick grep shows that most architectures are assuming vmalloc space is > VMALLOC_START >= addr < VMALLOC_END. x86_64 seems to be an odd one out > with the following construct in architecture specific code: > > arch/x86_64/mm/fault.c: for (address = start; address <= VMALLOC_END; > address += PGDIR_SIZE) { > > However, it also has this: > > arch/x86_64/mm/fault.c: ((address >= VMALLOC_START && > address < VMALLOC_END))) { > > A couple of filesystems and sparsemem also appear to assume the > VMALLOC_START >= addr < VMALLOC_END model. So it seems likely that the > architectures not using this model are wrong. Ah, right... I also found this one in include/asm-arm/pgtable.h * Note that platforms may override VMALLOC_START, but they must provide * VMALLOC_END. VMALLOC_END defines the (exclusive) limit of this space, * which may not overlap IO space. Thanks! -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org