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 BECBFC5320E for ; Mon, 19 Aug 2024 09:39:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E55C6B0083; Mon, 19 Aug 2024 05:39:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 394766B0085; Mon, 19 Aug 2024 05:39:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25BA66B0088; Mon, 19 Aug 2024 05:39:43 -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 08C1B6B0083 for ; Mon, 19 Aug 2024 05:39:43 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B34C5410E4 for ; Mon, 19 Aug 2024 09:39:42 +0000 (UTC) X-FDA: 82468497804.19.CA28893 Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf03.hostedemail.com (Postfix) with ESMTP id D36B420029 for ; Mon, 19 Aug 2024 09:39:40 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=j4Va35g3; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@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=1724060342; 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=FoSIypTkdSHgxCYznKRlFZjuPRFaRgIlgz1FV3iiul0=; b=FS3GNjPXbBTb8G3haeTcTQLtuZxTDfLLDydOe47GdasQHzGLMRvM4Ncm8iqyOZwb3q25pC IPrrRpJ12+c1XpZ2qjQDu+xtoDjy1f17iZWig2PdFNkyybwYlOdiAgWmdmvtUg6b0D77HA 7B4DA0UiUa1438IN2y1fETUF1DZ3psc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=j4Va35g3; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724060342; a=rsa-sha256; cv=none; b=KsIT7mwauoLt04I1VY5qRc+f36y8127KSEh+QC7qDYJ3CCiVwVcX3KgkcUZ6ZMzytzidMs bt00OoCEMopYN7e1hmhvn4S1nOeKLd/hojFB4vf1Dh2jhHeAWHd3eQ829pkeCFYsv0OI6x l9UOR03b+qy9efHtRrrUlh/fda8awpk= Received: by mail-ua1-f41.google.com with SMTP id a1e0cc1a2514c-8430fdf256bso688166241.0 for ; Mon, 19 Aug 2024 02:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724060380; x=1724665180; 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=FoSIypTkdSHgxCYznKRlFZjuPRFaRgIlgz1FV3iiul0=; b=j4Va35g3hmBSGfFCgh2zJh034sHXPj+K+yH/NGnXTHr0s3Ntk3f7sDC9tyGdxvAQ9I 1wQpnS/efcj/Urr0LA7ZDaJA2L5rq6NjusEhypTUzn3XHPMVnYIdg9NG+M40M5MHPPI8 XF6jxy4CWUFVxoCiRrT/2UFKuv1VcO9KQnxROgumvN6uvGEJPtqIJFW7ys4I+0XZgq2J H6XmJRnKJqbrWuEe/q9gRfMNXfJ53YQ+9+xNgPHHw0LhiryZ1jthMci7hITDFZicPc24 PVPJbDo1qs2MsPFNCoCYCLZ4bGh+/YLxYC0fHAF5pL8RojfqH9XqScSE641icbToDHe2 09rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724060380; x=1724665180; 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=FoSIypTkdSHgxCYznKRlFZjuPRFaRgIlgz1FV3iiul0=; b=SZ7OWF5wEXwkYLpUWItX7T0DkVqQmYfkicPbakHYZ8OsRakIhSXQdkQ/OQaYHwh12w fhnoXvxCLuZ5igOTIGSrZuVgxeb4s1XaMBV4UvM29nRp9kYGc+7qEtoCisSEEkUCJGkl 4YVW/a3bt3O3paxdp++TFrScHynnEMC1Q4zSDYziRV06dd6m8p4Yisza9MmjcrzHkLdJ k42VCoQksM+REJjc15uWHOC+F6Qrx0Eu5EikslnvNDVIr4ye06Ddjq1gId4aQkXtVciB YciTd/lMifICAE5tAWyfA4H67izRXEALahzFFynjSt0cvz89Owh/8+KQLLKzWpdBFlS0 1iGQ== X-Forwarded-Encrypted: i=1; AJvYcCUDdcNmtW/KQJgJn1F+6hGdvfQzaUX1mTt0LhlwpM5DJtd15H326kZo8qMlIozZ134GtTSmx/m4jwjNnH/e133B7jg= X-Gm-Message-State: AOJu0YzozG5iwFw++Dun2f6a//Y0+15/seaieMlQMm9xIPaXMJUdZ2Pj mSgxbwkVD23D8nFu/Y0QjEE2ePSZF9dgH1ELhhlb+wjqsZCewViLNe1hdZaWfQ01ocMj4jeP+hU UVjH7q5q4ZhKxnYVWTR9GgsqFo4g= X-Google-Smtp-Source: AGHT+IHX29MnZ9UrMREVVXwbQctg0qwq8C2OW+jJ6hBslxhJVtXPzAUrhLdm+xUDMkzb+8FMgyYPGJC2mgagbGph09k= X-Received: by 2002:a05:6122:d99:b0:4ed:14e:9342 with SMTP id 71dfb90a1353d-4fc6c5c2b6fmr12295328e0c.1.1724060379834; Mon, 19 Aug 2024 02:39:39 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <20240817062449.21164-5-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 19 Aug 2024 21:39:28 +1200 Message-ID: Subject: Re: [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL To: Yafang Shao 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: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: D36B420029 X-Stat-Signature: oq4nha5ni5s7mmk49kfd7b9x8umj4jnb X-HE-Tag: 1724060380-258051 X-HE-Meta: U2FsdGVkX1/eDsfI//qSwF88k3lw/D3QdLB7+nroHPhQb4z8GHt9zVOzVo5Y6GylQKIkd9JGIZO1WqloAaNetMGtIx8ITdbrYy40qUVpx7LSLkQmTccuKdrrALs+fX8yNCnRODWx1pVaGPyTOccWKjdoxvjuFYebZ+gMOpupk+Hb1QlErrIewkF7gFYmYvbKz7ZGVCI6gUof2Pl1fqiEeu4TNSw38o+t1QW9Sr+Zwd6NEhLlj81w00zng1zB1HitxRcne3czx4V7YFHbjMrOcKDz+kan8hLL1qUNgc8lyI9QdJK7eJZYQLQvw7TCWxTTna9W3SU13q+PW1I6tIdWmhQ2hzihhL1AK2FeUICo5nzrmM/RuXJCr82ySpJsXkBLWHSGzkwQq/94KESh6BTxkmMseKi7v2U1tsZ6Q3oNzBY5jDTQJsseDbVa/VZ5y/+lk2S0xzOfLpIhx8YylqzXLapkREOMQKjyh15vJ9x1PJyTK+YYoZIpLjvEtsY1z63p+1h/RM/iVQwCc91hAS8r9OgRKXME9u2LKRwRhd3nd6WQ0QlBj2FYp/hLnc2dL5F9YyuzcanjdaWsY+Lghyodh3NwoO7n4kpHPMAjM5ydtrbyXUQSxHmPHWxjGDVXYy0U6a0lQt5qBpDbn1flpGJU5OcDIZz4c4tzDAk5pVeSfSFMwcS08vXoB4Tq0ylNEZqMB7xfsBAlAR545a+oFAaSEV4AOumSQn0gUdwudlc+zlm6fcZ0kKk3Ez5GWLCYzC9Z5ogtiCCak0OJbN1sKKEwgvocj6Rrz3rU5e40dGWwzjZQl8dC9Uu53mA9rVQy4w1hnajajOqE2nBViBiA4c2vaTpDvVlzJAWnk3QtWSWOEPTOBXCF0dWpaWXiO2f4oXZz49ua3xIhHGI9BLbuj1bvelCOzhKAu6RZgdDBC2CjWweLSELbIE0IRRSvWF37w7xLFGmV3v5NjZwROsPRVSc IrMVsKns ocvwFWzDVvBrM5dJ2jTndqKXY1zDDYQ+/c8W/OP9LkvsBIQ614ZW1ndCe2zqiE2RoOHkJeGURpD1QN3NfSWiL2p++bPdBcf/N6hareVdDOw2YisweWb+ttvmLxbKLG0SYrl9Y2ONtBDxeE1UpUwkMOUZRPirObi4WRIKDkW+4556MVajK7F03AR4A4meOnlWySbXDS5V6dOVn86mNswTyhG72xxKwRxQpHdjb0uEKYU5x20jmji16+daHzief4IqHFjLHRBiDQ9oATB1S1wqucJMj9Y4xLV18OTU3ZZiLOSUbvSQobT5HFXXLY2s5VHw34NDQn1LaDjAxt9M1XdnfuUp7HcN9gry/EKTFN/OTNDxBH5j/8mw9IU5q2atznQpzvIaVm3lpO6556Tu0UmqYB2NLURPyzMUdPwdS9YJQLZ08JzejIkuS6KWvzmecjIVkSPVuIvuSEZR4BlAbBJd4QNJW63HADIUMze9bdCG0lS8dBSs63ZvkCLczYG4EXeNCeN0jRjRdyw+JNYEiB7YwlOj1irf8AvG4Ra/fkqexp46UkkdfI+Qd7lkKCA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.073367, 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 9:25=E2=80=AFPM Yafang Shao = wrote: > > On Mon, Aug 19, 2024 at 3:50=E2=80=AFPM Michal Hocko wr= ote: > > > > 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, they might > > > > incorrectly use it alongside GFP_ATOMIC, GFP_NOWAIT, etc. This kin= d of > > > > non-blockable __GFP_NOFAIL is not supported and is pointless. If w= e > > > > 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 reclamati= on 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 lon= g > > time to satisfy the allocation but it will reclaim to get the memory, i= t > > 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. This is certainly different. A lockup occurs when tasks can't be scheduled, causing the entire system to stop functioning. > > > > > > 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