Re: [PATCH] mm: document risk of PF_MEMALLOC_NORECLAIM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 16, 2024 at 4:17 PM Michal Hocko <mhocko@xxxxxxxx> wrote:
>
> 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.80299-1-laoar.shao@xxxxxxxxx/T/#u
> ---
> From f17d36975ec343d9388aa6dbf9ca8d1b58ed09ce Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@xxxxxxxx>
> 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 <mhocko@xxxxxxxx>

Documenting the risk is a good first step. For this change:

Acked-by: Yafang Shao <laoar.shao@xxxxxxxxx>

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.

-- 
Regards
Yafang





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux