On Thu, 2005-01-12 at 13:48 +0100, Krzysztof Halasa wrote: > Hi, > > Stefan Rompf <[EMAIL PROTECTED]> writes:
> > +} > > This is of course much much more correct than those strange operations > on dev->char_type, though netif_dormant* is still misnamed - dormant > isn't one bit but rather a combination of bits: admin up, carrier > (lower level etc.) up and (I call it) protocol down. > > This bit alone doesn't tell if it's dormant or, for example, simply down > (either admin or carrier). > dormant is an operational state and _not_ an admin state. > While I haven't fully analyzed the remaining part of the patch... Tell > me, do you think adding more code can at last break the theory? Do you > think you can avoid *real* locking (as opposed to protecting a write to > a variable) especially when userspace is involved (i.e., there is no > serialization and everything is asynchronous)? > > How do you protect against the scenario I have already outlined few times: > > - kernel driver signals lower-level down > - kernel driver signals lower-level up (dormant = 1) > - slow userspace (in this case, could be a kernel module if strict > serialization of all operational status changes isn't required) doesn't > (yet) see the above events and sets "fully operational"? > > How is this different from say a link flip-flopping? Which is something that could happen today even without these changes? Stefans code does protect against that with a damping time. > > Look, you (I mean Thomas and Jamal, too) can ignore that problem (or > "problem"), pretend it's fixed when it's not, exactly like you ignore > existence of my patch. > Please stop talking about your patch. > However, in case it's unintentional (hard to believe maybe but I trust > people), Not including your patch was _without a doubt_ intentional. I apologize for being blunt: Your patch was nothing more than a bandaid; a bad hack that was just hiding the real problem. Now can we get you mentioning your patch out of the way please? In regards to the rest of your comments: I dont see any races at all in what Stefan posted- but i could be wrong. The issue you pointed out about state flip flopping is something that is expected; infact the RFC talks about it and the suggested workaround is even in current code by a little damper time and double checking the state before announcing it to user space. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
