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 54345C3DA4A for ; Mon, 19 Aug 2024 12:09:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDF6F6B007B; Mon, 19 Aug 2024 08:09:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C90036B0082; Mon, 19 Aug 2024 08:09:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B306D6B0088; Mon, 19 Aug 2024 08:09:55 -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 94BE56B007B for ; Mon, 19 Aug 2024 08:09:55 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3421B141280 for ; Mon, 19 Aug 2024 12:09:55 +0000 (UTC) X-FDA: 82468876350.25.A436C0E Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf28.hostedemail.com (Postfix) with ESMTP id 069F0C0017 for ; Mon, 19 Aug 2024 12:09:52 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CczqtULW; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724069306; 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=VsXc2LF6RY+Mbl+0XKQZtcelxbPxf1NuiraWq9n6YWk=; b=UKehJzRS6HoI6TU1XdjFd/AQbSo/ibGB58vsRrZhzTzBl+oZ6FfHklsFRJunG10FzzpT5/ 2+ryRNLSAHWGxlQxuT1YXq0q2Q9xJAwzNwZND8A2ub3G5+zrC/hyJSX2D/ixWD/gewyYnc 3FwgudD1o+MLK8tzaGvH6zCGuZGZuDo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724069306; a=rsa-sha256; cv=none; b=G1Tf3c2GQpDVRiufuir3H5Z2FNLBgBt7dkxXBXiCMFj4qQpn6O0tvNcWx9B6L9eo3tC+BZ rNyL5r/Tu6N9fqpOy5jhzTBnqiPYK+onOawTxO4yyF4b/powpkvp1irEJktlFI8JiqmoLr qNDeyCcx7rVtnQA6rvYREd1AL8VhYTw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CczqtULW; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2f3ce5bc7d2so18607691fa.0 for ; Mon, 19 Aug 2024 05:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724069391; x=1724674191; 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=VsXc2LF6RY+Mbl+0XKQZtcelxbPxf1NuiraWq9n6YWk=; b=CczqtULWtTpacZx4w2nENWvC1p45RTsJ7FOz78tkhWQlAxcOG6EqL69tkQmFCffVwC 8JfRxRu5yE1VpTOnqZ/YrV7pgZtUKAlL23ofIHkAH6APh4ws1d8qNve3hK+3JX2NhDT9 lwFXLyVnwt7eTLfB1+bRZhGhoI5s43+td6sJOWCmyPlAYTOAmEn8n5YBPioX1sgtckJ6 bx7AOghQ9MHBwEnVyo3okh7ipqhZvU+QrRovojUOjoFXNJ+2JniGPmw38gHVcKLmhRWf 9PCkk2Mt6shf4xD5SMBZx0swRy5eOzjfOeh369YFs8Nbqyj0S9GX6O7sLj9N9TQQNwGT FCnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724069391; x=1724674191; 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=VsXc2LF6RY+Mbl+0XKQZtcelxbPxf1NuiraWq9n6YWk=; b=C0QVzSPdUhJH+3t3tOpbv12kgWyr3tVw12F1YReVGeB02SMq3waGqjHBh02PzRp5BX 5pdt3GeEcTwve0LoUA4F62VuqgKE/NO6SehJw/kBXQyOYB8rEtg/Uv0bbqug0EYr3tec P3nkY20APJZRDS8+Smf74VgYv1OqsDgAAN/LFb8ZD84FAtQj7MKwp1aI+b0VPjxrymcl UmY3fZOWrC/Bdwg75We4J3/XvGCVkg5HWl/zld+wqnO0yOkiDPiKAYNqxxl5ixUHGZsP kA5agoZiwGW7N7cQUOemDvhaaInpR4vmcRS5BDOtMrp/BxtCM1WVeu59Uau6XFCHPCWA Iidw== X-Forwarded-Encrypted: i=1; AJvYcCXEQx2/Xt6h7lBpPA9snYzzM+LUGn0KXnqLU/LMKNLvepH6EENFx+KqOYyzweDZzuXNPTHcwZVb6OOhpV2f1ni0TJ4= X-Gm-Message-State: AOJu0YwoqN84j3zfnsd5QsExULTEGL/1cfILrc4IswiVDJEMXN5VRbnw ALHikZSM9+lhoglqfmIYI2GyyfjRNg55WbKD56/kAygvFZ5Sd2C6PvkNKKJ2Wjs= X-Google-Smtp-Source: AGHT+IF3tfkg4bHEJaHO7fC9laXoEarCWgUUsjT+mRti4XGeALMRYiGfJyow6r+v1G/f4J/p5pqqTg== X-Received: by 2002:a2e:9b50:0:b0:2f3:abb4:4f08 with SMTP id 38308e7fff4ca-2f3be58574emr69486761fa.12.1724069390888; Mon, 19 Aug 2024 05:09:50 -0700 (PDT) Received: from localhost (109-81-83-72.rct.o2.cz. [109.81.83.72]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5bebc081cf5sm5475615a12.90.2024.08.19.05.09.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 05:09:50 -0700 (PDT) Date: Mon, 19 Aug 2024 14:09:49 +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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 069F0C0017 X-Stat-Signature: zc93m9wayddei6yygdp19rdzceb9buhn X-Rspam-User: X-HE-Tag: 1724069392-330273 X-HE-Meta: U2FsdGVkX19aWDoc9Wc0sNA+sRjZQUO3QZuSLOKDzWLNyrxqEtXeBKCt515ZqV3vlXESMbgITROC7fR+LNWgZVfAJHQhFykRI2w5GiyLx9XyqgoMF0cj/Uwqe6d7XqBTb2NaAPpVmxY8YiWEq9EA5twXK4CXTOVljbDitSdivM+uVwQfcheNp4ajT2+UCAN9uQ2GQxclyPvrF7HLWvy5bAkZafjyM+7b6cAENWGVCTS7HUhDmLTfJNPmnp9xJLAQjod1x0LJJgctEBJBPxRv7r4fQdMMFWrq4XYnYY3HcW82OIiD7Ho+Hvd2ATfkmYpP59d+0Cmb9EX9vq95MIet2nBLtYBynmCTQk6VycBvLD3n0KS46SjUmNKyhDQ4x9+5wBKCe+I26MOGpUi1viTDD4l0z+qwYIhVX4Vahg1xCK+kj1AFmVtiyk85rS8RPLeFc2lrP7BRSsnDp5Fc2zwe2I4Ep6s5dRYT6GkqT1ykfpWkyAo7HPbciUG4xv5C9yj4NgxuIR0Z+0i5OOe8eyrRAjYhD69jNp7q3/6Nvh/qVJukeJXzHDIe9V6hHlEs9idlFOXaAufEOTICKIH477FvbkFZp/G6dp8qIDPeSsWa1odv14/de+DolhC33saSQhpHEa5O077AaPmjSrBHNAAAFlNDLYbJk876jcHIX/sjncHm8vQDHEhf4d1nyj2cw9BZkP5FibItBkkq9wmwaPpqqaI3jO2hum4yXFulSlGsic8ALnIyMZ15JVKYlxSbvaC2dMtew/CrFWSehHvQXM3n95KMKkoQ7Cn3gDXqOkay2likR5yNyahU/in3uY1ZJnA6uvZSaJE95JyJRTgkhpicTmYqQJm9ITZVd3aXohVcV8pOM8WEPib3d0wfGxMVgCM0fpCgjOQzN5JlQXozvnEcHpRy0iNx71b6XJay+3awv7nUByVH1IdtSwDKesWfYsEBEffee8lcyZEIZsWJHjg mWpclFUt qpoReTJyjf6AWXsQmR3Pt3zazz5LeM2bYZMgeXXiCNlCf6qjvyZ1kise85G6PgVysVrxwq6yClhgu79Kpr1qeb54BXLfF+2CPm+rKD+jTOg6UrWCG0Aw1s0pe/Qh5SSB1nkKRdnViUW2dicyRlmJJcqXlYg3L8t7Dq8G6EvPGw6oW6qkVyG3ypqlV1elH/vjG/HmTGFtSRHT8rFdpfECymdS1xJ9DupM+e/9lOOZPIMNORxjgaIiJvIIhytuXPaaXgt53V+lFcj/WznNMkxdElCrlO7sJ2ihks0SBkjJ3cathdJREB2MCFJgfau6lrOtCO8/G1UXqdQFMIP39qHJ7KApgM69E/79k4FdwOFAGT7E0OGJI9MYmrB9RitbgFD0a+wyYOpF+V9rU3THg0+fPz1usvfUKRXwAYy1n8EIwmnI5zyUZ9pyV67uEsiR+0k19vSTaEgdTI7LmAV9LUEkJaLhb6RXnYZKizPaL4UTGjLGZ9z08/YUyr4et9DFXTyopKt7b7Q1V64QIjy6+3XipqHsXtU/d8Zj1C2cAkGhjsknJBF1jmXkvoI+5R2PnrSBoRFbs X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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:53, Yafang Shao wrote: > On Mon, Aug 19, 2024 at 6:10 PM Barry Song <21cnbao@gmail.com> wrote: > > > > On Mon, Aug 19, 2024 at 9:46 PM Yafang Shao wrote: > > > > > > On Mon, Aug 19, 2024 at 5:39 PM Barry Song <21cnbao@gmail.com> wrote: > > > > > > > > On Mon, Aug 19, 2024 at 9:25 PM 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. > > > > > > > > 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—there’s 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—such as after reaching the maximum retries > without successfully allocating pages—simply failing the operation > 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 = alloc())); or BUG_ON(!(ptr = 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? -- Michal Hocko SUSE Labs