Messages in this thread |  | | Date | Fri, 13 Sep 2002 09:27:16 -0600 (MDT) | From | Thunder from the hill <> | Subject | Re: [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/
|  |