Re: [PATCH] netfilter: nfnetlink: always ACK batch end if requested

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi Nikolaos,

On Wed, Oct 01, 2025 at 11:15:03PM +0200, Nikolaos Gkarlis wrote:
> Before ACKs were introduced for batch begin and batch end messages,
> userspace expected to receive the same number of ACKs as it sent,
> unless a fatal error occurred.

Regarding bf2ac490d28c, I don't understand why one needs an ack for
_BEGIN message. Maybe, an ack for END message might make sense when
BATCH_DONE is reached so you get a confirmation that the batch has
been fully processed, however...

> To preserve this deterministic behavior, send an ACK for batch end
> messages even when an error happens in the middle of the batch,
> similar to how ACKs are handled for command messages.

I suspect the author of bf2ac490d28c is making wrong assumptions on
the number of acknowledgements that are going to be received by
userspace.

Let's just forget about this bf2ac490d28c for a moment, a quick summary:

#1 If you don't set NLM_F_ACK in your netlink messages in the batch
   (this is what netfilter's userspace does): then errors result in
   acknowledgement. But ENOBUFS is still possible: this means your batch
   has resulted in too many acknowledment messages (errors) filling up
   the userspace netlink socket buffer.

#2 If you set NLM_F_ACK in your netlink messages in the batch:
   You get one acknowledgement for each message in the batch, with a
   sufficiently large batch, this may overrun the userspace socket
   buffer (ENOBUFS), then maybe the kernel was successful to fully
   process the transaction but some of those acks get lost.

That is, 1bf2ac490d28c allows you to set on NLM_F_ACK for BATCH_END,
but that acknowledgement can get lost in case of netlink socket
overrun.

ENOBUFS scenarios break assumptions on the number of messages that
you are going to receive from the kernel.

Netlink is a unreliable transport protocol, there are mechanisms to
make it "more reliable" but message loss (particularly in the
kernel -> userspace direction) is still possible.

In this particular case, where batching several netlink messages in
one single send(), userspace will not process the acknowledments
messages in the userspace socket buffer until the batch is complete.