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 30D40CA0EE6 for ; Fri, 30 Aug 2024 07:24:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B68706B00CE; Fri, 30 Aug 2024 03:24:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B17E66B00CF; Fri, 30 Aug 2024 03:24:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DFB36B00D0; Fri, 30 Aug 2024 03:24:51 -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 80B0D6B00CE for ; Fri, 30 Aug 2024 03:24:51 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 03666141561 for ; Fri, 30 Aug 2024 07:24:50 +0000 (UTC) X-FDA: 82508074782.01.3CBDAE6 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf20.hostedemail.com (Postfix) with ESMTP id 003721C0009 for ; Fri, 30 Aug 2024 07:24:48 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ay5+4R7R; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.47 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=1725002618; 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=ecl9V3mHP2TroPJgyQO8RmF2Y8C5vbk13wxZrIkGuAw=; b=XecNCo41vzJDA3AahBPSxDfNrsJtqa5XCiWPb36zJqzacppHnmebsLOwyV0xA3TA4MCOlH LUwxyaKiZceuknpodYJgRrYjTAgEmUDBBF/Zy/tjVoZ9jYu29DSH0qbw+OlHqlgXHAN3gP uyVuMJ1MDhxuPexCQYRKdZCHbpCGZ8k= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ay5+4R7R; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.47 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=1725002618; a=rsa-sha256; cv=none; b=ymigAdLyNPMClMRgkhGgsCnKgEo6Eshw9fdwtwVKxwxzi+stgPWHUpt9T/xIOd5TDCQnM/ l/9amGbWVty2LZjeWxW7a0ekKwzdOqlcG6l/3ZC/go/bAN30tGv/lMGbjZ40zeV4AYZtFH mRrEEcGGAt2/jjc+ABZdbjj6YFU7frM= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-42bbdf7f860so1041125e9.3 for ; Fri, 30 Aug 2024 00:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725002687; x=1725607487; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=ecl9V3mHP2TroPJgyQO8RmF2Y8C5vbk13wxZrIkGuAw=; b=ay5+4R7RbGYMk1sV/nr7bey6ZOpv+O43cSnJkPZO55Dvd9t9UvsJuZbCpYbfZgVdhy KS4bnz1LMI7Ttl0kBpCqY6TipVNWh9nT9tzUp3AyLsEImi8ccSv3JB7LQ0uLw4/QIzkg QNJz+WDXSq9WEGzi6xnItR6urvRJCjyhd4FPu7OYqXvWPgO9aXC9K7YzFy+nbvR8cjeM DVHFULpTyH+WvnzwiBBaPi/K04LLDHrxuoFHvMgcyJQRJc2qoNV9yoxaH4iG/2tAT0GT FZYqK+ZvwS1lFEUYEwW0NdR5UhAbsZgpLHuctuZRJDcwAnjOvyBpKYpq/DI5KAtRer3x xOJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725002687; x=1725607487; h=in-reply-to:content-transfer-encoding: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=ecl9V3mHP2TroPJgyQO8RmF2Y8C5vbk13wxZrIkGuAw=; b=PlWr0HLWOMudEOXErf0aYXYPu/QPhfjsww6ORsLhmtMdLpRSjhDjvgOP7YVjRPQDJ9 5n0WJx/0AiArgLI9lkaixw50OM0IzVuB8V0I6FnNFQ8fa85FKM++ldXs6+KY0HiwVWW/ 5YJw5RwbWS85ZhnJwnFiZ7/xA8v2Bzxbbz6/mb4ykfG6Refv9U8QwbWifKu21h0hEohF oaG9TF+SfhVJFhZeWK7DblNw+9PaKtI+X62pgjG4k90RhD8+g/FyJCjzLyfl/wr3p4Mv ZrfMEG8eutOjfpiDFYymWIl7bZ8laLX/8Q1RWgBeAW83pspQ4vU5s4esqEPr71892mdW kwxg== X-Forwarded-Encrypted: i=1; AJvYcCWoaKjGrRKb+ZPvGoXvKJUtpjUCaqH2ZEVRUZDYQ2Sb7rm6zlCVjt93yDWkwbrSt02vcrXWTJBx3Q==@kvack.org X-Gm-Message-State: AOJu0Yz4r0VkvMKk81Br6xkbPZCaVspLM4b64RUImxQwONDwoIvB0ig0 TiKzDlBhpDrQrfp2A4IaEjITi8PfQ0CXjV02Ki2ZfttBaeLkNRmFSz9duXLat54= X-Google-Smtp-Source: AGHT+IGd+v4gw5NFrcdO2V0+lNAzqgrBBOAwStEmLuvRWpuojLyJlgncKQDgdAUlXD0sjILmrgTK8w== X-Received: by 2002:a05:600c:4693:b0:426:63b4:73b0 with SMTP id 5b1f17b1804b1-42bb01fd12dmr45492325e9.34.1725002687187; Fri, 30 Aug 2024 00:24:47 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bb6deb3efsm37586855e9.6.2024.08.30.00.24.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Aug 2024 00:24:46 -0700 (PDT) Date: Fri, 30 Aug 2024 09:24:45 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: vbabka@suse.cz, 42.hyeyoo@gmail.com, akpm@linux-foundation.org, cl@linux.com, david@redhat.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, laoar.shao@gmail.com, linux-hardening@vger.kernel.org, linux-mm@kvack.org, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation Message-ID: References: <20240829223114.1102-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240829223114.1102-1-21cnbao@gmail.com> X-Stat-Signature: peqetunuun13sx1qdro15a3bnkizq3ct X-Rspam-User: X-Rspamd-Queue-Id: 003721C0009 X-Rspamd-Server: rspam02 X-HE-Tag: 1725002688-343338 X-HE-Meta: U2FsdGVkX19bXtXvup+bp7/2F2m2IYYaVjcv+HbxexC/0hX+Y/raBm4jBGpbbJ7a6ptgDQaFbGpyekZFXt1Z6DJo0bxp4+Mb5kFVEFvWOupieZ4eEZ0q7MW67lDMp59sCKGC7PWuJCBzM2E1/jlX0xGdvFodfx9viUIP8UC8nodM4fwB09DczNMEfJijNyCsbBORr+5wxxnRA+TxwITKjAcq+Qu5w1qHHjQGhEKmG8FIOYP4vFh2YMZHe8vjWEQG6ldHTF2uKVMghgrrHT/yhVfItoMtPahNSnpxPRx9gYXHiLMJVl/VZNklduIBU10KGdDQBnj4evVChNSyM3K646i9ZDffItLga/Bc9lKyuCia7gsiuBO9akEMstx7Bal/Gmb8Hf8tchvmde6+YVq1YccjsI3dxsSqYuAFYO7sQVUcRG5pc2qKJSC8urTDznGTryXbU4/BLZ/PnQKH4zIIZGMXOxVcxvu6kcfXFuhIeud4izcK5oj7Q3g9oK2Kh0gnoLgwFqbxr5lz7Omi70YiUSxRLpPe0ISuImqdK2NluyNtYfJ5KwaUhJVJeI87e3EG+QdGhRDT6GT155A+SQt89fWZLK0xwUhVhIFDWfGwihXmvch6vEeT/71tCc7LPa/Dgljg5EM53ejhWNe0r9+xl0nun8S7BldZ9J0szR7nQ0M9Ur+FCtVBziiMFNjpC1yHO+4daw/00oz61knyzgZU38aEMxkdyXqMjv46YtGm2bIn2A28cfGdm1Idf5ImTiXvqZYm1t1s3nSQIG4QcQF8k8pVCoKzKaYJTEzj8DwAO0Hn0pHL+Z876y6mrqGyP0bbMDBWtbsTuli4P0U0h8SAwffaOgb68KejbyaqW48fbheUjROC2BBBHAyEcV+oRUpDyaSIFXPyj5VOjtEOld2BSmR9FqhJgSNn0QjopI2aPhT9CPhi5SllXnKRVygT1O2EawOPnQI1JiAt01pl9uE DwwAUkwl l01a3y9Wc++OoCs+nPLQGGAAB/HVndFYkVGRfETzf9xqXE878sqRd7bDCGJwiZ5dEINoPSPH4h98DmO4/NfDUEVSQBrFeQPZlG6cDqH2UNN1eRuTFkAJIFYrjV58TtrJDmxXuFHcLdx2WfbNnWEgjC3XhCBxA40XN9lao0cStfosMXxp2m1H41vkNbLdx4vFp9dr8XxoVu9foN9IEyb43LdfDPU8KQG7WzQ4rF+HsmeLQFjiXktJN1h9PHfTebfGu6VSfxMSOH8azFuQXph80+Nv8NayvOtkruP7qDXGI+B7xZ4kKLX9A4mQtrCL0IRByyHqmiJRBhEWlrgaTBMiOA00RnUyV1dNuIghDKGxlH18DFx4hgkMSWdttE2BO2yV6AsDcjLmvdLOJNjDKF8OxYN6Y8Q== 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 30-08-24 10:31:14, Barry Song wrote: > > > > Patch 4/4: We will move the order > 1 check from the current fast path > > > > to the slow path and extend > > > > the check of gfp_direct_reclaim flag also in the slow path. > > > > > > OK, let's have that go in now as well. > > Hi Michal and Vlastimil, > Could you please review the changes below before I send v4 for patch 4/4? > > 1. We should consolidate all warnings in one place. Currently, the order > 1 warning is > in the hotpath, while others are in less likely scenarios. Moving all warnings to the > slowpath will reduce the overhead for order > 1 and increase the visibility of other > warnings. > > 2. We currently have two warnings for order: one for order > 1 in the hotpath and another > for order > costly_order in the laziest path. I suggest standardizing on order > 1 since > it’s been in use for a long time. > > 3.I don't think we need to check for __GFP_NOWARN in this case. __GFP_NOWARN is > meant to suppress allocation failure reports, but here we're dealing with bug detection, not > allocation failures. > So I'd rather use WARN_ON_ONCE than WARN_ON_ONCE_GFP. > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index c81ee5662cc7..0d3dd679d0ab 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3033,12 +3033,6 @@ struct page *rmqueue(struct zone *preferred_zone, > { > struct page *page; > > - /* > - * We most definitely don't want callers attempting to > - * allocate greater than order-1 page units with __GFP_NOFAIL. > - */ > - WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); > - > if (likely(pcp_allowed_order(order))) { > page = rmqueue_pcplist(preferred_zone, zone, order, > migratetype, alloc_flags); > @@ -4174,6 +4168,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > struct alloc_context *ac) > { > bool can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM; > + bool nofail = gfp_mask & __GFP_DIRECT_RECLAIM; > bool can_compact = gfp_compaction_allowed(gfp_mask); > const bool costly_order = order > PAGE_ALLOC_COSTLY_ORDER; > struct page *page = NULL; > @@ -4187,6 +4182,25 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > unsigned int zonelist_iter_cookie; > int reserve_flags; > > + if (nofail) { > + /* > + * We most definitely don't want callers attempting to > + * allocate greater than order-1 page units with __GFP_NOFAIL. > + */ > + WARN_ON_ONCE(order > 1); > + /* > + * Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, > + * otherwise, we may result in lockup. > + */ > + WARN_ON_ONCE(!can_direct_reclaim); > + /* > + * PF_MEMALLOC request from this context is rather bizarre > + * because we cannot reclaim anything and only can loop waiting > + * for somebody to do a work for us. > + */ > + WARN_ON_ONCE(current->flags & PF_MEMALLOC); > + } Yes, this makes sense. Any reason you have not put that int the nofail branch below? > + > restart: > compaction_retries = 0; > no_progress_loops = 0; > @@ -4404,29 +4418,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > * Make sure that __GFP_NOFAIL request doesn't leak out and make sure > * we always retry > */ > - if (gfp_mask & __GFP_NOFAIL) { > + if (nofail) { > /* > - * All existing users of the __GFP_NOFAIL are blockable, so warn > - * of any new users that actually require GFP_NOWAIT > + * Lacking direct_reclaim we can't do anything to reclaim memory, > + * we disregard these unreasonable nofail requests and still > + * return NULL > */ > - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > + if (!can_direct_reclaim) > goto fail; > > - /* > - * PF_MEMALLOC request from this context is rather bizarre > - * because we cannot reclaim anything and only can loop waiting > - * for somebody to do a work for us > - */ > - WARN_ON_ONCE_GFP(current->flags & PF_MEMALLOC, gfp_mask); > - > - /* > - * non failing costly orders are a hard requirement which we > - * are not prepared for much so let's warn about these users > - * so that we can identify them and convert them to something > - * else. > - */ > - WARN_ON_ONCE_GFP(costly_order, gfp_mask); > - > /* > * Help non-failing allocations by giving some access to memory > * reserves normally used for high priority non-blocking > > > > > > > -- > > > Michal Hocko > > > SUSE Labs > > Thanks > Barry -- Michal Hocko SUSE Labs