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 24081C5320E for ; Mon, 19 Aug 2024 11:56:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B29A76B0083; Mon, 19 Aug 2024 07:56:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADA136B0085; Mon, 19 Aug 2024 07:56:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 97B326B0088; Mon, 19 Aug 2024 07:56:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7881A6B0083 for ; Mon, 19 Aug 2024 07:56:55 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3F764A8EA3 for ; Mon, 19 Aug 2024 11:56:55 +0000 (UTC) X-FDA: 82468843590.07.252E313 Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 7CE0B10000D for ; Mon, 19 Aug 2024 11:56:53 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JaGuaopg; spf=pass (imf05.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.128.174 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=1724068510; 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=Zax0iS3R88IPyCYGGTmSynWmp0TtBpfhEgytoqyCcIU=; b=o05fTQhZo5+S+DObQmYBXDnlbVcxJ11f2NtLNzaG3OASv05ZqaVk5UZVwq2qp/0ilM6HyP qwFMr5dZ37cphtu1gyz/bGc8PTfQ/38WSieegCCQhniWGjvD3JVOhxcavUl8sSFkB6eCWI M3WvW7OQn3/huHDCEt6kvNmfBu0myR8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JaGuaopg; spf=pass (imf05.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.128.174 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=1724068510; a=rsa-sha256; cv=none; b=BYTeBNIwmk1C6/HiA15f8d9DYsUfmAkAszzhbhjIZ6hLv1aNQkXCj9KFeEoRcw85ZTPV7S bXo4J22WPk2Yc0xZrc4giDfmWYZFTTcT9D9Y43/3OqJunheFnrxFjYJfYgfXyiXi/fBTWI 9gF1MsxFw0l1k3fpTv+6qO44BLqw6rs= Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-6b4412fac76so22196887b3.1 for ; Mon, 19 Aug 2024 04:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724068612; x=1724673412; 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=Zax0iS3R88IPyCYGGTmSynWmp0TtBpfhEgytoqyCcIU=; b=JaGuaopgPHehSz0wtqW28SqRIt/YYM36zcQR8rKz8CM8S7sNYyFZhpKaXuSrFlJAgD ucwmYoZmHWNU4BzNV9ykI71Abc6wQrJDBjhCqvYczQquMI/Nf0gTRCY3lZ2KBLnUzsPE S7fh5REz4toiYuuXbI6y3bRFL9IPoKSNQvq9bAWyglz9TW6zbzQqOjnavFZjeRs0ZKX5 avGybHx4N3y7EN27iG7HmABXAoO1rckx8QJLbidQr0sL/YuVoPhNJnfCEG5pNhgbsPE2 YcUctfFUTf2l1BCYc9c5uhILuicIlGsUS2VOSisekfEX05CbjYcnGkxTbMeQOnNi6Qo/ b3eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724068612; x=1724673412; 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=Zax0iS3R88IPyCYGGTmSynWmp0TtBpfhEgytoqyCcIU=; b=g2yjG+B0qWpSlqKld/Oq8HJNykzVLJnEN9Fm54aR803zEBHeOs9xxXCGcSEby7H1Ob tGzq9IQsTTVGwMD51Kx8s+xTVEFnULypExOTMsQSWhzcQLfz7Mh4+q9Zadg/CGTKSFQR Ow2FrV32BPjAVFAZ3HlOWpeVp8dKSV91QAlprwPGvdrk8M/hDfzu2XhQqGm/BtsAvNNt bNBddznWn8bZOAZJCvZ4bkTtnRUF6L+WqY6r2/CZ+P/M3oBk3BrcuhcF751gOn4oU3ds hQlmwwryaF0XPkM27h2DfIjaqJpBZifvxjh5CC4jvnmpsnntxDUgnbibsL7+PdJYsk3H Lkag== X-Forwarded-Encrypted: i=1; AJvYcCU/Ndt8o66RuV1EKjDmNU5xAZMl6s5xHK8ojmoaeEfZkzGAllM7LJVDGSX+SG6MBdv5iQJJbqlg4wX+V7cCK7RZLZI= X-Gm-Message-State: AOJu0YzwWySxzcOgtHKpg/19QaCypAo+f2SQH0uvfkcQO7bGv4/0dfXc oHDHaliAoqug9QGKj1Rqkz1aID4HKE1UUSOapiUiXfyCFT46yzlD2VM76aoEkvhR6OTxDuqL+OS cYoVMn/yIe/NLDJPbcyFJIiII+DM= X-Google-Smtp-Source: AGHT+IGY4+ahEENd4tqGGPEWZMtu0Zp7oltkm2wZf64KEdMR+q8B0+xoZWEsOdh01kCr1nnH4wQe9Wjx4OYI52pqXqo= X-Received: by 2002:a05:690c:6e07:b0:699:7b60:d349 with SMTP id 00721157ae682-6b1b823ef82mr119570727b3.11.1724068612484; Mon, 19 Aug 2024 04:56:52 -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 19:56:16 +0800 Message-ID: Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Michal Hocko 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 , =?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: 7CE0B10000D X-Stat-Signature: 1nnpxro474ys477bpfticatn38rw57kk X-Rspam-User: X-HE-Tag: 1724068613-637975 X-HE-Meta: U2FsdGVkX1+zpAD+JTtxMpvIOEeyBrmRFuIxAcYpT9GgN27lK6Yl3Nnusesm4KwzBir70J0qGFCmk+MjzMuJbr/4tia4mRREKQYGPJiz/CI5uRDflaZ+NVc7iNx6F8ECsM5eXVDeYeAk6Sq4agHmTtmn9XmnEz7Xfo82FO2rbF+SHHZ8zmRmMQ3h8GC25SBrB+JcN/OOMGJ0So7AccHWbG4iKFxeDoWNwfDGvMJhfFXEyELyDneOQJGQBGasIYw2VuR7hgtB5/8C84gGfpaTpwp10BSXNWWTzX3+2s0XHjOL8rqwUg08PfyAbK1H57hxwyZcFS9yNGqscJU9VLUUSU/ljl5rNrsfC3he8zB4EmrnlPYRfroy4sNsP3G1XdXe2jkYSkXquQeNLHH6rs0OC7lS+b1BXM4kEl/fEGoVlQNhKL+71uQyqW9PXa+QoYZFC2OzYNDOkj70Cc+yKQZ2kjk6kIxij0DWWfwS/xA47AEtiKrnTN69D4uYFf2cIxNCc+mB/Gdy40l/1qZ20t/nLq+lm0TPMCR1KgLw+MK3lHXA1O/d4VYWVwL4irsVqA4kCO2e9c0KQH8KJDH/JgFkFkrHs/QiZbpI2/3avIFGBHKRrsmCZn0DwEFUAYc3FpiDfDSCUdLmkfewdYwnNjWjrgnychovd80DHEpB8PH2rErYazKLJnaq98/d/Umfcl8UVym76I7Dy0HLAXMu+eCrJ+OJgKGffptMRTPdfFdZIN7mEadiNUArv+Rnu0IJtp69DkNvE+JOHEH8BoHu+Sm+tTFq4DJpm8hU3XTpON57P8d7slGve/YTl5A0+XSdX3HSvFLQrnaya+SJsOKzzcaAh0zWVSf9ULJHvtXo3qp4w3FuDuEd2H1wTfGECNGs3tqAQna/ke1uege5b+H6fEXaLhT/UXIPJBf5zr0e1wS1jU+hHZs7yw6qV6RCA0+U8V0GAHMg0kgp5c3zF7s2QKg McL3XEla GNCYu4U1HlFXAkyWTOMDerlmEjGKkb7/I26IXWpIUsEaYHJmha/e8Ssv+DcV/awDoWusbGm6gM/B/sniMult/iRfUyMEMnVDQZ8rBwHodHhnbveQ7bdgRd1IBB4NBeAd0g4R8LeM2PkdEwiqqgZWOcQmjFRbAizyOe47UHUsfh3OsHHi7uwK3dVqmlFyt3IhKaWhyAkR+K6AgGjliaPT4hgl6aBybJ0uy9vG9wVYTLxaaj2Sndb6uA/kSp1kUbVd+27sOzMvZPnARiexFSPGgZKlnF/oLX6YqxnacMc7iB6TpJ4UbFDGbDl2/VcDNoB6Q9RO9bdjCW/80KE3+wgIa+FWfP387dPtb/ndHTAXbVSo4hJDCdQUirOejl+/4L/vgmBDYlg5+VeXYD2eRZyVa157NiWNRl4atBUYcpf4royvHyXXX0zF57iwW6YqCLVvElZzACluGw1GXrlJbyXJINHfNV+opy8uIyUz7Y8oObqnhsQSauLOwFoNc8uxbMWWTOXEExaLXjyjfa3vWENMRbdtlS5sHdfA9MCe719X5tVDBhwrpZI2K3YzcutK6nH9HAKh1+6JsOToDtA/mRhD7vLaTvg== 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, Aug 19, 2024 at 6:18=E2=80=AFPM Michal Hocko wrot= e: > > On Mon 19-08-24 17:25:18, 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. > > 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. In such a scenario, does it really matter whether you sleep or not? > > 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(). -- Regards Yafang