[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZEAwcaVlYq+PNwEK@google.com>
Date: Wed, 19 Apr 2023 11:18:25 -0700
From: Jaegeuk Kim <jaegeuk@...nel.org>
To: Chao Yu <chao@...nel.org>
Cc: Wu Bo <bo.wu@...o.com>, linux-f2fs-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, wubo.oduw@...il.com
Subject: Re: [PATCH 1/1] f2fs: allocate trace path buffer from names_cache
On 04/19, Chao Yu wrote:
> On 2023/4/19 0:07, Jaegeuk Kim wrote:
> > On 04/18, Chao Yu wrote:
> > > On 2023/4/14 18:43, Wu Bo wrote:
> > > > It would be better to use the dedicated slab to store path.
> > > >
> > > > Signed-off-by: Wu Bo <bo.wu@...o.com>
> > > > ---
> > > > fs/f2fs/file.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > > index 15dabeac4690..27137873958f 100644
> > > > --- a/fs/f2fs/file.c
> > > > +++ b/fs/f2fs/file.c
> > > > @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw)
> > > > struct inode *inode = file_inode(iocb->ki_filp);
> > > > char *buf, *path;
> > > > - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL);
> > > > + buf = __getname();
> > >
> > > How about:
> > >
> > > buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, F2FS_I_SB(inode));
> >
> > This looks like a hack using names_cachep?
>
> names_cachep was exported in fs.h.
I think that's for __getname() in general, which doesn't indicate you can hack.
No one is using like that.
$ grep names_cachep fs/* -R
fs/dcache.c:struct kmem_cache *names_cachep __read_mostly;
fs/dcache.c:EXPORT_SYMBOL(names_cachep);
fs/dcache.c: names_cachep = kmem_cache_create_usercopy("names_cache", PATH_MAX, 0,
$ grep __getname fs/* -R
fs/ceph/mds_client.c: path = __getname();
fs/cifs/cifsproto.h: return __getname();
fs/dcache.c:/* SLAB cache for __getname() consumers */
fs/d_path.c: char *page = __getname();
fs/exfat/dir.c: nb->lfn = __getname();
fs/f2fs/file.c: buf = __getname();
fs/fat/dir.c: *unicode = __getname();
fs/fat/namei_vfat.c: uname = __getname();
fs/hostfs/hostfs_kern.c: char *name = __getname();
fs/namei.c: result = __getname();
fs/namei.c: result = __getname();
fs/ntfs3/dir.c: name = __getname();
fs/ntfs3/xattr.c: buf = __getname();
fs/ntfs3/inode.c: new_de = __getname();
fs/ntfs3/inode.c: de = __getname();
fs/ntfs3/inode.c: de = __getname();
fs/ntfs3/namei.c: struct cpu_str *uni = __getname();
fs/ntfs3/namei.c: de = __getname();
fs/ntfs3/namei.c: struct cpu_str *uni = __getname();
fs/ntfs3/namei.c: uni = __getname();
fs/ntfs3/namei.c: uni1 = __getname();
fs/vboxsf/utils.c: * Returns a shfl_string allocated through __getname (must be freed using
fs/vboxsf/utils.c: buf = __getname();
fs/vboxsf/utils.c: shfl_path = __getname();
>
> > Using f2fs_kmem_cache_alloc is able to inject malloc error.
> > But here is a trace event, is it ok to inject error in a trace path?
>
> Yes, the fail path handling is very simple, so it's fine to leave it
> as it is.
>
> Reviewed-by: Chao Yu <chao@...nel.org>
What is this for?
>
> Thanks,
>
> >
> > >
> > > > if (!buf)
> > > > return;
> > > > path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX);
> > > > @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw)
> > > > trace_f2fs_dataread_start(inode, iocb->ki_pos, count,
> > > > current->pid, path, current->comm);
> > > > free_buf:
> > > > - kfree(buf);
> > > > + __putname(buf);
> > >
> > > kmem_cache_free(names_cachep, buf);
> > >
> > > Thanks,
> > >
> > > > }
> > > > static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
Powered by blists - more mailing lists