[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090106145741.e9844b93.kamezawa.hiroyu@jp.fujitsu.com>
Date: Tue, 6 Jan 2009 14:57:41 +0900
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Cyrill Gorcunov <gorcunov@...il.com>, npiggin@...e.de,
riel@...hat.com, penberg@...helsinki.fi,
linux-kernel@...r.kernel.org, jirislaby@...il.com
Subject: Re: [PATCH] mm: __nr_to_section - make it safe against overflow v2
On Mon, 5 Jan 2009 16:37:42 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Mon, 5 Jan 2009 13:31:32 +0300
> Cyrill Gorcunov <gorcunov@...il.com> wrote:
>
> > __nr_to_section should check for array bound overflow.
> > We should better get NULL dereference then silently
> > pass some memory snippet out of bounds to a caller.
> >
>
> Are there actually any known problems here?
>
IIRC, I never saw any problem. (But I may see in memory-hotplug development.)
I don't like adding any check here.
This __nr_to_section[] is very internal function and will not be accessed directly
by codes other than VM(of sparsemem and memory hotplug).
For general users, this function will be called via pfn_to_page(). So, this means
what this patch should really do is checking "pfn" argugments to pfn_to_page().
Of course, I don't want any check in pfn_to_page()'s "pfn" range.But, pfn_to_page()
is usually called with pfn_valid() if necessary. pfn_valid() and pfn_present(),
other callers of this, check this in explicit way.
Cyrill, if you really want to do check "idx", please add
==
__nr_to_section_direct(unsigned long nr) (or some better name)
{
BUG_ON(nr >NR_SECTION_ROOTS);
return __nr_to_section(nr);
}
==
to, mm/internal.h or somewhere. and use this in sparse.c and memhotplug.c
So, Nack from me for now.
Thanks,
-Kame
--
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/
Powered by blists - more mailing lists