linux-kernel - Re: [PATCH] lib/alloc_tag: Remove the sysctl configuration to prevent users from disabling it at runtime

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: <a2bcfd4a-8276-2544-7a1a-367635e031c6@linux.dev>
Date: Wed, 13 Nov 2024 14:14:27 +0800
From: Hao Ge <hao.ge@...ux.dev>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Suren Baghdasaryan <surenb@...gle.com>, akpm@...ux-foundation.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, Hao Ge <gehao@...inos.cn>
Subject: Re: [PATCH] lib/alloc_tag: Remove the sysctl configuration to prevent
 users from disabling it at runtime


On 11/13/24 02:14, Kent Overstreet wrote:
> On Tue, Nov 12, 2024 at 11:30:39AM +0800, Hao Ge wrote:
>> Hi Suren
>>
>>
>> Firstly, please forgive me for my improper wording in the commit message.
>>
>> After sending it, I realized that I should have used "suggestion" instead of
>> "decided".
>>
>> Secondly, please forgive me for taking a few days to respond. I've been
>> quite busy these days.
>>
>>
>> Let's continue to discuss this issue.
>>
>>
>> On 11/9/24 02:16, Suren Baghdasaryan wrote:
>>> On Thu, Nov 7, 2024 at 11:50 PM Hao Ge <hao.ge@...ux.dev> wrote:
>>>> From: Hao Ge <gehao@...inos.cn>
>>>>
>>>> After much consideration,I have decided to remove
>>>> the "mem_profiling" sysctl interface to prevent
>>>> users from dynamically enabling or disabling the
>>>> MEMORY ALLOCATION PROFILING feature at runtime.
>>>>
>>>> I have taken the following actions: I set
>>>> CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y to
>>>> enable memory allocation profiling by default,
>>>> and then made adjustments to mem_profiling dynamically
>>>> during runtime.
>>>>
>>>> When I ran the OOM test program, I obtained useful
>>>> information that was indeed very helpful for debugging.
>>>>
>>>> [ 1023.065402] Memory allocations:
>>>> [ 1023.065407]     12.8 GiB     6546 mm/huge_memory.c:1328 func:do_huge_pmd_anonymous_page
>>>> [ 1023.065412]      873 MiB   229985 arch/arm64/mm/fault.c:986 func:vma_alloc_zeroed_movable_folio
>>>> [ 1023.065415]      187 MiB    29732 mm/slub.c:2412 func:alloc_slab_page
>>>> [ 1023.065418]     99.8 MiB    25560 mm/memory.c:1065 func:folio_prealloc
>>>> [ 1023.065421]     47.2 MiB     3189 mm/readahead.c:434 func:ra_alloc_folio
>>>> [ 1023.065424]     30.0 MiB       15 mm/khugepaged.c:1072 func:alloc_charge_folio
>>>> [ 1023.065428]     28.6 MiB      514 mm/compaction.c:1880 func:compaction_alloc
>>>> [ 1023.065430]     25.8 MiB     6592 mm/page_ext.c:271 func:alloc_page_ext
>>>> [ 1023.065433]     25.6 MiB     6546 mm/huge_memory.c:1161 func:__do_huge_pmd_anonymous_page
>>>> [ 1023.065436]     23.5 MiB     6017 mm/shmem.c:1771 func:shmem_alloc_folio
>>>>
>>>> After running echo 0 > /proc/sys/vm/mem_profiling
>>>> and then executing the same test program,
>>>> I obtained the following results
>>>>
>>>> [ 1156.509699] Memory allocations:
>>>> [ 1156.509703]      187 MiB    29645 mm/slub.c:2412 func:alloc_slab_page
>>>> [ 1156.509707]      142 MiB     9357 mm/readahead.c:434 func:ra_alloc_folio
>>>> [ 1156.509710]      136 MiB    41325 arch/arm64/mm/fault.c:986 func:vma_alloc_zeroed_movable_folio
>>>> [ 1156.509713]     99.7 MiB    25531 mm/memory.c:1065 func:folio_prealloc
>>>> [ 1156.509716]     56.0 MiB       28 mm/huge_memory.c:1328 func:do_huge_pmd_anonymous_page
>>>> [ 1156.509719]     30.0 MiB       15 mm/khugepaged.c:1072 func:alloc_charge_folio
>>>> [ 1156.509723]     28.6 MiB      514 mm/compaction.c:1880 func:compaction_alloc
>>>> [ 1156.509725]     26.3 MiB     7460 mm/readahead.c:264 func:page_cache_ra_unbounded
>>>> [ 1156.509728]     25.8 MiB     6592 mm/page_ext.c:271 func:alloc_page_ext
>>>> [ 1156.509730]     23.5 MiB     6016 mm/shmem.c:1771 func:shmem_alloc_folio
>>>>
>>>> Because mem_profiling was disabled by executing
>>>> echo 0 > /proc/sys/vm/mem_profiling,we are unable to
>>>> record memory allocation information after the disablement.
>>> Naturally you are unable to track the allocations after disabling it.
>>> You disabled it as root, so I assume you know what you are doing.
>>>
>>>> These output logs can mislead users. And similarly, the same
>>>> applies to alloc_info.
>>> I would understand if you made /proc/allocinfo empty after disabling
>>> it to avoid confusing the user, but ripping out the ability to
>>> enable/disable profiling at runtime does not make sense to me. Once
>>> you collect required data, disabling profiling gets you back the
>>> performance that you pay for it. There are usecases when a program on
>>> a remote device periodically enables profiling for some time, records
>>> the difference in allocations and then disables it. Your change breaks
>>> such users.
>>
>> Actually, my original intention was also to make /proc/allocinfo empty when
>> disabling it,
>>
>> but I considered the following scenario: after we disable it and clear
>> /proc/allocinfo,
>>
>> we then start a memory-intensive application,
>>
>> such as our OOM (Out-Of-Memory) test program.
>>
>> If we later enable it again, the issue described in my commit message would
>> still arise.
>>
>> Perhaps we need to further consider how to handle this situation.
> Why would you do such a thing?
>
> We put a lot of effort into making memory allocation profiling cheap
> enough to leave on, and I haven't seen a single complaint about
> performance overhead.


Hi Kent


Thank you very much for your and Suren's hard work.

For me, this feature is still very useful

As I mentioned in my previous reply to Suren's email, I did overlook 
some things, and for that, I apologize.


Thanks

Best regards

Hao