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 698F6C3DA4A for ; Mon, 19 Aug 2024 11:57:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFABA6B0088; Mon, 19 Aug 2024 07:57:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAB226B0089; Mon, 19 Aug 2024 07:57:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D72FF6B008A; Mon, 19 Aug 2024 07:57:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B5DAB6B0088 for ; Mon, 19 Aug 2024 07:57:32 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7826E1211DC for ; Mon, 19 Aug 2024 11:57:32 +0000 (UTC) X-FDA: 82468845144.04.373774B Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf12.hostedemail.com (Postfix) with ESMTP id 9AD874000F for ; Mon, 19 Aug 2024 11:57:30 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ah291ba8; spf=pass (imf12.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.181 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=1724068635; 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=GXfL86t3Z+jcKcbaIzRv07HiHvdjxdQowzTrEPH4qKA=; b=MotJ2tX8IBUH6YT989sEWRWYXqeNiwiQfdrmgzC/uYRvPc/th3wP2kwso6QjzKoBokIbm/ S5fTwls46MX3xf04ZJq+UL0jeUBXGtaPXunGiB5CD/wl3r08dS3NJmEW60M4ObYdgELgJn 9dRiG1ZUjTMBWW1w3Yr9oTv72QyoWKU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ah291ba8; spf=pass (imf12.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.181 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=1724068635; a=rsa-sha256; cv=none; b=h2gthaYnAUFaeAMmaKnbSjj25sos+GFW14Vy5R5qjV+gSV/RWAuF5+tmpKDyk39FUnrrsu 0W/ujv6DC0n0hj1XWLktLStWvVpF3SP15RsUikmti5ERUIXAF8k6YCfyh+4VLsI6enS/BQ PsAW9GKhe9Umo2hUyS/zNSBMUk9EMRQ= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-e162df8bab4so886282276.0 for ; Mon, 19 Aug 2024 04:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724068650; x=1724673450; 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=GXfL86t3Z+jcKcbaIzRv07HiHvdjxdQowzTrEPH4qKA=; b=Ah291ba8CPajG5zElGTxrQ9gJkv4DfX8wxbHh+qzWeoPG7/8h3az8rmrCBdgcQTcq1 SbxDlqCUu1TQVXPng4iKlv6pxbjtyfOkj5+kh7tCf08mtCCb1iAK5fnO+kPw/bmr5f2l frRCrflbwPowkhw5Di6TFm5h7f4GsiNvYawVP9sn/bVHmpiWd6qtVvkz/Xl8EM4KPWTU 6oamJomxrMElcRIToEuYQ7l9xlkXCwKq+nStdnaRV/nNeeQxynwc25gW3XQTNYYlJBA2 cFgQqLISvxKuLtp4qXrF+yDTMZ5/HJHMKk/ie2YG3O2nTchQP9I0zBWroFkO0P8oyZY3 qZUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724068650; x=1724673450; 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=GXfL86t3Z+jcKcbaIzRv07HiHvdjxdQowzTrEPH4qKA=; b=u4cSoNdtFwUzrAwPsNQbxMAlLI8dmPsmO0BZD9nncCIK4RgTeqdCtw5x7qSHKmzoI9 cYFLixlR0L1aEpd/vfKJOR4AVvSC6JT3QsoPK4NkRVt7IfwkKHqwDjJXmKDDm9QD/vTM m6rjZUprWZcTsCZLgAImvOTIZs/xY1UEpsOiBvb59qgmoHZEvpJkW4BkA1sz7kxyabEP Q/1Ca4Xq6XZz5s7+IdQrP0pTwGoXVjg4h6PstO80QN/Y+kskIOKdgPULwIh10AltCQ3Z LMFkc2F3yAN3tKvZO+NABRxmspUjmz4Jj1wKhMZ83CcoKDyQHzTUounU1DT5hW3mdLY4 Nv4g== X-Forwarded-Encrypted: i=1; AJvYcCV8MgjYNi3w6/l+tOlSbk64xdLmIDx1PWFLAvr8afayLO33GmHwx4of5e2cCl5B3wOyJE6MxZBYQCWtwI1VVlAAhqU= X-Gm-Message-State: AOJu0Yxg7/LsA7XIgIu/9qIqnNJ4KqdiZLyBnsqUv3L0pQ2VP76EZFJR mvdI4Io42gnh5a6I6BUNNsa63xW68B3R2IM4oyPctxwArL9aZrCIXhNm2cNm3tNbYn3LocUlznF zM9eyfLJiGz+uVEpRRl/00Ep5aU8= X-Google-Smtp-Source: AGHT+IE8YG5pmyFM3Gt3hUzOIz0+yzyv7VRZmBp1lKn/TW1F90p6br2E0LiamSC9AepikX1hz6cwIjxvmy9llhLFOho= X-Received: by 2002:a05:6902:1248:b0:e0e:cd17:610a with SMTP id 3f1490d57ef6-e1180e6b2b6mr13912288276.6.1724068649755; Mon, 19 Aug 2024 04:57:29 -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:53 +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-Rspam-User: X-Stat-Signature: yrj9ciricwwfnqufnyuwrdp5mrqbhd9k X-Rspamd-Queue-Id: 9AD874000F X-Rspamd-Server: rspam11 X-HE-Tag: 1724068650-393845 X-HE-Meta: U2FsdGVkX1+CPIvHrxgVR8fbM5IqJykvgkFegfFYtwghbKCpVjTJ/HOyLQOCMoBvoJ38RcG3PKwgR23QhsOToHegQoBzvgIjrHLH+DYLP7wlD0q2OlHf4UbKHWLpsZH0o/JLttZz6URDS1e4g8rmz47y6zxLvLCELqPee4kRkK4rJbpYXtyqhYstlS5+ljIN4ocE+pYx545LQvVr9GcVE+YJg3dV1Zpc9d1o0cht09q/RTlM11k97nWVQsAgdWFlXS0cO97Nv2SsSJgj3AwuoF57xdmZ/vdIyzse5JMubKG9GoZCHUGNJy6GudH5qqMD52wnsId/gCUB7wFMEdquZ9WBAdFGnh5FsVWlBlMiRIkro/zAnyGvTwFxk6ZGr12CUxxcgjJGQ+A8eg8q2vJvyY+K6i3af0Hul4WSRmunSMU9QtD1BHtVgeLhgLp4BKMH5G4navM3em/YDKyhbmyUTHtZbmDBMYXshxs1gy/1fSZQLQL0ckoGyejToUbavQa0NMOFZokGMvt+bHSLEAFongNeZ71Gk/WRgUCmfY/EAKg+RJ7rf/2ZHiGFpJk8o3h+VMTZt9xSmHTtyKO9Sxlytt7CATHlCQIhcy3RHo38jcgLz/ssbtnYJaBCRgHa+Nw7sIkT244uwUMVV0zh9PFjrSVzN+d7Co3qXmZfupUg83rcpYP2KPSMOI2LbtnsZJ+fZfwU2poacec1Bgq5XkIavJilRWmZi3fDWc5/VGV+uT2RBLUMKG/Jo0Ka4Fx884EZVNrUFsbc86pgqPFO6Z4SppWSNy2EgW9B23RxB8557kDloD3XqguzNZnI/MZGZ/eQX5I7Din7xtY17yDt2Nty6PW3SSpfP1CvlhuEW1anYAI2IsOqXHc0OrebfQqY67sd66/LkZ2MUdhhY4eEPqDnxmO1F4SyWUkz5h/UJqflSyvcrLvQ6gM1jX/ydX88IyyMNVh5genMgh+0RwnZKai rhgjbu6v FeQwYO6gVggKTnWzZZHGWsli8fJ+eqKvkA4sBTXxraJiL9/Gjofjb3SOlgLmoyhmNHgMnAw4mZn1YIAxwcXagwhXzzYTtDTswKr6qEIrzSf+VwvQ1ry038Qve+rM6XA3GY7yyy6/dC4BVQzjPLunErNz7ADSTIn6D8ou0NT5Pc9Z1WImHJ9cUdhzOwAvy7+JtoEHIRLGSuUnrnNIDQLP4FdHnsgHxP2jAFKxr6vRA0xPZQqclD7mRWP/xwvGMO+JuLtc1yEeNw1MZHGj8EAbKdGZ1txirNjjce18ZSxcdijsPThAIa1+KmAF7NxmN51SH9T1QGfyYKMXwMDIqJZupB7+bCl4SId9cL7ZTPbx1BKVsxP7LMKtWJUKQrMKLeaST4ygOKdZlbAiu88826j/cAeePuCGWUSJLUMtnhnNc2CLp5e7WXq8z+EcUW1TDpF6cCio+k3YG8grFjTOhA2CtJRFRjBad2TVMVn6zA6ZBZrAfc0HIq3NBuda/h1AdGpMCqbJ/CIcoqcDesLhOvGuhehmlbv/p5BtJ76tqLPu0pPME+bHq8gUGne3tVXOB7bIiuoZ3GxyvP5qk0EEfgmQCkCCznQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000263, 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:10=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > 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.com> = 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@gma= il.com> wrote: > > > > > > > > > > > > > > From: Barry Song > > > > > > > > > > > > > > When users allocate memory with the __GFP_NOFAIL flag, they m= ight > > > > > > > incorrectly use it alongside GFP_ATOMIC, GFP_NOWAIT, etc. Th= is 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 rec= lamation or > > > > > > > kswapd rescues the current process. However, this is unre= liable > > > > > > > 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 mem= ory, it > > > > > will sleep if necessary and it will will trigger OOM killer if th= ere is > > > > > no other option. __GFP_DIRECT_RECLAIM is a completely different s= tory > > > > > than without it which means _no_sleeping_ is allowed and therefor= e 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 betwe= en > > > > a livelock, soft lockup, or hard lockup. > > > > > > This is certainly different. A lockup occurs when tasks can't be sche= duled, > > > 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 retr= ies without successfully allocating pages=E2=80=94simply failing the operation might be the better option. > > 2. no matter if it is an unsupported case, such as, GFP_ATOMIC| > __GFP_NOFAIL, we always loop till a soft or hard lockup? -- Regards Yafang