On Thu, Mar 21, 2024 at 01:31:47PM -0700, Andrew Morton wrote:

On Thu, 21 Mar 2024 09:36:27 -0700 Suren Baghdasaryan [off-list ref] wrote:

quoted

From: Kent Overstreet <kent.overstreet@linux.dev>

We're introducing alloc tagging, which tracks memory allocations by
callsite. Converting alloc_inode_sb() to a macro means allocations will
be tracked by its caller, which is a bit more useful.

I'd have thought that there would be many similar
inlines-which-allocate-memory.  Such as, I dunno, jbd2_alloc_inode(). 
Do we have to go converting things to macros as people report
misleading or less useful results, or is there some more general
solution to this?

No, this is just what we have to do.

But a fair number of these helpers shouldn't exist - jbd2_alloc_inode()
is one of those, it looks like it predates kmalloc() being able to use
the page allocator for large allocations.

quoted

--- a/include/linux/fs.h
+++ b/include/linux/fs.h

@@ -3083,11 +3083,7 @@ int setattr_should_drop_sgid(struct mnt_idmap *idmap,
  * This must be used for allocating filesystems specific inodes to set
  * up the inode reclaim context correctly.
  */
-static inline void *
-alloc_inode_sb(struct super_block *sb, struct kmem_cache *cache, gfp_t gfp)
-{
-	return kmem_cache_alloc_lru(cache, &sb->s_inode_lru, gfp);
-}
+#define alloc_inode_sb(_sb, _cache, _gfp) kmem_cache_alloc_lru(_cache, &_sb->s_inode_lru, _gfp)

Parenthesizing __sb seems sensible here?  

yeah, we can do that