search

OpenFastPath / ofp

OpenFastPath project
BSD 3-Clause "New" or "Revised" License
353 stars 126 forks source link

Race condition in MAC address lookup #121

Closed semihalf-berestovskyy-andriy closed 7 years ago

semihalf-berestovskyy-andriy commented 7 years ago

Note: the issue was created automatically with bugzilla2github tool

Bugzilla Bug ID: 121

Date: 2017-01-16 11:03:41 +0100 From: janne.peltonen@nokia.com To: openfastpath@list.openfastpath.org

Last updated: 2017-01-16 11:03:41 +0100

Bugzilla Comment ID: 227

Date: 2017-01-16 11:03:41 +0100 From: janne.peltonen@nokia.com

ofp_arp.c:ofp_ipv4_lookup_mac() caches arp table lookup results in shm->arp.cache[set]. Use of the cache is not protected against simultaneous modifications of the cache by other threads.

This can result in some sent packets getting a wrong destination MAC address.

sovu commented 7 years ago

This is as designed. I am inclined to close this issue, as the aproach would be to use the ofp_arp_ck implementation of arp table.

The cache is not protected because the performance would drop too much. The assumption is that there is no collision under a good designed size structure and usecase. The cave heat is that some packets will go to a wrong MAC.

We have a lockless implementation for ARP table using libck, see ofp_arp_ck.c file. To fix this, one should use the _ck implementation.

rishdas commented 7 years ago

This issue can be closed as part of this commit https://github.com/OpenFastPath/ofp/commit/2522674842ce14a22b2b6e129cf2e37dc8444879