linux-kernel - Re: [Patch v2 2/2] mm/page_alloc.c: define node

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]

Date:   Sun, 29 Mar 2020 02:31:04 +0000
From:   Wei Yang <richard.weiyang@...il.com>
To:     John Hubbard <jhubbard@...dia.com>
Cc:     Wei Yang <richard.weiyang@...il.com>, akpm@...ux-foundation.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org, jgg@...pe.ca,
        david@...hat.com
Subject: Re: [Patch v2 2/2] mm/page_alloc.c: define node_order with all zero

On Sat, Mar 28, 2020 at 06:30:00PM -0700, John Hubbard wrote:
>On 3/27/20 7:56 PM, Wei Yang wrote:
>...
>> > Further note: On my current testing .config, I've got MAX_NUMNODES set to 64, which makes
>> > 256 bytes required for node_order array. 256 bytes on a 16KB stack is a little bit above
>> > my mental watermark for "that's too much in today's kernels".
>> > 
>> 
>> Thanks for your explanation. I would keep this in mind.
>> 
>> Now I have one more question, hope it won't sound silly. (16KB / 256) = 64,
>> this means if each function call takes 256 space on stack, the max call depth
>> is 64. So how deep a kernel function call would be? or expected to be?
>> 
>
>64 is quite a bit deeper call depth than we expect to see. So 256 bytes on the stack
>is not completely indefensible, but it's getting close. But worse, that's just an
>example based on my .config choices. And (as Baoquan just pointed out) it can be much
>bigger. (And the .config variable is an exponent, not linear, so it gets exciting fast.)
>In fact, you could overrun the stack directly, with say CONFIG_NODES_SHIFT = 14.
>

Thanks :-)

This is better not to use "big" structure on stack.

>> Also because of the limit space on stack, recursive function is not welcome in
>> kernel neither. Am I right?
>> 
>Yes, that is correct.
>
>thanks,
>-- 
>John Hubbard
>NVIDIA

-- 
Wei Yang
Help you, Help me