Am Mittwoch 09 November 2005 21:13 schrieb Jamal Hadi Salim: > I will try and list the contended issues and my comments below. Again, I > may have missed something since it was a quick scan.
Ok, time to get on topic again ;-) > 1) In regards to the connected routes: > - I would agree that there is need to do something about them - but i > dont think those extra L3* states are the answer. So Stefan, we need to > kill the L3* thingy IMO. My main concern here are dial on demand interfaces. Routes pointing to them must be considered even if the interface is !OPER_UP. Routes pointing to "permanent" interfaces in !OPER_UP should not. If we drop the OPER_DORMANTL3*-states, we might later define a flag that marks a route as permanent (stays when interface is !OPER_UP), as opposed to a transient route that is removed/deactivated during !OPER_UP. However, L3 would lose the possibility to differenciate between a dialer that can dial and one that can't. I don't consider this limitation too bad, but it would be there and stay for a while. > From an adjacency perspective this is no different than the kernel > resolving arp request and then obsoleting it when the neighbor fails > to respond. If arp is run in user space however, it will be upto user > space to take care of this. Sorry, I don't get this in this context. > 2) on admin and operational status relationships: > [...] > Summary: lets not set any oper status > on admin changes. agreed. > 3) On case of _who_ sets the link oper transitioning. I think i didnt > follow this well in the quick scan. At the moment if this is done via > the driver, the are no known issues in atomicity. In the case of > protocol based link administration such as the case referred to for > 802.1x, i am not sure i see the issue. Can someone please explain it? > anything from user space wont reenter the kernel as long as we have the > rtnl semaphore (which we do); and if the flags are being protected by > the dev base lock, where is the problem? Currently, IFF_RUNNING is created out of dev->state that is *not* protected by any lock as the driver can change it from interrupts. Instead, atomic bit operations are used. If we allow userspace to write into operstate - either into independant bits that Krzysztof suggests or into my operstate_kernel field - we would have races. So based on the transitions we need I had the idea that userspace can put an upper limit on the operstate reported using the user override field. However, this is still not race free. We have a 802.1X protected device that cannot go from DOWN->UP, only from DOWN->DORMANT because supplicant needs to run. Depending on system load, the driver can report an UP->DOWN->UP flap before the supplicant gets a chance to run and change user override to DORMANT. That's why I've defined a semantic that allows kernel to lower the user override field when a link state notification is sent. As Thomas pointed out, this is still not perfect if the driver produces events too fast for linkwatch workqueue, but that's an implementation detail and not a design flaw. > 4) it would probably be a good idea to use a u8 instead of uchar for the > oper flags If Thomas is right and byte accesses are not atomic "enough" on some platforms, maybe I even have to use atomic_t. I don't want to take dev_base_lock for a write access in case a device goes berzerk. (Without also taking rtnl which can't be done from an interrupt it would be against the locking semantics defined in net/core/dev.c anyway) Stefan - 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
