linux-kernel - Re: [PATCH 28/31] memblock: Export MEMBLOCK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1280294376.1970.239.camel@pasglop>
Date:	Wed, 28 Jul 2010 15:19:36 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 28/31] memblock: Export MEMBLOCK_ERROR again

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.

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 :-)

Cheers,
Ben.

> Ben.
> 
> > Signed-off-by: Yinghai Lu <yinghai@...nel.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/