java-topology/docs/tickets/linkerd2-0001-federated-service-remote-discovery-quadratic-dedup.md
russell@unturf.com 9934133dcf whitepaper: 312 sites / 151 ecosystems — wave2+3 defect tables and PDF rebuild
Add 88 new defect entries to HIGH and MEDIUM tables:
  HIGH: mysql-0001/0002, mariadb-0001, redis-0001/0002, valkey-0001/0002, openvpn-0001,
        vlc-0001, prometheus-0001, otel-collector-0001, cockroachdb-0001..0004,
        tidb-0001..0008, kubernetes-0001/0002, go-0001, kotlin-0002, scala-0001,
        allegro5-0001, sdl2-0001, grafana-0001, clickhouse-0001, duckdb-0001,
        mongodb-0001, envoy-0001, istio-0001, cilium-0001, linkerd2-0001,
        linux-0001/0002/0003, tor-0002/0003, curl-0001, julia-0001, lua-0001,
        perl5-0001, nats-0001, spring-0003/0004, tomcat-0001, onos-0002, odl-0002

  MEDIUM: helm-0001, mariadb-0002, openssl-0001/0002, memcached-0001,
          cassandra-0001..0004, flink-0001, storm-0001/0002, zookeeper-0001..0003,
          pip-0001, gradle-0001, nginx-0001, haproxy-0001, caddy-0001, varnish-0001,
          ffmpeg-0001, gstreamer-0001, raylib-0001, love2d-0001, php-0001/0002,
          r-source-0001, cpython-0002, ruby-0001, rabbitmq-0003/0004, activemq-0001,
          ovs-0001, onos-0003, odl-0002, jetty-0001

PDF: 976K
2026-03-27 15:23:43 -04:00

2.9 KiB
Raw Permalink Blame History

linkerd2-0001: federatedService.update() slices.Contains O(n) inside loop → O(n²) dedup

Target: linkerd/linkerd2 Severity: MEDIUM CWE: CWE-407 (Inefficient Algorithmic Complexity) File: controller/api/destination/federated_service_watcher.go Status: PATCHED

Description

federatedService.update() computes the diff between the old and new remoteDiscovery slices by calling slices.Contains inside two separate for range loops. Each slices.Contains call is O(N) where N = number of remote discovery IDs. With N IDs in both old and new slices, the diff is O(N²).

This function is called on every Service update event. In multi-cluster Linkerd deployments with many federated services, each annotation update triggers a full O(N²) scan.

Location Pattern
federated_service_watcher.go:231 slices.Contains(fs.remoteDiscovery, id) inside for _, id := range newRemoteDiscovery
federated_service_watcher.go:238 slices.Contains(newRemoteDiscovery, id) inside for _, id := range fs.remoteDiscovery
federated_service_watcher.go:46 remoteDiscovery []remoteDiscoveryID — stored as slice

Root cause

// federated_service_watcher.go:229
func (fs *federatedService) update(service *corev1.Service) {
    newRemoteDiscovery := remoteDiscoveryIDs(service, fs.log)

    // O(N²): for each new ID, scan old slice
    for _, id := range newRemoteDiscovery {
        if !slices.Contains(fs.remoteDiscovery, id) {
            ...subscribe...
        }
    }
    // O(N²): for each old ID, scan new slice
    for _, id := range fs.remoteDiscovery {
        if !slices.Contains(newRemoteDiscovery, id) {
            ...unsubscribe...
        }
    }
    fs.remoteDiscovery = newRemoteDiscovery
}

With N=1000 remote discovery IDs, each update event costs ~1,000,000 struct comparisons. In active multi-cluster deployments this runs on every Service reconcile.

Fix

Convert remoteDiscovery to a map[remoteDiscoveryID]struct{} or use sets.Set[remoteDiscoveryID]. Diff becomes O(N).

// After fix: O(N) diff using map set
func (fs *federatedService) update(service *corev1.Service) {
    newSet := make(map[remoteDiscoveryID]struct{})
    for _, id := range remoteDiscoveryIDs(service, fs.log) {
        newSet[id] = struct{}{}
    }
    oldSet := fs.remoteDiscoverySet

    // O(N) adds
    for id := range newSet {
        if _, exists := oldSet[id]; !exists {
            for i := range fs.subscribers { fs.remoteDiscoverySubscribe(...) }
        }
    }
    // O(N) removes
    for id := range oldSet {
        if _, exists := newSet[id]; !exists {
            for i := range fs.subscribers { fs.remoteDiscoveryUnsubscribe(...) }
        }
    }
    fs.remoteDiscoverySet = newSet
}

Ops/ns numbers (Java benchmark)

See defects/linkerd2/unit/Linkerd2Test.java. At N=1000 IDs: slow ~1,000,000 ops, fast ~2,000 ops → >100× speedup.