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 98FC9C3DA4A for ; Mon, 19 Aug 2024 07:56:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D2CF6B007B; Mon, 19 Aug 2024 03:56:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 083046B0082; Mon, 19 Aug 2024 03:56:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3F4E6B0088; Mon, 19 Aug 2024 03:56:29 -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 C1C2B6B007B for ; Mon, 19 Aug 2024 03:56:29 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 47110A8928 for ; Mon, 19 Aug 2024 07:56:29 +0000 (UTC) X-FDA: 82468237698.18.79CCFC9 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf12.hostedemail.com (Postfix) with ESMTP id 5467340005 for ; Mon, 19 Aug 2024 07:56:27 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=X2GkCwzW; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.41 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=1724054101; 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=TZy1R/aGokLe46oAtBLjuw7d3h1Spy9qlLcDxS6nr+M=; b=G8VnE33yYXF1XOItp46ze2W5hL9kD74TBt8si1RfVDqggQaElu+Yu9TkVa2x7B6wkB8GS7 JibxTs4Wwp9NJLx7pZ0b7+gKC+mgMQ+eGA6+PvVaegblULn6ha5xIAwuszZPBPbKw1+/Xx NL0zOgSFr6T+n9pA2/klPP+1bHDP3mw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724054101; a=rsa-sha256; cv=none; b=boKN751QfKsw1uEUmxHdISRZEDibYrlu3CckM4u/cyaknLCn1muLoPa8jurAgvWEpojTdA wnMck229y8Cb2cQbpOM87XvEBAh4pyRkF7KKelNXbLfNNsTU2K18EycNxjM5SXA3T86Q4n vl2rUuyAqQM9wRnSvhGdHPNCNNpa2oQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=X2GkCwzW; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-58ef19aa69dso3976724a12.3 for ; Mon, 19 Aug 2024 00:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724054186; x=1724658986; 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=TZy1R/aGokLe46oAtBLjuw7d3h1Spy9qlLcDxS6nr+M=; b=X2GkCwzWx2Lf8lNfJ4JC47LY76ax66e1xPAM398sUCqundIrvXZ0vIEzUykMGWb/iV eCiJ3MojJ/pR/wO3d554cimZMG6E1LzqDlmUvHD+2n8keiMCAmeMTfxr+pNm2A4HiE2I pyNiotf9WokmsYfb3VbA1jVIhy3rVsblt41zzikEeJwnl9S5O8AtsjxYJAcZ+iGwUrcN Bjm/kOVSCuY14v/LusbkoaM0I33G1Hz8ASJ39Qefr797+X25cUDfIx+z7mfl6+0O2WJF u1H0RdKdTLosysaZGP/V0DT+Ql1dFck5G18k1msi/3avz+4a+hC8EUEPljQZF95Q6w1v 0k2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724054186; x=1724658986; 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=TZy1R/aGokLe46oAtBLjuw7d3h1Spy9qlLcDxS6nr+M=; b=S1okqo8KB7sCENM/79gHCboD0J5lj3UlSOv8syOUjZK2QLBMqV2eCRTb6rg/y8141I iOQewpSmNrNJNahYzbKX/LbAbDaSQBI+AwFt9q3poiEpoJyZwuDUzgfY8lQfUFumr+R/ taQooOEMG5wd6pgUZ59t4RWiTb6nEUrAmr4qQ+KwqPKtgE98fSYF1ZkJmbF7I/poLxPq 5+Lrt1dEmCwPL5kNflZP5s0kkDSrcoDprrD5MWpLN5q1ocR+4J/NToI5FTuz1nOKb6B1 EgL5JE/ygEP91x0s4q73qxPv7s9n0pSeGh0iCvlL+wGKl3MvsWVKCzNv4u5vOfkZ+tMo dRuw== X-Forwarded-Encrypted: i=1; AJvYcCUHd43lYSa9ke2z/wPBMHIlCP9IyDsTazs4MM46VckqI4V6IDGWZdHDJjQ/sbv/ARcRLCnz4E3Z2wkkUa/ieMporsI= X-Gm-Message-State: AOJu0YzMTi5sX9CN4KVnxwLO/j3OmgieN19Sib92ZoR1jMAvfnLrKq7d FYhn9ZRmdtWSMwXTcm2bLoaGGYl1QVHXvlNJPTu4tDafoXCM4+vUd8G1121xyFBXk+chbE0ALkx x X-Google-Smtp-Source: AGHT+IG7tile/06Xpownlqx6q8Tlrt9mUJtZaMBoQ5z0zzagdeFkMFHBefIzXhIlqDXtAF7x4PLKjg== X-Received: by 2002:a17:907:94d4:b0:a77:bfca:da57 with SMTP id a640c23a62f3a-a8392a1149bmr663686766b.44.1724053805986; Mon, 19 Aug 2024 00:50:05 -0700 (PDT) Received: from localhost (109-81-83-72.rct.o2.cz. [109.81.83.72]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a83839471e1sm599610666b.152.2024.08.19.00.50.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 00:50:05 -0700 (PDT) Date: Mon, 19 Aug 2024 09:50:05 +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: 5467340005 X-Stat-Signature: wrowu16g616ygdz5ii6rbxwrqa6mkoio X-Rspam-User: X-HE-Tag: 1724054187-730735 X-HE-Meta: U2FsdGVkX1/RHqhTZePn+s28b4V7GmGrtr9g3Rf0ZnPKRIhKv08roZmM4VJkipmqsW+64tWktdGSIs+VqEgqEz9zPd9ryOhc/I+GByr6Zfq0B69PcgHNASgJvbmIoQBeqXkFk2xqsPWcSuyXOgNxRZaBcovxrXS6eR4JjfqLW4H/JhPHVjAHdjhu+PqD1hfdRJ0kzV4l6q9oH5zC+ICRwMf5Hg44lcWvP/5WFuME3s8PqP7BaU0Gd6NeGFxjsWg9mr1QgnPUUs8jSr7m/ovVjp+QE/e1eGMfvLlGZsWTfpSeUwEb1jWG87nh4GhTpfipWBUxc8XRuo4smtT7i7J8zzEsoW31t0dzaiqGnxi3snjYLvWcUg+K2oZ/EMBKW6LfEQkKx/mnoW4uTnS0jVCziYGPvW27DYDDmU0L5RGLG2PWxEq/GozkhcsBcU5fbqWzvwblgk6UB8b8wp+zYC8WcqoolV8K3CNIprOYYzJRu+a3EHiCWgT+YKTirq0PnLvIwoGwy+rR4FqeYMWl6lJjYXB9D+otIKzYfTRC7urqwWnGdtmQ33CybEABLEB7EH18fa3B5hu1Hn5FXnR32+xzZ+dsBgXIVWGkc3roil+NrbCdTQMcpAHM8EO55lkmtrClUXZ/220o2yNbeyxJXXoau4hZm+czSq0wGwRUKI9G6L2RGSy+m/H9SEBCUoDou0q/QBmVdGZfHtUgghgWuVEyKKatUWHifjtAE5/PRqwZd5quzWrMm8c+ecAbfQ7ABDUtml8Qy+HlpL5e+u+rHvGLu9WlVzgvCNQpoyx0R/VTbycN1vbd/vC+c78FX63xqMw7JhkNMDNCGpR/xcmzYvQYaspux7kNzUyd+Z2dy7l+9qhr/SRSwty8dvhigjXmTyxaxlPEBRXfB+2gmsZU5U+6BS/VayY6U66jsHkGWqgRh8sCVKbTcbit1F33P079sMXc1/CFJWjRC/7McjmHaQn v1vbHiPp Ure34pAi5tk2T5Zpp885B6hHdTF1NziAHQABNKtdwGRujVFxDKuvhFlXLyGCyEtPM/PjqWoVeivBCtiU8nNG5QYJOqExrf+bXM87+caUx2i410MXvQrlsDcEHY+y9IAIQ4GR5BEWhM1D/y6TgekerGp7U8mo/wAM8rJTPtCUCA2IsdOWhA7rAtDnOS4HknSIkJbrlm3sy7H1Y281bI3KaiqE+TfiFkEsRveFafXylNqSrT2iuKQIisropn86Lq/S6JUAdMxmrM0xHUXHp/pzJTeZYB5Vy0BHsfGQI2gGUp4fCVL/gZiA2s7CzuxOc/E0Y9FBo2l4JPA6pVEEmTkZ2EQNzVdj4BJOXUQqQ8q/GmYCd0/Y/096+oO5+NHqN866PDwEhSIZlSaotflYBCS8/jtOvhBwKXgcvdsjf5rfmFwQBnUlFURl1CQmWE49AmuQPnzkdLwJglWHzeYL/jeo00p/a8/BQ5grONmN+KYPU7TDXdy1oOd0ALeG4kPneqwIfjmmc X-Bogosity: Ham, tests=bogofilter, spamicity=0.057664, 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 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. > 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? -- Michal Hocko SUSE Labs