Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
lib: Fix corruption when routemap delete/add sequence happens
If a operator issues a series of route-map deletions and then re-adds, *and* this triggers the hash table to realloc to grow to a larger size, then subsuquent route-map operations will be against a corrupted hash table. Why? Effectively the route-map code was inserting each route-map <NAME> into a hash for storage. Upon deletion there is this concept of delayed processing so the routemap code sets a bit `to-be-processed` and marks the route-map for deletion. This is 1 entry in the hash table. Then if the operator recreates the hash, FRR would add another hash entry. If another deletion happens then there now are 2 deletion entries that are indistinguishable from a hash perspective. FRR stores the deleted name of the route-map so that any delayed processing can lookup the name and only process those peers that are related to that route-map name. This is good as that if in say BGP, we do not want to reprocess all the peers that don't use the route-map. Solution: The whole purpose of the delay of deletion and the storage of the route-map is to allow the using protocol the ability to process the route-map at a later time while still retaining the route-map name( for more efficient reprocessing ). The problem exists because we are keeping multiple copies of deletion events that are indistinguishable from each other causing hash havoc. The truth is that we only need to keep 1 copy of the routemap in the table. If the series of events is: a) delete ( schedule processing ) b) add ( reschedule processing ) Current code ends up processing the route-map two times and in this event we really just need to reprocess everything with the new route-map. If the series of events is: a) delete (schedule processing ) b) add (reschedule) c) delete (reschedule) d) add (reschedule) All this really points to is that FRR just needs to keep the last in the series of maps and ensuring that FRR knows that we need to continue processing the route-map. So in the creation processing if the hash has an entry for this map, the routemap code knows that this is a deletion event. Mark this route-map for later processing if it was marked so. Also in the lookup function do not return a map if the map found was deleted. Fixes: #10708 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
- Loading branch information