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 1D8B3C3DA63 for ; Mon, 22 Jul 2024 08:09:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 874E26B008C; Mon, 22 Jul 2024 04:09:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 824C16B0092; Mon, 22 Jul 2024 04:09:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EC766B0093; Mon, 22 Jul 2024 04:09:52 -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 4EB526B008C for ; Mon, 22 Jul 2024 04:09:52 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E3A2E1C396F for ; Mon, 22 Jul 2024 08:09:51 +0000 (UTC) X-FDA: 82366664982.24.62DBA97 Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by imf12.hostedemail.com (Postfix) with ESMTP id 24A9B40016 for ; Mon, 22 Jul 2024 08:09:49 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Jx5BJv6G; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.51 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=1721635767; 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=vv2tA6U9MpIJ3XeQhWg7dY4jMKxxd9JGN/Z6tEEZ4MA=; b=t8BvcrFAzqSM6Aqq+gXEOgrJMVrtVKKT3lozccKVCXv6K67J72qThirQ+ZTFqFqkvkVMXJ DU441/FH05IASFaKZkLPp6oni6e5i1LztlJScU8BuxcRsMzbcHuxrOsHXR7jhtOW9/gwNL Xi6V5AcyYXdf5NPK74940pamSJWMDOw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Jx5BJv6G; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.51 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=1721635767; a=rsa-sha256; cv=none; b=cst2E11mVe5eZFNzTH72fPIp4qG/6ccJBOkveisdWVlBTw2BV/oKHDluG7SL0y67Hmuc98 PmbBDOO4szN50+w6letJOPD9vRAA6bYf7wEgEQTXfRL/pFmYoEal4vv7JeTfuK6D1jaMvI nbKxBCfQ19wTT2oAleRkaPRXBFLYBn8= Received: by mail-vs1-f51.google.com with SMTP id ada2fe7eead31-49297ff2594so356608137.1 for ; Mon, 22 Jul 2024 01:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721635789; x=1722240589; 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=vv2tA6U9MpIJ3XeQhWg7dY4jMKxxd9JGN/Z6tEEZ4MA=; b=Jx5BJv6GsBHqJRxaDYd+aXxdCzKUkKu2a0m1vCeZIOkOxOQSOuaTozu9KEQK0dyeWI mblV3M+AKH409l6erpHtcTCDcTYzH8sbYx8fvQT9wjfd9ejH8lA0dJLdwSdJaz/v7Ct6 NOuhSXxTdBHcsJ5ONpGjM1mTiObRII9unTrLjTDoPkLYBVwYDbwalXbWU4FaVyJlCzHV idfLKpIuQzuitYJiXm7KEvnyjIVjOjvVlM6y1DFzK1eiP/yy/LHyl0vPQ4HtoaLkDDys upNTsEpV2yXYxiAcKsWEerAZbeRx5FLfObVCtzVGuUdqUJ+la7VThT0GOUChEO0T7kZy NRqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721635789; x=1722240589; 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=vv2tA6U9MpIJ3XeQhWg7dY4jMKxxd9JGN/Z6tEEZ4MA=; b=xDk3WOEejx9//UH62LM1z/hQ7mFesL1XObtwTfYhOIvl1Y0SYkNWaoO9ikCpKCyTEW OzDV/p+wMhBGL7yezGBA7s4cDp6EYDPxbsOWvBoJBoiBZhJOo0uu6rf05BVglMBoHgRh DTNd2llChdfHPCl/SVrSSZMfRvei0reKh7IfEIN/+IYWWsU3cCrqcrysC04Eu1JmQmd/ RT4CN0MiitdVi25akLRLJhVnRxm4LemVMP+Z3WmIO9A4QuJ5FPEamNabBLOtwdG3PKms usMJ0S6sDntne1pytJ47SZq4V5puH/9d5m4SPPp1eqnq7PUcClEgdQOZfOgRpUyeTNji lZjw== X-Forwarded-Encrypted: i=1; AJvYcCWZOjzB7WBZ84Jk7XyT/zwTBl6d90qzTnIPitv8MRHp4gLTb1+QU7UP3BPJzXTA1eASToEyl5XWmbN23yKoBeursOU= X-Gm-Message-State: AOJu0YyHy4tGIIr54iUqTl5ODuYn27xy5m5b9uyzhgih/MJjIzJ7oXJJ AjoQTG8XFjT8M1A5wdmiwKoOf0htN3/0mJmiO5DvYbKzT3dvyqzdZHkCStv6Ao52804rda0URlC Bd3F6fz9nIdf3Zx7xDOakfRzfCEw= X-Google-Smtp-Source: AGHT+IE6cWwJb39zto9tvqOstBgYCvesgZY6bI5CwEANF36g9aLWs/CiLfnAdLfnLJjEoMY1mYTqVX97qnaZ/t7wyz8= X-Received: by 2002:a67:e705:0:b0:492:97f7:8433 with SMTP id ada2fe7eead31-49297f78581mr5656358137.0.1721635789155; Mon, 22 Jul 2024 01:09:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 22 Jul 2024 20:09:37 +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: Christoph Hellwig , akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , 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: 24A9B40016 X-Stat-Signature: a653kybmphxek94xcth5wxef196ustpy X-HE-Tag: 1721635789-649602 X-HE-Meta: U2FsdGVkX1/BEZWe47mF/4tkNW79XIykaiuHCiMI5aG6BRlW5AYGv/qOTaB2bRB12MozrGC1F+n6+NSyA56RAd3XEcon9idkLSc4Tw6st49OMzRKXF5Qw9JfZ9qwoB59n8lY5qJ4fMUTbya66m9GCvK549N8t6J4Z8bdOd4lX/97qVUukZHQdrBnsSC8ezya0BrFY3WbJ0mKJBQAxMAgqrrSMyuPQo/dvf1D6WJ7sskfpXq21Pvcr5Ygv3JwW7iBNinJ7GLCnChKL+eBzH80Kg4iN7BcpxT3kdkPP6FyoN/YF2kXnxx5VnVKVAgFxUzZQDVMZ0f5S176QfUVyi2jKb4dXl7QLScc2m5IG1Hi46YSJvWACERN6jKWORi9MJAAcsnE0vCXl+ExpEESXZmZ1k7P0EKHKCC3Wh5YaigLKjau6FCxIv6fcp/V5nHLxWcZmMle0UUn2bKPe/AFWbORe6xWGUeMglWmdzus0IAPLDDsIIOhJlS35j/fuBSL+NP/PWocxCN6F5KpRDfKw8zgDHmey1zJ1twhvdOpei9ymeLglyYZ6jsxznxtrF0JiBrmIv9Q++Um6QvehV8moFbo9ZAsvNaFPNECPVJndOQmq2O1ueZrddlk0XZZ1o+oxsTUwctwnVfKgvvLgkI2KCdK1L5yjOwhFW0aNhh38fN+n5JhLMgRYkA4WqaJgOs5C65VRrG+PlvnHg6tqlwe+Q/bRzK6WlFfK5jT40qUoXFYdrnLXH4qAaYCYYJSuZZJd0roszEOYlg8QqapSpFVZJ3Qsz8rmeO1KQxUvQOjnrjnPWBfAu5G8B6h57POL4bCbMOmj+fZ5W4r4u9g12bD5J9FBPz0RvAJVRfwSJ4vj4zdIOwk3ypvENUDE/R5aP99TS1wsd7ECRd+uCn4IGBrMJS/sVjlUUsJhIFUO2lA7zTJ2V2lE0oyD1a8jkJOs7rZkUcPW77R17wfQjfi6R7yf7v Wn6iQ33t 7wFaj/ZAN22xjJEXuwleJwRMiUquHmRR4tCrikZduiBcfl+71XEUB8ZpiZMp3LrHXTPSQONePC4aWaEKEquXLbkVWGj/Ydx4ACZP4OwjoX3ixjCK9B02xPnVV9dLyzYzyNVTRKX8EBoo52VI7a5ksqqzUoByQlF903hY/TfnOcg1UOuwzQztZLB0JhbSk09FTAFJYc1jEmIuikeAnVJ8C9CaVireG/yDxa18jcYhPbEmGcnLZozegc21uNqlaBou72tB4c8/4+751ifiDWaFt4DG7wZvOHRdd0xz1jPrdGgzHsQW3Lg388MD6rOQUUzgtP5NMmCtrTrSKIuzaEAgcVqrgQkPuvAhtWJ3U4Y1MH2qjtYriG5R6zz9dtFg7yV64s+rsYtH2QAgdKFWVgx7TM/Q4hiq+/LGH+G9P0ntaoSCdGSj+kV9b6ToY9UJJiJe6+W6LwWFqZEx77inDv8oT+LDhpKai7mke3hIbD9gPDbgl6HzLAnv/2UCy5pVmJEfaZtH/KlsLlwGAIVkxoPS9mQ2daQ== 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 Mon, Jul 22, 2024 at 7:26=E2=80=AFPM Michal Hocko wrot= e: > > On Sun 21-07-24 10:14:03, Barry Song wrote: > > On Fri, Jul 19, 2024 at 7:53=E2=80=AFPM Christoph Hellwig wrote: > > > > > > On Fri, Jul 19, 2024 at 07:43:38PM +1200, Barry Song wrote: > > > > I doubt this is going to work as users can use a variant to save gf= p_flags. > > > > On the other hand, isn't it necessarily a bug of vdpa, why can't it= be mm? > > > > > > > > if mm disallows GFP_NOFAIL, there must be a doc to say that; if it= allows, > > > > we should never return NULL. > > > > > > Yeah. Maybe the right answer is to have separate _nofail variants th= at > > > don't take any flags and make GFP_NOFAIL an entirely mm-private inter= nal > > > flags that is rejected by all external interfaces. That should also > > > really help with auditing the users. > > This would require duplicating many of our allocations APIs. > > > Just like Michal has consistently asserted that using GFP_NOFAIL with > > non-wait is against the rules, I think we should enforce this policy by= : > > > > diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h > > index 313be4ad79fd..a5c09f9590f2 100644 > > --- a/include/linux/gfp_types.h > > +++ b/include/linux/gfp_types.h > > @@ -258,7 +258,7 @@ enum { > > #define __GFP_KSWAPD_RECLAIM ((__force gfp_t)___GFP_KSWAPD_RECLAIM) > > /* kswapd can wake */ > > #define __GFP_RECLAIM ((__force > > gfp_t)(___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM)) > > #define __GFP_RETRY_MAYFAIL ((__force gfp_t)___GFP_RETRY_MAYFAIL) > > -#define __GFP_NOFAIL ((__force gfp_t)___GFP_NOFAIL) > > +#define __GFP_NOFAIL ((__force gfp_t)(___GFP_NOFAIL | ___GFP_DIRECT_= RECLAIM)) > > #define __GFP_NORETRY ((__force gfp_t)___GFP_NORETRY) > > > > Anyone misusing GFP_ATOMIC | __GFP_NOFAIL in an atomic context > > risks experiencing a crash due to sleep in atomic. This is a common > > consequence, as all instances of sleep in atomic should result in the > > same issue. > > I really dislike any of __GFP_$FOO to have side effects like this. > Please let's not overdo this. Okay, but my point is that if GFP_NOFAIL is inevitably blockable, why not enforce this and let users understand that it is definitively blockable? ust like when we call alloc_pages(GFP_KERNEL), we know it might sleep. My thoughts on this aren't very strong, just my two cents :-) > -- > Michal Hocko > SUSE Labs