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 9E720C3DA4A for ; Sat, 17 Aug 2024 02:30:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E08D66B034F; Fri, 16 Aug 2024 22:30:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB8C46B0350; Fri, 16 Aug 2024 22:30:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C804B8D0066; Fri, 16 Aug 2024 22:30:13 -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 AA58C6B034F for ; Fri, 16 Aug 2024 22:30:13 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1AAA812040B for ; Sat, 17 Aug 2024 02:30:13 +0000 (UTC) X-FDA: 82460157906.30.7BA36D6 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf21.hostedemail.com (Postfix) with ESMTP id 5CAE81C0018 for ; Sat, 17 Aug 2024 02:30:11 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bvxb0HOE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723861797; a=rsa-sha256; cv=none; b=6uQrpmtHhU/1/ePyTuuYDKzRSb0ZvzsQBRNo5AO8uwu0LoCchjqdFp5c4H3RqgibAG8WON zUJTRC1RuaFzkX+RmxxyZSzWjN+B/qZBzSSAj3J5zwEZKVDeIJV6NAjVmFqpKAE1BF+xCP stgpz9A7hMKu1sQLP8erItf1vWiBDHM= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bvxb0HOE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723861797; 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=rwAZjQgeVGZrYr9IuVBFyd4iX8rZTH/EnHUupg2Amrw=; b=eJkM1QVJDJ6qZYRRlkjPW1Vk80F3xFP6tjs2VLdC61Wlv2TmgDvxEZ8RwS5nHmw6G7Crld DjNaORLdv9/AfrSHRxN4N8iuFCjTRtsIShpBXunCQI0soTI0TtdLRfcE26U5lU05kN6tYh igFUjyEGa2TfNHnOhxzWBWQoaohCRp0= Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7a1d3e93cceso349550285a.1 for ; Fri, 16 Aug 2024 19:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723861810; x=1724466610; 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=rwAZjQgeVGZrYr9IuVBFyd4iX8rZTH/EnHUupg2Amrw=; b=bvxb0HOEccqTYn1Oy/DbMmSTq4czhhagxvlCJmE4JHyMxypb4oCEEPnvCiXoYNlvw/ GAiFE/lmwZdJgN7sEFFJdJWwvNQ3sgH/X0NIXmCZpEwHclHKpFzQWMl8JsCc7bIU2Kea 8YGL/5lsNPX5dbwdzAilgzkng5Iiyuoo2Jw+ihira2sIz17oxYFAZtZnq99AWb3Q16ij 2ojckW0j0yVwbVZ4Fw/SBQGHuRoHA2OX3V+/kBAcq9KECQREbz47EbQNOSqoNlTf12tl 9nWKVQJQsk7mMXy5l5mbKyE+m8dcttSeth8RIJZQPOOb+ApfzD/EVqyExhCqENu1E3bi P4iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723861810; x=1724466610; 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=rwAZjQgeVGZrYr9IuVBFyd4iX8rZTH/EnHUupg2Amrw=; b=RsXAMX7/JeDS0VulAjdhHS8aneJkZJfUmODa7aQXQ0vZWfbd5Wi+92S4FAXVftzAgB Kl6nHewhMzp7lVEHMtvvYZcuJ0SiOKIflEZYJWnRIo/MYxGeyaeHchsX0cHB6YFbzaJF wrN924UWrPR8D7BS1n8VK9u68SLojY15QrsiO4F3lmV9+eyvvmOP7uc709sQCUUdwDOa PR45sUoJencT3OL/A9Pkal1RHz3MZkIoAGI9Vqlhjof7W+jbUiWONa714Nu/hhLmONeD 1eX4kcDd0bTFqsdTUvHvfAPs7N1aR+mrNEm/SsLhQNjG68fBW+3QSgbLvxyNKoNuvYP3 QJ5Q== X-Forwarded-Encrypted: i=1; AJvYcCXWYLJ8FxIMBSUOCaduuY1pxXDy7arhLhfaKlUdepBxW4l+6M2DUamn3qsBZrvfnUeDSH5MFOPao7BJyK4UaQWjM6s= X-Gm-Message-State: AOJu0Ywmnlzb8YwrZslcORfYzhWMnfIWlX6GeK5pOBXbNU9rVf2EMYzM rie1Nx1mM6jq3r3FFVvRdK48gTakUGEB6CjRPZ8y9GAa+FA37levTb72cgqscWEt3JYcM/tFpzs 2idwQ7e1om3TYQ1Oqfj2KRZCfL1k= X-Google-Smtp-Source: AGHT+IH6/NH2oVuhgX6MdpvQ/jEnsYAyd6PV0KjqWitQwCLEl4gYN0YgHFSjzxPSCRIM1jsvzR/hFGchPXrQbfMKxME= X-Received: by 2002:a05:6214:3203:b0:6b2:9e53:fe50 with SMTP id 6a1803df08f44-6bf7d5b4121mr103159136d6.22.1723861810360; Fri, 16 Aug 2024 19:30:10 -0700 (PDT) MIME-Version: 1.0 References: <20240812090525.80299-2-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sat, 17 Aug 2024 10:29:31 +0800 Message-ID: Subject: Re: [PATCH] mm: document risk of PF_MEMALLOC_NORECLAIM To: Michal Hocko Cc: Andrew Morton , Christoph Hellwig , viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, david@fromorbit.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Kent Overstreet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 5CAE81C0018 X-Rspamd-Server: rspam01 X-Stat-Signature: w7j6i5dohw6fba6ebo1rgnkypz3st4cr X-HE-Tag: 1723861811-998608 X-HE-Meta: U2FsdGVkX1+2JUbisQ1F26re2A1V01GSoCqh3s01eriArH0RpNpdgO9+Z8gZKCK80ZTUguFdItIannx8pdZ6gixCEkwqyZUdh7W+63EIeEEhgUb2XhqLrwfO5WvsrqRVxlw7X87jrvQERf3FQKLR+L3pSHpSk482dTuuo4jv81U+SW8w8S3RKBhbKp1iX9yHft/Xs91K+kIGIs+B/Nvhdwr7esnzHKt8v8H4SsaLhFYRwsm1zi8NK0l6iiLdsJOThHu6h0GDBdKSwZj3K33zSIdACLjSNgMcONd9Bf655/cj+nGhoRPY8G1yKD5XxPTrA3500XbFzXsYBJCk/o8kbWNlOxWH6jakXMEXGeRqCa8lQVSxSwYEC8yMQOp2ejls/3mQCbZq7YKm8+xiHmlC7HBfxjAYTmSP2tD4Icogxmac0zpuRvKALsksOGll5TWyLWtBLP+x7USuA0O0urU3gpz1kITAfJ8gRszByXN8oYLMaAUE1rh9zCZcxmuBC4URLS8owOXEIeUysKcQZGw0Omnr/y7YAXMLxRJgEYHx9dPGJLa4G4c+tZVFAmh9/ANdSepuLugZVTJ4SxCxshk1lsFIaoTQQr2/SojbqiR5BspxZGNV5AJqmu/O9qKOVOO/nvn4nWsPYPodOOTRkXmU9lLZEbXd4KQvACBzzepOg3yxgnwb3HgNbqMKgFaHT2hWJTa3dmh40tUArTFCueJCFWD9adpTv2uTdmAIhcLiV1B54D7zFJID0OnH1SrKRKCqje/1v//cAunj5BbbqsRV58fqLLXKrCPi5/VNHrAR1HDm+ApGUfehT6RV00i1tJROcPphwu76AiQegj8opwWsvql2ppNcBh66xkIN0R0cIRlIjf7o9772FmoH2UQhTFgOyfAhQ9G7aktItiojd0eEMl0hu9ai2daJLZrLh/cPsTuXcWXPjTfcPlW8eDAjvTrBE/25kH9H8gcEJS/4lpW huBxUPMB qCUU5ncRcfONC30gMjciJhJgQzWdH3vG4hvYEGSiDQzBpBBCzjrXWBflXHo++YDSq7TD4U5Zvp9/ML+qYqDj90gKZGrlP6ev1Ywwx5pOyJiJ8OR9w7BpZkVL1HTHRsXWiqCiBleygoQqK5UAENaXeIfk+VIQRM6maK/JlJv03xBTmRPGoVV9nqPqs7nQbgg40Huplg0ee5WId4G/oul8Wirr/m8dpbIgs42XPYroE6nyWkfX5S6RCplmsP3rOWBgRDWUlm3MOO5WjdRuf8nIU9pHI8GcKDdzRIJzf2jnuoKoRW96Ot4DIDe5zB9exMRvMcBayMe/0jr0gR1NsH+u4Nk5EdYWYeks0uwphmMbTX+5xe9jJICWvtBhQXvBqKDjLeicXsSZ3JIrm+baXERBwu06CcYbDDK8QkFUvjS4ST/Fj4DJbBwC8+SqDChU0uydUOKfvpDXgEBn9uTPMpbf0d2L66bzWhf9VQCLbvr7j9JPh8PTWbk9o+pGmZziYB90MlrtFgdTakT9M8dJp07jZXuq5v9MfBIyWILEK X-Bogosity: Ham, tests=bogofilter, spamicity=0.135107, 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 Fri, Aug 16, 2024 at 4:17=E2=80=AFPM Michal Hocko wrot= e: > > Andrew, could you merge the following before PF_MEMALLOC_NORECLAIM can > be removed from the tree altogether please? For the full context the > email thread starts here: https://lore.kernel.org/all/20240812090525.8029= 9-1-laoar.shao@gmail.com/T/#u > --- > From f17d36975ec343d9388aa6dbf9ca8d1b58ed09ce Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Fri, 16 Aug 2024 10:10:00 +0200 > Subject: [PATCH] mm: document risk of PF_MEMALLOC_NORECLAIM > > PF_MEMALLOC_NORECLAIM has been added even when it was pointed out [1] > that such a allocation contex is inherently unsafe if the context > doesn't fully control all allocations called from this context. Any > potential __GFP_NOFAIL request from withing PF_MEMALLOC_NORECLAIM > context would BUG_ON if the allocation would fail. > > [1] https://lore.kernel.org/all/ZcM0xtlKbAOFjv5n@tiehlicka/ > > Signed-off-by: Michal Hocko Documenting the risk is a good first step. For this change: Acked-by: Yafang Shao Even without the PF_MEMALLOC_NORECLAIM flag, the underlying risk remains, as users can still potentially set both ~__GPF_DIRECT_RECLAIM and __GFP_NOFAIL. PF_MEMALLOC_NORECLAIM does not create this risk; it only exacerbates it. The core problem lies in the complexity of the various GFP flags and the lack of robust management for them. While we have extensive documentation on these flags, it can still be confusing, particularly for new developers who haven't yet encountered real-world issues. For instance: * %GFP_NOWAIT is for kernel allocations that should not stall for direct * reclaim, #define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN) Initially, it wasn't clear to me why setting __GFP_KSWAPD_RECLAIM and __GFP_NOWARN would prevent direct reclaim. It only became apparent after I studied the entire code path of page allocation. I believe other newcomers to kernel development may face similar confusion as I did early in my experience. The real issue we need to address is improving the management of these GFP flags, though I don't have a concrete solution at this time. Since I don't have a better alternative yet, I'm not strongly opposed to reverting the PF_MEMALLOC_NORECLAIM flag if it is deemed the root cause of the problem. --=20 Regards Yafang