On 23.11.2016 20:53, Ido Schimmel wrote: > On Wed, Nov 23, 2016 at 06:47:03PM +0100, Hannes Frederic Sowa wrote: >> Hmm, I think you need to read the sequence counter under rtnl_lock to >> have an ordering with the rest of the updates to the RCU trie. Otherwise >> you don't know if the fib trie has the correct view regarding to the >> incoming notifications as a whole. This is also necessary during restarts. > > I spent quite a lot of time thinking about this specific issue, but I > couldn't convince myself that the read should be done under RTNL and I'm > not sure I understand your reasoning. Can you please elaborate? > > If, before each notification sent, we call atomic_inc() and then call > atomic_read() at the end, then how can we be tricked?
The race I am suspecting to happen is: <CPU0> fib_register() <CPU1> delete route by notifier <CPU1> enqueue delete cmd into ordered queue <CPU0> starts dump <CPU0> sees deleted route by CPU1 because route not yet removed from RCU <CPU0> enqueues route for addition sometimes later in the ordered queue: delete route -> route not in hw, nop add route from dump -> route added to hardware The result should actually have been that route isn't in hw. Bye, Hannes
