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 823BEC5320E for ; Mon, 19 Aug 2024 09:46:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19F326B0082; Mon, 19 Aug 2024 05:46:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14FAB6B0085; Mon, 19 Aug 2024 05:46:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 016796B008A; Mon, 19 Aug 2024 05:46:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D1B926B0082 for ; Mon, 19 Aug 2024 05:46:12 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5214BA0104 for ; Mon, 19 Aug 2024 09:46:12 +0000 (UTC) X-FDA: 82468514184.28.E7ADC73 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf03.hostedemail.com (Postfix) with ESMTP id 90CD420004 for ; Mon, 19 Aug 2024 09:46:10 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JW87gVmy; spf=pass (imf03.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=laoar.shao@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=1724060667; 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=KXCBzcxXQZDKDh5jvG0krAECq5GkrwQb/bMSCsqxdTg=; b=JGvQyh4lsp3rRyYpJPhjbR4ExZ/Y2mBIOLpUzDXpz7JwOoAQ13i+FSvUMQZgwREjw3EZwe hGwU6TvyeBsEulsBa5KFKuPremvqftRySDzIvhK+A63ley8mNtlIMFkUrkkug6XUdQeIYC kNH2PcWAmEH9MYdawFk5LynNPp+pd8Y= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JW87gVmy; spf=pass (imf03.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724060667; a=rsa-sha256; cv=none; b=pKps39yuuaKhKirLsgQDkt+kjZvXjfa8SGvdspYhdxdTQlBEINhgMSMO32a7877/nCFYpL B+5p4zmAA9YtdNPgpKc3rqfHV8NrDy3zWYXnveUCayxNSMvQNNfIw+VyRGhvj2OyGuBVCR Ga0KsHdi87esy7LNXS5TUSihS+5aoDk= Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6bf775d1bdfso21176676d6.1 for ; Mon, 19 Aug 2024 02:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724060770; x=1724665570; 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=KXCBzcxXQZDKDh5jvG0krAECq5GkrwQb/bMSCsqxdTg=; b=JW87gVmyVe9kfhDyqoI2XLBsiw1oqWR0ywvidp4cynqm9CTzvfZhzLSyCk2LH8i6z3 Si2jr3inqu3uou5+xUHVmUuErNQXyTIsz+Iaj/KMx5zuqUDpZgmP/iRMJujRsMg5K8+0 b0dfsxLxZKRFzJVBXYNn7Xk2jORGWrXSvRksjTACdyGkTpRnuJKH7S7NkFDVNNG7sWPI u71V/XNw+eecC4SBPQh0jNHwzCpe41EQWUcTRqEFaSwdC53JGIzmwBt9DDnbMM6xTLT7 gmh9NCNALRPZO+a0DZxMN4KLm6R5MZ64jzrm25zkzoagfl8AuwYYE9jkVObnC62OFFsH 5gxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724060770; x=1724665570; 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=KXCBzcxXQZDKDh5jvG0krAECq5GkrwQb/bMSCsqxdTg=; b=ufgoCBKRjgjAFL/7saeQLIrMOM7JQrilV8alH79QWomL3XRMWXDTsD5RjUE7WpmbHO l1JMeolp0NMF6qBOKf8DdsG95wkeEnw6RmBQGiMie/mwQwaKhmNWRC/r7/GjaOzvXnKZ usj6bWhU3+m54a6Ng05+WeISYZGNeMsqe/088rtfHF2TwFtCWvJAUMA+SZtpAeeHynpp BOike++eoL8tbBLF8BgeY++AzNn9JqthXamTooLcFIRCxrY8ux1MD/nxIJHEBHL6Jbkp +vTGTiOJJ53tz8W2K18xLacEcbhF5Qb+BIxpM+ssC9vZKVxuSxtaHHaztlJHl2P9Q5rT 8WfA== X-Forwarded-Encrypted: i=1; AJvYcCWv+3EesPxiFApW5atSfYTy14QxbwUeJdni+l2GkJi841RmWr5UH1CSXtK7TgkKmf5d/jRNYJV1hqTneRnkv2Qonbc= X-Gm-Message-State: AOJu0Yxl8zNA3QSTsWhoTtce1xAlCziQnSOAsclegw+TLedNyoSoPzKh 43ncAISVd/UB3prQ2taYmf28fSg0k4Ry5yCFKA8hujim2eH7QsBcuRiA8NfzYyMON3NHNeN7MEd 8fv2+yxFY05h9AneCGFGilWYUjbU= X-Google-Smtp-Source: AGHT+IE7Pi3RcMcMogobI6rI3YXFsgqP3OWgMvEQsKsPBWROiJJfxBP7HuGKH3+n1F5ADFzhiLI0CUa0SKUPwdh9CrA= X-Received: by 2002:a05:6214:5890:b0:6bf:9281:96b0 with SMTP id 6a1803df08f44-6bf92819984mr60124336d6.33.1724060769602; Mon, 19 Aug 2024 02:46:09 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <20240817062449.21164-5-21cnbao@gmail.com> In-Reply-To: From: Yafang Shao Date: Mon, 19 Aug 2024 17:45:33 +0800 Message-ID: Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Barry Song <21cnbao@gmail.com> Cc: Michal Hocko , 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, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev, Lorenzo Stoakes , Kees Cook , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , Jason Wang , Maxime Coquelin , "Michael S. Tsirkin" , Xuan Zhuo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 90CD420004 X-Stat-Signature: tooy3eakitqugxudp4qpo8qjanxhy193 X-Rspam-User: X-HE-Tag: 1724060770-209725 X-HE-Meta: U2FsdGVkX1/DJVkBvXcrDrY+KpKNrQ9H2A4I8EEuROo/EXSdM14dEsWV+kHv7TppKwz94eKPb80xopHgRa/PVXfniOvWsdytOd4NFtK/NLLWOXwmy7D3VGChVWmh05n9Baj3vcx2WOsFDasx2hKNfT20GmtydrpE2maJjJ+9FjlnygqWSqKIHa0k0PmFfmDlo3Nsae2OPzDk4KDFncix46HXbEBY4kHZG05J90aBl7dDYak90b7RcDFfPdBLUtec90nyYcz7Yg4/W+Oz/qiAVwN8HaF9nFU+zd86afikgyjH9xDgr9GNjNvJHI0vuHYhrn3TYV34EgQW8i5QfS/LcfrkE11CU7HwZQtuRCqh3Atc+AnCqzs7P6p/lB4BU6TyVXlHLH06NVyYaOs53M4LxtnEnUyx5SQiDFZnaLtFp8BQ17qmoV1VT12U3UyjRjmoxXuDPyATiiAzy22wZU1GbaHSrmwsaJdcQb9I0rVHxRuprUzvYWwaLUCv9i5NtQuWom3Ji27yGBEiC3Cu5tUpBWQKvwzhFyxSxR39+a2sqEdHe+Du0l1/U0X2WQ1biKqBAokEiiMDrHa3RoGgdJ7cZpC8NU8LHKIZ0WqTL+Lgti1RU51c1OoP3yt0EJSEg9LR4jK77/2P5wcl4Fsp6uemft0Is49LKt2hrEliC0/QMRat6Yc3RnZECq8WW956LGPXdHxxCX2I6tt4MMe5RVB4dvoK47FOpULkXj6GSxZCpAuM6I+xjvchNBMyHBq9FCQwDjsNFCzHLZVEEYSc1W5PH5UifpfM+9XxKDR8cC6QXwfgWkygYnIZzCfxVCUFZw1ntR36YMJdDGXwkgKm62/5KR8m00qdURTD77ROoC4v1eErHyIIDqVpdhqvcVOrC0zQu3P3DCmIaD5sXBehiK62i0vNQZfsyc8onsu8WISoHknLgRN4hpwA0ZHd3kV8kG/+/rkib97Ho8QfsAH4Gnr OLbgq15n 5GjcF/JCMBdFv4bXaj67frMtWAaG9JS4Wp9g64/9DTqGWlrL1ynMyE8c49lvYsMXyFqWUcNtYb3cbZBU3JKMm8U8DXOrZdhdxTdAAEJQkQlRZK8o1p2T0eutRIZ19piQGUCDyaQWfnlSwcN+QLQO/HqcN0aDECtqmdObs5PgvbphqvP1UK3GoSdmdQg0ilod0CXANrKZpYbzTeFjoUyR5JZGXailLZ0V4Rp7vXtdK/Oq5rzXU7QpdN7IW8gz7EDsB9Wg0MiLpaRV06DmkhL1bDNp2oW66QIZuWWZg35vIP86sMbCjBek3lEXgAmIGOVx/vWJrq1aolpINCnnKxX7qg7ugqDIr0zvZ4XQsm1uMz7Xmv5U3tmGM72SArDFN/WaVvXw1QBvFuASRD//HvFUVOz3jP82QzWq+YUCoovoqnoDdZFdIH6m2BmV0uJFXlCjGS324I6GUquvGNH+pGQlxYgM6evUD4VoOeahrGFNLyBfRulExSW9Mn/BRak69THHyskKblyKFww8TiH4SnuggogapFuMn/NHmR7qATaP52a9rN4Nt5NO/g55xQ98YU7C54Lu36PqgqvFpiGENiPfuujQUkQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.033758, 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 Mon, Aug 19, 2024 at 5:39=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > On Mon, Aug 19, 2024 at 9:25=E2=80=AFPM Yafang Shao wrote: > > > > On Mon, Aug 19, 2024 at 3:50=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Sun 18-08-24 10:55:09, Yafang Shao wrote: > > > > On Sat, Aug 17, 2024 at 2:25=E2=80=AFPM Barry Song <21cnbao@gmail.c= om> wrote: > > > > > > > > > > From: Barry Song > > > > > > > > > > When users allocate memory with the __GFP_NOFAIL flag, they might > > > > > incorrectly use it alongside GFP_ATOMIC, GFP_NOWAIT, etc. This k= ind of > > > > > non-blockable __GFP_NOFAIL is not supported and is pointless. If= we > > > > > attempt and still fail to allocate memory for these users, we hav= e two > > > > > choices: > > > > > > > > > > 1. We could busy-loop and hope that some other direct reclama= tion or > > > > > kswapd rescues the current process. However, this is unreliab= le > > > > > and could ultimately lead to hard or soft lockups, > > > > > > > > That can occur even if we set both __GFP_NOFAIL and > > > > __GFP_DIRECT_RECLAIM, right? > > > > > > No, it cannot! With __GFP_DIRECT_RECLAIM the allocator might take a l= ong > > > time to satisfy the allocation but it will reclaim to get the memory,= it > > > will sleep if necessary and it will will trigger OOM killer if there = is > > > no other option. __GFP_DIRECT_RECLAIM is a completely different story > > > than without it which means _no_sleeping_ is allowed and therefore on= ly > > > a busy loop waiting for the allocation to proceed is allowed. > > > > That could be a livelock. > > From the user's perspective, there's no noticeable difference between > > a livelock, soft lockup, or hard lockup. > > This is certainly different. A lockup occurs when tasks can't be schedule= d, > causing the entire system to stop functioning. When a livelock occurs, your only options are to migrate your applications to other servers or reboot the system=E2=80=94there=E2=80=99s = no other resolution (except for using oomd, which is difficult for users without cgroup2 or swap). So, there's effectively no difference. > > > > > > > > > > So, I don't believe the issue is related > > > > to setting __GFP_DIRECT_RECLAIM; rather, it stems from the flawed > > > > design of __GFP_NOFAIL itself. > > > > > > Care to elaborate? > > > > I've read the documentation explaining why the busy loop is embedded > > within the page allocation process instead of letting users implement > > it based on their needs. However, the complexity and numerous issues > > suggest that this design might be fundamentally flawed. > > I don't see "numerous issues", only two issues: > > 1. allocation size overflow with __GFP_NOFAIL > 2. unsupported case: __GFP_NOWAIT/ATOMIC | __GFP_NOFAIL. > > for 1, it has been a BUG to require an overflowed size to always succeed. > > for 2, it is an unsupported case. we just need to hide __GFP_NOFAIL > and only expose GFP_NOFAIL(which definitely includes blockable) so > any unsupported case like vdpa will no longer occur. I would greatly > appreciate it if you or someone else could take over this task, as I am > currently extremely busy. > > > > > -- > > Regards > > Yafang > > Thanks > Barry -- Regards Yafang