x86, lmb: Add lmb_reserve_area_overlap_ok()
in [Kernel]
|
Prev: ftrace syscalls: Allow arch specific syscall symbol matching
Next: lmb: Move __alloc_memory_core_early() to nobootmem.c
From: Benjamin Herrenschmidt on 13 May 2010 22:40 On Thu, 2010-05-13 at 17:19 -0700, Yinghai Lu wrote: > Some areas from firmware could be reserved several times from different callers. > > If these area are overlapped, We may have overlapped entries in lmb.reserved. > > Try to free the area at first, before rerserve them again. I have already told you to make this a property of lmb_reserve() instead of adding that function with a terrible name. Cheers, Ben. > Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > --- > arch/x86/include/asm/lmb.h | 1 + > arch/x86/mm/lmb.c | 18 ++++++++++++++++++ > 2 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/include/asm/lmb.h b/arch/x86/include/asm/lmb.h > index dd42ac1..9329e09 100644 > --- a/arch/x86/include/asm/lmb.h > +++ b/arch/x86/include/asm/lmb.h > @@ -7,6 +7,7 @@ u64 lmb_find_area_size(u64 start, u64 *sizep, u64 align); > void lmb_to_bootmem(u64 start, u64 end); > > void lmb_reserve_area(u64 start, u64 end, char *name); > +void lmb_reserve_area_overlap_ok(u64 start, u64 end, char *name); > void lmb_free_area(u64 start, u64 end); > void lmb_add_memory(u64 start, u64 end); > struct range; > diff --git a/arch/x86/mm/lmb.c b/arch/x86/mm/lmb.c > index 19a5f49..1100c18 100644 > --- a/arch/x86/mm/lmb.c > +++ b/arch/x86/mm/lmb.c > @@ -309,6 +309,24 @@ void __init lmb_reserve_area(u64 start, u64 end, char *name) > lmb_add_region(&lmb.reserved, start, end - start); > } > > +/* > + * Could be used to avoid having overlap entries in lmb.reserved.region. > + * Don't need to use it with area that is from lmb_find_area() > + * Only use it for the area that fw hidden area. > + */ > +void __init lmb_reserve_area_overlap_ok(u64 start, u64 end, char *name) > +{ > + if (start == end) > + return; > + > + if (WARN_ONCE(start > end, "lmb_reserve_area_overlap_ok: wrong range [%#llx, %#llx]\n", start, end)) > + return; > + > + /* Free that region at first */ > + lmb_free(start, end - start); > + lmb_add_region(&lmb.reserved, start, end - start); > +} > + > void __init lmb_free_area(u64 start, u64 end) > { > if (start == end) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai on 14 May 2010 02:50 On 05/13/2010 07:32 PM, Benjamin Herrenschmidt wrote: > On Thu, 2010-05-13 at 17:19 -0700, Yinghai Lu wrote: >> Some areas from firmware could be reserved several times from different callers. >> >> If these area are overlapped, We may have overlapped entries in lmb.reserved. >> >> Try to free the area at first, before rerserve them again. > > I have already told you to make this a property of lmb_reserve() instead > of adding that function with a terrible name. make every lmb_reserve() call lmb_free at first? > > Cheers, > Ben. > >> Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> >> --- >> arch/x86/include/asm/lmb.h | 1 + >> arch/x86/mm/lmb.c | 18 ++++++++++++++++++ >> 2 files changed, 19 insertions(+), 0 deletions(-) >> >> diff --git a/arch/x86/include/asm/lmb.h b/arch/x86/include/asm/lmb.h >> index dd42ac1..9329e09 100644 >> --- a/arch/x86/include/asm/lmb.h >> +++ b/arch/x86/include/asm/lmb.h >> @@ -7,6 +7,7 @@ u64 lmb_find_area_size(u64 start, u64 *sizep, u64 align); >> void lmb_to_bootmem(u64 start, u64 end); >> >> void lmb_reserve_area(u64 start, u64 end, char *name); >> +void lmb_reserve_area_overlap_ok(u64 start, u64 end, char *name); >> void lmb_free_area(u64 start, u64 end); >> void lmb_add_memory(u64 start, u64 end); >> struct range; >> diff --git a/arch/x86/mm/lmb.c b/arch/x86/mm/lmb.c >> index 19a5f49..1100c18 100644 >> --- a/arch/x86/mm/lmb.c >> +++ b/arch/x86/mm/lmb.c >> @@ -309,6 +309,24 @@ void __init lmb_reserve_area(u64 start, u64 end, char *name) >> lmb_add_region(&lmb.reserved, start, end - start); >> } >> >> +/* >> + * Could be used to avoid having overlap entries in lmb.reserved.region. >> + * Don't need to use it with area that is from lmb_find_area() >> + * Only use it for the area that fw hidden area. >> + */ >> +void __init lmb_reserve_area_overlap_ok(u64 start, u64 end, char *name) >> +{ >> + if (start == end) >> + return; >> + >> + if (WARN_ONCE(start > end, "lmb_reserve_area_overlap_ok: wrong range [%#llx, %#llx]\n", start, end)) >> + return; >> + >> + /* Free that region at first */ >> + lmb_free(start, end - start); >> + lmb_add_region(&lmb.reserved, start, end - start); >> +} >> + >> void __init lmb_free_area(u64 start, u64 end) >> { >> if (start == end) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 14 May 2010 05:00 On Thu, 2010-05-13 at 23:44 -0700, Yinghai wrote: > On 05/13/2010 07:32 PM, Benjamin Herrenschmidt wrote: > > On Thu, 2010-05-13 at 17:19 -0700, Yinghai Lu wrote: > >> Some areas from firmware could be reserved several times from different callers. > >> > >> If these area are overlapped, We may have overlapped entries in lmb.reserved. > >> > >> Try to free the area at first, before rerserve them again. > > > > I have already told you to make this a property of lmb_reserve() instead > > of adding that function with a terrible name. > > make every lmb_reserve() call lmb_free at first? Either that, or make it check for collisions first, and if there's one, call free and try again. A little bit more work but I plan toq make it smarter at some stage, ie, directly adjust surrounding ranges instead which is not -that- hard to do. Ben. > > > > Cheers, > > Ben. > > > >> Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > >> --- > >> arch/x86/include/asm/lmb.h | 1 + > >> arch/x86/mm/lmb.c | 18 ++++++++++++++++++ > >> 2 files changed, 19 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/x86/include/asm/lmb.h b/arch/x86/include/asm/lmb.h > >> index dd42ac1..9329e09 100644 > >> --- a/arch/x86/include/asm/lmb.h > >> +++ b/arch/x86/include/asm/lmb.h > >> @@ -7,6 +7,7 @@ u64 lmb_find_area_size(u64 start, u64 *sizep, u64 align); > >> void lmb_to_bootmem(u64 start, u64 end); > >> > >> void lmb_reserve_area(u64 start, u64 end, char *name); > >> +void lmb_reserve_area_overlap_ok(u64 start, u64 end, char *name); > >> void lmb_free_area(u64 start, u64 end); > >> void lmb_add_memory(u64 start, u64 end); > >> struct range; > >> diff --git a/arch/x86/mm/lmb.c b/arch/x86/mm/lmb.c > >> index 19a5f49..1100c18 100644 > >> --- a/arch/x86/mm/lmb.c > >> +++ b/arch/x86/mm/lmb.c > >> @@ -309,6 +309,24 @@ void __init lmb_reserve_area(u64 start, u64 end, char *name) > >> lmb_add_region(&lmb.reserved, start, end - start); > >> } > >> > >> +/* > >> + * Could be used to avoid having overlap entries in lmb.reserved.region. > >> + * Don't need to use it with area that is from lmb_find_area() > >> + * Only use it for the area that fw hidden area. > >> + */ > >> +void __init lmb_reserve_area_overlap_ok(u64 start, u64 end, char *name) > >> +{ > >> + if (start == end) > >> + return; > >> + > >> + if (WARN_ONCE(start > end, "lmb_reserve_area_overlap_ok: wrong range [%#llx, %#llx]\n", start, end)) > >> + return; > >> + > >> + /* Free that region at first */ > >> + lmb_free(start, end - start); > >> + lmb_add_region(&lmb.reserved, start, end - start); > >> +} > >> + > >> void __init lmb_free_area(u64 start, u64 end) > >> { > >> if (start == end) > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 14 May 2010 12:40 On 05/14/2010 01:30 AM, Benjamin Herrenschmidt wrote: > On Thu, 2010-05-13 at 23:44 -0700, Yinghai wrote: > >> On 05/13/2010 07:32 PM, Benjamin Herrenschmidt wrote: >> >>> On Thu, 2010-05-13 at 17:19 -0700, Yinghai Lu wrote: >>> >>>> Some areas from firmware could be reserved several times from different callers. >>>> >>>> If these area are overlapped, We may have overlapped entries in lmb.reserved. >>>> >>>> Try to free the area at first, before rerserve them again. >>>> >>> I have already told you to make this a property of lmb_reserve() instead >>> of adding that function with a terrible name. >>> >> make every lmb_reserve() call lmb_free at first? >> > Either that, or make it check for collisions first, and if there's > one, call free and try again. A little bit more work but I plan toq > make it smarter at some stage, ie, directly adjust surrounding ranges > instead which is not -that- hard to do. > > later, after this patchset. this patchset is hanging around too long already. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 16 May 2010 20:50
On Sat, 2010-05-15 at 09:32 +0200, Ingo Molnar wrote: > > Btw., it would be nice to ready the LMB core bits for > upstream for 2.6.35 if there's agreement about them - > that will make the subsequent x86 patches much easier > to merge. Well, 2.6.34 was released already. I think it's a bit premature. We need to fix a few more things (the result codes for example) and do more testing to ensure we didn't break other archs. Also, Yinghai wants some more changes to the core that I need to discuss with him to understand exactly what he wants and why :-) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |