linux-kernel - Re: [PATCH] mmtom : add VM_BUG_ON in __get_free

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]

Message-ID: <20090302231628.GA7228@cmpxchg.org>
Date:	Tue, 3 Mar 2009 00:16:28 +0100
From:	Johannes Weiner <hannes@...xchg.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	MinChan Kim <minchan.kim@...il.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmtom :  add VM_BUG_ON in __get_free_pages

On Mon, Mar 02, 2009 at 02:27:57PM -0800, Andrew Morton wrote:
> On Mon, 2 Mar 2009 18:31:48 +0900
> MinChan Kim <minchan.kim@...il.com> wrote:
> 
> > 
> > The __get_free_pages is used in many place. 
> > Also, driver developers can use it freely due to export function.
> > Some developers might use it to allocate high pages by mistake. 
> > 
> > The __get_free_pages can allocate high page using alloc_pages, 
> > but it can't return linear address for high page.
> > 
> > Even worse, in this csse, caller can't free page which are there in high zone. 
> > So, It would be better to add VM_BUG_ON. 
> > 
> > It's based on mmtom 2009-02-27-13-54.
> >  
> > Signed-off-by: MinChan Kim <minchan.kim@...il.com>
> > ---
> >  mm/page_alloc.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 8294107..381056b 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1681,6 +1681,13 @@ EXPORT_SYMBOL(__alloc_pages_internal);
> >  unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
> >  {
> >  	struct page * page;
> > +
> > +	/*
> > +	 * __get_free_pages() returns a 32-bit address, which cannot represent
> > +	 * a highmem page
> > +	 */
> > +	VM_BUG_ON((gfp_mask & __GFP_HIGHMEM) != 0);
> > +
> >  	page = alloc_pages(gfp_mask, order);
> >  	if (!page)
> >  		return 0;
> 
> If someone calls __get_free_pages(__GFP_HIGHMEM) then page_address()
> will reliably return NULL and the caller's code will oops.

It will allocate a page, fail to translate it to a virtual address,
return 0 and the caller will think allocation failed because it checks
for the return value.

But the highmem page is still allocated and now leaked, isn't it?

> Yes, there's a decent (and increasing) risk that the developer won't be
> testing the code on a highmem machine, but there are enough highmem
> machines out there that the bug should be discovered pretty quickly.

Another thing is that a device driver developer does not necessarily
has CONFIG_DEBUG_VM set.  Can we expect him to?

> So I'm not sure that this test is worth the additional overhead to a
> fairly frequently called function?

Well, it's only done conditionally if you want to debug the thing
anyway.  But as mentioned above, maybe this isn't the right condition.
--
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/