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 D6ADEC83F16 for ; Thu, 29 Aug 2024 13:20:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F5BE6B0085; Thu, 29 Aug 2024 09:20:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57EF56B0088; Thu, 29 Aug 2024 09:20:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D0F96B0089; Thu, 29 Aug 2024 09:20:26 -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 1B6C76B0085 for ; Thu, 29 Aug 2024 09:20:26 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B1C53120E91 for ; Thu, 29 Aug 2024 13:20:25 +0000 (UTC) X-FDA: 82505342010.03.FDBC70E Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf06.hostedemail.com (Postfix) with ESMTP id 7166A180023 for ; Thu, 29 Aug 2024 13:20:23 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=DQFADXN0; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724937551; a=rsa-sha256; cv=none; b=dVLfHPeG8Re7ovgDAX/dMNGfriDfzoJ0ictOiODg9vfr1GjxJ7wRjADVlDGjai5JntDXzH i9TrCI0gvTRO5iynBxl7WPCSHDHtv+6Jg3ofTmZHr/Q+8uKgxD0Df47Re/SGxXhKDhBAa0 XKcMb9Q6uw3r18DTF6LkjfnKNxJNSzc= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=DQFADXN0; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724937551; 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=TO8oarX08QKeq0s+M0Wyl/wzcfkTIbZOOC4bUyVHle4=; b=VYcwchKyyGoV3c0sKo9qmBXMERhfWJu0Gy0Fv+VoKOw3/qG8zhWqEgvxWDcOYZjRPtCm/C sY8sFpU4h4O/W3lDAcJMZTqMwTh2Mct/YtH9/uajfkHohGO6SkaZvYGwe+Qmy/M0WBIeHj PVDoqHbe9KBWCYVc8UQwAqOedg3cUUg= Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4281d812d3eso7420875e9.3 for ; Thu, 29 Aug 2024 06:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724937622; x=1725542422; 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=TO8oarX08QKeq0s+M0Wyl/wzcfkTIbZOOC4bUyVHle4=; b=DQFADXN0p1ZPquARsXb2uQCdvnYFSdislbehDRdJD0nFK0Hc6Z2oMRbjLogxEtopB5 RYuhyLpkJqO4M0X24wMYoGReS6LZKSwqhJumf+vnXJgy2ZWH7hKTj1Od1QxNMrWqc+/f MXkkIvHBX52vPFKG/M0NQgqzBiDiV5UsRhbsRjD2vd4lRJMRsujFel23CK/gdJ4FSoOk 6Nb31EgWG7tcGbGJFX+hvLxao1NrSZa6UC35btazL+iDdabdS3SmuTrNhk2x8/uvvQKW pE/NnVoEIVjTT2Y8a7uZKyiQtIi7lfYuXbxnYI7VxHkZ07YVsU59y71YuoZuSx4N+YEy zNUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724937622; x=1725542422; 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=TO8oarX08QKeq0s+M0Wyl/wzcfkTIbZOOC4bUyVHle4=; b=vM9I/Ph3i0rNHpCpUU6LQ5Ub/siaNUGFJCCJ9/ll0sAQlzKe2JmEnjclOxxEGHh8Ce X2T/L3EyCHrnuB+uovPHG1f4W8kmZ+edyCdh54ck2RdgC+HXt20p9cyUZADO6O/tdYJS 97Zd+tyb6CCMdNy1KHvO0zv2E00unHEAUemOgQd2Br2oW5cSxKigqR37EGD6GernpfZj 4tesWqwgluLqWs5OBnnwHTXzX4lGalJozcSLcOG/KxLBZQrWvYTLnRFEyOlfZVrEMn1k so7X8bWfxjU31QRDopRwzrp69xrgjiWs6Aug/wvnMTpnpbqam0GMlaUO2m6l3ta5EBhb H4Qw== X-Forwarded-Encrypted: i=1; AJvYcCXLjZieJRajmfvgsB/iDDTfrbev7VyQw6MfTsNTzkty+Ac/1TWD6Ca+fhMj9dACPRzIjacH75Xj+A==@kvack.org X-Gm-Message-State: AOJu0YyAtrqHp7mqLmfBaFA1pnvpuuW2KJ+xRukXVZZx8jbE4EdtBmVu QJqnJt/z/3eeOxx6NQZE1f1Yg+ukcPzkuzNkgcxBJqfa773hkIvg0MyRzO77L+4= X-Google-Smtp-Source: AGHT+IFG5xKEi8ZsOnVw2Jz8XiZur7+Fa4YTw3Tr8fXJGmRY/H10RnF1p8PnSg6TzvPizLMIX/pOhQ== X-Received: by 2002:a05:6000:1085:b0:368:6596:edba with SMTP id ffacd0b85a97d-3749b57ae21mr2302313f8f.39.1724937621686; Thu, 29 Aug 2024 06:20:21 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bb6df9705sm17293945e9.27.2024.08.29.06.20.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 06:20:21 -0700 (PDT) Date: Thu, 29 Aug 2024 15:20:20 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> 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" Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation Message-ID: References: <59e90825-4efa-4384-8286-06c0235304dc@redhat.com> <2663352f-ecef-4e5b-bee5-e31d2b286c63@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7166A180023 X-Stat-Signature: igtmaa5q5wrn8r78bekckxkeeem7qfdh X-Rspam-User: X-HE-Tag: 1724937623-463485 X-HE-Meta: U2FsdGVkX188VWDrJIBWKSF3ZUcFxqIHRd2CHmXnoHl5WCDSDyqSLQCt0m5HaF/remRWnQRsOCpDgnwnWui8tDulh8kEdUHafabMnHZXKTOwxixaKAzjGhHrxCVeWGGRqsAhcFFqv2stvqZ783Cva0Vpl1VIxJouhTJ2h5bm3oAQGBT0aQ8vcMMsRG8KB3RyNUFHkuxX0tVichMUDjekY8QZthQkeMz+HeHwX3i9XAn5pIp0d/oxNk14l2yWDMNhh82M7tXkBr2MmUuCJtJRn+NrSg/DkP6CrBqYdq3QOC0QHtjn36c55+k1PPBv0HPGegMg7KWQUkA1aKlD4Ebp/VzpvZZChasqRlcvGrOiD3VZlsIv0TzmNIYzRZv+BTp8rOrO4+ZkMndVwcGn4VKsuscKDen6NXBNW9PD13mwdkpDUYijJkK7UTxPF8j76EN2FZKDMm5RkyItzBGrk4eiBDZ6yWXskJBfInLcT5dPH5fl6y+Iv4kNc5Qs96SrqRtFjQIlqeLY8U+z7YRqMs1ZhPW0ejdxT95j+/x8NmDB9tYAuIJmcVz2OBMuZwwOOR6dFz9eNbSMqDCpPOhP6A1DQHdorHUDjWfeEt2t5GDSo4vij0+qJvhmBxMOLQsw4LbShDioqYEhVD5PArg1EK71mRx2kEpioNo/CNx2d6+OaqrBmVNV4hcUqEJch8O7gceJWMc0t7XUjZg6obB9sPUqkwGOn/+HoIwwuB89UFoF/fiOnRF6hZH0oAYdDLXcX96KKYTwckKYQJ6EzYXxyHv/9ROnVs9myL6SIkXmNvq03fHen6/+Db6sjwesN6aAagxOgNNgbncG7pVAxLQEecUHNN6BcDVBmEs5yfVt4xkc6j3Rr57xuigslTBA+Hu8T2SHzgAfQQMy8S8x7bUxrAlVlnZ+5QJvHQwhixtlP+Tz+EVQTP/4Qagj0x/DmesKpyQrkMUtbdr75ZFc1NZbrhw 2W9J6w78 YA0GqceMHvdiK5eWWGYeX6hRwOSWx1oDE7s9qOqBmJ9R+QdQ0TRqBrIleKchHb8hkiv9N79ZHkwfmPPGB5D2jBXdmIc2wOMkVP3jko/X55Hd5/aK5Wth4M5gdQf03pQrLaLUq3tkbEIQtxWuLZGsudELGmJoulXZ462cJrJBIW6Da+dvDbxrRkQVqUxifhNy9YrxOVW8jGepmk3Z/vJU8JYcu+JedRlF5FuCpLfmFMinNEYtUPOZ8yrB1yeYh9c8eO5rPORCmSvGY8tVUnKw3L2L5LSbBb/zjFS4HY0XC+wgF6Cphu3Yr/SAWVkL/Xa4Js2dnVN7UNdkYrNCvYkDuSgOagir19OXL9KEAvXIvrWGmvIg4gMJq9pBQwVw2UaKCtSpwYaV3XMXrfg+rs543ev/Pp85UUW4fJ8X65AWWsgHUWzg= 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 29-08-24 23:53:33, Barry Song wrote: > On Thu, Aug 29, 2024 at 10:24 PM Vlastimil Babka wrote: > > > > On 8/27/24 09:50, Barry Song wrote: > > > On Tue, Aug 27, 2024 at 7:38 PM 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, 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=N 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. > > due to panic_on_oops. Which the security people are setting to 1 anyway and > > 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 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. > 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