ofed: fix GID table reference leak in roce_gid_update_addr_callback()

[aehrenberg_nvidia.com]

Summary

The "add missing GIDs" loop uses rdma_find_gid_by_port() to test whether
a GID already exists, but forgets to drop the reference it returns. So
every rescan that finds an existing GID leaks one, which pins the entry
and prevents its slot from ever being freed on delete.
Just release the reference once the GID is found, like the "remove stale
GIDs" loop already does.

[kib]

sys/ofed/drivers/infiniband/core/ib_roce_gid_mgmt.c

264

Same question, what ensures that the gid is still at the index between search and update?

Should the put() be done after update_gid()?

[aehrenberg_nvidia.com]

sys/ofed/drivers/infiniband/core/ib_roce_gid_mgmt.c

264

Nothing keeps it at that index, and nothing has to, because the index isn't used after the search. The search is only to know if this GID already in the table or not, and that's the only thing the result is used for.
The real work is done on update stage, that takes table->lock and search again, matching on the GID value, the GID type and the netdev. So it acts on whatever slot the entry is in at that moment. If the slot happened to be taken by a different GID in the meantime, it simply won't match.
Indeed a race can leave a hole (stale entry), but that will be corrected at next scan because each scan recomputes the full desired state from scratch, and every address change queues another scan on the ordered workqueue, so it converges.

[jhb]

Good catch.