linux-kernel - Re: [RFC 22/22] tcm_loop: Add multi-fabric Linux/SCSI LLD fabric module

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: <AANLkTimhHt78GFbxxjy1tosmebMVg-vKCNoJuqVa+iLH@mail.gmail.com>
Date:	Mon, 6 Sep 2010 07:48:20 -0700
From:	Richard Sharpe <realrichardsharpe@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Greg KH <gregkh@...e.de>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Mike Christie <michaelc@...wisc.edu>,
	Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
	James Bottomley <James.Bottomley@...e.de>,
	Jens Axboe <axboe@...nel.dk>,
	Boaz Harrosh <bharrosh@...asas.com>
Subject: Re: [RFC 22/22] tcm_loop: Add multi-fabric Linux/SCSI LLD fabric module

On Sun, Sep 5, 2010 at 11:26 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Sun, Sep 05, 2010 at 11:01:01PM -0700, Nicholas A. Bellinger wrote:
>> On Sun, 2010-09-05 at 22:38 -0700, Dmitry Torokhov wrote:
>> > On Sun, Sep 05, 2010 at 10:21:20PM -0700, Nicholas A. Bellinger wrote:
>> > > On Sun, 2010-09-05 at 22:17 -0700, Greg KH wrote:
>> > > > On Sun, Sep 05, 2010 at 10:08:16PM -0700, Dmitry Torokhov wrote:
>> > > > > On Sun, Sep 05, 2010 at 02:51:19PM -0700, Nicholas A. Bellinger wrote:
>> > > > > > On Sun, 2010-09-05 at 13:30 -0700, Dmitry Torokhov wrote:
>> > > > > > > On Mon, Aug 30, 2010 at 02:23:23AM -0700, Nicholas A. Bellinger wrote:
>> > > > > > > > +
>> > > > > > > > +static void tcm_loop_primary_release(struct device *dev)
>> > > > > > > > +{
>> > > > > > > > +       return;
>> > > > > > > > +}
>> > > > > > > > +
>> > > > > > > > +static struct device tcm_loop_primary = {
>> > > > > > > > +       .init_name              = "tcm_loop_0",
>> > > > > > > > +       .release                = tcm_loop_primary_release,
>> > > > > > > > +};
>> > > > > > > > +
>> > > > > > >
>> > > > > > > No, you can not have statically allocated devices and dummy release
>> > > > > > > functions.
>> > > > > > >
>> > > > > >
>> > > > > > Last time I checked this is still what mainline
>> > > > > > drivers/scsi/scsi_debug.c is doing for struct device pseudo_primary:
>> > > > > >
>> > > > > > static void pseudo_0_release(struct device *dev)
>> > > > > > {
>> > > > > >         if (SCSI_DEBUG_OPT_NOISE & scsi_debug_opts)
>> > > > > >                 printk(KERN_INFO "scsi_debug: pseudo_0_release() called\n");
>> > > > > > }
>> > > > > >
>> > > > > > static struct device pseudo_primary = {
>> > > > > >         .init_name      = "pseudo_0",
>> > > > > >         .release        = pseudo_0_release,
>> > > > > > };
>> > > > > >
>> > > > > > so for these type of things in TCM_Loop I tend to follow what scsi_debug does,
>> > > > > >  so I don't exactly see a issue here atm.  Anybody else have comments..?
>> > > > >
>> > > > > The kobject embedded in the device structure is refcounted and it's
>> > > > > lifetime may be different from lifetime of your module. If somebody
>> > > > > happen to hold reference to the driver while your module is being
>> > > > > unloaded bad things will happen.
>> > > > >
>> > > > > I am sure Greg has something on this topic ready for cut-and-paste.
>> > > >
>> > > > Documentation/kobject.txt :)
>> > >
>> > > I still don't get it..?  Does this mean that scsi_debug and TCM_Loop are
>> > > currently broken wrt to this item or not..?
>> > >
>> >
>> > Yes they are broken.
>>
>> Hi Dmitry and Greg,
>>
>> Would you mind giving a bit more specific idea as to what a patch to fix
>> this issue would involve for an emulated struct device usage..?  I would
>> be happy to generate patches for scsi_debug and TCM_loop to resolve this
>> issue, but I need a bit more information what I should be looking at.
>>
>
> I think what you need is root_device_create() which will allocate a
> device structure and assign ->release() that is implemented outside of
> your module. This way your module may be unloaded even if there are
> outstanding references to tcm_loop_primary device.

I am embarrassed to admit that scst_local (or whatever its new name
will be) probably has the same fault, as it too was based on
scsi_debug ...

However, I did a search of the 2.6.24.1 source tree and could not find
any instances of root_device_create() being called nor defined. I just
double and triple checked the spelling.

Ahhh, I see why. A slightly different search suggests that it is
root_device_register(const char *name).

>From include/linux/device.h:

static inline struct device *root_device_register(const char *name)
{
	return __root_device_register(name, THIS_MODULE);
}

Was that the one you were thinking of?

> The rest of devices you create needs to increment module counter or
> otherwise ensure that their methods stay available until they are
> cleaned up (->release() is called).

OK, I need to check out how this is done.

> Hope this helps.

Sure does.

-- 
Regards,
Richard Sharpe
--
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/