linux-kernel - Re: [PATCH 01/11] kset: fix documentation for kset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6df8844d-7f0c-17ac-96a4-beb981f2267c@amd.com>
Date:   Fri, 21 Oct 2022 04:18:28 -0400
From:   Luben Tuikov <luben.tuikov@....com>
To:     Yang Yingliang <yangyingliang@...wei.com>,
        linux-kernel@...r.kernel.org, qemu-devel@...gnu.org,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-erofs@...ts.ozlabs.org, ocfs2-devel@....oracle.com,
        linux-mtd@...ts.infradead.org, amd-gfx@...ts.freedesktop.org,
        gregkh@...uxfoundation.org
Cc:     rafael@...nel.org, somlo@....edu, mst@...hat.com,
        jaegeuk@...nel.org, chao@...nel.org, hsiangkao@...ux.alibaba.com,
        huangjianan@...o.com, mark@...heh.com, jlbec@...lplan.org,
        joseph.qi@...ux.alibaba.com, akpm@...ux-foundation.org,
        alexander.deucher@....com, richard@....at, liushixin2@...wei.com
Subject: Re: [PATCH 01/11] kset: fix documentation for kset_register()

On 2022-10-21 04:05, Yang Yingliang wrote:
> 
> On 2022/10/21 13:34, Luben Tuikov wrote:
>> On 2022-10-20 22:20, Yang Yingliang wrote:
>>> kset_register() is currently used in some places without calling
>>> kset_put() in error path, because the callers think it should be
>>> kset internal thing to do, but the driver core can not know what
>>> caller doing with that memory at times. The memory could be freed
>>> both in kset_put() and error path of caller, if it is called in
>>> kset_register().
>>>
>>> So make the function documentation more explicit about calling
>>> kset_put() in the error path of caller.
>>>
>>> Signed-off-by: Yang Yingliang <yangyingliang@...wei.com>
>>> ---
>>>   lib/kobject.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/lib/kobject.c b/lib/kobject.c
>>> index a0b2dbfcfa23..6da04353d974 100644
>>> --- a/lib/kobject.c
>>> +++ b/lib/kobject.c
>>> @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops);
>>>   /**
>>>    * kset_register() - Initialize and add a kset.
>>>    * @k: kset.
>>> + *
>>> + * If this function returns an error, kset_put() must be called to
>>> + * properly clean up the memory associated with the object.
>>>    */
>> And I'd continue the sentence, with " ... with the object,
>> for instance the memory for the kset.kobj.name when kobj_set_name(&kset.kobj, format, ...)
>> was called before calling kset_register()."
> kobject_cleanup() not only frees name, but aslo calls ->release() to 
> free another resources.

Yes, it does. For this reason I said "for instance..." I didn't want to include
this in case in the future if the code changes, the comment would be wrong. IOW,
I wanted to add the minimalist comment possible.

>>
>> This makes it clear what we want to make sure is freed, in case of an early error
>> from kset_register().
> 
> How about like this:
> 
> If this function returns an error, kset_put() must be called to clean up the name of
> kset object and other memory associated with the object.

It's bit too wordy and redundant with what else it does--this can be gleaned
from the code. I'd say:

	On error, kset_put() should be called to clean up at least kset.kobj.name allocated
	by kobj_set_name(&kset.kobj, format, ...).

This tells the reader the symmetry of the calls: kobj_set_name() --> kset_register() --> kset_put();
Because if the code evolves to use other means of allocation, or if the the user allocates a name
by different means, then they'll understand what to watch out for.

Regards,
Luben

> 
>>
>> Regards,
>> Luben
>>
>>>   int kset_register(struct kset *k)
>>>   {
>> .