On Wed, Aug 21, 2024 at 02:37:33PM GMT, Michal Hocko wrote: > 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. Ugh, I really don't like that we have to add a flag argument especially for an api that's broken but fine.
