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 0D043C83F07 for ; Thu, 29 Aug 2024 11:53:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 875716B0085; Thu, 29 Aug 2024 07:53:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 825286B0088; Thu, 29 Aug 2024 07:53:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C65E6B0089; Thu, 29 Aug 2024 07:53:48 -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 4EDC26B0085 for ; Thu, 29 Aug 2024 07:53:48 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E2D9C1C538A for ; Thu, 29 Aug 2024 11:53:47 +0000 (UTC) X-FDA: 82505123694.30.6359985 Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by imf28.hostedemail.com (Postfix) with ESMTP id 01843C001C for ; Thu, 29 Aug 2024 11:53:45 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NJsAIsCF; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.51 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=1724932405; 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=u8n1UFj1Q+wM5iePo02UkDVC+29Y7BUbYM34gTWJxTE=; b=4KoLaS5UJvicBnk7wl+TrxCYth980vxfta3n35PsEdgWfQ7darVQKO9gHEFJtBIDm1cVDb JW2+GyYnAYz9oytHNsN/5VmTGxBQDCoNY117oU3F6X42CKARFn5RExuf2alE2vA7wApwU7 pErp2OVjciV/g7zat8fX0OHomdmV6co= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NJsAIsCF; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.51 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=1724932405; a=rsa-sha256; cv=none; b=xSQ7a6OaHcEtgMA43sXeJxBQhmK+nb9C+Upp1fKtyWRGqb2OFufzKe8eXY/UCk47xyUiAV O1x7mAylI0IcpyWBsGarujZBRpkOgfUTBoniT6gdHEiNdlITIZHWJYkCAr6Wb3x9NIpYJn a65M60Xt0zJN/aDE4J8vc126CX75cT8= Received: by mail-vs1-f51.google.com with SMTP id ada2fe7eead31-498c4d5a912so248528137.2 for ; Thu, 29 Aug 2024 04:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724932425; x=1725537225; 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=u8n1UFj1Q+wM5iePo02UkDVC+29Y7BUbYM34gTWJxTE=; b=NJsAIsCF7NM3NdnAS3KccnuYaU/1NuIadkSvIMD+RqY76b1ixe+ygk7JeAL811bvLk 4rWpYkeL4WMx9dqkxf7Ofj78H72lr1QhdSwKEtADbceWbdOJxJYrE/vNxysZUJ68eKUd HtKeGabpA1lq65ZPxd/QhvUM8Dzjk5oC9QugvaLTPJfeSGKiaSH53FoWIQ95aBdsYbyM E8Ec2VkIlqfxWhI3t1ZoUUCZcP6GsXO+9v1dJdWBRr9ZJmTqNkFcrZYItLuprTCZFYCY q7o0GMOWaDKzTwM7qlzVhybDYXcWT5u+vT57JwrvsXWkQl9RklAQWdB80lyJElu4PUpz S/LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724932425; x=1725537225; 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=u8n1UFj1Q+wM5iePo02UkDVC+29Y7BUbYM34gTWJxTE=; b=Tomk7abpl4PiiY1aRLcjqt1WM83innhMuTxv/PBiihakRyt3NkCYCHrOVDCUUICkW4 Iat82OXIPg1dLrx61MkVaaq5QS6hoh3+N0H+i1Yn2cdLhZC8gOhYW4JtRCkSx5gIrh+G sitc+Ss5tE9JMxVDwQgEZd6yPITFNweCI0KJcVxvGQe20TZaqqrBwplmnyP1/WeJZxYk 404dbjYQOaCukidCB9IVsYhPU4+0RHL7dhli5kOydvRZNQotmLRiSJs7XIFmPYMMAtPd GoiII3NT+LGgtWea8wzWa9THNjIUMD3lllKlG8Ni/WjxMZsSYdTIMwI1tk9XfUeapx+L FXVw== X-Forwarded-Encrypted: i=1; AJvYcCVwPDkOYgLXUwzFQA3UG62HbdKHKHm70cOdhVF4RxXF5mk7ecgGuM8pgRXHMfL77fgIroN8IGUTMQ==@kvack.org X-Gm-Message-State: AOJu0YyLsG3QG9eaZs5OXnKdl8OaDNEhWZ5nAMHv/iW8HK7UQv5A7TcE UvZQq/aSqCbJegwIa7ueB68H9QwgbC2ntffKJ/DOzoZd/aob0eEEuf2zeraT4NScH0rklYEL8jc H+xS5rrQT8tTPjsa4YGj13dOioIg= X-Google-Smtp-Source: AGHT+IFRqcSUwe4ES9Z3J6iwBOoWu0IKyMK1mGG/uCxzyYADeSDjgNDnl/+yRGY4XWsjM+0Q8viLj81bGzymvDCeYqw= X-Received: by 2002:a05:6102:50a:b0:498:d3b7:be39 with SMTP id ada2fe7eead31-49a5af7bae1mr2287830137.29.1724932424886; Thu, 29 Aug 2024 04:53:44 -0700 (PDT) MIME-Version: 1.0 References: <59e90825-4efa-4384-8286-06c0235304dc@redhat.com> <2663352f-ecef-4e5b-bee5-e31d2b286c63@suse.cz> In-Reply-To: <2663352f-ecef-4e5b-bee5-e31d2b286c63@suse.cz> From: Barry Song <21cnbao@gmail.com> Date: Thu, 29 Aug 2024 23:53:33 +1200 Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Vlastimil Babka Cc: Linus Torvalds , David Hildenbrand , Michal Hocko , 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-Rspam-User: X-Stat-Signature: fwr5kd91qnf97ey36z7pkkb71aiwuc71 X-Rspamd-Queue-Id: 01843C001C X-Rspamd-Server: rspam11 X-HE-Tag: 1724932425-494409 X-HE-Meta: U2FsdGVkX1+wZQmviJbbhKsthcjzQoBPfiSkRHLXvIrB9KvgdSNkQikJKSFwu6JuvcaIsywZURT9Y4TDjzBUkTKFZ2uUxhUbGg1fuctNlKL88SajhuRYoK2J0ahzBFRK3IE+auwLpZZL/i6AQ9fbrSHbPBMThb90E+9DT+HX+RNNY9QRQ+NQMNLLhqlJr5JYMCnnOQZoPmOVeWB6Q22K7rnOkcdpLoGFuQMPf9kn8GqoOkbOPfqttDKcxcsuuCZbIw4aS794FouQ8JkzEOIZDI8j/7BV2sNDjey906mLw3y7FjX8LaQ2hO65Sx6wxxN0Nnb2gexMbEZLwoAoA3D1NW587RFNPY8/W4gmW/X1gDvU4GeH9UNOrl2nCHvqpwJkyEu6jep42vT8q27GR1YWGa9RQESgzE8uKJi+fnfnYde7cMTqzVzwNYnfrUeCJnCiv5Upgv/ploBEzy2EnNa1WfznSmeIujnja8D5oAd0HVys/I+gxsywsvaSG3sQPAJJz8tXUjvyhJJMaYgoTf0eQkCjrHTcERmwjsNpLO+9qqyGmuih0pdIYXUbJhslbbmjEoar5J3vdYsBSBBZKktDM4JTjKbMHj0b9FXXo07fSflgMjhUTBmKPbUV4Fqr1hMESCoX4v1ndJUlUVwz7aOxocs1+k5YV5a4dGGBy6V4JpVVYNS09FiGsqNGrqpNPIGYXwvyjLe4D5evgPgGFgmkGn4wae9MaqPtJq+XkylMHxqaYCCBTDAnmk0u2KUWr6JYKZmJF70qciEsmITOJIp8Cs1dWvbg5FXQ+Fn+uz6U338gskyN6fCubrsVUfv1PJZj8eULLs598zvLL2EpfHu9qkN8atUcl/tGeQF0YqQ1MqsAEO6lquwtX3ywzwRMS+EafMGV1A7fj5Ue4L1qY2LePa4qmhKoNiD9yyOX7mYlkZLtvSFPX2sQrStbgN0/xTNgl+wvgz2aA1z9jQ0FeFo hLDgwIyd prej0azLNQqPvgmmfwj/21RJMz54aYwTjz5bT55Et7WJOScmhfW1tgKWWxIlpzEdXNmGzQBtqWyrU/+Plg2Qt3s/VM82xHuhNL6Xf+ggQTMW9m7fiaEGzLiNcH/FmScMMdEwX3iyQHEo5UA8Udsets8WMt67ElY9eq2UxiL1hkLjZYYpW9UzJLRGpvRhMnsxhpx7Q1v1TC1xWNU0jmAEPHYwuyH3fFERwGve7x33ZbDxIgWE7WNOD6T8R/s0PAbj65IAUUH3Ej7+jwz1WCVb8Htk8isezMmgXXO9FrI0FHIBbhNdQX6SFr54GoasUPkQivzQKelTI9j3mw46M/gXofqdWipeXhpFcRJDeL/HYLrjdScmL5lMUdAobQKGAFRpLU0rVATSfmLTmMW3KBHZ5WCmZKdWcWldateZF 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 Thu, Aug 29, 2024 at 10:24=E2=80=AFPM Vlastimil Babka w= rote: > > 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 shouldn't = be > >> existing users of __GFP_NOFAIL with order > 1 :) > >> > >> But also the check is in the hotpath, even before trying the pcplists,= 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 calling > process is terminated. panic happens in case of being in a irq context, o= r 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). > due to panic_on_oops. Which the security people are setting to 1 anyway a= nd > OOPS_ON would have to observe it too. So AFAICS the only difference from > 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 points w= e > 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. 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. 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= . If nobody has an objection, I will prepare v4 as above. Thanks Barry