Re: [PATCH v4 05/36] fs: Convert alloc_inode_sb() to a macro

From: Suren Baghdasaryan <surenb@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev,
	mhocko@suse.com,  hannes@cmpxchg.org, roman.gushchin@linux.dev,
	mgorman@suse.de,  dave@stgolabs.net, willy@infradead.org,
	liam.howlett@oracle.com,  penguin-kernel@i-love.sakura.ne.jp,
	corbet@lwn.net, void@manifault.com,  peterz@infradead.org,
	juri.lelli@redhat.com, catalin.marinas@arm.com,  will@kernel.org,
	arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com,
	 dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com,
	 david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org,
	masahiroy@kernel.org,  nathan@kernel.org, dennis@kernel.org,
	tj@kernel.org, muchun.song@linux.dev,  rppt@kernel.org,
	paulmck@kernel.org, pasha.tatashin@soleen.com,
	 yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com,
	 hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org,
	 ndesaulniers@google.com, vvvvvv@google.com,
	gregkh@linuxfoundation.org,  ebiggers@google.com,
	ytcoode@gmail.com, vincent.guittot@linaro.org,
	 dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com,  bristot@redhat.com, vschneid@redhat.com,
	cl@linux.com, penberg@kernel.org,  iamjoonsoo.kim@lge.com,
	42.hyeyoo@gmail.com, glider@google.com,  elver@google.com,
	dvyukov@google.com, shakeelb@google.com,
	 songmuchun@bytedance.com, jbaron@akamai.com,
	rientjes@google.com,  minchan@google.com, kaleshsingh@google.com,
	kernel-team@android.com,  linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,  iommu@lists.linux.dev,
	linux-arch@vger.kernel.org,  linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org,  linux-modules@vger.kernel.org,
	kasan-dev@googlegroups.com,  cgroups@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v4 05/36] fs: Convert alloc_inode_sb() to a macro
Date: Mon, 26 Feb 2024 09:48:46 -0800	[thread overview]
Message-ID: <CAJuCfpEQPgg6-TD+-PEsVRXnK=T0Ak6TvMiwz7DbS-q9YxsVcg@mail.gmail.com> (raw)
In-Reply-To: <f68e7f17-c288-4dc9-9ae9-78015983f99c@suse.cz>

On Mon, Feb 26, 2024 at 7:44 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 2/21/24 20:40, Suren Baghdasaryan wrote:
> > 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.
> >
> > Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> > ---
> >  include/linux/fs.h | 6 +-----
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 023f37c60709..08d8246399c3 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -3010,11 +3010,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)
>
> A __always_inline wouldn't have the same effect? Just wondering.

I think inlining it would still keep __LINE__ and __FILE__ pointing to
this location in the header instead of the location where the call
happens. If we change alloc_inode_sb() to inline we will have to wrap
it with alloc_hook() and call kmem_cache_alloc_lru_noprof() inside it.
Doable but this change seems much simpler.

>
> > -{
> > -     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)
> >
> >  extern void __insert_inode_hash(struct inode *, unsigned long hashval);
> >  static inline void insert_inode_hash(struct inode *inode)
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>