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 A4D57CA0EC0 for ; Thu, 29 Aug 2024 21:28:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3ED576B0096; Thu, 29 Aug 2024 17:28:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 375456B0098; Thu, 29 Aug 2024 17:28:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EF5F6B0099; Thu, 29 Aug 2024 17:28:00 -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 F1BE86B0096 for ; Thu, 29 Aug 2024 17:27:59 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 99A4F121322 for ; Thu, 29 Aug 2024 21:27:59 +0000 (UTC) X-FDA: 82506570678.15.E5C1084 Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf11.hostedemail.com (Postfix) with ESMTP id CDB4C40025 for ; Thu, 29 Aug 2024 21:27:57 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="fT//C1QK"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724966811; a=rsa-sha256; cv=none; b=sxGWeuzCvu68XEfsG+alvGTljk3PXexRWa1iYgqtrxTVXzoGrUaaWurXaC6xmNt3tm4mn/ bcCRxwWZzctZb7mKhgTDPKUzdYRoQGNrj/DdHa98tUlnmaDUVaXifYU3S2VgYfgE9Ns3je 36FsIEjdx7F1/V3FKBTjW1UJlusDp/U= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="fT//C1QK"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724966811; 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=b74/nL6yM7DqQj6YIDRSkjEeKfBsodW/MeHd7rIt+PI=; b=S4LXPlo38xRuPd6St2Z7fWWkkGuM+nxEkkbyKlNji2lAaDdsQGo02hcsps6JmdzOeSL+Cr yyEdz+3hJZ9WXnvGYzcNkycuWA+ClmjtDD9x2OBUgzzvByA+Czq8GZ7vQ5DVw4YXDzcnBu YFdjp+G7lSxqmknE+z60f3HerosFmEM= Received: by mail-ua1-f41.google.com with SMTP id a1e0cc1a2514c-842efa905a5so329621241.0 for ; Thu, 29 Aug 2024 14:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724966877; x=1725571677; 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=b74/nL6yM7DqQj6YIDRSkjEeKfBsodW/MeHd7rIt+PI=; b=fT//C1QKyNi8LPiitMcQrUWaXWsH+Air16wxh5ITEALoLMFdU9RQJT4R1Mxd5eYug1 hyTDjCOVpC0gSbKRPNM6gHMs78m85DnVFXopviXeom9VmOeFgvYYkUNn2RNoAELD1soC jIDfYWBaZlOrypLEG1yrWvmse7TK8QZSc7v1mZdlFjqoVQeytcinsvFcrZdBPsEjV+XZ oKj1nQHuzrOw+Afl3yREqnmxKCOoKpl7C5VwwQ3Gqz2kWbDDHYL1NW7uM1RGVcS3ziqX gEqagYkhdCMpzbctddJfECGQGyzvw6JYjTUQZYSmXosvRxTJx9EasvUjOV8a/te9TBb1 zr1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724966877; x=1725571677; 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=b74/nL6yM7DqQj6YIDRSkjEeKfBsodW/MeHd7rIt+PI=; b=G2aIlY6GVXdpYWhRspZ9BihyJYGjan9+b0BWiIKA9SmmDUXymlXTNF/g6Nuu2vQK+5 CMSvCN/zzPeRJV8k/bKtUD06lZBN8nvtddJNaquUM01qaPng4S1MBC61RmdjGfGol+rJ 3ZXJ1hkOC/BSecEC2UUMhD2Z2cqvOSzNjlKPh3qDNp3PPeD6NeWFqlU2/cVNyBPdDyTV az9bsE8rGE9jp0r3ysWMpPSSGsiwN6ZG3gcvYklYkCls1zomvftdkAokhIWt1YuYU9NR BgLMHgfzi1IdiCwbzfj4FJQZMOFQI6Ig2DsawlF/RAEIe5cSH62/GUYl6DAXSkXO77Mu BrjQ== X-Forwarded-Encrypted: i=1; AJvYcCVYVBdbYv0EWgJVJkzY0O2BO/+luYWmEDthRr3wsmaaWC3iSzvBjpjMkbj7Ylv/4NoBbUEkrqR/QA==@kvack.org X-Gm-Message-State: AOJu0Yx5MASY6Om2Svr6A3hZyL7dFDI6E3mqp+AzDdZ1SLBs4hPyLDYV 3rvLkIH00X0JzDhhcqeH2qRmQqY9IeAZchGhfOJa/uRQiUTAfHQ+6rNTP9z3X1vFt28aBargM21 OZ08Zg1PvDMKfVUurOGY3aWvVsq4= X-Google-Smtp-Source: AGHT+IHFl75GTpZGRhFgVBJELmEX9X/2XagOVMq2pkrForU7wgZKEZm8rM3Zk7y1bShZr5WrMKfOlQpwnaSO7fbHhbY= X-Received: by 2002:a05:6102:c92:b0:48f:cb62:231a with SMTP id ada2fe7eead31-49a5b1a85ffmr4651130137.23.1724966876680; Thu, 29 Aug 2024 14:27:56 -0700 (PDT) MIME-Version: 1.0 References: <59e90825-4efa-4384-8286-06c0235304dc@redhat.com> <2663352f-ecef-4e5b-bee5-e31d2b286c63@suse.cz> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 30 Aug 2024 09:27:45 +1200 Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Michal Hocko Cc: Vlastimil Babka , Linus Torvalds , David Hildenbrand , Yafang Shao , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev, "linux-hardening@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CDB4C40025 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: pf391w7thufnhhrc41ocru9sgtaac77c X-HE-Tag: 1724966877-596848 X-HE-Meta: U2FsdGVkX1/aBlHTlrAQfhEHG3SFyEBa3vl8+sUAqwM8S1JV2UwNX2wRbkYBAsgvS1KiovRgiB+af1tzmBc+7kHIIv/MStQluMjeeQZHtvDzAxuaj2K/ryONLgkPHLkbUskK9cjKCYzco1Voj18uDsay42yMdc4Vbj3Vb9AwgW6SP9Fb3OGLBmuesDiYUuX1Dy/AKkVfJUmxGRRsqcbkrdTsQceaIinMgMtxA+CllOZFfnkhy5TIXwqsUJOcsyNQ9iI+zOWzGtWBjBvnhxxtwiQbIckprh2g1RitOV6lQXMjQr10Q/yOdqU+90QOStUrrHiKzEzQiE3aXod0Exoa2wuo6EWNJbOzgiVALRSIYByljuJHXy6J2T+eoD/hb3qsRQMDli71ZSTYkMlGdx35y9hM+jZjjg7H7ocrLGkzmwMffevRPGG0/Ba/bDR5JcjbOCmys/igUkQAGX63j/JA3G52kg2u9bshOq/5Y00/sGVLK/2WELObJcybT0L/RmvhdHf3rlIYiQ4C1jGRIneC/iAk7hZhutPHMN3KKSG6v6VvfgyPOkKbpIWnsIEeZcKnBYz+6EtN2cJJ0qvtwN06r7IqOTkk8xXK5yKX5kp16XLK6LinK3wxj6VmfLej8K9ntaiMTF2sthsY+r0/Hwgt1GgiOQI3vj9KcJw3U4oxDMdrWpJKN79TfkeuDxjEYZsfeqAHBWy1SaK46FcGLoPCt08t14Lzv4XoFQScBt855JwsCTOTT/GHoqAMM71eEiSmgYD0ahv4V/hAXVFsiD1/ymNtNGDnFq+nvNPEqMEY3/ZiyIJAUA/K4fwZEUfiS0mCQv0KDp5TbIIxKMDY+8jAD9f0ZgsyNiGhAb4DlxxLYi1+CLpEIQqBHyXhwdJjyQ67k495J8k2oPCkVTf52REBYyFbmNBMg6tJX8cRUZ665cO8jRb4lHiOeHSAdDVEDQG8l5dzVmYkFG/eCdG6uix M2SaS6/d uT0jzwp7kGs0lH2Yos5f3NiSQuv97xBRENHjJcyi5Qtrlx0/otsXmx6ZwnRaq/shIGe7BLwxKyM2L9Vp0Lpcd897ieD71pI1/4u3RwFpAl5FpQdRiA9b3+swZfmWp08QO01xtAHR6gwNKWO2VrpkrSp8w++vNOGGGteqdQTOh6rcMGzm2ACF47vYKvymum8p1bnQfU5cshJYSwb2b46tv6lRT0TtqV4y29Ay5Z1HfpZFM/xaA7niW3RlcFO6k19NsBvjPXnsq8hyBbfLgB6YoJ5yJ8OBTILaMjwmBRm1sHZKNhm7j+CaP7Qc+vNlDGhqyZTEZf3O1yis6RE7DTbZFKCdlQ7fdIcgKY8T5PHISyjE9tXvBetbFA8kdeA159vhKSFPigz578qbS7+Q7v1Mzy1RGcZsBfQvlvnfpJ9XL+sW10TiuhRw3Sl76BAZq8NUP1NK8/Z1KaMtGxbnwgLT8H5XPwlS8VFCdHMKhJOzwQbvDyseA6WqRNz6LyQ== 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, Aug 30, 2024 at 1:20=E2=80=AFAM Michal Hocko wrot= e: > > On Thu 29-08-24 23:53:33, Barry Song wrote: > > On Thu, Aug 29, 2024 at 10:24=E2=80=AFPM Vlastimil Babka wrote: > > > > > > On 8/27/24 09:50, Barry Song wrote: > > > > On Tue, Aug 27, 2024 at 7:38=E2=80=AFPM Vlastimil Babka wrote: > > > >> > > > >> > > > >> Ugh, wasn't aware, well spotted. So it means there at least should= n't be > > > >> existing users of __GFP_NOFAIL with order > 1 :) > > > >> > > > >> But also the check is in the hotpath, even before trying the pcpli= sts, so we > > > >> could move it to __alloc_pages_slowpath() while extending it? > > > > > > > > Agreed. I don't think it is reasonable to check the order and flags= in > > > > two different places especially rmqueue() has already had > > > > gfp_flags & __GFP_NOFAIL operation and order > 1 > > > > overhead. > > > > > > > > We can at least extend the current check to make some improvement > > > > though I still believe Michal's suggestion of implementing OOPS_ON = is a > > > > better approach to pursue, as it doesn't crash the entire system > > > > while ensuring the problematic process is terminated. > > > > > > Linus made clear it's not a mm concern. If e.g. hardening people want= to > > > pursuit that instead, they can. > > > > > > BTW I think BUG_ON already works like this, if possible only the call= ing > > > process is terminated. panic happens in case of being in a irq contex= t, or > > > > you are right. This is a detail I overlooked in the last discussion. > > BUG_ON has already been exactly the case to only terminate the bad > > process if it can > > (panic_on_oops=3DN and not in irq context). > > Are you sure about that? Maybe x86 implementation treats BUG as oops but > is this what that does on all arches? BUG() has historically meant stop > everything and die and I am not really sure when that would have > changed TBH. My ARM64 machine also only terminates the bad process by BUG_ON() if we are not in irq and we don't set panic_on_oops. I guess it depends on HAVE_ARCH_BUG? if arch has no BUG(), BUG() will be just a panic ? #ifndef HAVE_ARCH_BUG #define BUG() do { \ printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func_= _); \ barrier_before_unreachable(); \ panic("BUG!"); \ } while (0) #endif I assume it is equally difficult to implement OOPS_ON() if arch lacks HAVE_ARCH_BUG ? "grep" shows the most mainstream archs have their own HAVE_ARCH_BUG: $ git grep HAVE_ARCH_BUG arch/alpha/include/asm/bug.h:#define HAVE_ARCH_BUG arch/arc/include/asm/bug.h:#define HAVE_ARCH_BUG arch/arm/include/asm/bug.h:#define HAVE_ARCH_BUG arch/arm64/include/asm/bug.h:#define HAVE_ARCH_BUG arch/csky/include/asm/bug.h:#define HAVE_ARCH_BUG arch/loongarch/include/asm/bug.h:#define HAVE_ARCH_BUG arch/m68k/include/asm/bug.h:#define HAVE_ARCH_BUG arch/mips/include/asm/bug.h:#define HAVE_ARCH_BUG arch/mips/include/asm/bug.h:#define HAVE_ARCH_BUG_ON arch/parisc/include/asm/bug.h:#define HAVE_ARCH_BUG arch/powerpc/include/asm/bug.h:#define HAVE_ARCH_BUG arch/powerpc/include/asm/bug.h:#define HAVE_ARCH_BUG_ON arch/riscv/include/asm/bug.h:#define HAVE_ARCH_BUG arch/s390/include/asm/bug.h:#define HAVE_ARCH_BUG arch/sh/include/asm/bug.h:#define HAVE_ARCH_BUG arch/sparc/include/asm/bug.h:#define HAVE_ARCH_BUG arch/x86/include/asm/bug.h:#define HAVE_ARCH_BUG > > > > due to panic_on_oops. Which the security people are setting to 1 anyw= ay and > > > OOPS_ON would have to observe it too. So AFAICS the only difference f= rom > > > BUG_ON would be not panic in the irq context, if panic_on_oops isn't = set. > > > > right. > > > > > (as for "no mm locks held" I think it's already satisfied at the poin= ts we > > > check for __GFP_NOFAIL). > > > > Let me summarize the discussion: > > > > Patch 1/4, which fixes the misuse of combining gfp_nofail and atomic > > in vdpa driver, is necessary. > > Patch 2/4, which updates the documentation to clarify that > > non-blockable gfp_nofail is not > > supported, is needed. > > Let's please have those merged now. > > > Patch 3/4: We will replace BUG_ON with WARN_ON_ONCE to warn when the > > size is too large, > > where gfp_nofail will return NULL. > > > I would pull this one out for a separate discussion. We should really > define what the too large really means and INT_MAX etc. is not it at > all. make sense. > > > 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. > > -- > Michal Hocko > SUSE Labs Thanks Barry