In D18546#395707, @eugen_grosbein.net wrote:

In D18546#395642, @sobomax wrote:

2. At some point administrator logins and changes MTU from value X prescribed by the DHCP to some other value Y of his liking.

JFYI: the PR 229432 mentiones working way to ignore option 26 (MTU) supplied by DHCP server:

interface "em0" {

supersede interface-mtu 0;

}

@eugen_grosbein.net actually upon thinking a little bit more about the difference between this proposed change and r336195 I came to a conclusion that those two are not necessarily mutually exclusive, but rather complementing each other. The problem with just r336195 alone is that it invalidates implicit expectations that dhclient should not try to touch interface at all after initial configuration, unless there are some changes on the DHCP side. As an administrator, I'd not expect dhclient to be actively policing interface parameters and try to enforce them, which would be the case for MTU now. Consider the following hypothetical scenario:

In D18535#395442, @eugen_grosbein.net wrote:

In D18535#395370, @sobomax wrote:

In D18535#395273, @eugen_grosbein.net wrote:

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

Well, that's where I respectively disagree. As an owner of hundreds of FreeBSD systems servicing many millions of customers I think that rebooting the system immediately after any slight kernel heap/stack memory corruption is detected is not just appropriate but the only sane action available. Shutting down particular netgraph node and hope for the best would just leave the service down indefinitely with no hope for any sorts of automatic recovery.

Node destruction and recreation is easily implemented automatic recovery. We obviously have different usage patterns. I use net/mpd5 that can use ng_nat connecting it to the session that can be destroyed and re-created by any of "client" or "server" recovering from corruption and not interfering with other sessions. Other usage patterns can react on such event to re-create nodes too.

In D18546#395445, @eugen_grosbein.net wrote:

Hmm, there was https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229432 and corresponding commit https://svnweb.freebsd.org/base?view=revision&revision=336195 fixing the problem.

Was it insufficient or your tree does not have that fix?

In D18535#395273, @eugen_grosbein.net wrote:

Looks good with one exception: additional plain panic(). Can it be replaced with KASSERT?

IDK, there is no way this option to be set to anything but DLT_RAW or DLT_EN10MB in the course of normal operation of the node. So it would require some form of memory corruption to actually happen. IDK, panic(9) seems an appropriate action in that case. There are other panic(9) call in the code in similar situations.

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

In D18535#395220, @eugen_grosbein.net wrote:

Looks good with one exception: additional plain panic(). Can it be replaced with KASSERT?

Make sure we have enough data for ethernet header.

o Due to popular request rename "erase" into "trim".

Looks good to me.

Looks fine to me. Just two small code nits.

In D11025#232116, @kib wrote:

In D11025#232110, @sobomax wrote:

@kib how difficult is it to also implement real NOTE_MONOTONIC, i.e. event that expires in monotonic time from the getgo? I think this would be very useful for real-world applications that care about precise timekeeping. We use CLOCK_MONOTONIC pretty much all across our code here. Yes, it can be added later on, but without it the API is somewhat incomplete IMHO.

In which way would this timer different from the existing timers without NOTE_ABSTIME flag ?

In D11025#228355, @kib wrote:

In D11025#228344, @ed wrote:

One suggestion, though: instead of calling this NOTE_MONOTONIC, would it make sense to use NOTE_ABSTIME instead?

NOTE_MONOTONIC sounds as if it uses CLOCK_MONOTONIC under the hood, even though your implementation still uses CLOCK_REALTIME, right?

Apple uses NOTE_ABSOLUTE, but their API is different from us, and from my understanding, glib maintainers, who asked for this feature, do not like Apple' edge-triggering feature of NOTE_ABSOLUTE.

I will rename the flag to NOTE_ABSTIME on next patch update.

Adjusted a bit as suggested.

Re-phrase a bit based on suggestions.

Reformat in-line example based on input from wblock.

Improve wording as suggested by the rpokala, bcr & bjk.

I've checked both forward and backward compatibility (3-way actually, old mdconfig+new kernel, old kernel + new mdconfig, new mdconfig+new kernel) everything seems to be working properly.

In D10457#216855, @imp wrote:

Love this idea, but the padding issue needs to be resolved.

Collapse if/return/else/return into a single return statement.

Rework previous change to restore ability to shutdown datagram
sockets to be easier to understand and put a comment explaining
what's going on and why.

I think Ed's comparison with other OSes here and in the relevant differential was not entirely correct. What linux does (tested with 4.4.0) when UDP socket is shut down is actually shutting down receiving end, so any threads that are blocked in recv() on that socket return. Still shutdown() system call itself returns ENOTCONN. FreeBSD on the other hand does not do anything for the socket, so that the threads just hang. I am pretty sure there are at least some software out there that relies on that behavior, at least in our case we do. Bumped into this after upgrading to the 11.0.

Looks like necessary functionality is already part of the -atime/-ctime/-mtime.