Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Nov 2022 10:11:56 +0100
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()
Message-ID: <Y24R3M8d2HHAu4DS@kroah.com>
References: <20221111065807.3278713-1-liushixin2@huawei.com>
 <Y23rC0N1cL2LQpyF@kroah.com>
 <d89eb156-3db2-df72-d21c-357baba3d377@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d89eb156-3db2-df72-d21c-357baba3d377@huawei.com>
Precedence: bulk

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