linux-kernel - Re: [PATCH v2] cma: introduce CMA_ALLOC

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: <9ab7df09-e128-4940-ace5-0cc5ffa1ec4d@quicinc.com>
Date:   Fri, 25 Aug 2023 18:38:13 +0530
From:   Bibek Kumar Patro <quic_bibekkum@...cinc.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
CC:     <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        Pavan Kondeti <quic_pkondeti@...cinc.com>,
        <quic_charante@...cinc.com>
Subject: Re: [PATCH v2] cma: introduce CMA_ALLOC_DEBUG config

On 8/14/2023 8:30 AM, Pavan Kondeti wrote:
> Bibek,
> 
> On Thu, Aug 10, 2023 at 09:54:51AM -0700, Andrew Morton wrote:
>> On Wed, 9 Aug 2023 18:46:40 +0530 Bibek Kumar Patro <quic_bibekkum@...cinc.com> wrote:
>>
>>> Currently enabling CONFIG_CMA_DEBUG enables DEBUG preprocessor macro.
>>> If DEBUG is defined, it's equivalent to a printk with KERN_DEBUG loglevel
>>> flooding the dmesg buffer with pr_debug prints from mm/cma driver and from
>>> included files as well. This results in excessive amount of CMA logging and
>>> also might distract the debug teams with unrelated KERN_DEBUG prints.One of
>>> the ways engineers currently tackle this problem is by passing loglevel=N
>>> though commandline to suppress KERN_DEBUG messages. This approach can
>>> sometimes become tiresome due to its repetitive nature.
>>> This patch proposes an alternative approach by introducing a simple new
>>> config CONFIG_CMA_ALLOC_DEBUG which only shows the cma bit allocation
>>> status in case of cma failure and do not enable DEBUG preprocessor macro
>>> from CONFIG_CMA_DEBUG avoiding excessive CMA logging from pr_debug.
>>> Engineers and tech teams seeking only for bitmap status in case of cma
>>> failure can use this simple config instead of worrying about changing
>>> the loglevel or trying other similar workarounds.
>>
>> Would it be better to control this at runtime?  With a /proc or /sys tunable?
> 

Thanks Andrew for suggestion and Pavan for the details, tunable approach
looks viable too since we get to control this during runtime, but had
one query in mind where your inputs would help. In case any engineer 
wishes to check boot time CMA failures, would it be easier to use a
CONFIG or /proc , /sys tunable?
(Assuming for /proc or /sys tunable, one has to modify the
init/post_boot scripts to mount the fs and set the tunable to true )

> IIUC, Andrew is asking/suggesting that would a runtime knob be useful
> here?
> 
> For ex:
> 
> /proc/sys/vm/cma_dump_on_failure : This needs to be registerd in the
> cma.c . grep for "register_sysctl_init" in mm code. We can set this to
> true by default in case CMA_DEBUG is enabled so that current users are
> not affected.
> 
> /sys/kernel/mm/cma/bitmap_dump_on_failure : This needs to stay in
> cma_sysfs.c code
> 
> Thanks,
> Pavan
> 
> 

Thanks,
Bibek