linux-kernel - Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE

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] [day] [month] [year] [list]

Message-ID: <400273a8-e764-53df-84d3-4ee4d4e22098@linaro.org>
Date:	Mon, 23 May 2016 11:35:16 -0700
From:	"Shi, Yang" <yang.shi@...aro.org>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linaro-kernel@...ts.linaro.org
Subject: Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on
 !FLATMEM explicitly

On 5/23/2016 11:22 AM, Michal Hocko wrote:
> On Mon 23-05-16 09:54:31, Yang Shi wrote:
>> Per the suggestion from Michal Hocko [1], CONFIG_DEFERRED_STRUCT_PAGE_INIT
>> should be incompatible with FLATMEM, make this explicitly in Kconfig.
>
> I guess the changelog could benefit from some clarification. What
> do you think about the following:
>
> "
> DEFERRED_STRUCT_PAGE_INIT requires some ordering wrt other
> initialization operations, e.g. page_ext_init has to happen after the
> whole memmap is initialized properly. For SPARSEMEM this requires to
> wait for page_alloc_init_late. Other memory models (e.g. flatmem) might
> have different initialization layouts (page_ext_init_flatmem). Currently
> DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which in turn
> 	depends on SPARSEMEM || X86_64_ACPI_NUMA
> 	depends on ARCH_ENABLE_MEMORY_HOTPLUG
>
> and X86_64_ACPI_NUMA depends on NUMA which in turn disable FLATMEM
> memory model:
> config ARCH_FLATMEM_ENABLE
> 	def_bool y
> 	depends on X86_32 && !NUMA
>
> so FLATMEM is ruled out via dependency maze. Be explicit and disable
> FLATMEM for DEFERRED_STRUCT_PAGE_INIT so that we do not reintroduce
> subtle initialization bugs
> "

Thanks a lot. It sounds way better. Will address in V2.

Yang

>
>>
>> [1] http://lkml.kernel.org/r/20160523073157.GD2278@dhcp22.suse.cz
>>
>> Signed-off-by: Yang Shi <yang.shi@...aro.org>
>> ---
>>  mm/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 2664c11..22fa818 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -649,6 +649,7 @@ config DEFERRED_STRUCT_PAGE_INIT
>>  	default n
>>  	depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>>  	depends on MEMORY_HOTPLUG
>> +	depends on !FLATMEM
>>  	help
>>  	  Ordinarily all struct pages are initialised during early boot in a
>>  	  single thread. On very large machines this can take a considerable
>> --
>> 2.0.2
>