On 27 May 2014 19:45, Dave Hansen <dave.hansen@xxxxxxxxx> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>