Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752799AbXKSVOp (ORCPT ); Mon, 19 Nov 2007 16:14:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751809AbXKSVOf (ORCPT ); Mon, 19 Nov 2007 16:14:35 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:38464 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751144AbXKSVOc (ORCPT ); Mon, 19 Nov 2007 16:14:32 -0500 Date: Mon, 19 Nov 2007 13:08:01 -0800 From: Andrew Morton To: Mathieu Desnoyers Cc: haveblue@us.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mbligh@google.com Subject: Re: [PATCH] Cast page_to_pfn to unsigned long in CONFIG_SPARSEMEM Message-Id: <20071119130801.bd7b7021.akpm@linux-foundation.org> In-Reply-To: <20071119202023.GA5086@Krystal> References: <20071113194025.150641834@polymtl.ca> <1195160783.7078.203.camel@localhost> <20071115215142.GA7825@Krystal> <1195164977.27759.10.camel@localhost> <20071116144742.GA17255@Krystal> <1195495626.27759.119.camel@localhost> <20071119185258.GA998@Krystal> <1195501381.27759.127.camel@localhost> <20071119195257.GA3440@Krystal> <1195502983.27759.134.camel@localhost> <20071119202023.GA5086@Krystal> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2157 Lines: 56 On Mon, 19 Nov 2007 15:20:23 -0500 Mathieu Desnoyers wrote: > * Dave Hansen (haveblue@us.ibm.com) wrote: > > The only thing I might suggest doing differently is actually using the > > page_to_pfn() definition itself: > > > > memory_model.h:#define page_to_pfn __page_to_pfn > > > > The full inline function version should do this already, and we > > shouldn't have any real direct __page_to_pfn() users anyway. > > > > Like this then.. > > Cast page_to_pfn to unsigned long in CONFIG_SPARSEMEM > > Make sure the type returned by page_to_pfn is always unsigned long. If we > don't cast it explicitly, it can be int on i386, but long on x86_64. formally ptrdiff_t, I believe. > This is > especially inelegant for printks. > > Signed-off-by: Mathieu Desnoyers > CC: Dave Hansen > CC: linux-mm@kvack.org > CC: linux-kernel@vger.kernel.org > --- > include/asm-generic/memory_model.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6-lttng/include/asm-generic/memory_model.h > =================================================================== > --- linux-2.6-lttng.orig/include/asm-generic/memory_model.h 2007-11-19 15:06:40.000000000 -0500 > +++ linux-2.6-lttng/include/asm-generic/memory_model.h 2007-11-19 15:18:57.000000000 -0500 > @@ -76,7 +76,7 @@ struct page; > extern struct page *pfn_to_page(unsigned long pfn); > extern unsigned long page_to_pfn(struct page *page); > #else > -#define page_to_pfn __page_to_pfn > +#define page_to_pfn ((unsigned long)__page_to_pfn) > #define pfn_to_page __pfn_to_page > #endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */ I'd have thought that __pfn_to_page() was the place to fix this: the lower-level point. Because someone might later start using __pfn_to_page() for something. Heaven knows why though - why does __pfn_to_page() even exist? - 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/