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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:33 EST