Messages in this thread | | | Date | Tue, 11 Jan 2022 10:55:31 -0800 | From | Roman Gushchin <> | Subject | Re: [PATCH v5 03/16] fs: introduce alloc_inode_sb() to allocate filesystems specific inode |
| |
On Mon, Dec 20, 2021 at 04:56:36PM +0800, Muchun Song wrote: > The allocated inode cache is supposed to be added to its memcg list_lru > which should be allocated as well in advance. That can be done by > kmem_cache_alloc_lru() which allocates object and list_lru. The file > systems is main user of it. So introduce alloc_inode_sb() to allocate > file system specific inodes and set up the inode reclaim context > properly. The file system is supposed to use alloc_inode_sb() to > allocate inodes. In the later patches, we will convert all users to the > new API. > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > Documentation/filesystems/porting.rst | 5 +++++ > fs/inode.c | 2 +- > include/linux/fs.h | 11 +++++++++++ > 3 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst > index bf19fd6b86e7..c9c157d7b7bb 100644 > --- a/Documentation/filesystems/porting.rst > +++ b/Documentation/filesystems/porting.rst > @@ -45,6 +45,11 @@ typically between calling iget_locked() and unlocking the inode. > > At some point that will become mandatory. > > +**mandatory** > + > +The foo_inode_info should always be allocated through alloc_inode_sb() rather > +than kmem_cache_alloc() or kmalloc() related.
I'd add a couple of words on why it has to be allocated this way. > + > ---
Reviewed-by: Roman Gushchin <guro@fb.com>
Thanks!
| |