On Fri 16-08-24 10:54:39, Michal Hocko wrote: > On Fri 16-08-24 01:22:37, Christoph Hellwig wrote: > > On Fri, Aug 16, 2024 at 10:17:54AM +0200, Michal Hocko 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 > > > > I don't think that's enough. We just need to kill it given that it was > > added without ACKs and despite explicit earlier objections to the API. > > 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. 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. > > So a very quick and untested change would look as follows: Anybody managed to give it a more detailed look? I have a fixup for [...] > diff --git a/security/security.c b/security/security.c > index 8cee5b6c6e6d..8634d3bee56f 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -660,14 +660,14 @@ static int lsm_file_alloc(struct file *file) > * > * Returns 0, or -ENOMEM if memory can't be allocated. > */ > -int lsm_inode_alloc(struct inode *inode) > +int lsm_inode_alloc(struct inode *inode, gfp) this > { > if (!lsm_inode_cache) { > inode->i_security = NULL; > return 0; > } > > - inode->i_security = kmem_cache_zalloc(lsm_inode_cache, GFP_NOFS); > + inode->i_security = kmem_cache_zalloc(lsm_inode_cache, gfp); > if (inode->i_security == NULL) > return -ENOMEM; > return 0; -- Michal Hocko SUSE Labs
