linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@fastmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Yangtao Li <frank.li@vivo.com>,
	xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com,
	jefflexu@linux.alibaba.com, damien.lemoal@opensource.wdc.com,
	naohiro.aota@wdc.com, jth@kernel.org, rafael@kernel.org,
	linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/3] zonefs: convert to use kobject_is_added()
Date: Thu, 6 Apr 2023 19:58:38 +0900	[thread overview]
Message-ID: <d732a8f6-4a0a-d7ff-af9c-f377fefd1283@fastmail.com> (raw)
In-Reply-To: <2023040627-paver-recipient-3713@gregkh>

On 4/6/23 19:26, Greg KH wrote:
> On Thu, Apr 06, 2023 at 07:13:38PM +0900, Damien Le Moal wrote:
>> On 4/6/23 19:05, Greg KH wrote:
>>> On Thu, Apr 06, 2023 at 05:30:56PM +0800, Yangtao Li wrote:
>>>> Use kobject_is_added() instead of local `s_sysfs_registered` variables.
>>>> BTW kill kobject_del() directly, because kobject_put() actually covers
>>>> kobject removal automatically.
>>>>
>>>> Signed-off-by: Yangtao Li <frank.li@vivo.com>
>>>> ---
>>>>  fs/zonefs/sysfs.c  | 11 +++++------
>>>>  fs/zonefs/zonefs.h |  1 -
>>>>  2 files changed, 5 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c
>>>> index 8ccb65c2b419..f0783bf7a25c 100644
>>>> --- a/fs/zonefs/sysfs.c
>>>> +++ b/fs/zonefs/sysfs.c
>>>> @@ -101,8 +101,6 @@ int zonefs_sysfs_register(struct super_block *sb)
>>>>  		return ret;
>>>>  	}
>>>>  
>>>> -	sbi->s_sysfs_registered = true;
>>>
>>> You know this, why do you need to have a variable tell you this or not?
>>
>> If kobject_init_and_add() fails, zonefs_sysfs_register() returns an error and
>> fill_super will also return that error. vfs will then call kill_super, which
>> calls zonefs_sysfs_unregister(). For that case, we need to know that we actually
>> added the kobj.
> 
> Ok, but then why not just 0 out the kobject pointer here instead?  That
> way you will always know if it's a valid pointer or not and you don't
> have to rely on some other variable?  Use the one that you have already :)

but sbi->s_kobj is the kobject itself, not a pointer. I can still zero it out in
case of error to avoid using the added s_sysfs_registered bool. I would need to
check a field of s_kobj though, which is not super clean and makes the code
dependent on kobject internals. Not super nice in my opinion, unless I am
missing something.

> And you really don't even need to check anything, just pass in NULL to
> kobject_del() and friends, it should handle it.>
>>>> -
>>>>  	return 0;
>>>>  }
>>>>  
>>>> @@ -110,12 +108,13 @@ void zonefs_sysfs_unregister(struct super_block *sb)
>>>>  {
>>>>  	struct zonefs_sb_info *sbi = ZONEFS_SB(sb);
>>>>  
>>>> -	if (!sbi || !sbi->s_sysfs_registered)
>>>
>>> How can either of these ever be true?  Note, sbi should be passed here
>>> to this function, not the super block as that is now unregistered from
>>> the system.  Looks like no one has really tested this codepath that much
>>> :(
>>>
>>>> +	if (!sbi)
>>>>  		return;
>>>
>>> this can not ever be true, right?
>>
>> Yes it can, if someone attempt to mount a non zoned device. In that case,
>> fill_super returns early without setting sb->s_fs_info but vfs still calls
>> kill_super.
> 
> But you already had a sbi pointer in the place that this was called, so
> you "know" if you need to even call into here or not.  You are having to
> look up the same pointer multiple times in this call chain, there's no
> need for that.

I am not following here. Either we check that we have sbi here in
zonefs_sysfs_unregister(), or we conditionally call this function in
zonefs_kill_super() with a "if (sbi)". Either way, we need to check since sbi
can be NULL.

> 
> thanks,
> 
> greg k-h


  reply	other threads:[~2023-04-06 10:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06  9:30 [PATCH 1/3] kobject: introduce kobject_is_added() Yangtao Li
2023-04-06  9:30 ` [PATCH 2/3] erofs: convert to use kobject_is_added() Yangtao Li
2023-04-06 10:03   ` Greg KH
2023-04-06 10:13     ` Gao Xiang
2023-04-06 10:27       ` Greg KH
2023-04-06 10:55         ` Gao Xiang
2023-04-06 11:19           ` Greg KH
2023-04-06 12:07     ` Yangtao Li
2023-04-06 13:50       ` Yangtao Li
2023-04-06 14:31       ` Greg KH
2023-04-06 17:52         ` Yangtao Li
2023-04-07  6:09         ` Yangtao Li
2023-04-07  7:23         ` Yangtao Li
2023-04-06  9:30 ` [PATCH 3/3] zonefs: " Yangtao Li
2023-04-06 10:05   ` Greg KH
2023-04-06 10:13     ` Damien Le Moal
2023-04-06 10:26       ` Greg KH
2023-04-06 10:58         ` Damien Le Moal [this message]
2023-04-06 11:18           ` Greg KH
2023-04-06 11:23             ` Damien Le Moal
2023-04-06  9:59 ` [PATCH 1/3] kobject: introduce kobject_is_added() Greg KH

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=d732a8f6-4a0a-d7ff-af9c-f377fefd1283@fastmail.com \
    --to=dlemoal@fastmail.com \
    --cc=chao@kernel.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=frank.li@vivo.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=huyue2@coolpad.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=jth@kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naohiro.aota@wdc.com \
    --cc=rafael@kernel.org \
    --cc=xiang@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).