zebra: enqueue NHG_DEL in rib_nhg meta queue

The NHG_DEL operation is done directly from ZAPI call, whereas
the NHG_ADD operation is done in the rib_nhg meta queue.

This may be problematic when ADD is followed by DEL. Imagine a
scenarion with two protocol NHIDs. <NH1> depends of <NH2> and
<NH3>. The deletion of <NH3> at the protocol level will trigger
2 messages to ZEBRA: NHG_ADD(<NH1>) and NHG_DEL(<NH3>).

Those operations are properly enqueued in ZAPI, but in the end,
the NHG_DEL is executed first. This causes NHG_ADD to unlink an
already freed NHG.

Fix this by consistently enqueuing NHG_DEL and NHG_ADD operations.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

1 files changed, 12 insertions, 13 deletions

diff --git a/zebra/zapi_msg.c b/zebra/zapi_msg.c
index 2d1614ca54..761eafeb13 100644
--- a/zebra/zapi_msg.c
+++ b/zebra/zapi_msg.c
@@ -1959,20 +1959,19 @@ static void zread_nhg_del(ZAPI_HANDLER_ARGS)
 		return;
 	}
 
-	/*
-	 * Delete the received nhg id
-	 */
-	nhe = zebra_nhg_proto_del(api_nhg.id, api_nhg.proto);
+	/* Create a temporary nhe */
+	nhe = zebra_nhg_alloc();
+	nhe->id = api_nhg.id;
+	nhe->type = api_nhg.proto;
+	nhe->zapi_instance = client->instance;
+	nhe->zapi_session = client->session_id;
+
+	/* Sanity check - Empty nexthop and group */
+	nhe->nhg.nexthop = NULL;
+
+	/* Enqueue to workqueue for processing */
+	rib_queue_nhe_del(nhe);
 
-	if (nhe) {
-		zebra_nhg_decrement_ref(nhe);
-		zsend_nhg_notify(api_nhg.proto, client->instance,
-				 client->session_id, api_nhg.id,
-				 ZAPI_NHG_REMOVED);
-	} else
-		zsend_nhg_notify(api_nhg.proto, client->instance,
-				 client->session_id, api_nhg.id,
-				 ZAPI_NHG_REMOVE_FAIL);
 	/* Stats */
 	client->nhg_del_cnt++;
 }