linux-kernel - Re: [PATCH] debugobjects: add a new Kconfig for POOL

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:   Sun, 18 Nov 2018 13:56:45 -0500
From:   Qian Cai <cai@....us>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Waiman Long <longman@...hat.com>,
        Yang Shi <yang.shi@...ux.alibaba.com>, arnd@...db.de,
        linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] debugobjects: add a new Kconfig for POOL_SIZE



> On Nov 18, 2018, at 1:21 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> Qian,
> 
> On Sun, 18 Nov 2018, Qian Cai wrote:
> 
>> The current value of ODEBUG_POOL_SIZE is not big enough for large memory
>> systems with timer or/and workqueue objects because during the early
>> boot, timer objects needs at least the size equals to
>> 
>> No. CPUs x 2 (worker pool)
>> 
>> start_kernel
>>  workqueue_init_early
>>    init_worker_pool
>>      init_timer_key
>>        debug_object_init
>> 
>> puls, No. CPUs
>> 
>> start_kernel
>>  sched_init
>>    hrtimer_init
>>     debug_object_init
>> 
>> Then, workqueue objects requires even more,
>> 
>> No. CPUs x 2 (worker pool) x 6 (workqueue)
>> 
>> start_kernel
>>  workqueue_init_early
>>    __alloc_workqueue_key
>>      alloc_workqueue
>>        init_pwq
>>          debug_object_init
>> 
>> plus, No, CPUs x 2 (worker pool)
>> 
>> start_kernel
>>  perf_event_init
>>    __init_srcu_struct
>>      init_srcu_struct_fields
>>        __init_work
>>          debug_object_init
>> 
>> As the results, systems have 60+ CPUs with both timer and workqueue
>> objects enabled could trigger "ODEBUG: Out of memory. ODEBUG disabled".
>> 
>> Hence, add a new Kconfig option so users could adjust ODEBUG_POOL_SIZE
>> accordingly if either timer or workqueue objects are selected.
> 
> why do we need a config option, when the required number can be deduced
> already from the active CONFIG_DEBUG_OBJECTS_* and NR_CPUS?
> 
It because I am worry about the coupling between the implementation details of
timers and workqueue objects, and the computation in the code you mentioned
here. For example, people could change workqueue.c to have different number
of worekqueues initialized during the early boot in the future which is going to
affect the required pool size, and I am not sure if people are going to adjust the
code in debugobjects.c here as well when they made changes like that.

Also, the computation could become so complex depends on lots of config
options like perf, hrtimer, and combinations that I have not tested so far which is
difficult to exhausted all the possibilities.

Hence, I feel like the Kconfig option is more flexible and less error-prone.