On Thu, Oct 17, 2024 at 08:18:10PM +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > This is a note to let you know that I've just added the patch titled > > Revert "mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN" > > to the 6.11-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > The filename of the patch is: > revert-mm-introduce-pf_memalloc_noreclaim-pf_memalloc_nowarn.patch > and it can be found in the queue-6.11 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable@xxxxxxxxxxxxxxx> know about it. > > > From 9a8da05d7ad619beb84d0c6904c3fa7022c6fb9b Mon Sep 17 00:00:00 2001 > From: Michal Hocko <mhocko@xxxxxxxx> > Date: Thu, 26 Sep 2024 19:11:51 +0200 > Subject: Revert "mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN" > > From: Michal Hocko <mhocko@xxxxxxxx> > > commit 9a8da05d7ad619beb84d0c6904c3fa7022c6fb9b upstream. > > This reverts commit eab0af905bfc3e9c05da2ca163d76a1513159aa4. > > There is no existing user of those flags. PF_MEMALLOC_NOWARN is dangerous > because a nested allocation context can use GFP_NOFAIL which could cause > unexpected failure. Such a code would be hard to maintain because it > could be deeper in the call chain. > > 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. > > While PF_MEMALLOC_NOWARN is not dangerous the way PF_MEMALLOC_NORECLAIM is > it doesn't have any user and as Matthew has pointed out we are running out > of those flags so better reclaim it without any real users. Why's this being added to stable? It's definitely not a bugfix, and the reasoning ("inherently unsafe") was also incorrect.
