linux-kernel - Re: [PATCH] mm: add warning if __vm_enough

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: <ceefb6c0-fbed-447f-791f-c48d3a4c41cc@huawei.com>
Date:   Tue, 26 Jul 2022 22:42:11 +0800
From:   Kefeng Wang <wangkefeng.wang@...wei.com>
To:     David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
CC:     Yongqiang Liu <liuyongqiang13@...wei.com>
Subject: Re: [PATCH] mm: add warning if __vm_enough_memory fails


On 2022/7/26 21:45, David Hildenbrand wrote:
> On 26.07.22 09:24, Kefeng Wang wrote:
>> If a process has no enough memory to allocate a new virtual mapping, we
>> may meet kinds of error, eg, fork cannot allocate memory, SIGBUS error
>> in shmem, but it is difficult to confirm them, let's add some debug
>> information to easy to check this scenario if __vm_enough_memory fails.
>>
>> Reported-by: Yongqiang Liu <liuyongqiang13@...wei.com>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@...wei.com>
>> ---
>>   mm/util.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/mm/util.c b/mm/util.c
>> index 1266a33a49ea..19bfff8a0ad6 100644
>> --- a/mm/util.c
>> +++ b/mm/util.c
>> @@ -1020,6 +1020,8 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
>>   	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
>>   		return 0;
>>   error:
>> +	pr_warn("%s: pid: %d, comm: %s, no enough memory for the allocation\n",
>> +		__func__, current->pid, current->comm);
>>   	vm_unacct_memory(pages);
>>   
>>   	return -ENOMEM;
> Users can easily spam the kernel log, no? Maybe at least ratelimit.
pr_warn_ratelimited is better, will update, thanks.
>