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 0FCCDC3DA6F for ; Fri, 19 Jul 2024 07:51:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 759F26B0093; Fri, 19 Jul 2024 03:51:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E34D6B0095; Fri, 19 Jul 2024 03:51:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55D576B0096; Fri, 19 Jul 2024 03:51:21 -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 35ECA6B0093 for ; Fri, 19 Jul 2024 03:51:21 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D6FDEC047C for ; Fri, 19 Jul 2024 07:51:20 +0000 (UTC) X-FDA: 82355731920.10.07A0818 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf14.hostedemail.com (Postfix) with ESMTP id 19067100014 for ; Fri, 19 Jul 2024 07:51:18 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=N19zKMRL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721375448; a=rsa-sha256; cv=none; b=Z5Rl6iHvXKtZZg7MxURRoBkHhyoCDHCmt4pL21xWZ6GtcCKMcHzwjOJPk001V8AFvNTUhm 2+VWNGmJe3MX+7qXPC5uDX+6R3Mcgoyy45KQYJW6qDHSbFpOtMsuY3msrHdOLAMXpOqL53 1F5Si3MzTYY1Ny6vw1qQLtmIbAGXS7s= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=N19zKMRL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721375448; 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=g/gN2iSF9oT1b7KMZwwR8F2gxxUfDCpugWe0P0PqUHs=; b=n1iP96eurejT+05ec1RCRb4/CkYvGWvcpKXQDLjglEHMaQIZmhCvuWp7UZ8/mklLK1Pcxt 1v2i7Bd89+2xMIoLWRFKtJXRTNgmMao6azVS6Noa4EF+SCcfN6j8KdGkcLJnzYxmEPHN9c EPgf181OtFeq754U10/RfpVfBOzopK0= Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4f4d7e7fda5so603192e0c.0 for ; Fri, 19 Jul 2024 00:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721375478; x=1721980278; 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=g/gN2iSF9oT1b7KMZwwR8F2gxxUfDCpugWe0P0PqUHs=; b=N19zKMRLHbZKLqtik5mjGLCUpSOCbg5IQq6lU00LQ0BfBDIKKdu5JwVgC+zeKN17EU NgkiFfze31AWitYEZmXCJgpsw12lFcV6IKjccx9whTkW9UjQ12cbwrfI5yTHmmqy4UrT Ieb+fHPGlwChmCZKA0fo7d5JoGmT9j3aQsonxcsKp4P/QAdLIAiYQ6F4qPYyFA50Hv7G l6CLvBArUXmg1v/100LbRCV3Vbth1yN4puOvPz/Uz8QFGzzRyLRhv7iST1MXDTiXU4OZ Se36cCRBjJSecdAouXfRx+6Wmqo7wrTucjdbgTh9P7pxZWIy92LYr9LhHJeWhftNIep5 dBVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721375478; x=1721980278; 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=g/gN2iSF9oT1b7KMZwwR8F2gxxUfDCpugWe0P0PqUHs=; b=UmQcbJ2yzTNccQnb/JD7sovYqvhE1ryyrWbeZWGPsqdRSmDJVHT/m6CiAVgs9FgwsC 2Ggz9qbXRZmLEVKpsLDF8iBPSD2NtaDO3zJtq/3oOBg7n1O5UwroYFYfB737lxnXGuJC Qs7LC8jSF6fGSsnt8rqHVFItY1UNQwHVy6spC2fTKl5PEsElqQYNkcQCjN2+Mo6+Ffnt xl5J0AwxOTlF9fpCm6y9f07m/MUCsgihYLnCoMDHxLyDG6OA5RR0X5MmiLd8waHUIrmQ I4cyeyVp93sQ0vZjmzHHBGuIR/tEZYI5Q12LsfBryJkYzujyincvNbeAIIXwSHPwF3ch D5dA== X-Forwarded-Encrypted: i=1; AJvYcCV4fvv/oVzmHZN5EyQeBvfFsz5Nso/QN+vteKtKM5P4M5zGBKzBftVDVBHT+oWHTddFXE69IK58DygwK9cks6lMAtc= X-Gm-Message-State: AOJu0Yw0E1ZGNr4jV48isgDcA2UdYJJ15StG+4Dro2Uey8nrTwyUx+SE Jq1XUZCDa73i5fxoTbxK+d6P1ha+uZMjR/lI8EkHtN8QJOb+pJ2Xa84MmqiRgh5cfYv+qWRl10m SeVfZqGUxCq3pr5TbB1pbbYkW8Ws= X-Google-Smtp-Source: AGHT+IGlX8YYdE8qFT0QnYzyRAoX/D064eoWp5rk2Dsc2UQpCVpmg6t977U9PMxKP0lgqaCkUVe8oI0eOIbvoNtx9DU= X-Received: by 2002:a05:6122:790:b0:4f2:f38e:1dbe with SMTP id 71dfb90a1353d-4f4df89f672mr8989304e0c.11.1721375478069; Fri, 19 Jul 2024 00:51:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 19 Jul 2024 19:51:06 +1200 Message-ID: Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL To: Michal Hocko 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 19067100014 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: r7nwxjm4ikxk9yr8krq18fkm8dnocj59 X-HE-Tag: 1721375478-81598 X-HE-Meta: U2FsdGVkX18jcR8zfpYPpU9yzZfSAZlV0iER9r9t6d23vwRrBrXKTlA8UPJQzHadrh1taikKcejF69y/l7QNmkpJ1j22ZqZg5/ykYDm5pZ7rA1jDs9Os/0W2ATkXQlNIfQq7/0myHsVB/WsyRCwNgsyL/PijRtgQIvXJLOeLda1u847/tVdqL+N0aKjA7I5XLZIVLFgYNVQcxIx/6AVdQIeF83FNeq+O1vJ8BjzgQKwHiXBEyhhB3MsZRxzPuqPLhowSYCYT0JRmbR/C8nHVaDt5nyQs/iatUmqgnyzKJksMmCqaOD7JsQyQRx73iswMk3TWxK6Hwr3all8eWjbDbH3fT6Ayd1jS/7FDQxHUZ4QnBA1b1Zc+8ml7NT0GHwYW99hiNmCjkAeYaKKErizf3Nkb5JnoJaeP2UZdMnfJalIH5DL5oD9j7/tLyvmQ8CpsV4jYoO+P1PdftWc0/xa9jAuFnQXTVFX4a+dOSHH7q2sUcxmnNOVmrr+M9lquOal1vvcm8A1zfrnC9aTlQ6eeL4jGtRS/zqHfADqlhkn0gjvAUVYRw1tzdSW5xLT2dH+U9mw0hLq7cI0H1/EmEeO6m4utg+OC+3t6HtsaFwmpxEHiKANFDQRD2WRn+4Fw8rmaUulxQ6mjRf41hp8khaow3uveKY4DjYOxyHQtjoNqb5+lPAr/6YIMQCbVRE9FMn/C8NNolwEW0SnMpglzqqxKXP/dgZCkZwS6mGvJzV/NfWOHgZpw9wNYs5+egBADk2pGCmgWXXZWt4f6pVkjoeax9jJ0WolJ8mPN0jDearsCkNghlgORGZQpXbAZgy3MKpGxkSKUneUipKJqaojW8tXOh4o9Ab0RtsGFglgS2zr6wM+qzOtXZC72yZO+A3V+ZUHU/Qz5BF9CZ3gjHH1OKkk+8rbyplriAx+ausZOQr4/XdXrt8nYDDz+BYtccUwqo1UhVbSiepDuUyuA2g9Ts5k RKD7vcRJ peJS89hmFc76UpWfGyNLWPpDpAM/P0VPtTTnLpPg/EjSEoQZSxvhOg0HsLgoPbuC4nkcQfE30dPa1uUT0p3WX0C+wFGYylRwSD2X6s55ldMzD7pibw6QpNZCT7RRKD3q5AzjXkLbnaFErxg40/uGeeGs50Nw7na3h7nbpVHVJufEiIjTmr+FjR5mul4PJKzFsiLOGPuMkrlK4KjUNGx8D44Rl1U9mYahA4LbBiWD+w0pcWAfRa8CqbOeQf3XtwlGKO4EmEsa1EfANDCjBXpA+fRooxzkR1oKx3gibk+KsNRV2Xmupfle9jN990AIgfr1GaMXzG5axoSWLNetEG9Im/+C5JgdJAZl5ib71npKuTyln6CAQgFtR2L+zGR1pJjBVDB67DYG8wl4hWDF77hL6hTe29TXJT51GNUoK5qk4mqV5fxqWgwWd1CnXZO4n0p79sSnE1hfiHFTScIYdbgETsbkOGazropWA85sI 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 7:42=E2=80=AFPM Michal Hocko wrot= e: > > On Fri 19-07-24 19:07:31, Barry Song wrote: > > On Fri, Jul 19, 2024 at 7:02=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Fri 19-07-24 12:35:55, Barry Song wrote: > > > > On Thu, Jul 18, 2024 at 8:50=E2=80=AFPM Michal Hocko wrote: > > > [...] > > > > > Yes, those shouldn't really fail. NOWAIT|NOFAIL was something tha= t > > > > > should never happen and I really hope it doesn't. Others should r= eally > > > > > retry but it's been some time since I've checked the last time. > > > > > > > > > > > > I assume allocations directly using alloc_pages() might not respect= GFP_NOFAIL > > > > and violate the semantics of GFP_NOFAIL. > > > > > > What do you mean? > > > > I mean, if we are using wrappers like vmalloc (GFP_NOFAIL | GFP_NOWAIT)= , > > though alloc_pages might return NULL, vmalloc for itself will retry. > > vmalloc(NOFAIL|NOWAIT) is equally unsupported. This combination of flags > simply cannot be delivered. > > > but if you call alloc_pages() directly with GFP_NOFAIL | GFP_NOWAIT, > > alloc_pages() may return NULL without retry at all. I believe alloc_pag= es() > > is also wrong. > > It cannot reclaim itself and it cannot sleep to wait for the memory so > NOFAIL semantic is simply impossible. We have put a warning in place to this is still "right" behaviour to retry infinitely at least according to the doc of __GFP_NOFAIL. I assume getting new memory by many retries is still possibly some other processes might be reclaiming or freeing memory then providing free memory to this one being stuck. * %__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. > catch abusers but apparently this hasn't been sufficient. There are only > two ways to deal with the failure. Either return NULL and break the > contract and see what happens (implementation now) or BUG_ON and blow up > later if the the failed allocation request blows up - potentially > recoverably. Linus tends to be against adding new BUG() calls unless the > failure is absolutely unrecoverable (e.g. corrupted data structures > etc.). I am not sure how he would look at simply incorrect memory > allocator usage to blow up the kernel. Now the argument could be made > that those failures could cause subtle memory corruptions or even be > exploitable which might be a sufficient reason to stop them early. You > can try that. > > I do not see a saner way to deal with this particular memory request > type. Unless we require all __GFP_NOFAIL|GFP_NOWAIT requests to check > for the failure but this makes very little sense to me. > > -- > Michal Hocko > SUSE Labs