From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05553C10F1A for ; Thu, 9 May 2024 03:18:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DD206B0093; Wed, 8 May 2024 23:18:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 88DC56B0096; Wed, 8 May 2024 23:18:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77BB46B0098; Wed, 8 May 2024 23:18:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 55F6E6B0093 for ; Wed, 8 May 2024 23:18:03 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F39071C130C for ; Thu, 9 May 2024 03:18:02 +0000 (UTC) X-FDA: 82097398404.03.BD3E4D9 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 49C0D1A000B for ; Thu, 9 May 2024 03:17:59 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="ie/rV9Ai"; spf=pass (imf19.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715224681; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bJbpI4Ykw2bPEOET9QEYBge5aKOtp0FuvaBCPXYq4j8=; b=WeIDWHpyeCyuwxUr69gaMxm4bsMTuKRPXX97Jzma6sMby+QNTVpc7wF7kKDNAWbX/NWzud rLE621Gw1XQqQtJofU8m8L9D22jQcs+8JopSMF8Pfwd+AWuRhkXGVfJxeviqhUoPq8c1zM biZu5/z1QDaO9uqnod6cDJwz8ACd7xs= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="ie/rV9Ai"; spf=pass (imf19.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=hsiangkao@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715224681; a=rsa-sha256; cv=none; b=Tvyi148qb6rfApOytBQK7mUVZEdCZOQ5wc+2H8GDsQGixpBn0MGm950Xct0GPEOLAe9dln P60aZY+cFzU44xnMCq4KkALmAA3fvIKF8bpEaf0l+B5vVidaRjqgTtE8novYJi71Y3x0hg rSpQ19UFPqDKuASRB+NR5u8/U+hjtX4= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1715224677; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=bJbpI4Ykw2bPEOET9QEYBge5aKOtp0FuvaBCPXYq4j8=; b=ie/rV9AiPdVq499F/55o8QEytk35qC6N7I5QRXAdNwrZqbBdmPBCREq4qmVhF23U6Bh8H2VVywjwx3dyG6297HgHmvlbLjPhiFfX3UBuDg9IZU/fsdfBMyn0cXgPtAD6fK9JHNrkQaDkcJ0IpkAIswfjWOylL3TywvojCB9Ymw8= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R621e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037067110;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0W65OPA9_1715224674; Received: from 30.97.48.191(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0W65OPA9_1715224674) by smtp.aliyun-inc.com; Thu, 09 May 2024 11:17:56 +0800 Message-ID: Date: Thu, 9 May 2024 11:17:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL To: Barry Song <21cnbao@gmail.com> Cc: hailong.liu@oppo.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xiang@kernel.org, chao@kernel.org, Oven References: <20240508125808.28882-1-hailong.liu@oppo.com> <20d782ad-c059-4029-9c75-0ef278c98d81@linux.alibaba.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: i9sigrsdd3npdenzuqsfs8mcp3sogbpi X-Rspamd-Queue-Id: 49C0D1A000B X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1715224679-820716 X-HE-Meta: U2FsdGVkX19LRnh4OY8JgZ37aycXMN6moDJk5B6cymx9rLzLuqs9bTkIK1yk+inZwtejelTKQHoAoRjMyCEi42I6wvOzUZZXLso5juZfNwDNc6xRoZZryebOsl4gaQHSpUcBiVqswInTvE1zfWX88t2991tFrDfHIb0BJ4/zpg+rU6iEHtmiVu47+TlTwsIixNXCw54rN8VRYMrqVtXd+jbZ2g5dNSQZad/XPEQ813f6ApXTMmtsHjAwpmniE3lpiAiV5HDKwc7HXW/KtI6gJLMoiM79f0uXWiVlpROjlBEskoRSLUboGrg8GJ474AH7rc9z40TXOoS1WZYzQIxRaMNrKszgYNQRPsOEHWUgu8y1sjl/v04L0h4JGtuv/lKvvq9lWLfAI9YB1IZJbr/7hRH0zmZuUREh66dMrlXX8kVCZRY96KZpPRf5QCV33D7j4ZTq9wqYwDsed8XzqLv1OMr5CZi0D7cRUQJQ8AItt+1d0d5tm9tcTeanzfh+D8HdlSFp60LkoEFSPM+hT9oMZ1R7bwjNOW6+n0F5ewI7AwFuOAroIDXEyzgcK44cB1kmwQ6bpnFL67JCi1FDWanwFlIsufQhBwYVJ4/6K8CECcphPgsTCB3cPf/CA9zsugMkGiXXKo/uaeepVnFeJB1yxWecsiGQlYMoZIoWtkt+NJApMEM4UJMMa7lHXl2Ng5dHhnQMAC4krzqm9oDphFPQEEQOz22QLQ9Y64GTRQ0Qbj5s8GHynXmSs9/JntgM2oXvRcO8Cr3sXcittW54vPMV39oX1lmYENJjRDqoEO7xZEXPEn5+SKJ1SZ0CUg8riITgtS31twNKIFARwu8ddujCXbuXgYukQKkNpNpuHvWhz+6nLuG/MybDJst2oXdDKCixwrlM8Qv6ph/Lr18MK9e4JBnIt+MZIwun8J1rWx+uEIPxNzXCpjNiO57Pghj+lyZUoA9wlHrsJ6PpjOyEpkp 85GqErK4 cVLDOe5ogVmzrA8vfSgglUBlwHgKpgY24AS6b8LitKpCgKsKQPCAiOqr/3iVqIUfAzG8yoJsTUtYyq+WfG31IB18rRhzLQOUL89oo6mFj7LZ626GT5wlllFFFUlLH9bQJEgeVw9RInqdqUTfjYla9VXwofOJUtaecOf/diVc+PBVtE4EMz7yMJ3R/LbUxthGCR6RhGzky/J150CYzDZCgbZRf67HEF1zyb+XZKt+DKQFq/PxMyUXSEK0SwVcwx0r0ol+gDzM0FhCS7PEagLGDzuKEFxPv+J2dwxT+hqiSF20cBERyBGDdO4GKV+bbeGwMA8YQHFrtHZVXg/GwrUbOAPJCvbSDg4MbDKtUIyT8zPbkYShycIQ7GTUCSEWMgIIfNGUt24Q0iL+nRfB7qedcrrDmerBfZY01zi1O67YSbXv4Z/ojhE5keCtRoysVstHbHE9vXsTK/+ZosprNcaBY5YXYgfx4DRG3a31QSo2qjVbgenAHqsUmCBtjfJet7OVdEtQ+ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/5/9 11:09, Barry Song wrote: > On Thu, May 9, 2024 at 2:39 PM Gao Xiang wrote: >> >> Hi, >> >> On 2024/5/9 10:20, Barry Song wrote: >>> On Thu, May 9, 2024 at 12:58 AM wrote: >>>> >>>> From: "Hailong.Liu" >>>> >>>> Commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") >>>> includes support for __GFP_NOFAIL, but it presents a conflict with >>>> commit dd544141b9eb ("vmalloc: back off when the current task is >>>> OOM-killed"). A possible scenario is as belows: >>>> >>>> process-a >>>> kvcalloc(n, m, GFP_KERNEL | __GFP_NOFAIL) >>>> __vmalloc_node_range() >>>> __vmalloc_area_node() >>>> vm_area_alloc_pages() >>>> --> oom-killer send SIGKILL to process-a >>>> if (fatal_signal_pending(current)) break; >>>> --> return NULL; >>>> >>>> to fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() >>>> if __GFP_NOFAIL set. >>>> >>>> Reported-by: Oven >>>> Signed-off-by: Hailong.Liu >>>> --- >>>> mm/vmalloc.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >>>> index 6641be0ca80b..2f359d08bf8d 100644 >>>> --- a/mm/vmalloc.c >>>> +++ b/mm/vmalloc.c >>>> @@ -3560,7 +3560,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, >>>> >>>> /* High-order pages or fallback path if "bulk" fails. */ >>>> while (nr_allocated < nr_pages) { >>>> - if (fatal_signal_pending(current)) >>>> + if (!(gfp & __GFP_NOFAIL) && fatal_signal_pending(current)) >>>> break; >>> >>> why not !nofail ? >>> >>> This seems a correct fix, but it undermines the assumption made in >>> commit dd544141b9eb >>> ("vmalloc: back off when the current task is OOM-killed") >>> >>> " >>> This may trigger some hidden problems, when caller does not handle >>> vmalloc failures, or when rollaback after failed vmalloc calls own >>> vmallocs inside. However all of these scenarios are incorrect: vmalloc >>> does not guarantee successful allocation, it has never been called with >>> __GFP_NOFAIL and threfore either should not be used for any rollbacks or >>> should handle such errors correctly and not lead to critical failures. >>> " >>> >>> If a significant kvmalloc operation is performed with the NOFAIL flag, it risks >>> reverting the fix intended to address the OOM-killer issue in commit >>> dd544141b9eb. >>> Should we indeed permit the NOFAIL flag for large kvmalloc allocations? >> >> Just from my perspective, I don't really care about kmalloc, vmalloc >> or kvmalloc (__GFP_NOFAIL). I even don't care if it returns three >> order-0 pages or a high-order page. I just would like to need a >> virtual consecutive buffer (even it works slowly.) with __GFP_NOFAIL. >> >> Because in some cases, writing fallback code may be tough and hard to >> test if such fallback path is correct since it only triggers in extreme >> workloads, and even such buffers are just used in a very short lifetime. >> Also see other FS discussion of __GFP_NOFAIL, e.g. >> https://lore.kernel.org/all/ZcUQfzfQ9R8X0s47@tiehlicka/ >> >> In the worst cases, it usually just needs < 5 order-0 pages (for many >> cases it only needs one page), but with kmalloc it will trigger WARN >> if it occurs to > order-1 allocation. as I mentioned before. >> >> With my limited understanding I don't see why it could any problem with >> kvmalloc(__GFP_NOFAIL) since it has no difference of kmalloc(GFP_NOFAIL) >> with order-0 allocation. > > I completely understand that you're not concerned about the origin of > the memory, > such as whether it's organized by all zero-order pages. However, in the event > that someone else allocates a large memory, like several megabytes with the > NOFAIL flag, commit dd544141b9eb aims to halt the allocation before success > if the process being allocated is targeted for termination of OOM-killer. > > With the current patch, we miss the opportunity for early allocation > termination. > However, if the size of the kvmalloc() is small, as in your case, I > believe it should > be perfectly fine. but do we have any way to prevent large size allocation with > NOFAIL? I think large size order-0 virtual consecutive allocation prevention should be done by the callers (e.g. EROFS) other than memory subsystem, since it totally sounds like caller bugs. It doesn't make sense for me to block getting a virtual consecutive buffer which only needs more than two (e.g. three or five) order-0 pages in the extreme cases. Yes, I need to prevent very insane allocations but it's an on-disk hard limitation of a filesystem itself. Thanks, Gao Xiang > >> >> >> Thanks, >> Gao XIang > > Thanks > Barry