Am Montag 14 November 2005 17:44 schrieb Krzysztof Halasa: [As Jamal answers later, I'll just comment on the technical questions]
> Why do you do that instead of atomic write? as described in net/core/dev.c: * The @dev_base list is protected by @dev_base_lock and the rtln * semaphore. * * Pure readers hold dev_base_lock for reading. * * Writers must hold the rtnl semaphore while they loop through the * dev_base list, and hold dev_base_lock for writing when they do the * actual updates. This allows pure readers to access the list even * while a writer is preparing to update it. rtnl is held by caller during linkwatch_run_queue(), operstate_useroverride is only updated in process context, so this works. > Still not sure any wmb() is needed. Unless I'm mistaken that's for > synchronizing I/O mainly (and to prevent gcc reordering but don't see > any possible here). atomic_set() maybe? But it doesn't make all real > locking issues go away. See Documentation/DocBook/kernel-locking.tmpl. I need the change in operstate_kernel to be pushed to other CPUs before linkwatch_work is scheduled. atomic_set would be possible, too. This doesn't guarantee yet that no other netif_set_kernel_operstate() has taken place before linkwatch_work runs - therefore, the change would need to be written in an event queue what I don't do [yet]. But it guarantees that there will be another event if that happens. 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
