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]

Message-ID: <AANLkTi=VwCj2MRTFM79aT78rov5XsiRo4KXHpw+EiDFi@mail.gmail.com>
Date:	Sat, 13 Nov 2010 11:52:12 +0100
From:	Bart Van Assche <bvanassche@....org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Greg KH <greg@...ah.com>, Vladislav Bolkhovitin <vst@...b.net>,
	Boaz Harrosh <bharrosh@...asas.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	scst-devel <scst-devel@...ts.sourceforge.net>
Subject: Re: [PATCH 8/19]: SCST SYSFS interface implementation

On Fri, Nov 12, 2010 at 7:44 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> [ ... ]
>
> No, you do not add a kref, but rather manipulate module use counter:
>
> static void blah_blah_release(struct kobject *kobj)
> {
>        struct blah_blah *b = to_blah_blah(kobj);
>
>        ...
>        kfree(kobj);
>
>        module_put(THIS_MODULE);
> }
>
> int blah_blah_register(struct blah_blah *blah)
> {
>        ...
>
>        __module_get(THIS_MODULE);
>
>        ...
>
>        return 0;
> }
>
> The above should reside in subsystem _core_ and it will pin the core
> module until last kobject belonging to the subsystem is released.
> Once all users are gone module counter will go to 0 and rmmod will
> allow core to unload. Note that no new kobjects will be created while
> module usage count is 0 because there are no users of the core - all of
> them have to be unloaded already, otherwise module loader would have
> bumped up usage count as well.
>
> > I'm not sure that it is even possible with the current kobject
> > implementation to solve this race.
>
> It is possible and it is solved in most (all?) mainline subsystems.

Thanks for replying, but sorry, it's still not clear to me. The use
counter of which module should be manipulated ? Manipulating the use
counter of the module that contains the kobject/ktype callback
function implementations would make it impossible to unload that
module because rmmod refuses to unload any module whose use counter is
above zero. And manipulating the use counter of a parent module would
not help in any way.

It would help if you could tell us where in the kernel tree we can
find a good example. I have tried to find such an example, but all I
found are examples of kobject release method implementations in which
no attempt is made to prevent the aforementioned race:
* iscsi_boot_kobj_release() in drivers/scsi/iscsi_boot_sysfs.c
* pkt_kobj_release() in drivers/block/pktcdvd.c

Bart.
--
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/