Upstream Zephyr: BUILD_ASSERT for CONFIG_ZVFS_POLL_MAX is off by one

[mikeysklar]

Not our bug. Recorded here so it is not lost. Do not file upstream without checking with Phil.

include/zephyr/net/dns_resolve.h:220-225:

#define DNS_DISPATCHER_MAX_POLL (DNS_RESOLVER_MAX_POLL + MDNS_MAX_POLL + LLMNR_MAX_POLL)

#if defined(CONFIG_ZVFS_POLL_MAX)
BUILD_ASSERT(CONFIG_ZVFS_POLL_MAX >= DNS_DISPATCHER_MAX_POLL,
	     "CONFIG_ZVFS_POLL_MAX must be larger than " STRINGIFY(DNS_DISPATCHER_MAX_POLL));
#endif

The runtime bound is one higher. sockets_service.c reserves ctx.events[0] for its own
eventfd and polls count + 1 entries, so the check at line 208 is
if ((count + 1) > ARRAY_SIZE(ctx.events)). When it fires the thread jumps to fail:, sets
SOCKET_SERVICE_THREAD_FAILED and returns, and sockets registered with the service are never
read. Both NET_ERRs explaining it are compiled out at the common NET_SOCKETS_LOG_LEVEL=0.

The stock configuration lands exactly on the boundary. DNS_RESOLVER=y plus
MDNS_RESPONDER=y, IPv4 and IPv6, one interface, DNS_RESOLVER_MAX_SERVERS=1 gives
DNS_DISPATCHER_MAX_POLL = 1 + 2 + 0 = 3, and ZVFS_POLL_MAX defaults to 3. The assert
passes on 3 >= 3 and the thread dies at runtime. Either feature alone is fine.

Fix is one character:

BUILD_ASSERT(CONFIG_ZVFS_POLL_MAX > DNS_DISPATCHER_MAX_POLL,

Even then the assert counts only the DNS services, while any other NET_SOCKET_SERVICE_*_DEFINE
in the image adds to the same array. The real invariant is the total across all registered
services plus one.

[mikeysklar]

Verified against upstream zephyrproject-rtos/zephyr main today: both the bug and the off-by-one are still live, and neither has been reported.

Searches, all negative: DNS_DISPATCHER_MAX_POLL returns zero hits ever, across issues and PRs. dns_resolve.h BUILD_ASSERT zero. ZVFS_POLL_MAX returns four, newest relevant from 2024 and none about the assert. Closest prior art is #69233 (jukkar, 2024-02-20), which is why warn-and-continue became today's hard goto fail, and #73524 (krish2718, 2024-06-28). Neither is this bug.

The strongest argument for the report, which we should lead with: the assert's own message contradicts its condition. The message reads "must be larger than" while the condition is >=. That mismatch is in the shipped source.

Provenance: it was inherited, not introduced. c4803752a86 (Robert Lubos, 2024-07-03, "net: Deprecate CONFIG_NET_SOCKETS_POLL_MAX") renamed the symbol and carried the >=-plus-"larger than" text over verbatim from the older CONFIG_NET_SOCKETS_POLL_MAX assert.

Runtime side re-verified independently at upstream main: sockets_service.c reserves ctx.events[0] for the zvfs_eventfd wakeup, services are indexed from 1 (get_idx(svc) = count + 1), and the guard is if ((count + 1) > ARRAY_SIZE(ctx.events)) goto fail;. So the runtime needs strictly greater than the service count, while the assert accepts equality.

Still not filed upstream, per the standing arrangement.