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 7958AC3DA5D for ; Mon, 22 Jul 2024 07:23:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1AC86B0082; Mon, 22 Jul 2024 03:23:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BCAE56B0083; Mon, 22 Jul 2024 03:23:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6B916B0085; Mon, 22 Jul 2024 03:23:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 880FC6B0082 for ; Mon, 22 Jul 2024 03:23:07 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DE90C81613 for ; Mon, 22 Jul 2024 07:23:06 +0000 (UTC) X-FDA: 82366547172.21.A835156 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf19.hostedemail.com (Postfix) with ESMTP id CB6441A0013 for ; Mon, 22 Jul 2024 07:23:04 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=C7SxHSq1; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721632939; 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=SUaiZfxtxAdawjHZGhF0YvhiUz0EPiUeY9HzgZ/YdV0=; b=QF1AWOy/B7+SW+TV+PdMmeEDA9fNd0sd477VBN2GP/L8Evu2k7sHeWT/Xb8DBrUsd/glBq Efo5lahux757mw0gkjZSwb85FcpY9jpYIh2WUwnfSIcd4qEdR/FBCG8NUpXQHxjYzsnQ0s FQl6CYHSCzYvZnEOYtfrmrtNVC7i72M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721632939; a=rsa-sha256; cv=none; b=b6H63fUDKjHneb4q8odstKIKa+BGx7bUCsRwKwEw1IzFaL++/5s8adiOZWmj06RzfGp7t4 VNT4Yo5QOSU/c2uPHsOWaivD4dkWx8T2tHjuZh+CmJqayBWL3J7a0SdSayEOmKmHjsq/SF szdgu/ZOBIYdsJCNpWqxNbH1bqcEaB8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=C7SxHSq1; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a77e7a6cfa7so389371566b.1 for ; Mon, 22 Jul 2024 00:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721632983; x=1722237783; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=SUaiZfxtxAdawjHZGhF0YvhiUz0EPiUeY9HzgZ/YdV0=; b=C7SxHSq1tXPLPLMxHXeTNkykGU5VNeQNsG6OJi/kBlZ2W9DbJ82RlEDwp3w9QGCy1V vbId4qQ/w4iDXdjtyQ5L5qpfEKbzSG+6R+m/dNV3yarrC2M86jZcj95S0gxd/y8NaJJk TVqefHPYZz2VoSRLj1OEo8bBInp83v5VvTcYivWkI40LvINaTBSU5D0TAxBZoSaZopM2 5eY76RR9433E8U6MZ4Ms0Lm7jnb+JtNXW+74Ioc5BLEfDu+dbZ6HzeqBQIjMG9TKloVz +rIgiA2kTII4XsZx894bvWA7lLLQczJ63RPFWh93JkxLmDHnDdXywzH5eDbjIFgWfjFz Me9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721632983; x=1722237783; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SUaiZfxtxAdawjHZGhF0YvhiUz0EPiUeY9HzgZ/YdV0=; b=jAvx8IB5Cb8tDZySyeT0+labBhzSMGsG7o2P+uGjlWG/C5XepLyFY+bqhuukOt3JY7 3X7C/8CnSMQDRyndDn1qiUxpoRiUAI7scbLpG9/unSM29P8W0F2ABCVJkGRrTQq7oJjw g7ge49VQMqdvNtY9iypwWynQxaf2OrLwpjzm9m/3iGcX2SqgRnEozTQXY9NeZYV7T+Gf Jf+YqtaSETVyCMhduPMx/hJ8c2oaSc8n/2WKbKUnTe8twmoH1THVPsRHRwWGi1fBs6lo YNfujsHWCi2sGe8jYWYaEvmq14dvyY5BJnWVPRdo5qZ5KTDGxWq3PfNlky+rLLPMFf7e B3iA== X-Forwarded-Encrypted: i=1; AJvYcCUhEcmSLw92kz7ToWkoMNJX6TcKLJWr+DIg/k01mzHKZazmYrWHr8PMWsttvCOLhOuWwr5V/qBQyWcYP38YSXLr3OA= X-Gm-Message-State: AOJu0YygDJgY3LX/97rvwI9dZ0yveqWAxX169J3j4dCj17Q/rHH2d66U 0+HWdZjIQScK9cGNgLpgD6oDI8QukhYPWi/8n3/3LIJ9uBgbhjHq/wltTbLfjbM= X-Google-Smtp-Source: AGHT+IFAE8uE11J2SBwiygwzWHzaYgaaEjOXbHseGvblIYVw1mcgWjVueZvNWqUA563BGYpnwhWmtg== X-Received: by 2002:a17:906:684b:b0:a77:c5a5:f652 with SMTP id a640c23a62f3a-a7a01147188mr906438866b.26.1721632983098; Mon, 22 Jul 2024 00:23:03 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7a3c94f09bsm382315266b.200.2024.07.22.00.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jul 2024 00:23:02 -0700 (PDT) Date: Mon, 22 Jul 2024 09:23:02 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: Vlastimil Babka , akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL Message-ID: References: <031ff35b-65f0-4ead-a08f-21711bad5e29@suse.cz> <4a1bd482-bfff-4843-a60f-004b3a8a99e4@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: CB6441A0013 X-Stat-Signature: t68u1n8awqsb4p1y4oqgexqyyxacf14f X-HE-Tag: 1721632984-977404 X-HE-Meta: U2FsdGVkX1/3hhfOu9SArtDxy9qGLWDdfLiYfvZisHWinl+EEQGZiN+3HpeBbr5tPYb6EHk6kLhXt2DK2/vTsZAtCvDna4hJtc2OrFhuLmYKi1+Evl9Yq13LWpe3ByoL7mtdK9AAD7Vl8p06b95gT3jDCC93R2NPaSI949/3lM8sACAUUzqDasDBvKnfQ2/9/vRtCWTbUZvpdvAS3XbrD3E74u/IPAOpqggEJlulGV9eLl0mu9vQG81RCrXz1TsKzJpXLa+j/tPikZrxBGBj93rZMjdpwDlamfxcX9rO/O6PQ6nLW8bCA7lgYJONe5prcx6xUD3S1ecAw4xOorOSBBCBe980UkkaABd1cVX/Ej1yffP7pp9Pz1AdhGKqBQxxxQHeIf3QBXeNNKC0HwwMN6KWRODFqAQXTOVZU6TJy3wcYPV9pomwm4/ZuPdf9b0t6/U+kDDHeovhNjnBYohzJMTCdfzwj+uGtwHK2LumB6nwVLM6fOAsp3Byahz4Z8qL1sQMK2asyhxAH8W8xVAXCKqYWMZb+ijZg30R7rEAdszg7y+BomUNePq1C9u2tDn5xEcJE7WMeNFgGj1mUMDFsh6aEmqzpc/VXQWxXq1wEHWUNhLFIsPaLMSHOzgYmIhNes/GfeesTi8BCcMUGL0+Kd/wUJpwnYJEI0UX22AQH0h5UIdbObfT6DXIgrlJXpb8iGTEIf7ytd8ioz0QhEAQ2HZlSGYo4Gm+VC+nFwVKfSMvfwXpri1I1tQnDJTM9OxXbuwq+l05eztQEr52EwEKcv6UNHVY9qTXVAp1KOQGmpPHRVwyieMz17w+wfQTfHFjy+3GgilwxELtaiurpal9nd1DAOqd8FzMILK4YlsPYQvRwwPJ0/zUnaeMBeHlLIlqEXYfKd5A9FV2X8dWEqMDwSt5P7zlgpZdpGZWpRGSejuYsT+84kfmggQObHwACyum2bmyTWNAoYX2GNnC4ON vHbXGAxQ vQq0SrRTeVOKmhF0UUgqhAXIHeTmDymJ3ROvcJ4nFqAoS09/rsJKbZhLY/t7//WuRo1a2hPC9Z6EXMX3W/Qfhukui59Z8upCWhfRli5HuZuYg9+GzK0sJlYKIeUJuYQlM/RaDmqUaeBLyFTjJVIQDtu+LTlbJYPcvM48RhgATpzm5YfF66kRKuF+hQG06Nq46bB0q5QGKbOnDeI1NaN2un/t0O4CR75jRtEaoNZrmAJLaiRztehxcFcZqKxufZULAw4y/QAze7wr8iOBF5gC/qc7cl/kR+DXvEwCIOsFEtL3jn4f7bcP7735yCA8rp9EcRb3lm9gvf8VpnZKuVCzB4rwsQ5EGySLr/rUKPTHztKA0AFMHXJAgP4t6E40p/aKCkC7SMn7WH/wtvQjttIArai3x5IOtjm2mnHSLF6TUn7F/yt1qUo0OR2Hpua/t+eXcqEre08yeim3DoOVqs1+XRIPzSSHu5lXD6pn+QdaKzooeG8g= 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 Sat 20-07-24 08:36:16, Barry Song wrote: > On Fri, Jul 19, 2024 at 9:30 PM Michal Hocko wrote: > > > > On Fri 19-07-24 21:02:10, Barry Song wrote: > > > what about an earlier WARN_ON, for example, even before we begin to > > > try the allocation? > > > > Page allocator is a hot path and adding checks for something that > > shouldn't really even exist is not a great addition there IMHO. > > I would argue adding checks for something that shouldn't really > even exist is precisely the point of having those checks. These > checks help ensure the integrity and robustness of the system > by catching unexpected conditions. I agree that the page allocator > is a hot path, but adding one line might not cause noticeable > overhead, especially considering that alloc_pages() already > contains a few hundred lines of code. We do not add stuff like that into hot path. > Regardless, let me try to summarize the discussions. Unless > anyone has better ideas, v2 series might start with the following > actions: > > 1. Update the documentation for GFP_NOFAIL to explicitly state > that non-wait GFP_NOFAIL is not legal and should be avoided. > This will provide a basis for other subsystems to explicitly > reject anyone using GFP_ATOMIC | GFP_NOFAIL, etc. No objection to that. > 2. Add BUG_ON() at the existing points where we return NULL > for GFP_NOFAIL - __alloc_pages_slowpath() , kmalloc, vmalloc > to avoid exposing security vulnerabilities. Let's see how this goes. > 3. Raise a bug report to the vdpa maintainer, requesting that they > either drop GFP_ATOMIC or GFP_NOFAIL based on whether > their context is atomic. If GFP_NOFAIL is dropped, ask for an > explicit check on the return value. GPF_ATOMIC is likely used because of write_lock(&domain->bounce_lock) vduse_domain_remove_user_bounce_pages is iself called with spin lock held from vduse_domain_release. So you would need some pre-allocation. -- Michal Hocko SUSE Labs