All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: naohiro.aota@wdc.com, Yangtao Li <frank.li@vivo.com>,
	damien.lemoal@opensource.wdc.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, huyue2@coolpad.com,
	jth@kernel.org, linux-erofs@lists.ozlabs.org, rafael@kernel.org
Subject: Re: [PATCH 2/3] erofs: convert to use kobject_is_added()
Date: Thu, 6 Apr 2023 13:19:00 +0200	[thread overview]
Message-ID: <2023040609-email-squad-25f5@gregkh> (raw)
In-Reply-To: <589f6665-824f-bf08-3458-d3986d88f7fc@linux.alibaba.com>

On Thu, Apr 06, 2023 at 06:55:40PM +0800, Gao Xiang wrote:
> 
> 
> On 2023/4/6 18:27, Greg KH wrote:
> > On Thu, Apr 06, 2023 at 06:13:05PM +0800, Gao Xiang wrote:
> > > Hi Greg,
> > > 
> > > On 2023/4/6 18:03, Greg KH wrote:
> > > > On Thu, Apr 06, 2023 at 05:30:55PM +0800, Yangtao Li wrote:
> > > > > Use kobject_is_added() instead of directly accessing the internal
> > > > > variables of kobject. BTW kill kobject_del() directly, because
> > > > > kobject_put() actually covers kobject removal automatically.
> > > > > 
> > > > > Signed-off-by: Yangtao Li <frank.li@vivo.com>
> > > > > ---
> > > > >    fs/erofs/sysfs.c | 3 +--
> > > > >    1 file changed, 1 insertion(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/fs/erofs/sysfs.c b/fs/erofs/sysfs.c
> > > > > index 435e515c0792..daac23e32026 100644
> > > > > --- a/fs/erofs/sysfs.c
> > > > > +++ b/fs/erofs/sysfs.c
> > > > > @@ -240,8 +240,7 @@ void erofs_unregister_sysfs(struct super_block *sb)
> > > > >    {
> > > > >    	struct erofs_sb_info *sbi = EROFS_SB(sb);
> > > > > -	if (sbi->s_kobj.state_in_sysfs) {
> > > > > -		kobject_del(&sbi->s_kobj);
> > > > > +	if (kobject_is_added(&sbi->s_kobj)) {
> > > > 
> > > > I do not understand why this check is even needed, I do not think it
> > > > should be there at all as obviously the kobject was registered if it now
> > > > needs to not be registered.
> > > 
> > > I think Yangtao sent a new patchset which missed the whole previous
> > > background discussions as below:
> > > https://lore.kernel.org/r/028a1b56-72c9-75f6-fb68-1dc5181bf2e8@linux.alibaba.com
> > > 
> > > It's needed because once a syzbot complaint as below:
> > > https://lore.kernel.org/r/CAD-N9QXNx=p3-QoWzk6pCznF32CZy8kM3vvo8mamfZZ9CpUKdw@mail.gmail.com
> > > 
> > > I'd suggest including the previous backgrounds at least in the newer patchset,
> > > otherwise it makes me explain again and again...
> > 
> > That would be good, as I do not think this is correct, it should be
> > fixed in a different way, see my response to the zonefs patch in this
> > series as a much simpler method to use.
> 
> Yes, but here (sbi->s_kobj) is not a kobject pointer (also at a quick
> glance it seems that zonefs has similar code), and also we couldn't
> just check the sbi is NULL or not here only, since sbi is already
> non-NULL in this path and there are some others in sbi to free in
> other functions.
> 
> s_kobj could be changed into a pointer if needed.  I'm all fine with
> either way since as you said, it's a boilerplate filesystem kobject
> logic duplicated from somewhere.  Hopefully Yangtao could help take
> this task since he sent me patches about this multiple times.

I made the same mistake with the zonefs code.  If the kobject in this
structure controls the lifespan of it (which makes it not a pointer, my
mistake), then that whole memory chunk can't be valid anymore if the
kobject registering function failed so you need to get rid of it then,
not later.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
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 2/3] erofs: convert to use kobject_is_added()
Date: Thu, 6 Apr 2023 13:19:00 +0200	[thread overview]
Message-ID: <2023040609-email-squad-25f5@gregkh> (raw)
In-Reply-To: <589f6665-824f-bf08-3458-d3986d88f7fc@linux.alibaba.com>

On Thu, Apr 06, 2023 at 06:55:40PM +0800, Gao Xiang wrote:
> 
> 
> On 2023/4/6 18:27, Greg KH wrote:
> > On Thu, Apr 06, 2023 at 06:13:05PM +0800, Gao Xiang wrote:
> > > Hi Greg,
> > > 
> > > On 2023/4/6 18:03, Greg KH wrote:
> > > > On Thu, Apr 06, 2023 at 05:30:55PM +0800, Yangtao Li wrote:
> > > > > Use kobject_is_added() instead of directly accessing the internal
> > > > > variables of kobject. BTW kill kobject_del() directly, because
> > > > > kobject_put() actually covers kobject removal automatically.
> > > > > 
> > > > > Signed-off-by: Yangtao Li <frank.li@vivo.com>
> > > > > ---
> > > > >    fs/erofs/sysfs.c | 3 +--
> > > > >    1 file changed, 1 insertion(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/fs/erofs/sysfs.c b/fs/erofs/sysfs.c
> > > > > index 435e515c0792..daac23e32026 100644
> > > > > --- a/fs/erofs/sysfs.c
> > > > > +++ b/fs/erofs/sysfs.c
> > > > > @@ -240,8 +240,7 @@ void erofs_unregister_sysfs(struct super_block *sb)
> > > > >    {
> > > > >    	struct erofs_sb_info *sbi = EROFS_SB(sb);
> > > > > -	if (sbi->s_kobj.state_in_sysfs) {
> > > > > -		kobject_del(&sbi->s_kobj);
> > > > > +	if (kobject_is_added(&sbi->s_kobj)) {
> > > > 
> > > > I do not understand why this check is even needed, I do not think it
> > > > should be there at all as obviously the kobject was registered if it now
> > > > needs to not be registered.
> > > 
> > > I think Yangtao sent a new patchset which missed the whole previous
> > > background discussions as below:
> > > https://lore.kernel.org/r/028a1b56-72c9-75f6-fb68-1dc5181bf2e8@linux.alibaba.com
> > > 
> > > It's needed because once a syzbot complaint as below:
> > > https://lore.kernel.org/r/CAD-N9QXNx=p3-QoWzk6pCznF32CZy8kM3vvo8mamfZZ9CpUKdw@mail.gmail.com
> > > 
> > > I'd suggest including the previous backgrounds at least in the newer patchset,
> > > otherwise it makes me explain again and again...
> > 
> > That would be good, as I do not think this is correct, it should be
> > fixed in a different way, see my response to the zonefs patch in this
> > series as a much simpler method to use.
> 
> Yes, but here (sbi->s_kobj) is not a kobject pointer (also at a quick
> glance it seems that zonefs has similar code), and also we couldn't
> just check the sbi is NULL or not here only, since sbi is already
> non-NULL in this path and there are some others in sbi to free in
> other functions.
> 
> s_kobj could be changed into a pointer if needed.  I'm all fine with
> either way since as you said, it's a boilerplate filesystem kobject
> logic duplicated from somewhere.  Hopefully Yangtao could help take
> this task since he sent me patches about this multiple times.

I made the same mistake with the zonefs code.  If the kobject in this
structure controls the lifespan of it (which makes it not a pointer, my
mistake), then that whole memory chunk can't be valid anymore if the
kobject registering function failed so you need to get rid of it then,
not later.

thanks,

greg k-h

  reply	other threads:[~2023-04-06 11:19 UTC|newest]

Thread overview: 42+ 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 ` Yangtao Li
2023-04-06  9:30 ` [PATCH 2/3] erofs: convert to use kobject_is_added() Yangtao Li
2023-04-06  9:30   ` Yangtao Li
2023-04-06 10:03   ` Greg KH
2023-04-06 10:03     ` Greg KH
2023-04-06 10:13     ` Gao Xiang
2023-04-06 10:13       ` Gao Xiang
2023-04-06 10:27       ` Greg KH
2023-04-06 10:27         ` Greg KH
2023-04-06 10:55         ` Gao Xiang
2023-04-06 10:55           ` Gao Xiang
2023-04-06 11:19           ` Greg KH [this message]
2023-04-06 11:19             ` Greg KH
2023-04-06 12:07     ` Yangtao Li
2023-04-06 12:07       ` Yangtao Li
2023-04-06 13:50       ` Yangtao Li
2023-04-06 13:50         ` Yangtao Li
2023-04-06 14:31       ` Greg KH
2023-04-06 14:31         ` Greg KH
2023-04-06 17:52         ` Yangtao Li
2023-04-06 17:52           ` Yangtao Li
2023-04-07  6:09         ` Yangtao Li
2023-04-07  6:09           ` Yangtao Li
2023-04-07  7:23         ` Yangtao Li
2023-04-07  7:23           ` Yangtao Li
2023-04-06  9:30 ` [PATCH 3/3] zonefs: " Yangtao Li
2023-04-06  9:30   ` Yangtao Li
2023-04-06 10:05   ` Greg KH
2023-04-06 10:05     ` Greg KH
2023-04-06 10:13     ` Damien Le Moal
2023-04-06 10:13       ` Damien Le Moal
2023-04-06 10:26       ` Greg KH
2023-04-06 10:26         ` Greg KH
2023-04-06 10:58         ` Damien Le Moal
2023-04-06 10:58           ` Damien Le Moal
2023-04-06 11:18           ` Greg KH
2023-04-06 11:18             ` Greg KH
2023-04-06 11:23             ` Damien Le Moal
2023-04-06 11:23               ` Damien Le Moal
2023-04-06  9:59 ` [PATCH 1/3] kobject: introduce kobject_is_added() Greg KH
2023-04-06  9:59   ` 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=2023040609-email-squad-25f5@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=frank.li@vivo.com \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=huyue2@coolpad.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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.