On Thu, Oct 17, 2024 at 02:22:13PM -0400, Kent Overstreet wrote: > 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. Because it is a revert of a commit that is in the stable tree, why wouldn't we want to take the revert there as well? Also makes future patches easier to backport. thanks, greg k-h
