mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: wubo.oduw@gmail.com, linux-kernel@vger.kernel.org,
	Wu Bo <bo.wu@vivo.com>,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 1/1] f2fs: allocate trace path buffer from names_cache
Date: Thu, 20 Apr 2023 09:10:35 +0800	[thread overview]
Message-ID: <0d53c53a-ebbd-292d-8c61-154cc98c5498@kernel.org> (raw)
In-Reply-To: <ZEBE2iT/fKhnhrhg@google.com>

On 2023/4/20 3:45, Jaegeuk Kim wrote:
> On 04/19, Jaegeuk Kim wrote:
>> 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@vivo.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@kernel.org>
>>
>> What is this for?

Oh, I mean I'm okay w/ original patch, because f2fs_trace_rw_file_path()
doesn't have complicated error handling.

>>
> 
> If we want to keep the error injection, how about this?

Both original patch or below patch w/ fault injection is fine to me.

Free feel to add rvb tag of me. :)

Thanks,

> 
> Signed-off-by: Wu Bo <bo.wu@vivo.com>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>   fs/f2fs/f2fs.h | 13 +++++++++++++
>   fs/f2fs/file.c |  4 ++--
>   2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 6cae94d51821..d87044516fe9 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -3347,6 +3347,19 @@ static inline void *f2fs_kmalloc(struct f2fs_sb_info *sbi,
>   	return kmalloc(size, flags);
>   }
>   
> +static inline void *f2fs_getname(struct f2fs_sb_info *sbi)
> +{
> +	if (time_to_inject(sbi, FAULT_KMALLOC))
> +		return NULL;
> +
> +	return __getname();
> +}
> +
> +static inline void f2fs_putname(char *buf)
> +{
> +	__putname(buf);
> +}
> +
>   static inline void *f2fs_kzalloc(struct f2fs_sb_info *sbi,
>   					size_t size, gfp_t flags)
>   {
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 1b4411271f54..5ac53d2627d2 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -4372,7 +4372,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 = f2fs_getname(F2FS_I_SB(inode));
>   	if (!buf)
>   		return;
>   	path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX);
> @@ -4385,7 +4385,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);
> +	f2fs_putname(buf);
>   }
>   
>   static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)

  reply	other threads:[~2023-04-20  1:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14 10:43 Wu Bo
2023-04-18 15:51 ` Chao Yu
2023-04-18 16:07   ` Jaegeuk Kim
2023-04-19  6:28     ` Chao Yu
2023-04-19 18:18       ` Jaegeuk Kim
2023-04-19 19:45         ` [f2fs-dev] " Jaegeuk Kim
2023-04-20  1:10           ` Chao Yu [this message]
2023-04-19  1:32   ` Wu Bo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d53c53a-ebbd-292d-8c61-154cc98c5498@kernel.org \
    --to=chao@kernel.org \
    --cc=bo.wu@vivo.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wubo.oduw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®