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 03020C3DA4A for ; Mon, 19 Aug 2024 12:18:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6CA1F6B007B; Mon, 19 Aug 2024 08:18:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 652176B0082; Mon, 19 Aug 2024 08:18:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A4F46B0083; Mon, 19 Aug 2024 08:18:16 -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 28F8E6B007B for ; Mon, 19 Aug 2024 08:18:16 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4AD741C2C7B for ; Mon, 19 Aug 2024 12:18:15 +0000 (UTC) X-FDA: 82468897350.13.BC1CC14 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf10.hostedemail.com (Postfix) with ESMTP id 33649C0032 for ; Mon, 19 Aug 2024 12:18:13 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VZbgO+rQ; spf=pass (imf10.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=1724069854; 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=O3WXgd7jOIC9DgakPiboiUDw3XFWqCJ/GAfcLSTu3LA=; b=8euZEHVoeTbfoPyHPyOt4Z3o9Mp5EMIbxeM4ilAbzcs1kgFIunm3eNk6OxrQydO5PUiYCd rn368I/sU0me7A99dDz4NI16UlgdkyUd53cJuc4gJNGzVKW1HTOQgzCFrjSIyTIqiNHE+W cLAjDefRwKL4+OII+niBBXsgdevX79Y= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VZbgO+rQ; spf=pass (imf10.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=1724069854; a=rsa-sha256; cv=none; b=YuEBHjqAKQqka2AP+lB371slqjwyPn6idF7lUCwV5t/gNUs+Psbc5tBwOTyaDTQOqoUCv7 zc0I605jewG0TxVWphUdMmbOHh7DiaHtbbPdW+QHUPfBBY6ql7DP9J7oY8DwVKKIIwYN+9 YElkHRE/G4p1yVghhpw6QLEivBylHNk= Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6bf9ddfc2dcso3655336d6.1 for ; Mon, 19 Aug 2024 05:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724069892; x=1724674692; 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=O3WXgd7jOIC9DgakPiboiUDw3XFWqCJ/GAfcLSTu3LA=; b=VZbgO+rQp7xcjecWhromnt5U60E4P42Nwp0xQrKJfEFQRHWVWP3YPG3N9ELBi5zEZH 0dUks3G+er19u09nJxNsEoZrQ2AU3CL2vilI/TaW9xIy01PeD7BW54f7cSPubPrqVjDL 4mx9layrdrs06J3XagMWOMSzWs8UJ4gzixMMX/6bWk/IPWTTCVueYyVwzf99dRLDsOlR ZcP4c/zAMLj0tcLWPlcZL8qc/1bn/AZLjLH2Bjt5NzBjQhMme02ZFE9gAlSC017wyOWU Lyahxo0LXb9YZEKLGo3YIYgnh/QlNRwOv9TJk9rTh68lz8nV9twn5tBCCXd8MZm+ovGe x3vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724069892; x=1724674692; 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=O3WXgd7jOIC9DgakPiboiUDw3XFWqCJ/GAfcLSTu3LA=; b=iWdDGZQBxBxZnEZJgkhnOCGQPaBLFRj0Q4VuuQ3zrynjLwsa0uzLoj19YTo8rWJVqD Yw0kK3H+xm1cmOU1QunOk/2EGFsgvX5/A0eEywd7/nq/ZLWfNmt2Uk1p1mzGApgIPlBk WAxIGDc2SoTmO1gcvw0rjl+PE/42Rnl4r7GoSitK/zqSgT+PQMmhQncA7lEB8GARClFr UFduHZuBkGxkt3lY3K7KUAp8p1MYE9JJfYYkAWu9v2Tz6P/Ejt247kiTR2EUSLqUOwEm gtXSfFEIT7G55b4vNUtgi762hJw/CWvfLZBYywd/OOG6yX7h7jdgIGNrxv8PoufOE3CT xJTQ== X-Forwarded-Encrypted: i=1; AJvYcCWV7N+HG8ZOJvXtmNsndOfZ9ZiGgBOPNUPdNJxX2X94J+W/9TXxCUvgMsCIGLUzWpptxWsecxtWeV1BouRrMgpHFEw= X-Gm-Message-State: AOJu0Yx6d/ovoM9ybaQf3hxryVB4QPb6k1VuaONQD9VgvWgzEW2VZS/9 z3AzV5E9CgJtJzXywId4Bi747uzOGXY5SgL/WsuVgFsZ/I7u3KA2oX83xH3EUdsVZImknl1FGKc vEXjGtyBY/4kSmPumHD6cGU0EzkE= X-Google-Smtp-Source: AGHT+IEN60bau7NvabOoijHRAzYIqifLLZmMVxSw4a2WQLNMA4HqbGgiTdnrSYlccxxg9C6eUVTTphqCRMiRyMMk+rA= X-Received: by 2002:a05:6214:4a83:b0:6bd:7373:8c8c with SMTP id 6a1803df08f44-6bf7cd79ea0mr122499716d6.11.1724069892067; Mon, 19 Aug 2024 05:18:12 -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 20:17:36 +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: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 33649C0032 X-Stat-Signature: q8a7ef5xqae8s79u7fj9cmcpyx4j39ga X-HE-Tag: 1724069893-505403 X-HE-Meta: U2FsdGVkX1+ioRwM6EuNPBsNRbDxQPiiuxhu00yWc3LtuXVFy3Bi7W4tAfl/BbEwu6+Rv4M13gD0bx4lS2jZ6cfx/E4znGY8KOfqCsC3oP12rYyfhtm8YcBQpNIWF6GACJnbk23hBQMPzIdIRn7NkCz0Zq2d2YJ95MnnkiCEXLOTO/fZsmdrzf+d0HKTQda+hvaullbjUSmcYSCMkSEqIzlPajTxJfjJ6MziOqGRJFeFgsZreaq2gxcdIOU7n+e7dt/tJE94GTqBNNTjMjSb9jLxiAERNPxDDZLayrKLvMARyvTYhPPffwAb95zm/kIy7bhJ07EPm5MkmC6lDrX86D8LjMupLX8/JPXNHXm1maIYwJD7ZJswsIVz1jbCmRRE7TRwn/74FMLCIM6SKTues1BdPqgdkKdJEgZZ3V56/uj3RxUahzbmJXauOgFbnPeWhxBk9e0fZgFNTyfjtSmmMHSHB+x2nyvtNpftpq2lvAQQg3M6pw4toB8WSg8PZmvIKnBb98+b0eokILUTWeBtT9f+NfQAc/Y1Be6LuEUCR9+jb6jcqzHoxK4qK4/hsa5GnzzefmGzpoWXqwmmMZszhcwhCat0I7CzqDkvHYJdrO/cJRl8HnniGE7G5nwe+2XgloZPOwcx53WrJtfaryNSUuXGXaWmoTqJrJst5djwCVyrd2KgjKXz++4r7IMmK2uLscLGGUaWWTcfVaRTZN0oTkn/zsgsTn9gLFaF7JDryTfW5oG+NAe05SNYWQwxiRd5Ho6ZXabA7TqrtgvrO/AwyFoywrgiKwKqA0XzJKwzQFVIzj33aMoy4EXvhAVg4G+BTR1DfHXwfzlaibYYLajFTUrVdbNMO0LER8hhQlwSg+96Jt9KCdD4aMdl6zos0oe9zidHOr2ed/q0dF+cLbgxuufU86f1FO2V7ZyLo3ZDoYfo+jnrcYyG/dpGTIKrpHbFo0wLffqeoYToDsf4ql/ 2j5Niu9Y kFS6PPwRK8gpU9RumZGFDAz6K5m45MXhqtrTfGe4mtvuyuklInh8miuI0nPuGviBA6HQlScIez0Z6+/ypEgHBb/2FjIbejHuwS9Ycgig4cSmAt3EZgCnXWfvRNodLdEiI8e1Q0ldebaX7M87xl18G+7xolyFD1XHNzlm/gWbfS0Pd2PJyMQnaWAyH29FgugTK0d6SxyPoTOQwucN5DM02/MYmJ+a8T5re8Xt8GiMqAWRastSA0cWBvihauzWEzVbx3+XmsfIRnyLdQHcK31aoIm3YEzz3SJz9u83cv9Y8H79iL+Uz9pGKUlhRkFmZcSiB1dySbDnlhYPESqG+HDpGYGaRu2czxtfRS9s2Rlra3GgPwgcmR/9JVh+HfdicF4K4CpR2RiOcOyUIp8jbdJfIc8iiNWzDkGyiBQCB9QJ4sjeeYrtLRxl/ixBLpbe16wextsvdFOqAYg5Bs0KsnCtwglV8xhWiWl53UEivkXGDsJrnqbmXb15yfZAYof923iMt5johVlSOprYzCpx3Isz1toxPPBQIxyn4wr6UZUrFHZIaHne85EIC4F9k6gc04DOVu6BkPgzafy6CyZlHQnp31VT+aA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000079, 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 8:09=E2=80=AFPM Michal Hocko wrot= e: > > On Mon 19-08-24 19:56:53, Yafang Shao wrote: > > On Mon, Aug 19, 2024 at 6:10=E2=80=AFPM Barry Song <21cnbao@gmail.com> = wrote: > > > > > > On Mon, Aug 19, 2024 at 9:46=E2=80=AFPM Yafang Shao wrote: > > > > > > > > On Mon, Aug 19, 2024 at 5:39=E2=80=AFPM Barry Song <21cnbao@gmail.c= om> wrote: > > > > > > > > > > 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.com> wrote: > > > > > > > > > > > > > > > > > > From: Barry Song > > > > > > > > > > > > > > > > > > When users allocate memory with the __GFP_NOFAIL flag, th= ey might > > > > > > > > > incorrectly use it alongside GFP_ATOMIC, GFP_NOWAIT, etc.= This kind of > > > > > > > > > non-blockable __GFP_NOFAIL is not supported and is pointl= ess. 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 i= f there is > > > > > > > no other option. __GFP_DIRECT_RECLAIM is a completely differe= nt story > > > > > > > than without it which means _no_sleeping_ is allowed and ther= efore 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 b= etween > > > > > > a livelock, soft lockup, or hard lockup. > > > > > > > > > > This is certainly different. A lockup occurs when tasks can't be = scheduled, > > > > > 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. > > > > > > Could you express your options more clearly? I am guessing two > > > possibilities? > > > 1. entirely drop __GFP_NOFAIL and require all users who are > > > using __GFP_NOFAIL to add error handlers instead? > > > > When the system is unstable=E2=80=94such as after reaching the maximum = retries > > without successfully allocating pages=E2=80=94simply failing the operat= ion > > might be the better option. > > It seems you are failing to understand the __GFP_NOFAIL semantic and you > are circling around that. So let me repeat that for you here. Make sure > you understand before going forward with the discussion. Feel free if > something is not clear but please do not continue with what-if kind of > questions. > > GFP_NOFAIL means that the caller has no way to deal with the allocation > strategy. Allocator simply cannot fail the request even if that takes > ages to succeed! To put it simpler if you have a code like > > while (!(ptr =3D alloc())); > or > BUG_ON(!(ptr =3D alloc())); > > then you should better use __GFP_NOFAIL rather than opencode the endless > loop or the bug on for the failure. > > Our (page, vmalloc, kmalloc) allocators do support that node for > allocation that are allowed to sleep. But those allocators have never > supported and are unlikely to suppoort atomic non-failing allocations. > > More clear? * New users should be evaluated carefully (and the flag should be * used only when there is no reasonable failure policy) but it is * definitely preferable to use the flag rather than opencode endless * loop around allocator. The doc has already expressed what I mean. My question is why is that ? Why not let it loop around the allocator? --=20 Regards Yafang