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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100323180823.GA6088@elte.hu>
Date:	Tue, 23 Mar 2010 19:08:23 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [RFC PATCH -v3 1/2] lmb: seperate region array from lmb_region
 struct


* Yinghai Lu <yinghai@...nel.org> wrote:

> On 03/23/2010 08:07 AM, Thomas Gleixner wrote:
> > On Tue, 23 Mar 2010, Yinghai Lu wrote:
> > 
> >>
> >> lmb_init() connect them back.
> >>
> >> also add region_array_size in lmb_region to tack the region array size.
> >>
> >> -v3: seperate lmb core change to seperated patch
> >>
> >> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
> >>
> >> ---
> >>  include/linux/lmb.h |    5 ++++-
> >>  lib/lmb.c           |   11 ++++++++++-
> >>  2 files changed, 14 insertions(+), 2 deletions(-)
> >>
> >> Index: linux-2.6/include/linux/lmb.h
> >> ===================================================================
> >> --- linux-2.6.orig/include/linux/lmb.h
> >> +++ linux-2.6/include/linux/lmb.h
> >> @@ -26,7 +26,8 @@ struct lmb_property {
> >>  struct lmb_region {
> >>  	unsigned long cnt;
> >>  	u64 size;
> >> -	struct lmb_property region[MAX_LMB_REGIONS+1];
> >> +	struct lmb_property *region;
> >> +	unsigned long region_array_size;
> >>  };
> >>  
> >>  struct lmb {
> >> @@ -37,6 +38,8 @@ struct lmb {
> >>  };
> >>  
> >>  extern struct lmb lmb;
> >> +extern struct lmb_property lmb_memory_region[MAX_LMB_REGIONS + 1];
> >> +extern struct lmb_property lmb_reserved_region[MAX_LMB_REGIONS + 1];
> > 
> > Is there a reason why this needs to be exported ?
> > 

> lmb_reserved_region is used in 
> kernel/early_res.c::__check_and_double_early_res/subtract_early_res/early_res_to_bootmem
> 
> later if those functions are moved lmb.c, we can make lmb_reserved_region to 
> be static
> 
> same thing to lmb_memory_region, that will be used by add_lmb_memory() 
> later.

I would strongly suggest for you to send the next (-v4) version to lkml only 
if it's 100% clean and complete in every known regard (with a good splitup and 
explanations in every commit), so that people dont repeat review or review an 
unclean aspect aspect that will go away in a next iteration.

Thanks,

	Ingo
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ