Hi Joe,
I'm investigating an issue where I've seen "handler_duplicate_upcall"
incrementing once, and where "upcall_ukey_replace" is happening quite
often.
This all relates to the try_ukey_replace() function:
+static bool
+try_ukey_replace(struct umap *umap, struct udpif_key *old_ukey,
+ struct udpif_key *new_ukey)
+ OVS_REQUIRES(umap->mutex)
+ OVS_TRY_LOCK(true, new_ukey->mutex)
+{
+ bool replaced = false;
+
+ if (!ovs_mutex_trylock(&old_ukey->mutex)) {
+ if (old_ukey->state == UKEY_EVICTED) {
+ /* The flow was deleted during the current revalidator dump,
+ * but its ukey won't be fully cleaned up until the sweep
phase.
+ * In the mean time, we are receiving upcalls for this traffic.
+ * Expedite the (new) flow install by replacing the ukey. */
+ ovs_mutex_lock(&new_ukey->mutex);
+ cmap_replace(&umap->cmap, &old_ukey->cmap_node,
+ &new_ukey->cmap_node, new_ukey->hash);
+ ovsrcu_postpone(ukey_delete__, old_ukey);
+ transition_ukey(old_ukey, UKEY_DELETED);
+ transition_ukey(new_ukey, UKEY_VISIBLE);
+ replaced = true;
+ }
+ ovs_mutex_unlock(&old_ukey->mutex);
+ }
+
+ if (replaced) {
+ COVERAGE_INC(upcall_ukey_replace);
+ } else {
+ COVERAGE_INC(handler_duplicate_upcall);
+ }
+ return replaced;
+}
+
Currently, there is no debugging in place to get an idea if the lock
failed or the wrong state it was in. I'll instrument the code if we can
get it to fail again/reliably.
In the meantime, I was wondering why we do an ovs_mutex_trylock(), and
not just a lock()?
Unfortunately, I've only seen it once, and replication efforts have not
been successful.
Thanks,
Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
