memblock: Export MEMBLOCK_ERROR again
in [Kernel]
|
From: Benjamin Herrenschmidt on 28 Jul 2010 01:20 On Thu, 2010-07-22 at 11:21 -0700, Yinghai Lu wrote: > will used by x86 memblock_x86_find_in_range_node and nobootmem replacement > > -v2: use 0 instead -1ULL, Suggested by Linus, so we don't need cast them later to unsigned long The patch in its current form is a NAK. You can't just do those two things in one commit. If we're going to switch LMB errors to always be 0, we need to ensure we cannot realistically hand out 0 as a result of lmb_alloc(). I'll cook up a patch to do that. Ben. > Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > --- > include/linux/memblock.h | 1 + > mm/memblock.c | 2 -- > 2 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h > index 70bc467..89749c4 100644 > --- a/include/linux/memblock.h > +++ b/include/linux/memblock.h > @@ -19,6 +19,7 @@ > #include <asm/memblock.h> > > #define INIT_MEMBLOCK_REGIONS 128 > +#define MEMBLOCK_ERROR 0 > > struct memblock_region { > phys_addr_t base; > diff --git a/mm/memblock.c b/mm/memblock.c > index 796ef8c..3d0a754 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -27,8 +27,6 @@ int memblock_can_resize; > static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS + 1]; > struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS + 1]; > > -#define MEMBLOCK_ERROR (~(phys_addr_t)0) > - > /* inline so we don't get a warning when pr_debug is compiled out */ > static inline const char *memblock_type_name(struct memblock_type *type) > { -- 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 28 Jul 2010 01:30 On Wed, 2010-07-28 at 15:15 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2010-07-22 at 11:21 -0700, Yinghai Lu wrote: > > will used by x86 memblock_x86_find_in_range_node and nobootmem replacement > > > > -v2: use 0 instead -1ULL, Suggested by Linus, so we don't need cast them later to unsigned long > > The patch in its current form is a NAK. > > You can't just do those two things in one commit. > > If we're going to switch LMB errors to always be 0, we need to ensure we > cannot realistically hand out 0 as a result of lmb_alloc(). > > I'll cook up a patch to do that. BTW. After that, maybe send a patch completely removing MEMBLOCK_ERROR ? I find 0 to be self-explanatory enough. Cheers, Ben. > Ben. > > > Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > > --- > > include/linux/memblock.h | 1 + > > mm/memblock.c | 2 -- > > 2 files changed, 1 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h > > index 70bc467..89749c4 100644 > > --- a/include/linux/memblock.h > > +++ b/include/linux/memblock.h > > @@ -19,6 +19,7 @@ > > #include <asm/memblock.h> > > > > #define INIT_MEMBLOCK_REGIONS 128 > > +#define MEMBLOCK_ERROR 0 > > > > struct memblock_region { > > phys_addr_t base; > > diff --git a/mm/memblock.c b/mm/memblock.c > > index 796ef8c..3d0a754 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -27,8 +27,6 @@ int memblock_can_resize; > > static struct memblock_region memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS + 1]; > > struct memblock_region memblock_reserved_init_regions[INIT_MEMBLOCK_REGIONS + 1]; > > > > -#define MEMBLOCK_ERROR (~(phys_addr_t)0) > > - > > /* inline so we don't get a warning when pr_debug is compiled out */ > > static inline const char *memblock_type_name(struct memblock_type *type) > > { > -- 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: H. Peter Anvin on 28 Jul 2010 02:00 On 07/27/2010 10:19 PM, Benjamin Herrenschmidt wrote: > > Screw it, I don't like it but I'll just split your patch in two for now > and keep 0. It's a bit fishy but memblock does mostly top-down > allocations and so shouldn't hit 0, and in practice the region at 0 is, > I beleive, reserved, but we need to be extra careful and might need to > revisit that a bit. > > That's an area where I don't completely agree with Linus, ie, 0 is a > perfectly valid physical address for memblock to return :-) > On x86, physical address 0 contains the real-mode IVT and will thus be reserved, at least for the forseeable future. Other architectures may very well have non-special RAM there. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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: David Miller on 28 Jul 2010 02:10 From: "H. Peter Anvin" <hpa(a)zytor.com> Date: Tue, 27 Jul 2010 22:53:21 -0700 > On 07/27/2010 10:19 PM, Benjamin Herrenschmidt wrote: >> >> Screw it, I don't like it but I'll just split your patch in two for now >> and keep 0. It's a bit fishy but memblock does mostly top-down >> allocations and so shouldn't hit 0, and in practice the region at 0 is, >> I beleive, reserved, but we need to be extra careful and might need to >> revisit that a bit. >> >> That's an area where I don't completely agree with Linus, ie, 0 is a >> perfectly valid physical address for memblock to return :-) >> > > On x86, physical address 0 contains the real-mode IVT and will thus be > reserved, at least for the forseeable future. Other architectures may > very well have non-special RAM there. 0 is very much possible on sparc64 -- 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 28 Jul 2010 02:20 On 07/27/2010 11:01 PM, David Miller wrote: > From: "H. Peter Anvin" <hpa(a)zytor.com> > Date: Tue, 27 Jul 2010 22:53:21 -0700 > >> On 07/27/2010 10:19 PM, Benjamin Herrenschmidt wrote: >>> >>> Screw it, I don't like it but I'll just split your patch in two for now >>> and keep 0. It's a bit fishy but memblock does mostly top-down >>> allocations and so shouldn't hit 0, and in practice the region at 0 is, >>> I beleive, reserved, but we need to be extra careful and might need to >>> revisit that a bit. >>> >>> That's an area where I don't completely agree with Linus, ie, 0 is a >>> perfectly valid physical address for memblock to return :-) >>> >> >> On x86, physical address 0 contains the real-mode IVT and will thus be >> reserved, at least for the forseeable future. Other architectures may >> very well have non-special RAM there. > > 0 is very much possible on sparc64 So still keep MEMBLOCK_ERROR to (~(phys_addr_t)0) ? We can change some variable from unsigned long to phys_addr_t that will be assigned by memblock_find_base(). that could avoid casting too. Thanks Yinghai -- 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/
|
Next
|
Last
Pages: 1 2 Prev: JPEG hw decoder Next: memblock: Prepare to include linux/memblock.h in core file |