public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Liu Shixin <liushixin2@huawei.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kobject: hide illegible sysfs warning of kobject_del()
Date: Fri, 11 Nov 2022 10:11:56 +0100	[thread overview]
Message-ID: <Y24R3M8d2HHAu4DS@kroah.com> (raw)
In-Reply-To: <d89eb156-3db2-df72-d21c-357baba3d377@huawei.com>

On Fri, Nov 11, 2022 at 04:27:03PM +0800, Liu Shixin wrote:
> 
> 
> On 2022/11/11 14:26, Greg Kroah-Hartman wrote:
> > On Fri, Nov 11, 2022 at 02:58:07PM +0800, Liu Shixin wrote:
> >> Some consumers do not care whether kobject_add() succeed or failed such as
> >> irqdesc. They call kobject_del() all the time even if kobject_add() failed.
> >> Then kernel will report some illegible sysfs warning like this:
> >>
> >>  kernfs: can not remove 'actions', no directory
> >>  WARNING: CPU: 0 PID: 277 at fs/kernfs/dir.c:1615 kernfs_remove_by_name_ns+0xd5/0xe0
> > Why not fix the caller here?  Is that somehow not possible?
> The caller should be freed by kobject_put() if kobject_add() failed. But in fact, the failure does not affect
> the function of the caller. So the caller do not call kobject_put() Immediately.
> If want to fix the caller, we can check konj->state_in_sysfs before call kobject_del(). This way has no difference
> with check kobj->state_in_sysfs in kobject_del().

No, no code should ever be checking the state_in_sysfs flag before
calling this function.

When a kobject is done with, by the creator of it, then it can call
kobject_del().  It can NOT call that function multiple times, as that is
just wrong and goes against the whole way the kobject should be used.

So there is something very wrong with the caller code here, THAT should
be fixed.

> By the way, I'm not sure how many callers have this problem. So I think it's better to fix in kobject_del().

As we have never had this report before, I don't know of many problem
users.

Let's fix the root of the problem here please, do not paper over it by
allowing this function to be called multiple times, as that is an
indication that the reference counting logic of the caller is very
wrong.

thanks,

greg k-h

      reply	other threads:[~2022-11-11  9:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11  6:58 [PATCH] kobject: hide illegible sysfs warning of kobject_del() Liu Shixin
2022-11-11  6:26 ` Greg Kroah-Hartman
2022-11-11  8:27   ` Liu Shixin
2022-11-11  9:11     ` Greg Kroah-Hartman [this message]

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=Y24R3M8d2HHAu4DS@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liushixin2@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox