linux-kernel - Re: [PATCH 04/12] mm: alloc_contig_freed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Mar 2011 14:14:38 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Michal Nazarewicz <mina86@...a86.com>
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, linux-media@...r.kernel.org,
	linux-mm@...ck.org, Kyungmin Park <kyungmin.park@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Ankita Garg <ankita@...ibm.com>,
	Daniel Walker <dwalker@...eaurora.org>,
	Johan MOSSBERG <johan.xx.mossberg@...ricsson.com>,
	Mel Gorman <mel@....ul.ie>, Pawel Osciak <pawel@...iak.com>
Subject: Re: [PATCH 04/12] mm: alloc_contig_freed_pages() added

On Thu, 2011-03-31 at 23:09 +0200, Michal Nazarewicz wrote:
> On Thu, 31 Mar 2011 17:58:03 +0200, Dave Hansen <dave@...ux.vnet.ibm.com>  
> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/