Skip to content

Don't just wait for a response because NLM_F_REQUEST is set - #44

Open
Toorero wants to merge 1 commit into
rust-netlink:mainfrom
Toorero:fix/expect_response_on_req
Open

Don't just wait for a response because NLM_F_REQUEST is set#44
Toorero wants to merge 1 commit into
rust-netlink:mainfrom
Toorero:fix/expect_response_on_req

Conversation

@Toorero

@Toorero Toorero commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

It is incorrect assuming a response is guaranteed solely because NLM_F_REQUEST is set.

NLM_F_REQUEST by itself only marks a message as coming from user space and is a requirement to make successful requests to the kernel as an application.1

We can only assume a response (in form of an ACK or error) is guaranteed if NLM_F_ACK is set.2
Then either an error or an ack is getting returned.


Further research is needed to determine if a response is guaranteed on NLM_F_ECHO as the kernel doc states it isn't universally implemented3. In my mind sending a NLM_F_REQUEST | NLM_F_ECHO request could produce no response if the message is successful (no ACK is issued, because NLM_F_ACK is unset) but the addressed system doesn't implement echo or the request changes nothing.

Footnotes

  1. https://github.com/torvalds/linux/blob/f5bbbfec59b4e2fb7520a91de3df8a6174325d6a/net/netlink/af_netlink.c#L2548-L2550

  2. https://github.com/torvalds/linux/blob/f5bbbfec59b4e2fb7520a91de3df8a6174325d6a/net/netlink/af_netlink.c#L2560-L2562

  3. https://github.com/torvalds/linux/blob/f5bbbfec59b4e2fb7520a91de3df8a6174325d6a/Documentation/userspace-api/netlink/intro.rst#notification-echo

@Toorero

Toorero commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

The current behaviour could lead to a bunch of stale PendingRequests accumulating in Protocol even if you'd use ConnectionHandle::notify without NLM_F_ACK set on success.

@Toorero

Toorero commented Aug 14, 2026

Copy link
Copy Markdown
Contributor Author

This would also allow to work around Kernels not acknowledging BATCH_BEGIN and BATCH_END messages prior to bf2ac49 by not supplying them with an NLM_F_ACK flag.

On kernels prior to bf2ac49 (e.g. Ubuntu 24.04 LTS) the newly introduced method request_batched by #45 would hang forever, even if NLM_F_ACK is set on every message.

In general, it is not recommended [1] to force the kernel to acknowledge every message. If you batch messages, requesting and receiving a single acknowledgement should be enough, since it's an all-or-nothing-operation.

@Toorero
Toorero force-pushed the fix/expect_response_on_req branch from dcd1deb to b1f09a0 Compare August 14, 2026 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant