Received: by 2002:ab2:6991:0:b0:1f7:f6c3:9cb1 with SMTP id v17csp911646lqo; Wed, 8 May 2024 21:19:26 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVMLGBgk4nH2fEsArr2LfhtCz2+3QLnLKvDCYpYcm0EJusm1vJBmPaRTQxxeoxWNq0iXOt0hVXYAFJa4MUnZzKQSOfZfCpEHe0hplongg== X-Google-Smtp-Source: AGHT+IGdvsyYJ3mgPaH2GQVy8grBhjh5V4rjm4u0EFPTVVsnqM4RsyQFE72JJ+RgXAiMId4AUg+B X-Received: by 2002:a17:902:b110:b0:1e4:b4f5:5cfa with SMTP id d9443c01a7336-1eeb03a05d3mr44950705ad.27.1715228366390; Wed, 08 May 2024 21:19:26 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715228366; cv=pass; d=google.com; s=arc-20160816; b=AuxXozU/kFk5t0Zk+AUo1rz6rL/MFUvyt7WE7/l4nod7hQ32DRnYWP6yzTP71fgEfM w6dfnM3Bw64xmb24HoBj64oDRuXOFsYcohrlO5afSyS92rvrN+r6jlCF0gG1X/jsyI6A woNro/Dil+6dWZpFmCraOFroHYcYxISHrpHODJaCwmzGVnYBHY4Y+c7uK1EYVhmmigJi 7mkWTAIcOUZiwUy02aEaoK68o9ytBLEUZsUYKqQBcQb21EkZIV49LMubNYsSfcWfDBbT 2TpKksBqUySw0+VNg6PGMCk7YZoUhQcdSn0DSTyZr0mlVKxM4DoxSQlsNHcdGi0fgHhX 89WA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:date:message-id:dkim-signature; bh=MlG1jzYm3DvAdthJlhJIxmB4JV1uRQxd2gQtWVSOmrE=; fh=PnwkTy7umUkZL3IgbWt7YBVOAiCpaGbuE9748OqnNSY=; b=Nr0REelv+gW/4u4ib3xT9sr2z7J+6OT/UDfH+9+n97ifzJbJqNhv8RAuewtti7g0Vm Zi7yvmfs8JYVtpJ08y75faYre+tiKOwMw1bUNM48+/vuy6chO6pStgUSiCv14X1LnUtA g+XW5jaVe03RFNnrsAIGJcW6+I4H7sNb1qKoswpF4MNsOvPzqEiyOcMxHuV0Z4HwtrKA OFWyeSSgADIy4FKUF2dDT/Hwjt0eVTVzwXIKz1NAyOrYZgegU4ftcqenXfMX+Jm0AsvF kScNfY8Fz+//VSZosy2zQ0V5yot+nEniia2XzbdMvGD2eZCiFsrZLHS3B4GCdc+5CaTk JTGQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=WlnvHTte; arc=pass (i=1 spf=pass spfdomain=linux.alibaba.com dkim=pass dkdomain=linux.alibaba.com dmarc=pass fromdomain=linux.alibaba.com); spf=pass (google.com: domain of linux-kernel+bounces-174120-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-174120-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id d9443c01a7336-1ef0b9d0aa5si6303045ad.45.2024.05.08.21.19.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 May 2024 21:19:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-174120-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=WlnvHTte; arc=pass (i=1 spf=pass spfdomain=linux.alibaba.com dkim=pass dkdomain=linux.alibaba.com dmarc=pass fromdomain=linux.alibaba.com); spf=pass (google.com: domain of linux-kernel+bounces-174120-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-174120-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id ECE40B21EB2 for ; Thu, 9 May 2024 04:19:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DF8231482EB; Thu, 9 May 2024 04:19:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="WlnvHTte" Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F6511E4A4 for ; Thu, 9 May 2024 04:19:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715228356; cv=none; b=moJtVkbTGMqa7dlsrfvNOQHo4pn7UcVpg28B/bHfKMmwb10IIA2ZqcsYdonjbmyyzWLJjWqKjtIe0eyVdFzUG6MwexDgTde+JWWOAmGlPovAWHDVsC2S9rjiHlxEOd5I+IZROfAYEcfoAZcYK9c03FrCdMehS5xPpir1Igz35NM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715228356; c=relaxed/simple; bh=t6X6Z9zekKog4v4Cd99gC/6aeRTVc7xC0att6kMZxXE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VcWKumuVOM00wZAQAdhCi9nDqsf+Y8h6Pd6i5e1zUGfMCRarDEaJVUDVQJBMwKrP97je1mBiqVuNpitvj+Jw9ApflbSloRQHNNYzkEQlbpSSinPzCj8xA+S8yBHQr4X0iRnZEAnJJoXHKEmhBGqb9JmmtX6aUgJ5ueFu/f3T8tY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=WlnvHTte; arc=none smtp.client-ip=115.124.30.99 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1715228345; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=MlG1jzYm3DvAdthJlhJIxmB4JV1uRQxd2gQtWVSOmrE=; b=WlnvHTtecf/AL6NiukuNt2iXr5XV/w6df5iV4DbA3RtrzUv9d8wjE1mdiI6BeIdiwooF15H+DnQ22hLl0wTHcV5Fk+L0Fag85Hg30LuN6W6ZBXHsc6r800+VjeGCzwpC/sy1EBd4YeTbiBCvsOEYJ1JWLL/LqxsKw1Vfwu4RFVU= 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 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.