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 EB41BCA0EC7 for ; Thu, 29 Aug 2024 22:31:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EA9A6B0082; Thu, 29 Aug 2024 18:31:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 773966B0088; Thu, 29 Aug 2024 18:31:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C5EF6B0089; Thu, 29 Aug 2024 18:31:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 398C96B0082 for ; Thu, 29 Aug 2024 18:31:29 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D6C061609CD for ; Thu, 29 Aug 2024 22:31:28 +0000 (UTC) X-FDA: 82506730656.14.8CC77A7 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf18.hostedemail.com (Postfix) with ESMTP id E9EA71C000F for ; Thu, 29 Aug 2024 22:31:26 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TQhKeErb; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.181 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=1724970597; 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=vw046BlQwqp0kheY735NpnzKZV77Hf8iJa45ZBjddEo=; b=Ia1JvaSrFL34roiFuAGvkaPdLybpTVT1dR1bMzW6BiN2azgCAz0Bxp1fIP7MmpnLybO9ZY dT2iklXSip3hVOL1NGh/ZCRovLvS3YpA09wR513R4CuNZSdBQ6QDKGy6p0KS/Wujp7C0+l aPs2WFtJhFUydGASP+Jyj6icw2wGnSc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724970597; a=rsa-sha256; cv=none; b=8DAbZW9uHVs+3lvDs9Z3DwVx3IrvdEDFbj8UpSNiuzR3NDZegd40M2aGW0hT4GpPBhXV7/ cyIIzl3lGX2prkV+cViCUhVs6KNK5juS9q6r1YWScTsQ8BzzWdzaihYkvlXoSaFjYRE7x4 GEX5C+WWRyIC8zQWwSz9k/sfSaSEUAc= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TQhKeErb; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-715cdc7a153so970237b3a.0 for ; Thu, 29 Aug 2024 15:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724970686; x=1725575486; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vw046BlQwqp0kheY735NpnzKZV77Hf8iJa45ZBjddEo=; b=TQhKeErbDLhF6Ff/+xhV9CKy1Yx1wMuI55ja6ZgP9SxQpB29PyCpwgIc8CKgvTEl11 jxrSoWZQqSVyjcdhhcOw7atSJBdb415Xft3jYFt4vJ84FTsX1NuTmfKSzm4hvCLCuzCd PnfTyqp1qo7XbIrAnfZ3BNdTQUvLpSIypTE9uOQioCGiBTbpMKIFZkwP4gN/8Yy1fpiq T5kIOfU18M03JIttLDQ9vRU1fnUJxmAC/Ce3HzZbWxiKN7UGAylSmm8T55fDueNKIuDw tsKJqnIFt2GHFdLRQpXh0NKg3QgeHQwRRcWvDMI7iaVGuvXpsUMwv59pVaKTrH4w363A Nb4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724970686; x=1725575486; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vw046BlQwqp0kheY735NpnzKZV77Hf8iJa45ZBjddEo=; b=gD++bVfSjle3V9yfW2HeAK/57WfvHUeDCUyEFTPaMXN1WjniJMxw61c2jzdSS7tRMJ itUSyVVFMWPDm9ulEw+j4Rq6hzfUZgkghGkLaLmgft33FsiLtNcUXLAyqs1ddydDApCv HvSoHjY3WDZJJR6xBzhHq1p/GAL0bTgaQv8spmqdH74eoG+v4LKuUEHHvNW6v0Ibsd4/ uqMABqcgSXf2gMMUYSeOg2J8ArCPK2O/0ZZmcjDjhucik+IqGYbc6o1mCHPt689Zku2c mPTz0CXVMEcZzonSxu8n1flPMBcOSv8Yjn3psI2059zR3iG0uV1U73wl7/i3YCEsUBB/ ax/w== X-Forwarded-Encrypted: i=1; AJvYcCUjXwNkvJtXZBwyCga5anFJiYqvXDBOOuE6luIydzxa32GL7QKsoDEEzoAR69nUko9V3JNKwR1rLw==@kvack.org X-Gm-Message-State: AOJu0YyTJFswxpcqyCyk380rcJvs64k1V4DFyE3qiKO6WvTS04UzYk3q jiWn+O4KQ6PhCe67o7mjr+knWL41Lgal5whj959zuj6JN8zQDoUe X-Google-Smtp-Source: AGHT+IFhau0GMb2+jI99unqrHoqo79ZPnsK5Fim1Ct1lLVzqOoXbfgd/rqPMQHsW9L0qYnI9rWHF1w== X-Received: by 2002:aa7:8650:0:b0:70e:cf99:adc7 with SMTP id d2e1a72fcca58-715e0f74250mr5263419b3a.3.1724970685474; Thu, 29 Aug 2024 15:31:25 -0700 (PDT) Received: from Barrys-MBP.hub ([2407:7000:8942:5500:b087:5dce:99f9:294b]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-715e569f1edsm1614198b3a.128.2024.08.29.15.31.18 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 29 Aug 2024 15:31:25 -0700 (PDT) From: Barry Song <21cnbao@gmail.com> To: 21cnbao@gmail.com, mhocko@suse.com, vbabka@suse.cz Cc: 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 Date: Fri, 30 Aug 2024 10:31:14 +1200 Message-Id: <20240829223114.1102-1-21cnbao@gmail.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E9EA71C000F X-Stat-Signature: ao7uf84fswrwrw3rzj1hwzb1bhrmp9m9 X-HE-Tag: 1724970686-446497 X-HE-Meta: U2FsdGVkX1+qM+9weo1dB2AAqAq7HbilOrdNQRj0kUkkIVnZd2E85/WDSUZXqu+SoIN6Ex0aK3uI3e4UFSiNlOUJpMl6F2qSFK2oS2zY54KUQr5f0kcKcRD6S4wABexVpCk3EOcHbGNzeQYPrFqKbYZjVJjgVZnGhttZdJIsRkmcOJE6Ihd6SQN/OZjiWZXvgn6hOo6VjNeRZVxVHb2Oy4bOQQlHzzyMN1IUOLgpk5Qd56SBVtQNH4N/wYZMYOvz69FWZ0jtlYHkBrLKJ4YmcY9eVlyouBZaRHI2QAsbHDg17wvMc29PLFsw9yDrFdkP9vA1HqDZTE78gxcOlkNhH4QBKpi6P6PC8KC9CAYneGxsYrfox/ZI6CLRJQnJim1gBxL0dXLQK9HHTl3U/buLXWUn5yCc9Sv3pmvOng4yHdshYSSgiUxoM0RGVvXFFzLNXsiiccp3ZBajXQZV7cf2WE7bDa8QXJNW6sapWJA3Vu7xbNEKQmwxYs6XM5/M9uHp66g37UcnVIi3x7hm/E1tAxp/3LByGO9Qya4FZ9TolHp6Bs0HOAxI7NzghAU5PU+ej1bSSNGIN9H6+yA/tRjubPn+aVMrtojVXS5O2O2o9eZaCTI93gVeVonb/tl7xeEt/Mhh9hLCnIvf2rH4cYk8g3DVksuBBl8YUGgHVxRG75fZcOirql3x7lTVanjKv/kJuqKLd7G7DA4WLY7Ua4bh6Z3HUJp+IYN96KzIfP+amzatuRB/50iIObsK57tCfCc1T++bO5RXQSs5wbQsIJ4dh7ndE0ukg3V9U9D2OLSht5Tz2RtzONy8FpnuT0dAGFt52ZGS1df3sz2u2xDtTy4jJzoS6JDQhMfvOMabghid1mIysh923rVxdM/YQlq4xb7p2FNguSl04NJdDkZ4TJ1WAhcXuN5biCUBci0Jttda6Y+AKF2o8vb+dpL+i8Ek6CJ1MzEedFS0xaCDW2tMfaO jhOifVr2 zR9yLqSDRJzLgrSPF6/acCu9eV2HUG6glBi1uDwo5m4XH6Ag03py1Incw39UybTMwsBNGtCdXe1Qur3xPEuxLeSTcGrfo7uvvlCkusrgocwP6kqp3YO71/fHWG8KcaKY4EtEf/egqQd72+0YcWUJBVaRqqlNko2PVSZ8xZD7UagtocH3jtbPZivoIHp8kCnb1T9O+CBtBBAQMsZYlafRX3gopmBlgaSJe8D+LgL+5DZGRfo6218dKnTkfW0qb7QlePb8WePbaRG+5pMnB48GnzRWJ87S+p1mMP3w9MN1CTHzLRhvL06oSmbt63i8OFV+5srpu4EANMImw/GaG1qrkx77WoiBDQRTQaMZ70ONyOu2Z9emXiVcLaurJHJQZ57XJMChU4peeyaSthwfIDbvzjU8pylL/p8WMsI0IfiOIDs77/icCPZyWMBgntxLHFAlt89Wc8kaliszgHH9L3mu+DYl5KlcFYSLdfISn 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: > > > 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); + } + 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