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 7C174C3DA59 for ; Fri, 19 Jul 2024 11:06:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F417C6B008C; Fri, 19 Jul 2024 07:06:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ECA286B0092; Fri, 19 Jul 2024 07:06:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D44496B0093; Fri, 19 Jul 2024 07:06:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B21946B008C for ; Fri, 19 Jul 2024 07:06:03 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 501851405D3 for ; Fri, 19 Jul 2024 11:06:03 +0000 (UTC) X-FDA: 82356222606.13.C6D292D Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) by imf27.hostedemail.com (Postfix) with ESMTP id 8247C4002B for ; Fri, 19 Jul 2024 11:06:01 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YOCD6U0v; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.48 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=1721387140; 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=voNH85sAJEA0y/PBrF9KaAjqpPvdqvDK0WkhR4GAjYQ=; b=LyC2GmL5sarPac/cDiTsruSpLc0uxsp1bV9qKYFHAIhgOpiga0M4aUBKNAoCTUDkdoqutN yIT95SDEoz2n8pQFrDrtCoDSQlbcPkNs064punsU8v0ZxQpl4UTOsoiVdP9sLwAx0xGWPR TRKaUByUxwR31y047nU4ryM3jf+YeYM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YOCD6U0v; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721387140; a=rsa-sha256; cv=none; b=Aujm+nhYhBLvHiV+cy1A/PcPTS/IEnVtOxL3FNYdV7q7zsQSr9WiASdCY3o6L06yRRGvPi 2yJKqjh/7Sh5qCfTCBggiLLY6J5dgPFPDX+MrQ6RmCLOYBwCNngIzG2f/VDlwsJCkS68vd Ka7r0pRoiCm2LXZ1/UULBjW9utaURC0= Received: by mail-ot1-f48.google.com with SMTP id 46e09a7af769-70362cb061aso955623a34.1 for ; Fri, 19 Jul 2024 04:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721387160; x=1721991960; 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=voNH85sAJEA0y/PBrF9KaAjqpPvdqvDK0WkhR4GAjYQ=; b=YOCD6U0vwUImw735VwXSqjvfeSS5OIfXJPs+3L1jz1jWqmvXwoCpMP99SZzNiMqAkB yNWByqVKNUnK5oH5zB6IOfy3yufycjSXVMefyqpke2iFecAl3v6/UBtv2Md4IAiMwE7D dSh4oGoJ8DDNRSNlUoLck0sUw93CGJ5wp3pZoXfzY2Ixw6wjhDFxH8DyY4At0LfQDfLd 35VtIKjmqpJ83AhOPPbaAWQ6aSzbTilzoC7ZpiEkH3b/duhnTq1feGXqL6wc6y6QYzn4 2jYHNflkpOqHtLs2Hdx0Xns1sH5OrGGRuSkwnCGRZ8YGWVDckuEs6Jcaxv6YQnr3xbxn xrsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721387160; x=1721991960; 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=voNH85sAJEA0y/PBrF9KaAjqpPvdqvDK0WkhR4GAjYQ=; b=Jya+O0A476YFmsRaOcfRtL03fDaU492Parkwsa8pfHeL6mRUJ1ZUS71/1y13xhhRon iP2XhGqFBjFBPIbsRTL2cgyd9oreswWcghZf5SfMUSZx5LZ7CzT1CT2NhnR+22PuCi2/ I8bmCWEyGcfLbvxIxo7vw/gpUdURR4gox6CAhskaNcse6HUhnEfBt0ICiNlTTgMp8XzE 9vojofliJ+KId7pZnzVBXz1hChfAf5EPFHOSwjNhFDsNieljWedV1zVZNpwJ71h1RKii gC4UUMjvsSxAtqZW9oqdnVK7+/HScvTRAKsW22K7R+VPOJmmW7D/DGbbBa10vRVZJ33y X5hA== X-Forwarded-Encrypted: i=1; AJvYcCURYcdmDnMZmZZSNYSsisjvc7IiH0tYYmP2f+nSRa1npe71tx3rNZuLrjnUVe9MeSvbzalwn+OWQk5WwWwtUTYfR10= X-Gm-Message-State: AOJu0YyAxmwlwoqCCl1fDJ7wx1DlftL+Uadw8v2/33JNx7KQ8RWWDUof QGQ6MALWb5oGwRXVvmlZWqaGvimqrPjB9Pa19/m8lv7OsHE7WkEHLtKVPBk3sii/82gw113vAnv gxxW+6FNfpVpgaZBIpb+Hkjv5lRo= X-Google-Smtp-Source: AGHT+IGdYOmkkFlJbOXeUdN8rY++0lxZKNVoU9OQpAZ+9aHH21stiJRmRkH3sjbhnE4Pry269H5udpAfOrorheUSAqU= X-Received: by 2002:a05:6830:670d:b0:703:6076:a47 with SMTP id 46e09a7af769-708e37f59f9mr8475104a34.23.1721387160339; Fri, 19 Jul 2024 04:06:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 19 Jul 2024 23:05:48 +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-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 8247C4002B X-Stat-Signature: b8t7dhz9ew7exd8sr89o85uhy7q4mj1m X-HE-Tag: 1721387161-572614 X-HE-Meta: U2FsdGVkX18OBkg0ta9BO5sGDqg11JXcUVOWTsrjyx+ycmMTxHF0B7t7mExx0M8h+TeYE0iVt0DubPsljs9jUr8mClrn2IRDLa23TEEXNvdNsdxbbwRrztaDbtaR0EN6yRTxLIb4zK0j4y8xip34AW5Jyhf+1s43W5VUJ+3cNKf26ZgFa+S784Qjy5uV+M32t+p7xJn+0VI+PHsrOCeJLUo5Zfjp2stwt4QW+t5oTvr3k3fXhYwKRkrrS02LBvqM7AN+0/DE99n3bS7jFYqp2julYo1MWFI3jhRSE4GmN8CJ1POZV61bbQNeM8WGXvkWAQdSxcN3nCpfmx0/0hGnytTIzBZPqPCZ5c2chPSkTCURCIXRBt7Qc38gzyWfOmYPrf95Vo/i1QK9QLEnA58JF6WfMg0qUm4NHxRu4jH43hwrj6fTfom08wyDBqesI4+mG6NOWE/5KDFMZ6873zTUPRJDBPEnl8PqfBqxlCjKoDaoRrFLFgD6cX56qjGZjEDKMFk7jOP4rgloTi45ibJXsv1F3I+rpcdW65ypacX7AfIasKLz3fawIWwvfoLtuPvVwtJ9AN7X64kW7utM84GbDCsSBzlWhMxLj9zAccFpmvgWz0++8fhdEV7dRhp/SbH6OMmC8sYX/AfKyrAuYYdCggnDddUHeOVAa2hlnGOClRR3jADaKwRupCGlLgjcaMoRfoNAWrDC3gr5hrJyPZGScAEXdLVruEYklEQvx17rmjcH0i9PJSWgG5arbGqWopxCScEeoFw4IgthYOyU2slkOMzTlx5SNZKcjQm0HOlqqGC2KgAwQ8LM633/U/d23ZyR5ZQtT5hlBquxDISfi1FIZg7JPYWnMNGZGUpZ2o34QVdBdoeuBZ/nYTqN1gUXD/6pcaPeAcBMbZKppNAv6jw3zfW6t85eDZQAnl5GcqlkmHki8wc/C7RDd3VLMXnTT/0b7+DKG7yMg62DeLY4sGL 2prHWMue D9J2uRutVVo7Puf0e/QZWN0L+Jk6bLjst9R+MgFB0rlIpSCZq2oK1VaHN6SuLb/4LyvtiiD9TOxNhnuzTEwSk51WUrrQ8XyZo5MGrwTRREFbHYGCx/4F4ldDkGw6MbdCcLFqEASZCWScFgxTnrDdni06QKkA4up9huOfyEZgYAYaNqIKKCnJlWRWTDD1cAd9aZFBBY+t+ew5rOTqsvXYaK+e1lAvR+Pxo3PKO1JHSQF01uH78eDHyRFk/wywdov2tTV+s5PgM/Dh6QAwKQbLxzlkABoBtPmi7zzS9WLSNvetKU/p6XkaXr72P99KfVveMhkNRJY1pkQ1tIydD9apn2tfbVDoCkPXsMukMm3BVw0uzzZVERXpSgF7iYMUUb09ih9A+lASH0XZc/iAmddsAIgM/tBu81NgfnVdAiQtqfRnaGhw8vbhJyuilaHgsDvRYB3YvN2T79F6vDhQem9qO4MW1M5IoOIBub87R X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, 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 10:57=E2=80=AFPM Michal Hocko wro= te: > > On Fri 19-07-24 21:58:51, Barry Song wrote: > > On Fri, Jul 19, 2024 at 9:45=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Fri 19-07-24 21:36:38, Barry Song wrote: > > > > And I believe that even most MM experts have no idea when GFP_NOFAI= L > > > > will fail. This is so bad to keep it as is. > > > > > > GFP_NOFAIL doesn't fail in any supported scenarios. We are talking ho= w > > > to deal with those that are unsupported. I am not sure how much helpf= ul > > > it is to document all potential gfp combinations that make no-sense. > > > > Sorry, I don't see any point from what you are saying. You are simply c= laiming > > this is the fault of those calling "unsupported" APIs while lacking a v= alid way > > to stop this from happening. Bear in mind, Everything which is not forb= idden > > is allowed. > > > > I don't think maintainers outside mm know what are supported and what > > are not supported. an "unsupported" scenario can find a way to come int= o > > mainline easily. > > Good luck documenting all of those in a comprehensible way and > maintaining the forward. I don't mean all unsupported GFP combinations should be documented. Other unsupported scenarios can reasonably return NULL, and the caller will check the return value. So, I don't see much value in documenting them all. But GFP_NOFAIL is absolutely *different*. Callers won't check the ret. BTW, we are really exposing potential exploits. Rather than an early stage BUG_ON(), is it reasonable to BUG_ON when we really return NULL for NOFAIL at the last moment? This will crash the system but it is still safer than exposing exploits. > -- > Michal Hocko > SUSE Labs Thanks Barry