lkml.org 
[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Raceless module interface
Hi,

On Fri, 13 Sep 2002, Daniel Phillips wrote:
> I'd be surprised if Rusty can do it any better than you. It's hard to
> show a race that doesn't exist, even harder to prove that a four-prong
> interface is necessary in order to be able to handle it. The latter is
> the question on the table.

Not as easy as missing ones point, yes.

> > However, there might be some weird situations. For example, take
> > someone trying to bring all modules down the moment we init. We might
> > start running in unchecked environment, and there we fail because
> > there is no 'we' any more.
>
> Oh indeed, there are weird situations, but they apply equally to the
> two-prong and the four-prong interfaces.
>
> > Thus rather module->init(). if (module) module->start(). Since then we can
> > be sure that the module is locked, and if somebody unloads it, he'll have
> > to wait for the use count to drop.
>
> This applies equally to the two-prong interface.
>
> > Or as another example, take someone trying to use the resources we claimed
> > before the module is really up. If you can rely on the module to be known
> > to be up, you know what do do. Yes, usually that's no real good example,
> > since resources ought to be locked as well.
>
> This applies equally to the two-prong interface. Do you see the pattern
> yet?

Yes, but you don't seem to. (No, I don't want to insult you here.)

Just to draw that:

2p:

thread1 thread2
struct x *y = malloc(sizeof(struct x));
check y;
blah(); cleanup(y et al);
touch y->blah; /* bang */

4p:

thread1 thread2

struct x *y = malloc(sizeof(struct x));
check y;
struct z *a = malloc(sizeof(struct z));
check a; cleanup(y et al);
struct u *v = malloc(sizeof(struct u));
check v;

return success;

(back in caller - from that moment we're protected against arbitrariness
from other threads)

check y; <-- detected

You know? We allocate, we lock, we check, we win.

Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-

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

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.084 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site