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
| ||
|
Message-ID: <50F007C9.10606@cn.fujitsu.com> Date: Fri, 11 Jan 2013 20:38:33 +0800 From: Tang Chen <tangchen@...fujitsu.com> To: Michal Hocko <mhocko@...e.cz> 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 01/11/2013 08:12 PM, Michal Hocko wrote: > 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. Hi Michal, Hum, I see. Thank you for your remind. :) register_page_bootmem_info_section() will be different in other architectures if register_page_bootmem_memmap() is empty. I think we can post a patch to make register_page_bootmem_info_section() the same as before, and we just implement the x86 version first. So that it will have no harm to other architectures. How do you think ? Thanks. :) > -- 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