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 620E8C3DA59 for ; Fri, 19 Jul 2024 11:26:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2A296B0082; Fri, 19 Jul 2024 07:26:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CDA1B6B0088; Fri, 19 Jul 2024 07:26:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7A3B6B0089; Fri, 19 Jul 2024 07:26:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 99AE86B0082 for ; Fri, 19 Jul 2024 07:26:17 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E1F334058C for ; Fri, 19 Jul 2024 11:26:16 +0000 (UTC) X-FDA: 82356273552.27.556209E Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf27.hostedemail.com (Postfix) with ESMTP id DBD414002A for ; Fri, 19 Jul 2024 11:26:14 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EPzoG4Yf; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721388319; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Cry7qZiCobTJ1vL4WJNm9uz8/DW7G6hf2U7xNeX6MgA=; b=hI9ppzCY9Jt6IBz+AbnaaXRda+QPoDtwEslRT7dQa0u7SX6v512NOwgFtJ0z8eGicLNWC5 RNW2/gcx1YT+s57nxB9dUQKpjmr4upaayWrjnLiH1SyWfzIRrccKk6WsWchLqem30q7iM4 y2EZHdm8LEfwEbYIPJiQNku2b53YfVY= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EPzoG4Yf; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721388319; a=rsa-sha256; cv=none; b=8FaxAOnVUFfcg5eqPXJb3SUQzJAjwOrJAm5tSPrNjib7D/Wwk4B4d1KDtBw6CTf3u11UqM G7112sV4Qv5FJKCogQRXG7u8yZMr6eMN9RAohzR9h1sbVdRTe9AHuLJjID5lNHquz+lTt7 jWxjoqvzBCNerP5QWL5mBWyR21KbQjk= Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-426526d30aaso12066455e9.0 for ; Fri, 19 Jul 2024 04:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721388373; x=1721993173; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Cry7qZiCobTJ1vL4WJNm9uz8/DW7G6hf2U7xNeX6MgA=; b=EPzoG4Yf2EIgVpeiTBcAZfWSGUNp90XDcFDfOHezi4fJ8miJyKV0UGS6QXxHSFxH0U YEFIRdl1Q8OvZ3/ZwEBwdATKX+QR9yYj94gV6k/EfXgguEmWthg4FxhA9EhlQZejjFYO VE045sn53zw4KNQ/J4iHL/agkI7+U1p3c3ODy3nMUXPwqcTr1d8LwPu3i9AWu9t2tSEn b75uy0IO9lQ2mcrbXx6HdRrIVJh+N2yQCgh+7lZyj/JusLFpBSPx7Gdrldz2Kpi/+/4t gUZI+mzOO4jvSseuBFld0Znov1Usgo0rUfTVoOdGA8DPw+8iDiAoz64UJvT6yL2uUvtc C4MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721388373; x=1721993173; h=in-reply-to: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=Cry7qZiCobTJ1vL4WJNm9uz8/DW7G6hf2U7xNeX6MgA=; b=GNWvXxOxLSwmEghAG7+bpbeXKMLbixHFDw8G4PRhAlKciAkP4Wn9f695isJ8WuhTSu cwo9Au4eUSRD/ikZejzTxBRO3a5j82qXP7JEI16nLBCxrASy/6E1DJi50ehJa+RoCgGq wRM00vEnxkMUc7MmgVtirLrNuUuYOsRyxdDNKlMojmJ6pmqbOUGBIlT/jjBmok/8PabK 3LKu8Ewgjtki4k4Azed8TVENj3iwSuKpOQR+bqHSbYbII+b4MeoAI3Lyxc4dn4RaaW4A UfzdKkC4ECEjGdIU2PAB4T5BF9R182JhBOecvkA4FnOnvH2xGj+IJICoROCYXCsfCqpn GDMA== X-Forwarded-Encrypted: i=1; AJvYcCXabDZ1bRLkf+ls6Ai3WXP++xmKCsRLvo9gEsP3idbZm6PCZRNogwbCom4ojaRZwMz5j4Heq7y2Dm68WqHrmoeWYr8= X-Gm-Message-State: AOJu0YzVvq5B1KEVUcZserCSAHF3yk14a2mfxUTbVUTH7FmOLoiWEVt8 bUfq+aqlMma7f00TzK3yJy96vyed+2gQ5jtcf82/T6plKurgT13XdtAHVclDSeA= X-Google-Smtp-Source: AGHT+IEt11cijYxSQELGprnQ4jjGez5bV7E49IpDvpUC0I6vPqJXOH/HQTFSmROMT0e6Pm3n3zrJRw== X-Received: by 2002:a05:600c:3501:b0:426:5f09:cf57 with SMTP id 5b1f17b1804b1-427c2ce5b92mr55840555e9.19.1721388373341; Fri, 19 Jul 2024 04:26:13 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-427d2a95099sm46971545e9.48.2024.07.19.04.26.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jul 2024 04:26:13 -0700 (PDT) Date: Fri, 19 Jul 2024 13:26:12 +0200 From: Michal Hocko To: Vlastimil Babka Cc: Barry Song <21cnbao@gmail.com>, 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> Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL Message-ID: References: <031ff35b-65f0-4ead-a08f-21711bad5e29@suse.cz> <4a1bd482-bfff-4843-a60f-004b3a8a99e4@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a1bd482-bfff-4843-a60f-004b3a8a99e4@suse.cz> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DBD414002A X-Stat-Signature: keo5eop79b81qcfic7nfy6h8w6htp653 X-Rspam-User: X-HE-Tag: 1721388374-226404 X-HE-Meta: U2FsdGVkX1+H7CeqT8L7Z/aCm4EWR1O3OTwEewRkySkMhxjF4jljaIVB1P5DEIbQVDzQ+wdv14M2vaN32uE1KUyf5ngGSDo3KbOJbWV9JtcHSIUJTJ+V1OKaf1+a3rMbi6Jb6gbeaHS6le5kcIwUMsmvEzRYinFCx5QwPF12SCRCEs3rDCLd5tZflXsAEXdi8vaTGBK9TGsnQ3XKyO0qFRvHvVPlP3wF24409z1JLzedPjzsiKP0Mg6l2AMEWaTyZc/53/wv6ySL2M3LpMGzuz74iKiF+rxXi21PJkewPrtbgg2IWPUpgkcc/hIrBLFoYUwV8uM2r/n4S3v19GxRL6T+HskiZFajzr4LnTdv/WQ+8AUTSAK+n6v2CvfQSol8/8IvfNhcOBRpJGb1ZmKWjx3dE73vgA5NwdcG/MsMGrwLw0yFn80915IYm+ky2DHJRvVfrrN3U0WatyuMzPntJq8wiBQ4+/TMbbJilngpdrufnN5z8sxPsCXBzpeeEtStpgxktqIz5gSXR2eNYakcWTppc9w9UnqJFNLVtF5bQas+CyXVi/nlZuIQx7sgl5WmBAMg9OFHLkqbnZcdlcKyumQHCOM4bGxRycQplCT+FYF5ym7Bj88to6S0CzrNJrOokFJGx849zBd0kQ/VPvr5WfzsYCqWIOUk0I/A6VxhthXpedEzsIVx3vIEpOupW8dMmW2imlwnGLHeevdjq0aofVcp2RjGFZOkCBx+b9hV6HKsi8QgEZyo5SK06xla0t5QhvQm7yLl93lzVV3vD5RUg0k9UkfTrwno06UKeGKopqjjZM73XEDf8AzwM4SmV/k/+rfsd0SjYUZgvlFJCw1EuFebGNAY1bjbq7TQajhmkiaZfhm2yCRK7SForUaQqoboYcreiBW7p5DQk2U3IdODavQQc6b/jxpbthzkJP54drsmUyWRl6g/K6L/Z2JxoxA6n6BleTEVqxQ81HjlGTb /bkxm+uT rvUtCR6NBSDS+AUqtHYqQDYwf/w+nLQT8UagIrtHLQFEdOFqx1sr6WdtATW9JrFWKsBjUpDrF77BLVRYDOIqn6xjpFXD6PtNbIPZCdVFGOwcLUFmFhpq6ojdx8woxpkmae4yQJNTxeWtYsxIBdUBADrnParbpRBTxViDZWtYi03i+UCttaFgYxm0KGf69PymP3spxXkmymidTUtMZCCpsncUkYRmPwPLIHzmUX0lNdH6SicrRFOs20kj7eIdCNYRgo6guABeriKCpDSDfH+mgNOFTdn7fkvfdIVPPB0yMN1tfjYqN1RD1QHMl7qvF4apr7I/9CzWTCAJ8O6BuvNdDePSUDUX5oCYa71wZRK79uE7KALkBUNMhNi94xG5P3qTLpgbtkVFXGAJ3j6wAAHlu9c2wRQ== 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 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 practice. 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. What > > 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 debug > 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. Maybe > 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 bizarre 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 int 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 page + * allocator from non-sleepable contexts. */ - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) - goto fail; + BUG_ON(!can_direct_reclaim) /* * PF_MEMALLOC request from this context is rather bizarre 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