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 09FECC10F1A for ; Thu, 9 May 2024 04:19:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E88E6B008A; Thu, 9 May 2024 00:19:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 498F16B0093; Thu, 9 May 2024 00:19:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 386F36B0095; Thu, 9 May 2024 00:19:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1A9586B008A for ; Thu, 9 May 2024 00:19:13 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BBD0F120CD7 for ; Thu, 9 May 2024 04:19:12 +0000 (UTC) X-FDA: 82097552544.27.AFF90A5 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) by imf19.hostedemail.com (Postfix) with ESMTP id 258B11A0010 for ; Thu, 9 May 2024 04:19:08 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=mAiWo9VC; spf=pass (imf19.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.113 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=1715228350; 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=MlG1jzYm3DvAdthJlhJIxmB4JV1uRQxd2gQtWVSOmrE=; b=nw6eV28it3L/h1Y1d07iCoNhiEfurAu2G6BEVieEQgOBAteAz8Rwg9CFIcCNNHQBFYVCNV hRbXm6ab9XXv3ijK0jQqaIsU4fq3ITp8q875mVjQ4kf/52Pcr7qFuCjMBDXliNNxT9ZP8P igjF6C8hIdzBh2h2SNHaJpWOh7H/dQ0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=mAiWo9VC; spf=pass (imf19.hostedemail.com: domain of hsiangkao@linux.alibaba.com designates 115.124.30.113 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=1715228350; a=rsa-sha256; cv=none; b=yZfIWUjscNgycLlGU1C/HuXB6jzYSlul3MGfepC7T7tH91bDGHrs1bw0gws+8RjhYFjJdG MXrHdxjNbaQ5tdIXTdnEsxK4tBX/s87oNDQ39XnTwWkoI2B5xG/2UpUvV318sE9Jt9Wp3T qFkepveKKBNtmn/FsVBoXL3c9Lo0zDU= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1715228346; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=MlG1jzYm3DvAdthJlhJIxmB4JV1uRQxd2gQtWVSOmrE=; b=mAiWo9VCHlGOvVxcZ0xIM58rEqTPbIyY1rInYEwwezcKoMoGLpxeh7ZPYaVvqC8ZIoE45QNGrspUnneSL/YDN5497WGnkXptRSeuH1/kPqwRSdZwMDGEgNYREm4Famu9ZNXfgBLGpbYJgJOV/AgbU+NFT0feLeKBJalILdQXphc= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R401e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045075189;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0W65Okvh_1715228343; Received: from 30.97.48.191(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0W65Okvh_1715228343) by smtp.aliyun-inc.com; Thu, 09 May 2024 12:19:04 +0800 Message-ID: <4fdc3040-4d20-4e9f-8002-e791e7a93c29@linux.alibaba.com> Date: Thu, 9 May 2024 12:19:02 +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>, Hailong Liu Cc: 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> <20240509033328.q2gwgaurpeg2mqqi@oppo.com> From: Gao Xiang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: a3fjbm66kpqg8ju3rzottg3qy3fecn5h X-Rspam-User: X-Rspamd-Queue-Id: 258B11A0010 X-Rspamd-Server: rspam05 X-HE-Tag: 1715228348-426246 X-HE-Meta: U2FsdGVkX19stHe06XsQFNGJcJd21Nd9jVeWTsqjaifBDCIAwILv1zqX5YOXKXQnH1a5Kgw+3M7lX3nQo0Lmghg0edY3pLMlqNHIZZBLPbKaD0BVl7g/F9Z+boUyBQ/0ligfK50cWHD/2rxNEvCse5EDczRJjZi12LWx5059V1dAIDHLUEQRWYIAlobsiX2iJAicmovjf7qR01lL5iBywjkjpdbHEviZnvzRzrCiTMB3OlG/yG4yqsGgESLGTqbu02xdeWL20A9g2dIhG1ghQJBDCqcV2zkdnj3FHzCS5Py1pyTTld+Hf5CzmLDJdtMoeG+vkqQx7buDHxB7ep6uSrf3R3opdXDPyHZiOOjdLhn+qSEbdTzpGEQqcCjg0Vc96dq+44j5dpApLqKk3XlO23qpzdeyDhkScm7kWK6kkeXVNF/3D7QJjQDXLEPq6/gcN7G9l4L7JqjFQjyzZYKI2nKJezVvFbD6GKK/Kw9Av/d0VpJ+iRqTv8eRoT9fmsypYR5y2vBXLcmj1VDU3VAniIOLiqes3Py1lSkoeWGaWPh1dH4sn6eg8FZV5wr+gxce8i/q4UopgT4CFw/gZDwG+Y9kANgBjbPbNzXR/9bNp69zhSogqq2Q4N15h5iwk0r5tTek61OZt08CJcJlHSJax7m5S/FAI96hYaWswaPwcCe7gWDZumf/IXF8sv3kdmbNau9wOtqqVkZsI5MPFdelSj9ZpHYjirMFLsx+gy8QxoKmSvcll61eQa19UUw2pjT2zZuOrque5UX/ddSqgGhbu/8rmE8jky5vAls8JqJlT5EDGcD/FjB1V4IFGMSm0g9r2f16ZeSKRiMZtwNIYVne3tNfTA2Bp3QAR0MwBUk/g2HWy7BSWxhXpHJDIfgpOW9TpNdoa5E1nRgNEO7YoQ9EFRuKRBQBaavnaV3W5mZkhlyYXmy3qBJ4N1SLO/vemQGAmd99y5zhRXXGyiAKLdw Z+ORCKeU vA9wcdBuTJhuv7OTnRTwuCICTAQ3INTVDs7DuXKNCbFWcedeJ+4gwjWTKTfVjlqF5gkas6B3JAKfr1kKKRPqK+Hf2CAamnRArlyeWWWFJ22/tvq62PiX8BL56Ie7Vigv3TTRPBxtEkY1sTahQewyEJWkkZRksba2a0WAcOsEaPnsYIq7r13G3ZTn8l6DKpAx0MIQ/OtTyyxmxj9pUDqx//hZV0+NTFmQbR1GmeJGSkB4szFDBHajXs26L6Xxl5vDdgjzWaJFoJnwDXAnKSWv92tIsmFxG0XbPenI1rmoQTeghCB9FJ1ARRXYGgLAeGxzyRtdJ0Tz4tYN8QEUUKe/k2XkIUR1RU9Pw9Zx+umsNe1hniax4OQgoCGPaMFhTjTXKI/onGVXYX+VJLbLXgSLIyZXYqoLbfP4ctzsrz8zQZu9a6vh+0MZDvPNbz2hNdYGSkrt9pZEes7Ws2qtMcsKP/KV5Dg== 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:48, Barry Song wrote: > On Thu, May 9, 2024 at 3:33 PM Hailong Liu wrote: >> >> On Thu, 09. May 14: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 ? >> >> if order = 0, nofail would not be set true in bulk allocator. in such a case, >> it is still possible to break early >> >>> >>> 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? >> >> IMO, if we encounter this issue, it should be fixed by the >> caller, not here. > > I agree. but could we WARN_ON a large kvmalloc(NOFAIL) allocation? For me, kvmalloc(~24k) sounds good to handle extreme cases (for extreme compression), only specific users for file archiving (and fuzzers) are expected to use this configuration. Anyway, it's just my own ideas. Thanks, Gao Xiang > >>> >> >>> >>> Thanks >>> Barry >> >> -- >> >> Best Regards, >> Hailong.