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:	Thu, 11 Nov 2010 23:50:01 +0300
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	Boaz Harrosh <bharrosh@...asas.com>
CC:	Greg KH <greg@...ah.com>, 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

Boaz Harrosh, on 11/11/2010 12:59 PM wrote:
>> static void x_release(struct kobject *kobj)

Yes. Precisely speaking, of its kobj_type.

> This one is put on the kobj.release Right?
> 
>> {
>> 	struct object_x *x;
>> 	struct completion *c;
>>
>> 	x = container_of(kobj, struct object_x, kobj);
>> 	c = x->release_completion;
>> 	kfree(x);
>> 	complete_all(c);
>> }
>>
> 
> I don't see the unregister of the object_x.kobj, where do
> you do this one in x_release or del_object below?

Which unregister? Put for object_x.kobj is in del_object()

>> void del_object(struct object_x *x)
>> {
>> 	DECLARE_COMPLETION_ONSTACK(completion);
>>
>> 	...
>> 	x->release_completion = &completion;
>> 	kobject_put(&x->kobj);
> 
> This put might not be the last put on the object, IOs in flight
> and/or open files might have extra reference on the object.
> We release our initial ref, and below wait for all operations
> to complete. (Is there a matter of timeout like files not closing?)

This is the last internal put. All other references are from outsiders.
So, we are waiting for all them to put before we go on.

> One possibility (There are others)
> 
> 3. struct object_x {
> 	...
> 	struct kref kref;
> 	struct kobject kobj;
> 	struct completion *release_completion;
> };
> 
> Every body takes kref_put(&object_x.kref) and  kref_get(&object_x.kref)
> I hope you have x_get/x_put, Yes?
> 
> static void x_kref_release(struct kref *kref)
> {
> 	struct object_x *x = container_of(kref, struct object_x, kref);
> 
> 	complete_all(&x->release_completion);
> }
> 
> static void x_obj_release(struct kobject *kobj)
> {
> 	struct object_x *x = container_of(kobj, struct object_x, kobj);
> 
> 	kfree(x);
> }
> 
> int x_put(struct object_x *x)
> {
> 	return kref_put(&x->kref, x_kref_release);
> }
> 
> void del_object(struct object_x *x)
> {
> 	DECLARE_COMPLETION_ONSTACK(completion);
> 
> 	...
> 	x->release_completion = &completion;
> 	x_put(x)
> 	wait_for_completion(&completion);
> 	kobject_put(&x->kobj);
> }
> 
> Or
> 
> 4. Exactly Like 3 but without the extra kref member
>    Only x_put() changes and x_kref_release() now receives
>    an x_object
> 
> int x_put(struct object_x *x)
> {
> 	if (kobject_put(&x->kobj) == 1)
> 		// Like above [3] x_kref_release()
> 		x_kref_release(x);
> }
> 
> Note that in 4 you don't actually have a kref member, and that you have
> one extra ref on kobj from the beginning. In del_object above the first
> x_put(x) makes it possible to reach the "1" count and then the final
> kobject_put(&x->kobj); frees the object.
> (You need to be carfull with [4] because it must have a refcount==2 before
> you expose it to any IO or sysfs.)
> 
> So this is what I meant.

OK, I see. You know, all non-trivial things can be done in >1 correct
way ;) (Although (4) is not too correct as Greg already wrote)

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/