From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 5C9AC8D0040 for ; Thu, 31 Mar 2011 17:14:44 -0400 (EDT) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2VKrDxS026622 for ; Thu, 31 Mar 2011 16:53:13 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 819BA6E803C for ; Thu, 31 Mar 2011 17:14:42 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2VLEgBf229348 for ; Thu, 31 Mar 2011 17:14:42 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2VLEepn010526 for ; Thu, 31 Mar 2011 17:14:42 -0400 Subject: Re: [PATCH 04/12] mm: alloc_contig_freed_pages() added From: Dave Hansen In-Reply-To: References: <1301577368-16095-1-git-send-email-m.szyprowski@samsung.com> <1301577368-16095-5-git-send-email-m.szyprowski@samsung.com> <1301587083.31087.1032.camel@nimitz> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 31 Mar 2011 14:14:38 -0700 Message-ID: <1301606078.31087.1275.camel@nimitz> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Nazarewicz Cc: Marek Szyprowski , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-mm@kvack.org, Kyungmin Park , Andrew Morton , KAMEZAWA Hiroyuki , Ankita Garg , Daniel Walker , Johan MOSSBERG , Mel Gorman , Pawel Osciak On Thu, 2011-03-31 at 23:09 +0200, Michal Nazarewicz wrote: > On Thu, 31 Mar 2011 17:58:03 +0200, Dave Hansen > wrote: > > On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote: > >> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned > >> long end, > >> + gfp_t flag) > >> +{ > >> + unsigned long pfn = start, count; > >> + struct page *page; > >> + struct zone *zone; > >> + int order; > >> + > >> + VM_BUG_ON(!pfn_valid(start)); > > > > This seems kinda mean. Could we return an error? I understand that > > this is largely going to be an early-boot thing, but surely trying to > > punt on crappy input beats a full-on BUG(). > > Actually, I would have to check but I think that the usage of this function > (in this patchset) is that the caller expects the function to succeed. It > is quite a low-level function so before running it a lot of preparation is > needed and the caller must make sure that several conditions are met. I don't > really see advantage of returning a value rather then BUG()ing. > > Also, CMA does not call this function at boot time. We BUG_ON() in bootmem. Basically if we try to allocate an early-boot structure and fail, we're screwed. We can't keep running without an inode hash, or a mem_map[]. This looks like it's going to at least get partially used in drivers, at least from the examples. Are these kinds of things that, if the driver fails to load, that the system is useless and hosed? Or, is it something where we might limp along to figure out what went wrong before we reboot? -- Dave -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org