Because this is an incompatible change to current behavior, it should be mentioned in the RELNOTES or UPDATEING

Good catch.

LGTM

LGTM

Do I understand correctly, that this is the first bpf-option to alter the packet in transit?
Usually I'd solve this problem by adding a simple netgraph network to the outgoing interface.

In D31099#699666, @kp wrote:

My plan was to push the preceding patches (i.e. adding and moving to the new call in libpfctl) first, and this one a week later. That'd give main and stable/X users some time to build a new kernel and userspace before we remove the old call. That achieves having the new kernel support old userspace, with a short transition period (so we don't end up with DIOCGETSTATESNV in a release and we have to support is forever).

Depends on D30959

Good work! But hard to review.

Why does it depend on other reviews?
If it's part of an open review, please fix it there.
If not, please fix it regardless of the other changes.

In D30947#696642, @mjg wrote:

Since userspace has to alloc all the memory anyway, you can extend the count by say 20% (or even double it if not going past a threshold). Then you can call the kernel and have it fill out as much as it sees fit and return, giving you a magic token which you can use to continue the iteration (which would normally be a row number). Then it is up to the kernel to make the most of what userspace is offering all while limiting its own memory use as it sees fit. This should probably be a new ioctl.

LGTM

Please MFC this to any version containing the "old" ABI, so that no intermediate versions enter the external visible trains.

In D30175#694137, @rozhuk.im-gmail.com wrote:

In D30175#693715, @donner wrote:

May you please add a paragraph to the rc man page, too?

I am not native speaker, it is a bit hard to me to write for humans.

Thank you for adding context to the diff.

First I'm happy to see such a sophisticated use of netgraph in the default rc context.
Thank you for this idea.

In D30811#693218, @zlei.huang_gmail.com wrote:

Can you please share the discussion? Thanks!

Use arc4random_uniform(3) as recommended by Dimitry Luhtionov.

I'm surprised. There was a discussion about not redirecting /32 on interfaces to loopback. So we see the consequence.