Re: [PATCH] mm: document risk of PF_MEMALLOC_NORECLAIM

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

 



On Wed 21-08-24 04:44:03, Christoph Hellwig wrote:
> On Fri, Aug 16, 2024 at 10:54:37AM +0200, Michal Hocko wrote:
> > Yes, I think we should kill it before it spreads even more but I would
> > not like to make the existing user just broken. I have zero visibility
> > and understanding of the bcachefs code but from a quick look at __bch2_new_inode
> > it shouldn't be really terribly hard to push GFP_NOWAIT flag there
> > directly. >
> 
> I don't understand that sentence.  You're adding the gfp_t argument to
> it, which to mean counts as pushing it there directly.

Sorry, what I meant to say is that pushing GFP_NOWAIT directly seem fine
unless I have missed some hidden corners down the call path which would
require a scope flag to override a hardcoded gfp flag.
 
> > It would require inode_init_always_gfp variant as well (to not
> > touch all existing callers that do not have any locking requirements but
> > I do not see any other nested allocations.
> 
> inode_init_always only has 4 callers, so I'd just add the gfp_t
> argument.  Otherwise this looks good modulo the fix your posted:
> 
> Acked-by: Christoph Hellwig <hch@xxxxxx>

Thanks. I will wait for more review and post this as a real patch. I
would really appreciate any help with actual testing.

-- 
Michal Hocko
SUSE Labs




[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