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 20CDDC5320E for ; Mon, 19 Aug 2024 12:04:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE0C46B0082; Mon, 19 Aug 2024 08:04:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A90F46B0083; Mon, 19 Aug 2024 08:04:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 931836B0085; Mon, 19 Aug 2024 08:04:36 -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 741A96B0082 for ; Mon, 19 Aug 2024 08:04:36 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1DC38121242 for ; Mon, 19 Aug 2024 12:04:36 +0000 (UTC) X-FDA: 82468862952.19.F1D365A Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf08.hostedemail.com (Postfix) with ESMTP id 0066A16000F for ; Mon, 19 Aug 2024 12:04:33 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=da1if46i; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724068996; 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=c1Xamb7BHh3zzuofJjRTL9tIrsrysppjOLQKWaBDkZQ=; b=Cyx1WDskv7TjbLP5U8hxAUbI9FkgegP1ZdVHJUmS/i0IsvEFaI8ASdVXyQordpTXbn+zIM agjEi8wYjpUixfzsEYSF8twQ+j0f5VgU6n5D5wvzTZZElV0l1Nr/pXkxt9vChvvWlrNygf Je/EGKOkV69iWIvDw0t7N6SagRALJG8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724068996; a=rsa-sha256; cv=none; b=vJ79FmvEHV6QoRyL0J4jLAvYuUKwq4FBNyPIivmrPHx+s4TALyRVSDAqwe/Nr+25Ke9PCG mblAaAXiqlBnLALu/QMr9vb/hnHwp14HN1QlyMp46TlLz2PQKqrB41hTi+Q3nmCbax02Zu 1XHq0JdT5PmgbetXJtQzRpelS4/9OYY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=da1if46i; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-a7aabb71bb2so462982966b.2 for ; Mon, 19 Aug 2024 05:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724069072; x=1724673872; 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=c1Xamb7BHh3zzuofJjRTL9tIrsrysppjOLQKWaBDkZQ=; b=da1if46iF5SDMh2x/xGRL5g4TwsxEnArcnf7JbdWIMPxUa8hnIpc1cxZA8B1CeZJuE Y7gelykWXP+U8/4R74bJNwWU4pJD5RpA7JQK7C9PgfJcek/B9MqnGT2HrQ6oTmHFuPfM WIjDrKfVVrwljecJ1NHjFuHUaacJq0j5O/oglbjkIPOeslu2fv1VOwg+3Gjs97Vm7F7I oL2q0zh6tgkFErGAlVHI7VxOnvSTOApdY62FCQBSlQckTLgsV8A32gA24ABSeURHBeQA ZvdcoCHwQ2OxgaT/W1gXhFEIm+zMDLiUgTEqAE4KJ3IsQOR2UbE+091hiFDW+56Lytjc rpVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724069072; x=1724673872; 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=c1Xamb7BHh3zzuofJjRTL9tIrsrysppjOLQKWaBDkZQ=; b=bssI66S9dHQqeFktBG2Qd68R0OP669ajmwROHvvTox5zHUN86VqB9wP7pa4KtjByrZ KsUkQ/zoI8f5PAzh+7jwe/vecGeL3XaQTlxM+4qbO9QRMpua+6uQuCkR6vXdvggFbOTZ F38V7lT9/Dxn9Z4dy1+N2m+N1ZzhfmIX2QtEIoxr64yCGdQySzcA/n1N4cin9xsefjrn k6HY1gqJ4fMuDDc/YReasX/bmPfaTTMnjRx9Uos70KSZV9jh/+uKIBA6v2hXuJhCriIS A7Pb7PVTfdV09EaMRSkkOb8IWk0xbCmg/cL1NTJL2XGi9bAv1HsXoYh7VG09gC8ag+F/ UOqw== X-Forwarded-Encrypted: i=1; AJvYcCWv1zhdlNDcsQF0FVbUk79HLX54YJva/7EUBYhrMTk7Pfek4viFnwtI4BsySKf+LmejeFzdLH3acMPdEhcvZSZP/r0= X-Gm-Message-State: AOJu0YzPX1DR445t1s6vAHJpbd0Xdo2566SACAPmxl/wTy2eTydt4as6 BLnPFkk5dOXgnzCjn+L4Rz8yt9E6zzZUsLXF3uivkMbfy1s1tW7pKiU0+Ko/Abo= X-Google-Smtp-Source: AGHT+IHS3lgR/Xmi8I9DU+TaI78Pgihv5BkldEHe0mmYos9hNFUy7u+OItkIMdOOUrsA4yJgZkp++A== X-Received: by 2002:a17:907:d84d:b0:a7a:bae8:f29e with SMTP id a640c23a62f3a-a83929544afmr781025866b.29.1724069072041; Mon, 19 Aug 2024 05:04:32 -0700 (PDT) Received: from localhost (109-81-83-72.rct.o2.cz. [109.81.83.72]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a83838cfa94sm622231766b.67.2024.08.19.05.04.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 05:04:31 -0700 (PDT) Date: Mon, 19 Aug 2024 14:04:30 +0200 From: Michal Hocko To: Yafang Shao Cc: Barry Song <21cnbao@gmail.com>, 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 , Eugenio =?iso-8859-1?Q?P=E9rez?= , Jason Wang , Maxime Coquelin , "Michael S. Tsirkin" , Xuan Zhuo Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL Message-ID: References: <20240817062449.21164-1-21cnbao@gmail.com> <20240817062449.21164-5-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: xzx8ekx9xuo3343aycysdy3t98bpgz4y X-Rspamd-Queue-Id: 0066A16000F X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724069073-979130 X-HE-Meta: U2FsdGVkX1+8e2iFAvQDLZK5QjfwWRN5jgyobv4LO03gOfMnQKm+eODB3NNOjk0uPBTsW5B/U3wTST6Vf1XEcgm6IDB3QcgYAj5+Tt62RaJ5X65ViXxzKxqCs5c62Klkwet6Fe8HUwYMX8jIc4Jv8KBkQZ4ODBtfziIQOrb12fA51JzhyEfFAPIl7+ZdbJbFqLm+o0Wuw/JchSQ7f+XJIHj0CEMtjsi6DseKgPLIqbs8RyVWsN+JvSwu7xbtM0MxDFutGmMu7PGS44KVt6Hi0d1OGfvdNghCOd4+YoS/1Us2HgGqJ/EmZ7xyaaXs++eKezOzmbtNuVRDKuuCDgrkzwxRXiSA5BS1vewEFcPaDKHxCA5snAv+ChEhjnX15mS/zVG+yuPxZbFZ0G6pVutWWRMS9vf/wMdLHrRFQmuvdmdiPlyujwTAzmDR3swuy5RNW6aoF3y+9mdrZiVrbkdELh8CPLolftpunWE5q8XnzVCXN4Udkkf845bltc6pZIUU5L5fjZo0trCJR339f7iqXXuAFOn9gT46lqn0q1p1UKs+C/m+qDXdbnrrHF72bXj7fWxAXeGXz58kOm0LGNSo9hNeKVOL3M/rTL1oTAiHOqOXqQIvXUhP49be+0HBeo6SiA55vn6GmX4xkbm+wXfHqVAbcDrxZ/GBaKJ6Ew5LQo5tI22E5RGwzlgc7ek3W3M6rlnkrisrO1PbO2pXrXo7kPku8giXnY+Q+YbbDewJQl05Pp3gFn14hsNLcDQv6RLGdXefGkvsf66zHEyuN6UfbnP3AL4gtvrUT1xdqSOoMlNZsX+UKJ9FQVqubIohe5ECK/A/hDqEfCaqkJJiTCrErlWXfyCrQNoq5QKOTBFGMsGcIEyEF+DIC6+iH/HM9hrbh6faWlUb0nbuBy4GtFxllqpUr0HZtXVutPmG2Wuc9LHUsOJ3nXD/eTBzIyh/58hdCcW5IYLjX5rGS5XkbMg 6qTN/aa6 FQntCL3kgf49HVP8aAzwRKWfIAml31QxJxEUJDgSNui6zLOalwFEZxgdNrgPcpZ7jXGkmMNymzToSg6fLlmycJJaWnYfKhmL8tMTQq4dOhTcqQt7ELwodYxoIiGOGUAdiaGcUJBuAwm4Y6CffkRaKt5aorgG+W9a6Rou70UDCOw5LCaI0eRj+Q7t52HZpnv4wDSMrPArDR0R7XfxlIkNzY5S98+e+f6rTaBcJ2NhPYsnph8yVyU++L1JDP45o++6FfxUf6PmrQpc8bvTxWdzBsvBHVC+bAfhj4gwxdIQ7sb8UjLDNY4ocMnr7iCKsbhQ8fjORQJyxZuIwrAa77WkH2QJXDyoGdbORYz1Gzv45KKPZKuXzx3VtAh8IqT00X3jDCthe0JrdZvXYSeG03BzSwxCTQ090yWlyfBGybDmeQ+rPgRoD7EwwOeu59VeYa5Cu7ZOyVRY+swxdM4PsOGhYT7a7UthlHaHtJQ0/GTuy5b+0uLQg7KLd8Iz9tU3DiRgowFVaws5qyDC+PEx2Gy/Fq70zoQhViHWdPVEGcYoR4lVxAnRziUDJIlHjjJjIsKQP+MN+ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 19-08-24 19:56:16, Yafang Shao wrote: > On Mon, Aug 19, 2024 at 6:18 PM Michal Hocko wrote: > > > > On Mon 19-08-24 17:25:18, Yafang Shao wrote: > > > On Mon, Aug 19, 2024 at 3:50 PM Michal Hocko wrote: > > > > > > > > On Sun 18-08-24 10:55:09, Yafang Shao wrote: > > > > > On Sat, Aug 17, 2024 at 2:25 PM Barry Song <21cnbao@gmail.com> 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 kind of > > > > > > non-blockable __GFP_NOFAIL is not supported and is pointless. If we > > > > > > attempt and still fail to allocate memory for these users, we have two > > > > > > choices: > > > > > > > > > > > > 1. We could busy-loop and hope that some other direct reclamation or > > > > > > kswapd rescues the current process. However, this is unreliable > > > > > > 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 long > > > > 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 only > > > > 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. > > > > Ohh, it very much is different if somebody in a sleepable context is > > taking too long to complete and making a CPU completely unusable for > > anything else. > > __alloc_pages_slowpath > retry: > if (gfp_mask & __GFP_NOFAIL) { > goto retry; > } > > When the loop continues indefinitely here, it indicates that the > system is unstable. No, it means the system is low on memory to satisfy the allocation request. This doesn't automatically imply the system is unstable. The requested NUMA node(s) or zone(s) might be depleted. > In such a scenario, does it really matter whether > you sleep or not? Absolutely! Hogging CPU might prevent anybody else running on it. > > Please consider that asking for never failing allocation is a major > > requirement. > > > > > > > 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 really fail what you mean. > > I mean giving the user the option to handle the loop at the call site, > rather than having it loop within __alloc_pages_slowpath(). Users who have a allocation failure strategy do not and should not use __GFP_NOFAIL. -- Michal Hocko SUSE Labs