"arc land --hold" generated a detached head locally, with a wrong commit message ("Approved by:" was missing)
After amending the commit and pushing it to git, the wrong message was pushed instead of the amended one.
I'm sorry.

Rebase to 31f481ca1c384b8c

• Change OpenPGP key
• Update the day of the commit bit

In D28123#628673, @afedorov wrote:

I also thought about getting rid of ng_bridge from NG_NODE_FORCE_WRITER. Since rcv_data is always called in the NET_EPOCH context, I think we can do it like @kp did it for if_bridge(4) (see D24250).

• Fix style for overlong line

• Fix some formatting, line up comments.
• Annotate helper functions to handle immutable objects.

It's far that simple. I missed the difference between

• const node_p: a constant pointer to a modifiable node.
• struct ng_node const * : a modifiable pointer to a constant node.

revert the idea of specialized const pointers, it's too confusing

revert the idea of specialized "const pointers"

Prepare ng_bridge for read-only data paths by providing const pointers.

In D28123#628673, @afedorov wrote:

Lutz, do you have any plans for the upcoming changes?

Reversing errornously included stacked commit.

Choose better names as suggested by melifaro.

In D28125#628582, @melifaro wrote:

LGTM. Does it really depend on D28123?

Converted local repository from subversion to git

I'd like to use the following commit message

I'd suggest to use the following commit message

Add committer entries for Lutz Donnerhacke <donner>

I do not have access to freefall at the moment, but from the current developer list, I'd assume, the name "donner" is free to be assigned.
The name is also my IRC-nick, so I'd like to keep them consistent.

Please add the description of the parameters (wgkey, wgport, ...) or point to the appropriate part in ifconfig(8) man page.

The example is more instructive, if it is split between two machines and follow the two step setup. Do not try to automate the communication by a script, it's erronous and not instructive. Remember to always use documentaion IP addresses (RFC 5737)

This patch causes a hanging kernel, if the ipfw ruleset is modified under stress.
To modify the ruleset, the system needs to be rebooted.

Given, that the old file was included by user space programms, I'd suggest to include some lines like

#ifndef KERNEL
# error "Kernel only file! Please include ...."
#endif

Updated to revision 368820.

Updated to revision 368820.

Excellent example how to apply the new API.

I was confused by your "we will clear priv->ifp in the ng_ether detach callback" sentence.
Clarified for me.

Using the accessor functions and given the fact, that only continuous netmasks are allowed (not yet), the route-prefix could be shrinked by storing the prefix length instead of the mask.
The accessor function can then return the mask from a static netmask table.

Do I understand correctly, that dst contains an explicit bitmask, which is assumed to be continuous?

Updated to revision 368146.

This patch seems to complicate things at the first glance.
But in the end, the sowakeup() call itself is the problem.
It requires to be called while holding the lock and releases it.

Mark annotations as done.

Updated to latest revision and fixed copyright annotations.

Thank you for the work. In principle the functionality can be emulated by ng_bpf as well, but this kind of node is easier to use.

In D27023#603682, @mhorne wrote:

In D27023#603532, @lutz_donnerhacke.de wrote:

OTOH even read-only access may fail without proper locking: There is no guaranty to read an unaligned multi-byte value while it's modified.
A separate function may keep the locking code locally, if necessary.
It may copy the struct into a (static) "read-only" buffer under the lock.

Can you expand on what you mean by 'unaligned'?

OTOH even read-only access may fail without proper locking: There is no guaranty to read an unaligned multi-byte value while it's modified.
A separate function may keep the locking code locally, if necessary.
It may copy the struct into a (static) "read-only" buffer under the lock.

If necessary, I'd like to change it to a read-only function call, which is exposed instead.

const struct igmpstat  * get_global_igmp_stat();

Updated to revision 367040.

Updated to revision 367040.

May I point you to D22076, which deals with vlan stacking, too.
And may I point you to D24179, which removes a show stopper for vlan stacking on Intel devices.

I do not understand, why you do not need to calculate the hash during the delete operation.

It's quite a lot of code. So the question is, why this effort?

I'd like to split the functionality of load balancing from terminating.
If you have an TCP/UDP load balancer (i.e. Linux IPVS), you can distribute you load in a very generic way between different physical servers, jails, or processes.
But that's just my feeling to avoid duplicated complexity.

Do I understand correctly, that this (heavy) patch works around the deficiencies of an unfit user space program?

In order to prevent this race, the node should be know. that it's in shutdown. This way the callout can skip the reinvocation.
Another solution would be to free the c_arg argument manually.

In D21968#592148, @afedorov wrote:

Do you have any performance measurements?
Is it have advantages over injecting packets through ng_socket(4) or ng_device(4)?

Fix typo and style.

In D21965#592154, @markj wrote:

In the example compact output, the edge labels overlap and are hard to read, at least with default layout settings using dot(1) or webgraphviz. Is it possible to fix it easily?

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

Rebase to r366170.

In D26548#591459, @markj wrote:

In D26548#591453, @markj wrote:

Indeed, there seems to be a race in ng_l2tp_seq_xack_timeout() as well.

This looks like it could cause transmission of a ZLB with stale NR or NS, again in rare circumstances. I don't think it will cause a kernel panic.

My problem is, that I do not understand, how this race condition can happen at all.
Sure, the fix seems obvious and does not harm, so let's go with it.

In D26548#591373, @markj wrote:

In D26548#591305, @lutz_donnerhacke.de wrote:

Can you please point me to the bug report?

The PR that Aleksandr noted, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241133

A pfsense developer also reported seeing a null pointer dereference in ng_l2tp_seq_rack_timeout(), apparently because seq->xwin[0] == 0. Apparently the panic was observed even after this commit: https://svnweb.freebsd.org/base?view=revision&revision=353027 .

Is the bug reproducible in a test environment?
Did someone try to compile with INVARIANTS (in order to bring L2TP_SEQ_CHECK into life)?

Can you please point me to the bug report?
We are running this node in a large scale production environment (with remote LAC at different carriers) and did not observe such an issue before.

I'm fine with this fix for a special case.
I agree, that a more complete approach would be fine, but this can be done in a later stage.

May you please provide a full context diff?
See https://wiki.freebsd.org/Phabricator

Heavy patch, looks promising overall.

In D26420#587790, @markus_stoffdv.at wrote:

In D26420#587703, @lutz_donnerhacke.de wrote:

Does this match your requirements?

Yes, it absolutely does. Thank you very much!

In D26420#587635, @markus_stoffdv.at wrote:

To be honest, I did not recognize ng_bpf would do that. I will reevaluate my requirements based on that.

In D26420#587637, @markus_stoffdv.at wrote:

I had another look into ng_bpf and I still do not understand how to express the required directionality in a tcpdump filter.

Can you please explain, what your node has in favor of ng_bpf (which is scripted with an arbitrary tcpdump expression)?
Currently I see a lot of parsing complexity moving into the kernel, which lacks a lot of expressiveness.

In D26358#586750, @ae wrote:

I think this patch is too complicated. Can you properly test this patch instead? https://people.freebsd.org/~ae/ipfw_frag.diff