linux-kernel - Re: [PATCH 8/19]: SCST SYSFS interface implementation

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]

Date:	Tue, 12 Oct 2010 22:53:45 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	Greg KH <greg@...ah.com>
CC:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	scst-devel <scst-devel@...ts.sourceforge.net>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Mike Christie <michaelc@...wisc.edu>,
	Vu Pham <vuhuong@...lanox.com>,
	Bart Van Assche <bart.vanassche@...il.com>,
	James Smart <James.Smart@...lex.Com>,
	Joe Eykholt <jeykholt@...co.com>, Andy Yan <ayan@...vell.com>,
	Chetan Loke <generationgnu@...oo.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Hannes Reinecke <hare@...e.de>,
	Richard Sharpe <realrichardsharpe@...il.com>,
	Daniel Henrique Debonzi <debonzi@...ux.vnet.ibm.com>
Subject: Re: [PATCH 8/19]: SCST SYSFS interface implementation

Greg KH, on 10/12/2010 01:32 AM wrote:
> On Mon, Oct 11, 2010 at 11:29:22PM +0400, Vladislav Bolkhovitin wrote:
>> Greg KH, on 10/10/2010 01:20 AM wrote:
>>> On Sat, Oct 02, 2010 at 01:46:21AM +0400, Vladislav Bolkhovitin wrote:
>>>> +static void scst_tgtt_release(struct kobject *kobj)
>>>> +{
>>>> +	struct scst_tgt_template *tgtt;
>>>> +
>>>> +	tgtt = container_of(kobj, struct scst_tgt_template, tgtt_kobj);
>>>> +	complete_all(&tgtt->tgtt_kobj_release_cmpl);
>>>> +	return;
>>>
>>> Don't you also need to free the memory of your kobject here?
>>>
>>>> +static void scst_tgt_release(struct kobject *kobj)
>>>> +{
>>>> +	struct scst_tgt *tgt;
>>>> +
>>>> +	tgt = container_of(kobj, struct scst_tgt, tgt_kobj);
>>>> +	complete_all(&tgt->tgt_kobj_release_cmpl);
>>>> +	return;
>>>
>>> Same here, no kfree?
>>>
>>>> +static void scst_acg_release(struct kobject *kobj)
>>>> +{
>>>> +	struct scst_acg *acg;
>>>> +
>>>> +	acg = container_of(kobj, struct scst_acg, acg_kobj);
>>>> +	complete_all(&acg->acg_kobj_release_cmpl);
>>>
>>> And here.
>>
>> Thanks for the review. In all those functions kobjects for simplicity
>> are embedded into the outer objects, so they will be freed as part of
>> the outer objects free. Hence, kfree() for the kobjects in the release
>> functions are not needed.
> 
> Sweet, you now have opened yourself up to public ridicule as per the
> documentation in the kernel for how to use kobjects!
> 
> Nice job :)

Thanks :)

> Seriously, you CAN NOT DO THIS!  If you embed a kobject in a different
> structure, then you have to rely on the kobject to handle the reference
> counting for that larger structure.  To do ANYTHING else is a bug and
> wrong.
> 
> Please read the kobject documentation and fix this code up before
> submitting it again.

Sure, I have read it and we rely on the kobject to handle the reference
counting for the larger structure. It's only done not in a
straightforward way, because the way it is implemented is simpler for us
+ for some other reasons.

For instance, for structure scst_tgt it is done using
tgt_kobj_release_cmpl completion. When a target driver calls
scst_unregister_target(), scst_unregister_target() in the end calls
scst_tgt_sysfs_del(), which calls kobject_put(&tgt->tgt_kobj) and wait
for tgt_kobj_release_cmpl to complete. At this point tgt_kobj can be
taken only by the SYSFS. Scst_tgt_sysfs_del() can wait as much as needed
until the SYSFS code released it. As far as I can see, it can't be
forever, so it's OK. Then, after scst_tgt_sysfs_del() returned,
scst_unregister_target() will free scst_tgt together with embedded tgt_kobj.

Sure, if you insist, I can convert tgt_kobj and other similar kobjects
to pointers, but it would be just a formal code introducing additional
kmalloc()/kfree() pair per each kobject without changing any logic anywhere.

Thanks,
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/