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 DF7D9C3DA59 for ; Fri, 19 Jul 2024 13:02:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 429946B0082; Fri, 19 Jul 2024 09:02:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D8F36B0083; Fri, 19 Jul 2024 09:02:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A0106B0088; Fri, 19 Jul 2024 09:02:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0D7916B0082 for ; Fri, 19 Jul 2024 09:02:26 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B4866806DB for ; Fri, 19 Jul 2024 13:02:25 +0000 (UTC) X-FDA: 82356515850.17.E2E8A27 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf07.hostedemail.com (Postfix) with ESMTP id 9BFC94002C for ; Fri, 19 Jul 2024 13:02:22 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P6O2uXBV; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.160.175 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=1721394122; 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=ntZJrjbkfkWJQ2EASIA4KQRqMslrU0iZ3RXw2CXl1Ig=; b=0X1aaSW468Cc+QevaOLeA5SBluCSDEsa2Aa4sFj58LgvT5O4u5zU9Sm4YZ7H6i5rWqJGsW bns+nkvHiJyVS3sl9RgZ796MGcl2UybZ5TTPvYA+QeL46swLQYewQ0BOKdgsJTXSFROuWu 5+ZWvvIQ+0fzmIM28i2LjwdgMgti/nY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P6O2uXBV; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.160.175 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=1721394122; a=rsa-sha256; cv=none; b=n4TAUuDq81UUowMG95S2BQgirnr9mc8awntWdmuPp0a8O9gPkd5n2kq5echFX3uk9MMjBB G5hpzFkyWwxvlcVuQKhCd9rhpXfIyTtksCSfWf5GCTYOfKkw9pm8jFGNFbOjt9gV1Apij3 +67pwY/gKy4hwuETUrtyn6nloDdTPpw= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-447e57103d5so6822791cf.2 for ; Fri, 19 Jul 2024 06:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721394142; x=1721998942; 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=ntZJrjbkfkWJQ2EASIA4KQRqMslrU0iZ3RXw2CXl1Ig=; b=P6O2uXBVOx9HXM62CVSJgpZYzVnHQ7aMpkxMaW+Fh62ho4v4z4ozwFq3cgHz6r71NE YRGaCRMFlh0UyXOCpT/eEyiFNBMbc8O0id7DOeVX6pguMtLqS7dI3R/STT9gUpArDK2W oRqBNyDsFpw3CH6nNwRjnCaqTqc48/i+X37h8ZUaP1Zk78afL89zpnq+pq67qp6bURWo tj4ZK/keEkr06Gxei0GiULXnmeNZqvzeTzsKvFVtMakKfBxlo9JTdgte2nKfvi26lKB4 5gRqyNub+QqzP/maHpiXGvTwbt6BadBpgECuyeoxGvJfO6yLo62xID7/iVOhZuFDXYMP 6djw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721394142; x=1721998942; 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=ntZJrjbkfkWJQ2EASIA4KQRqMslrU0iZ3RXw2CXl1Ig=; b=hbkiXZAVs8qAHH5Ht4GObcuobXMtsblAM6qgnI34zCDwREeKJ7YI2eED69tYAZcmuO 34n3a8Uq4G93KSvnPr27sFb8Oucd958BOqxkQ7GXup+uXOZO5wPbpd+0xT3KW9dM0BN8 CpEZ/uTzDeDUfS3LYcNvLp82Ml0yBXqLJUzxs9FK/kI7hkZ51IWhoRQBoCygV6oGH/7m K+L7C6xl90S9ZIV49oqDNT+jg1jnJcA+Jr1krr7DJE3U9P8EvWdPrJWUdJ2xK7zxw3cN X3xScNT8FXbbB6FFDpzu8KgSBQySV7sbg0qvQFyzAu8vdSXktshz/mQRFuq/mUXdl9U+ 98Fw== X-Forwarded-Encrypted: i=1; AJvYcCWuSwGXlBSEnmayFxQ8fp5aWfLJD2rNTH/ov5nRsZ1tRmOeddOi2fwWlNCvUy2IbHjVm5UBhQMsn0JWmDCtElFOES8= X-Gm-Message-State: AOJu0Yw8I/jXua1GQO1Z45F8tlePE8xG3Fwloy2C+tC/7WNvjTBegfLc kEu3iealpJkw8MBNHeOKtozszm7toi2cpYMBXl4HBP5IBuJlUvbHV0XNMViHda6wjYaTNoe7CtN eUTVpkzoaMU79bRkdkgRoCyU9pnk= X-Google-Smtp-Source: AGHT+IHyUDV1Et5R+whhlpplkdPMXqTLmcdJU71hvYOkkJEuMjl0r3pDz0UIEdGnKQMrSknV3KLZn1NO3cuBM8fRUqE= X-Received: by 2002:ac8:7f06:0:b0:447:d87e:7873 with SMTP id d75a77b69052e-44f96abbe83mr40831311cf.64.1721394141519; Fri, 19 Jul 2024 06:02:21 -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: Fri, 19 Jul 2024 21:02:10 +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-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 9BFC94002C X-Stat-Signature: 67m7n43nxr7m1fph1eekyozyfd8k3cj7 X-HE-Tag: 1721394142-162587 X-HE-Meta: U2FsdGVkX1/KllRn7VO1qPepczIu2C3e6wJgZax2lDiDGtkM6B+Rmjx/jmvSp9PYwOUzCEvYSUsh8Ax5qQKeCp9fKlk+cAvKRppuss+e9M16Exc6afa/CLEVc2Rn4m/1y7gE+FirCDx05EppaZT5/t1/rI2YruurIQnqlnjMkdFL7JzSNC8etuHU+J8O8ZTkXTTQJxIjAJiptKJaHPDNgFlAS90xJwKe3yWWr9hPsSKLI2pE3SjLZqunPER3H/pJEhiMdSdfEpQeJh3aJ7aQBA8KXzInDIH9Uv5ujMZ+h5aUE0JcP21XTcexSUIqbBrIAR4DfXwMzt+t2KVbPlOXxtCAmkbVXeroi2varj+mX79PI9WEFLkua0k1tPGwjdG+jzCU74g5LsDFpDT5b5VrLTo0+QgBo48f8n6U88sDDatFK7Y6AAeGRZAKylfQvlNzlO40B5oIv9GONgLrmdhTi0bzyu7Zp7uN5YL3GjvVlq4bnA8KPxBAjpp0MVOc0x2grXTUMBQM/E6gPbCCBVYrg7JsvImJEvSSqNELuUv0CIxQKvFWOGDxV86jODlzkR2qpbnHxQa+mummzE2FJvf8I62vNknD06baC/084NVFgIiDp/44JJB3vlkGJBRp3rmRHmRw9dRR4lQ+i1Ozteavwy0BrMonfv7CO6etrDcHd9ArReR4MI/j+QGznSqqSZ4JoeIktPxxhpc1ga3GkHfacEXlsiXAIG3iwrps4c9+b4E1AoDkScL62Vlj4Pn9fk8plngZ9I656x1At/P0825YsJKTPpzSoKLV82ULX8XIddXncaPX40SVsj0ZIPg6/kVol5zjlKhxylj09LorVPJM+3gEy2cvW4S0IYwbuO/pDrZAmvWhL+oYbzbja282RjwKVabeZnV4OEA5GyenqRllwxqJQZqFb0Tx45s1wFvhElGfaW6aQROPrXVgOBLAVEsz1yKFwL5cbGpLVT36EmB E0bg+q3E WA2QiBrCxGHnQ3SdM0UHZxSivWuuosROLXXzPJ/k2dCjyBlFZn3FzIn8io6TUQ8Vrli2oGKO+4RHy7yUby+CBRW9irKcpJXqydeASvfLZ8kGT0Y0xEYqIxYuH/Lx62qCQlC614RuWU5nqqKxQkGUpTQNNyqHnDiV91TVDvgcmI/VB3yPpOIkF6+jxEKNYAUuDW2QyttYJLN0xe9LxCrDsMcw+xqTb60kIkO5R+51XrDR5qWx8ULfQpZBEgoQid4jVX1SrL1p6+pNAiixdVCj4+5NbYBPolAgNKIYo5Ri3dH5Cp11KbrZP2R85SN8wPGgy3JjSSWasIFv2ld8RdjbGpidkaeB6+ANDg+rGHkPZuAytpjv38uj/ymdlrGDALc+23Uc4Lim51rIzLt2iPrVRC9v3FFc+JJx1eYQOWxu3Sp/jKcezpBXaNybB1DuIMxieEz0zoi4Lnew2+e46QBP8ZUEUb2ibUKQTDFEF 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:26=E2=80=AFPM Michal Hocko wrot= e: > > On Fri 19-07-24 13:13:28, Vlastimil Babka wrote: > > On 7/19/24 12:52 PM, Michal Hocko wrote: > > > On Fri 19-07-24 12:10:13, Vlastimil Babka wrote: > > >> On 7/19/24 11:33 AM, Michal Hocko wrote: > > >> > On Fri 19-07-24 10:50:07, Vlastimil Babka wrote: > > >> > [...] > > >> >> That wouldn't mean the busy loop is a correct and supported pract= ice. It > > >> >> would just mean it's the least bad of the bad options we have to = deal with > > >> >> an allocation that's wrong but we didn't catch soon enough in the= development. > > >> > > > >> > So you want to make those potential BUG_ONs hard/soft lockups (not= sure > > >> > all arches have a reliable detection) instead? > > >> > > >> I'd expect on a SMP machine there's fair chance of being rescued by = kswapd > > >> or other direct reclaimer. > > > > > > I would expect hard/soft lockups... Anyway, the question remains. Wha= t > > > is the preferred way to express this is not really supported scenario= . > > > > The documentation and warnings? I don't think the warnings are failing = us > > fundamentally. We could limit the corner cases where the are not being > > reached in case a buggy code is being executed (maybe only in some debu= g > > config if the checks would be too intrusive for a fast path otherwise).= That > > would leave the corner cases where the buggy code is executed rarely. M= aybe > > Christoph's suggestion for a build-time check would catch some of those= . > > I fail to see what you are actually proposing here. I can see only two > ways > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 9ecf99190ea2..d5b06ce04a0f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4391,7 +4391,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int= order, > * of any new users that actually require GFP_NOWAIT > */ > if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > - goto fail; > + goto retry; > > /* > * PF_MEMALLOC request from this context is rather bizarr= e > > or > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 9ecf99190ea2..6ca9c4d33732 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4387,11 +4387,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned i= nt order, > */ > if (gfp_mask & __GFP_NOFAIL) { > /* > - * All existing users of the __GFP_NOFAIL are blockable, = so warn > - * of any new users that actually require GFP_NOWAIT > + * All existing users of the __GFP_NOFAIL are blockable > + * otherwise we introduce a busy loop with inside the pag= e > + * allocator from non-sleepable contexts. > */ > - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > - goto fail; > + BUG_ON(!can_direct_reclaim) what about an earlier WARN_ON, for example, even before we begin to try the allocation? This will help developers find their problems even during development stage= . then at the last moment, if we have to return NULL, we do BUG_ON(). a potential way to mix two poisons is that we retry for a couple of times(for example, 500ms), if we are not rescued by anyone (other direct reclamation/kswap/free), we raise BUG_ON. but it seems too complex:-) I'd rather simply raise BUG_ON. > > /* > * PF_MEMALLOC request from this context is rather bizarr= e > > Choose your own poison ;) > > BUILD_BUG_ON will only work for statically defined masks AFAIU (which > would catch the existing abuser) but it will not catch the code that > builds up the mask conditionaly so there needs to be a stop gap. > -- > Michal Hocko > SUSE Labs