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 6CF32C3DA5D for ; Sat, 20 Jul 2024 00:36:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EED2E6B0082; Fri, 19 Jul 2024 20:36:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E9C456B0085; Fri, 19 Jul 2024 20:36:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D63616B0088; Fri, 19 Jul 2024 20:36:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B98486B0082 for ; Fri, 19 Jul 2024 20:36:32 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6CEB840A07 for ; Sat, 20 Jul 2024 00:36:32 +0000 (UTC) X-FDA: 82358265024.03.07E30ED Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) by imf30.hostedemail.com (Postfix) with ESMTP id B186780003 for ; Sat, 20 Jul 2024 00:36:30 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QheyfO0Z; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721435749; 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=7YIpxCYKRP3TEtLSrFSLeid7VvyapOp9F7vcn4esaco=; b=vGbJJiFkibPW3728QYoaent7nC1mDjkHxOK176wTjaQMqO9kew02hNDwtYOL4NGcyDFUt1 sDForLt0IsF6SyE0BYOPJGslFHW59A607OZu/pXfyLGlmpkr9gSrGx3cwipTHaghmSL0wP Xj/v+XMzGbXw7fBfe7p3wnT+s/uFf20= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721435749; a=rsa-sha256; cv=none; b=Dlx/gmyPtiT09jtvgbKNmITjv0YA64VHbAjbZNLCsDsxujQ9/3RBOUz293moZ8inSQCTVD yMYXyGXJcFWtuduba4HjAk8792r0TPlOsqtiedSNZ700zVFa2pNnd90XNJVSK7dKVQ9IOU YzjbkpcgYsIcaZpiJQpkmqKMqejdcw8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QheyfO0Z; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-4f50294aeb2so284421e0c.2 for ; Fri, 19 Jul 2024 17:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721435790; x=1722040590; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7YIpxCYKRP3TEtLSrFSLeid7VvyapOp9F7vcn4esaco=; b=QheyfO0ZQSlBQmECz+2GsWy1FMojdht7bkfVk6zhhpJzukkRY58+XyYA12ynHDJriV boIZMwuAuxtSjLUKZ+dammA1wBsAIId7jOTs8Pyj9yRm9Uwy2usw1XqCR+X/CyGfZPiy hbiWEFph+CpTcg0zLE9U+mFJbFkBu2RtobubajDb0Mdgl2FSi6OKXqnVMiO6s42iA+31 Q1pXH9wDoB8oIwnAvZYR2M5bRJx9Tbn6ksZzmHRy7R5UzffCs//Cc+TGJ/mC9M+dNTxG c+Z/Bbf3pZhJyuvPBqXE7V6Kubqe+EfnTktuQc0ybry+/C8xYuFoaEp2I52mHf0ai9i8 0RkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721435790; x=1722040590; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7YIpxCYKRP3TEtLSrFSLeid7VvyapOp9F7vcn4esaco=; b=kaIG5hDjr0WnxK3cCoAjsyBeSpBCh8pMRwoX2XRr/CHZetNJgsGILaI7uA2jOFA2nF QoS/REa9fgMQzqggIVtKu+phziWJBxXIlgXDztQV/BzQqkj0oo9rxeUhwmXALb7IBX0r 802aejSwMiEzjtQp42KvzqUJvBCFcrdRv6fvm+WT5sUtvH27EUrnSmZbrgTGHUVfrtIy zzrc9EshQAp260mq+6rv8qht7p/saDpj6M6skowaR3DiQCmBLssHQ3PsLYo94/Rz3UIw 69BD5dnGjOaqYi7MNPa+zH7Gu4zFD1iF4+CNGEJTkvGAjDjhY/c6yGTNUlL01wsRREhK /AHg== X-Forwarded-Encrypted: i=1; AJvYcCVt8ZO8H+J9YnmgX3+0pkzGD3t57cm92KtVKIOZoxHYdtgPPsNyBQv+t/asMdn8RRVMAUu7b9MbSvoPrZf1kjA422o= X-Gm-Message-State: AOJu0YycqhcJ8Rw/mSGwvRG6DruYCzt9WfXELGixWg17RE1KYgHLD/MQ j1xMpOgQrwS5x2ZnJuI/B1f3A2Bahag6WALQoKlO2NRQ82pC1rTJNV40Pc2NaofwZNi59PfVKug gsh4rGgxlUt/XV1BB/WslYy7w2Mw= X-Google-Smtp-Source: AGHT+IFOiKNAZSpcYlwJf/vJnZv2sHF5UHga76fkOU3VQqxn/HRhZEuFTrSCvWCmbDWhOTPo7wzVSbTrDIT5SZ/oq08= X-Received: by 2002:a05:6102:468b:b0:48f:c0ee:28e8 with SMTP id ada2fe7eead31-4928b9a2c0amr108865137.16.1721435788091; Fri, 19 Jul 2024 17:36:28 -0700 (PDT) MIME-Version: 1.0 References: <031ff35b-65f0-4ead-a08f-21711bad5e29@suse.cz> <4a1bd482-bfff-4843-a60f-004b3a8a99e4@suse.cz> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sat, 20 Jul 2024 08:36:16 +0800 Message-ID: Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL To: Michal Hocko 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B186780003 X-Stat-Signature: 4axeej988ptb559bn3tsduqzmuh91yuo X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1721435790-538991 X-HE-Meta: U2FsdGVkX18SfIOg619KBJKza05oEbbAkCsXekGvL3RvNcHdSLZgF/Z/A3WP/JRpNMKjM8J0a7p0gsQawg8OqIMcBEiiA0U+0M+5k8rkCdCuPvM9Gm0jKklV9ZbCaIOYmkFvjAaN3UR7EJaMedB46WRheMwe6Oij++YAQw2HcIauyyoKXtHqZRxyXBa0grqVcU4I2lwQ3iglfCUTwnZEWSO0zc9MCkB5uOCBYL/BXapa2+fC+bXEECDY5Uka/JnkH6XHFOblXvFPK+KQQuxvq99NYmPpgUY8frKRzln9VFDijVBsMX4xOFwoa/f7QIwP6++iWWVLE+XUsKKxygYESGmrkQYwaS2vvZ5UQBiIyQ3S72QYVrREhcf+o8a8w6KoxgUvfgS1okqNAb1bAxzNG/ci4PX35Ocd0gb064SvWXtQl7e8ZQv0obpiEkyroyjmPPNAiX+GDEg4xtqMNYwt0XxSTl8ev/ZrTRqhgTAKWwJsoqWNCR9x4jo5IcaM0SmlzyK3PSig+CRD1AM4CnwPDdYiIvH2zuENGWD1B111eBtJ1xmujWThu4B8eaJ+6oisxsuVQJmTqdIRqUXiHOj3zDsrO4Q/s/YJewMZmyOc0hvDv4nedg/Bp24OuFmhgtF3u0G1SvyjB5zFATV7LhXY+mf557Qh8KRyGx/4texxLemZOnt+SUM2dRegLuMXH6lRM3pbU32G22PwYf2/IyZUIvODBQz56d0RzoSi9xCAY/1nwwy7XBQ42M6aRweUjmOUdjdbcP2NJGCuD2KMzD6WiCelqAqs4MgzT9+dCzHPvMqYJ8DTNCEX9GmZwRGaH0a1qts3LwAljANEwcaMajhbq+wcyNqVZA/R/kqNqnuUrbeEeJFlpFR4iKaIHRg97ZYN5XgYCffB5wBHUhMVOltM7MWEBwcx8CW9Mw/eezjfNN7sSOaqFfhKNO7g2lsaq0yDuippYxDU/vZZglXucRl tfBC2LxE bHCxRVNorFhz+w0TvNntsBRbEbelcro2PgDc/ktONBQhA3pLBPSr2tTcpnytLWc/NuM2aMjqz/ocwWeh93f3ezlaq7YA3se4mEr7Jy44QUBlBYXqpSKzR1dtP750DEA5ltygq30e6bYyyD635kI2wnNmKrCgoGijSfKeRcIWDlVm7oepeG38EAV++w34TSaeO9jd3RY3MGN/D4cWHy9ZJYLk+94hbxBjQgqadQO+KPpAjNMY0jiB8h3EEW2hTH0iu3pyJQ/rVJ9Fq3IMw6WTj43YRDmZCTcbB1Nv2vI5of5xUrr3GbKBHTLaHcBf+e5pRLePj767X2wHxH9lBp/ATq7/pdD4EhBxYqPtncEWsS0uA4lXHvkElitdL+qIieFvHNmMIlDJl0hEvnufWhJT8oS8lk9xMVhAHERH4BLVjpXC1p9b4nnl4vHtrArE95mafVPBt0cd+MthzUaICqbPyOiEuhHztqwOl19Hu 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 Fri, Jul 19, 2024 at 9:30=E2=80=AFPM Michal Hocko wrot= e: > > 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. 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. 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. 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. Christoph, Michal, Hailong, Vlastimil, if you have any better ideas or objections, please let me know :-) > > -- > Michal Hocko > SUSE Labs Thanks Barry