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: <20200804061526epcms5p3ff393f7e51d28ed896105c868bd31e5b@epcms5p3>
Date:   Tue, 04 Aug 2020 11:45:26 +0530
From:   Vaneet Narang <v.narang@...sung.com>
To:     Mark Rutland <mark.rutland@....com>
CC:     Maninder Singh <maninder1.s@...sung.com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "oleg@...hat.com" <oleg@...hat.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "adobriyan@...il.com" <adobriyan@...il.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "steve.capper@....com" <steve.capper@....com>,
        "vincenzo.frascino@....com" <vincenzo.frascino@....com>,
        "anshuman.khandual@....com" <anshuman.khandual@....com>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "james.morse@....com" <james.morse@....com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "maz@...nel.org" <maz@...nel.org>,
        "kristina.martsenko@....com" <kristina.martsenko@....com>,
        "samitolvanen@...gle.com" <samitolvanen@...gle.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "gladkov.alexey@...il.com" <gladkov.alexey@...il.com>,
        "daniel.m.jordan@...cle.com" <daniel.m.jordan@...cle.com>,
        "walken@...gle.com" <walken@...gle.com>,
        "bernd.edlinger@...mail.de" <bernd.edlinger@...mail.de>,
        "laoar.shao@...il.com" <laoar.shao@...il.com>,
        "avagin@...il.com" <avagin@...il.com>,
        "john.johansen@...onical.com" <john.johansen@...onical.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        AMIT SAHRAWAT <a.sahrawat@...sung.com>
Subject: RE: [PATCH 1/1] arm64: add support for PAGE_SIZE aligned kernel
 stack

Hi Mark,

>> currently THREAD_SIZE is always in power of 2, which will waste
>> memory in cases there is need to increase of stack size.
>
>If you are seeing issues with the current stack size, can you please
>explain that in more detail? Where are you seeing problems? Which
>configuration options do you have selected?
>
>I'm not keen on making kernel stack sizes configurable as it's not
>currently possible for the person building the kernel to figure out a
>safe size (and if this were possible, it's be better to handle this
>automatically).
>
>If the stack size is too small in some configurations I think we need to
>ensure that it is appropriately sized regardless of whether the person
>building the kernel believes they can identify a reasonable size.

Motivation behind these changes is saving memory on our system. 
Our system runs around 2500 threads concurrently so saving 4Kb  
might help us in saving 10MB memory.

To ensure 12KB is sufficient for our system we have used stack tracing and 
realised maximum stack used is not more than 9KB. 
 /sys/kernel/tracing/stack_max_size

Tracing interface defined by kernel to track maximum stack size can be used
by others to decide appropriate stack size.

>> Thus adding support for PAGE_SIZE(not power of 2) stacks for arm64.
>> User can decide any value 12KB, 16KB, 20 KB etc. based on value
>> of THREAD_SHIFT. User can set any value which is PAGE_SIZE aligned for
>> PAGE_ALIGNED_STACK_SIZE config.
>> 
>> Value of THREAD_SIZE is defined as 12KB for now, since with irq stacks
>> it is enough and it will save 4KB per thread.
>
>How are you certain of this?

Prev ARM64 uses 16KB stack size to store IRQ stack and thread on the same kernel stack.
Now since these are stored seperately so maximum kernel stack requirement is also reduced. 
ARM still uses 8KB stack to store both SVC and IRQ mode stack. So ARM64 shouldn't
have requirement more than double when compared to ARM. 
So considering these points we realised 12KB stack might be sufficient
for our system. Analyzing stack using stack tracer confirmed max stack requirement.

This is still configurable, if some system has higher stack requirement then user can 
go with 16KB but there should be option to change it.

 
Regards,
Vaneet Narang

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ