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]
Date:	Fri, 11 Jan 2013 13:12:26 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	Tang Chen <tangchen@...fujitsu.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Wen Congyang <wency@...fujitsu.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Wu Jianguo <wujianguo@...wei.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: mmots: memory-hotplug: implement
 register_page_bootmem_info_section of sparse-vmemmap fix

On Fri 11-01-13 20:06:25, Tang Chen wrote:
> On 01/11/2013 06:47 PM, Michal Hocko wrote:
> >>
> >>Darn! And now that I am looking at the patch closer it is too x86
> >>centric so this cannot be in the generic code. I will try to cook
> >>something better. Sorry about the noise.
> >
> >It is more complicated than I thought. One would tell it's a mess.
> >The patch bellow fixes the compilation issue but I am not sure we want
> >to include memory_hotplug.h into arch/x86/mm/init_64.c. Moreover
> >
> >+void register_page_bootmem_memmap(unsigned long section_nr,
> >+				  struct page *start_page, unsigned long size)
> >+{
> >+	/* TODO */
> >+}
> >
> >for other archs would suggest that the code is not ready yet. Should
> >this rather be dropped for now?
> 
> Hi Michal,
> 
> Do you mean remove register_page_bootmem_memmap() from other
> architectures ?

No I meant the patch to be dropped until it gets implementation for
other architectures or the users of the function would be explicit about
archs which are supported. What happens if the implementation is empty
will the generic code work properly? From my very limitted understanding
of the code it won't.

-- 
Michal Hocko
SUSE Labs
--
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