On Thu, Jan 24, 2019 at 10:17 AM Baoquan He <[email protected]> wrote: > > On 01/23/19 at 10:50pm, Kairui Song wrote: > > > > int fix_aperture __initdata = 1; > > > > > > > > -#ifdef CONFIG_PROC_VMCORE > > > > +#if defined(CONFIG_PROC_VMCORE) || defined(CONFIG_PROC_KCORE) > > > > /* > > > > * If the first kernel maps the aperture over e820 RAM, the kdump > > > > kernel will > > > > * use the same range because it will remain configured in the > > > > northbridge. > > > > @@ -66,7 +67,7 @@ int fix_aperture __initdata = 1; > > > > */ > > > > static unsigned long aperture_pfn_start, aperture_page_count; > > > > > > > > -static int gart_oldmem_pfn_is_ram(unsigned long pfn) > > > > +static int gart_mem_pfn_is_ram(unsigned long pfn) > > > > { > > > > return likely((pfn < aperture_pfn_start) || > > > > (pfn >= aperture_pfn_start + aperture_page_count)); > > > > @@ -76,7 +77,12 @@ static void exclude_from_vmcore(u64 aper_base, u32 > > > > aper_order) > > > > > > Shouldn't this function name be changed? It's not only handling vmcore > > > stuff any more, but also kcore. And this function is not excluding, but > > > resgistering. > > > > > > Other than this, it looks good to me. > > > > > > Thanks > > > Baoquan > > > > > > > Good suggestion, it's good to change this function name too to avoid > > any misleading. This patch hasn't got any other reviews recently, I'll > > update it shortly. > > There's more. > > These two are doing the same thing: > register_mem_pfn_is_ram > register_oldmem_pfn_is_ram > > Need remove one of them and put it in a right place. Furthermore, may > need see if there's existing function which is used to register a > function to a hook. > > Secondly, exclude_from_vmcore() is not excluding anthing, it's only > registering a function which is used to judge if oldmem/pfn is ram. Need > rename it. > > Thanks > Baoquan
Thanks a lot for the review! I've sent V3, using a different approach. It's true repeating the hook infrastructure cause duplication, but I see vmcore/kcore didn't share much code, so instead of sharing a common hook infrastructure / registering entry, I used a new kcore memory mapping list enum type to fix it, it also introduced less code. Please have a look at V3, let me know how you think about it, thanks! -- Best Regards, Kairui Song
