public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] EVMS core (3/9) discover.c
@ 2002-10-10 22:53 Mark Peloquin
  0 siblings, 0 replies; 6+ messages in thread
From: Mark Peloquin @ 2002-10-10 22:53 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel


On 10/10/2002 at 05:19 PM, Andi Kleen wrote:

> > We plan to register a "__this_module.can_unload()" that
> > should prevent plugin modules from unloading during
> > discovery.

> Ok in this case. But how about when you search that list later after
> discovery for some reason and drop the lock. Then you could race with
someone
> else removing the plugin inbetween, no ?

The only time the lock is released while actively
searching the list is during discovery and direct
ioctl communication. So yes, you are correct, the
can_unload() would have to take both operations
into account. All other list operations take
place completely inside the lock. All in-use
plugins are kept from unloading by module ref
counts. Outside of the scope of the discover and
direct ioctl operations, any unused plugins
should be safe to unload.

Is something being missed?

Mark



^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] EVMS core (3/9) discover.c
@ 2002-10-10 22:05 Mark Peloquin
  2002-10-10 22:19 ` Andi Kleen
  0 siblings, 1 reply; 6+ messages in thread
From: Mark Peloquin @ 2002-10-10 22:05 UTC (permalink / raw)
  To: ak; +Cc: linux-kernel


On 10/10/2002 at 03:48 PM, Andi Kleen wrote:

> > + list_for_each_entry(plugin, &plugin_head, headers) {
> > +       if (GetPluginType(plugin->id) == EVMS_DEVICE_MANAGER) {
> > +             spin_unlock(&plugin_lock);
> > +             DISCOVER(plugin, disk_list);
> > +             spin_lock(&plugin_lock);
> > +       }

> How do you know "plugin" and its successors are still valid when retaking
> the spinlock? Looks like you need a reference count on the object here.

The spinlock itself should protect the integrity of the
list. If a prev or next element in the list should be
removed, while in a discover function, then the prev
or next field in the current plugin will get updated,
but I don't believe that should cause the list_for_each_entry
macro problems traversing the remainding elements in the list.

The first instruction in every plugin's discover function
is a MOD_INC_USE_COUNT and the last before the return is
MOD_DEC_USE_COUNT. So there exists a small window by
which the current plugin might be unloaded between the
spinlock release and MOD_INC_USE_COUNT, and the
MOD_DEC_USE_COUNT and the spinlock reacquire.

We plan to register a "__this_module.can_unload()" that
should prevent plugin modules from unloading during
discovery.

Mark



^ permalink raw reply	[flat|nested] 6+ messages in thread
* [PATCH] EVMS core (0/9)
@ 2002-10-10 19:30 Kevin Corry
  2002-10-10 19:35 ` [PATCH] EVMS core (3/9) discover.c Kevin Corry
  0 siblings, 1 reply; 6+ messages in thread
From: Kevin Corry @ 2002-10-10 19:30 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel, evms-devel

Greetings,

On behalf of the EVMS team, I would like to submit the Enterprise Volume 
Management System for review and possible inclusion in the 2.5 kernel.

This submission includes only the core driver and include files. Additional 
plugins will be submitted in the future in separate patches.

This series of patches contains the following files:
1) evms.c
2) services.c
3) discover.c
4) passthru.c
5) evms_core.h
6) evms.h
7) evms_ioctl.h
8) evms_biosplit.h
9) miscellaneous files

If you are interested in other information about EVMS, or would
like to obtain the user-space administration tools, please visit
our website at http://evms.sourceforge.net/.

Thank you very much for taking the time to review this submission. If you 
have any questions or comments, please email us at any time. We will be happy 
to do whatever is necessary to make EVMS acceptable for inclusion in the 2.5 
tree.

-- 
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2002-10-10 22:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <02101014305502.17770@boiler.suse.lists.linux.kernel>
     [not found] ` <02101014352905.17770@boiler.suse.lists.linux.kernel>
2002-10-10 20:48   ` [PATCH] EVMS core (3/9) discover.c Andi Kleen
2002-10-10 21:15     ` Kevin Corry
2002-10-10 22:53 Mark Peloquin
  -- strict thread matches above, loose matches on Subject: below --
2002-10-10 22:05 Mark Peloquin
2002-10-10 22:19 ` Andi Kleen
2002-10-10 19:30 [PATCH] EVMS core (0/9) Kevin Corry
2002-10-10 19:35 ` [PATCH] EVMS core (3/9) discover.c Kevin Corry

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox