On 27 May 2014 19:45, Dave Hansen <[email protected]> wrote: > > I don't think this is quite right. pfn_valid() tells us whether we have > a 'struct page' there or not. *BUT*, it does not tell us whether it is > RAM that we can actually address and than can be freed in to the buddy > allocator. > > I think sparsemem is where this matters. Let's say mem= caused lowmem > to end in the middle of a section (or that 896MB wasn't > section-aligned). Then someone calls free_bootmem_late() on an area > that is in the last section, but _above_ max_mapnr. It'll be > pfn_valid(), we'll free it in to the buddy allocator, and we'll blam the > first time we try to write to a bogus vaddr after a phys_to_virt().
Ah, the sparsemem case wasn't something I'd considered. Thanks Dave. > At a higher level, I don't like the idea of the bootmem code papering > over bugs when somebody calls in to it trying to _free_ stuff that's not > memory (as far as the kernel is concerned). > > I think the right thing to do is to call in to the e820 code and see if > the range is E820_RAM before trying to bootmem-free it. OK, this makes sense. I'll try that approach and see if it also fixes Alan's problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
