Messages in this thread | | | Date | Wed, 16 Apr 2008 11:20:15 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [patch] mm: sparsemem memory_present() memory corruption fix |
| |
On Tue, 15 Apr 2008 19:00:18 -0700 "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> On Tue, Apr 15, 2008 at 6:30 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote: > > > > On Tue, Apr 15, 2008 at 6:17 PM, Ingo Molnar <mingo@elte.hu> wrote: > > > > > > * Ingo Molnar <mingo@elte.hu> wrote: > > > > > > > > > this is the only call to memory_present() we do in 32-bit arch > > > > > > setup, so it's required. > > > > > > > > > > We could clip there if SPARSEMEM is configured. I wonder if this > > > > > affects other platforms that need HIGHMEM support? > > > > > > > > clip where and what? > > > > > > i.e. as per my previous argument i'd consider the need to sanitize the > > > calls in the architecture fundamentally wrong. > > > > > > whether the core code emits a warning or allows the call is an > > > additional question i mention in the changelog - but the core sparse > > > memory code should _definitely_ not silently overflow a key internal > > > array ... (of which data structure the architecture code is not even > > > aware of) > > > > or you can move that check into find_max_pfn for x86_32? so it will > > not affect other platform regarding Christoph's concern? > > > the patch doesn't have side effects on x86_64. > also no side effects on my ia64/NUMA box, which has sparse physical memory map.
Thanks, -Kame
| |