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 130E6C3DA49 for ; Thu, 18 Jul 2024 08:50:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DE536B0089; Thu, 18 Jul 2024 04:50:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 966EC6B008C; Thu, 18 Jul 2024 04:50:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E01F6B0093; Thu, 18 Jul 2024 04:50:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5203E6B0089 for ; Thu, 18 Jul 2024 04:50:54 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F17FE1A19DD for ; Thu, 18 Jul 2024 08:50:53 +0000 (UTC) X-FDA: 82352253186.17.A5AFEBF Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf12.hostedemail.com (Postfix) with ESMTP id E44454001F for ; Thu, 18 Jul 2024 08:50:51 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=LDAdOtlx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721292619; a=rsa-sha256; cv=none; b=GelLPajNVV7WWbL1bfGTOZRmRQpO9e2kk8rY5tkqpArWABdTwKEtd3U14Oiz8E98MEKN8o Kt1J6slBqffLb9mU1F1rguI74Y1Odv3bL7awOnKtvLhaW/O2R3z24yFG0Z7cKm2O2bUky0 GUJMJcurrIoh1YB28x9vk8nBXfgfCe4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=LDAdOtlx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721292619; 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=SRa9nE/DcutKk6WAbOyJkAzLdIrYfxLmfM2mm4RbGC8=; b=rnF3M3Pvp/q9gFDr6tdiZtr+zAvyQY5IXQVRHZbZVlfM4xCNL738JEzCe+0U/QtyUdfZVd e218Zi7dRCkeIb7ffmkhB8IQIwvVrFamJr2cYbhknT/91+dzKxGi/w+mDNWwds0RMx3yzF Tmvko8UMxLwv5TtSMfDc4yQrxdzoc8Q= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a797c62565aso51377466b.2 for ; Thu, 18 Jul 2024 01:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721292650; x=1721897450; 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=SRa9nE/DcutKk6WAbOyJkAzLdIrYfxLmfM2mm4RbGC8=; b=LDAdOtlxSF6YIyVDFmI5vV183p1zWwluDtw0xMHd4alTc3KDzkb5QP0KFpOj54O4OP LYt5XwbNxjBxk4T2sJmdjiawD16P7iSs0QHHu/H2uNecScYTwGOZ1Me+Oq4tHs/IB6ta ZZ923otJ/DiW5tZUlVLPJYvwuBbKL/bkR8D1xq3kznIQtxTJLZ9pv/8hsMkxFngYmI4E 1Tqkgz820wCg+s5imXvVvHzMZFuT6F+sY/1wcoFtwtulBR5A33Rcnn6RPEqXsjUsLJsL Ny7gQ4kSM/5DXrIHxeAfNv9igQXdiK843KdeFklDSuaaBvpBGMZDxWZKl2bXalyceA06 +m0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721292650; x=1721897450; 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=SRa9nE/DcutKk6WAbOyJkAzLdIrYfxLmfM2mm4RbGC8=; b=xEdOXjwJP9Rhkj2jm7yc+wTi0J+4iVn7RFcMivxeOcE7SGx1ch4RmsSQwlLFJ2ENB4 lvCbgI4CfDKC5xKNvyWqG8/VHwp0exT74Y95+8dKakmRBCEUBLY+bQRUVDhlDzWw6drA qjCGL0xpVVvVAkQdKwnwJn/XyJ6dGkurPBVBW+mwh4ZivbN7shMilsLbvpmzlqg9fJqY 1k4/w3+Iep6WKir6LCmTT443a7sSBeTUEFg6XQMT4wY0vPdTtMPp4G7ELp7bQtwEs5sB 8QnDBBRsxZmnDdvFXDQH4ItVUeVfQLf+yR5IxZmn+Lf+lCCN0rPce8ZG68RIfOEaz0HC Lweg== X-Forwarded-Encrypted: i=1; AJvYcCWCu5RQEEst8XDfKEBUMdc8kiJ1T0KOQ+w0K5qK9klzG1tFpAQbNxDe/0taPjhrEwCQg9jB/sdy5xDTs2kOi8nZxjU= X-Gm-Message-State: AOJu0YwRXdG7E62Oe1qv1UrJtUIo5mjJvpDB7Hh2C4xyXaL8Hz0VxxXI Z9nZ7zXgblee1zuDSzG5KelYUbHcU7ZGE/caf25Nw+pSyV4h155a66WzKrBYEcQ= X-Google-Smtp-Source: AGHT+IGjYK5AYvefXfQn28B4sUguKAOTFTwQedmp8FIrrgZMOHAe0IQucTd6GYaMbSrTrV/bmXt8aQ== X-Received: by 2002:a17:906:cb8e:b0:a77:db36:1ccc with SMTP id a640c23a62f3a-a7a01145f36mr301166166b.24.1721292650230; Thu, 18 Jul 2024 01:50:50 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a79bc7f1cfbsm532226566b.107.2024.07.18.01.50.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jul 2024 01:50:50 -0700 (PDT) Date: Thu, 18 Jul 2024 10:50:49 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , 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: <20240717230025.77361-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E44454001F X-Stat-Signature: zabmu1xwu84mdctpbxcxhpaqghs5ej18 X-Rspam-User: X-HE-Tag: 1721292651-640688 X-HE-Meta: U2FsdGVkX1/VjPGsUhjtv7ZcIwOfOWfyuPsbdmA2507SVtqsoEsWY4ygpu+t/Mcl4yCRUW2AuvXAxByqO1px50GsAjNXlTNBqdmAdIczYqNTecAOw0hKn8GRl6Gofwm24Q/iBlYjq8PRXpXl2JRtwZUaanU2fVBbkcRpMBRilrsrQSIdranC1alcl3JP+VPZyPDYRd1Jw/5sORYSPJg/wDDfSpkj8R+D3rlHjMJaz0OjqJufeotT4hBCbXtiZRCKwHEPztM/i0riKGuU/SJl0YBxS4ym40b9fJJ00Q8w+WnmuWUAtqJM2sJ+/4w+NazLAHla8yjCXfwO84zxilIVGrXeg5x7ODgtiBgWO2tW7C0FIES8EerEW+hi/b2X3Qrvt0FuJbukLv9tojxHRbvz+x1WR1ZimGbWoLzvs7lJKOlXr/PJDDF7F3Ndf0SxuK5KHa8ecq+W3RKhwyJ4XvGJ0K+zfdF3qVGqvZTbMYnzMqyneblFJbqS41gytXuCNRkDmlXWT/v8icDFXngpn5xI3781XEBSf2CXY+XDR5qoPwfYOdVUac3vFBm4wKdeW+Q0pnSYlL77iC9rRE3BSsyd4SnzwGQ0VldPDf8InYe0jnuhYkIaGwKXWIAgvR5sCLzL0MGtMo4bgsrt+i8SUFDrrBS7+eXZkURyXRFDYTt8vqn6grKysj3ECRwQomJWNgisZHltdeRR4Nb4Ekr183BP03MiKfkE1jz3q4FCtsJkbWb+crbPZSX+982kyEasstfm1vGOOt8+Siq5Ybjr8Kofn5i239rdnvHErjOtXuds3iN/XpCGHR1e8EK8hq3MUl96I730jMgRNDsK9XRoMhRC9MNZqtnSs4CiqGAjHXpUFlfNOl4pGtocsGl4rq+SYPtydhxl++WWATSdFrTZzVtifxs1WRlm8jyHnxzBGLt84HbqxkuZ3sREIyKU4pzgRGzixkCsPcve6OrGHjvuUAt 1Vrz+ZXm TnBrz81hiqmENqNtLZpMi5Sx1f4fFUTtEYt8yjsNdn0fyyo75hyl6rAQn7Uspe4coYU9WAwhZeNb1QlFyyeLeq4x1qsPXboVhCxf+tlg+qoLGN/GwTWIrPbgesijQvllJ1tWgYDcrfi07mt29Sly56a1kLZEDpKeUf9EilydmF3iOpEaMyaOf3rmMpDilxW1GzPE1U+ZxLVwTRDMiO4MitwtQYoBQ/MqRbftteSiwcRA4P3q/cnMR568Qch7lZs1IPacAEthwpjuOGPw+UbR6acgu56RlWjpuO+LOBotuxJ381kFZmzjuM3mvGnif//nyTKOxYTV18rRaKtHQMMaR6C43w5a5n14XNhcqSNg4q0TzKHCmp754nd9WdqyZSLAzRfPWlypNzNeG1NZU4H7n7l2Jaz487tDUM784M/idGc9MRMH5S+R/mJBXHnW7HhsF+9ttQ6W4IyCAgrDMtNuXHiwftU3D1lPPMA/xgefGoPcUdDE= 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 Thu 18-07-24 20:43:53, Barry Song wrote: > On Thu, Jul 18, 2024 at 8:32 PM Michal Hocko wrote: > > > > On Thu 18-07-24 20:18:02, Barry Song wrote: > > > So the purpose is making sure the semantics - NOFAIL means no failure > > > and we don't need to check ret. If we can't really succeed, it should throw > > > a BUG to stop any potential exploits. > > > > This would require to panic consistently on failure in all allocator > > path that can bail out. E.g. page allocator on GFP_NOWAIT|GFP_NOFAIL > > req. not sure how many more. > > Right, this GFP_NOFAIL issue seems quite messy. However, at least vmalloc > will retry by itself, even if alloc_pages might have failed with > GFP_NOWAIT | GFP_NOFAIL. > > But isn't that the definition of __GFP_NOFAIL? > > * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller > * cannot handle allocation failures. The allocation could block > * indefinitely but will never return with failure. Testing for > * failure is pointless." > > So I believe any code that doesn't retry and ends up returning NULL should be > fixed. Yes, those shouldn't really fail. NOWAIT|NOFAIL was something that should never happen and I really hope it doesn't. Others should really retry but it's been some time since I've checked the last time. These overflow checks were added without any acks by MM people... -- Michal Hocko SUSE Labs