In D55064#1258692, @zlei wrote:

Is bpf_chkdir() dereferencing a NULL d->bd_bif in net epoch ?

and if they do I believe they deserve to go on a treasure hunt

Oops, sorry. If the reviews.freebsd.org mailbox was open in mutt while I was fixing the test, then I would not jump in front of you.

Oh, sorry for that. Let it be then -fms-extensions until -fms-anonymous-structs hits our version of clang. But for the files that need it.

First, let's talk about -fms-anonymous-structs then instead of -fms-extensions, cause the latter enables much more. Second, please don't use the fact that I added this flag back in 2015 for gcc as an argument. Gcc is our second tier compiler and back then this change was the least intrusive hack to allow us to go forward with C11 feature and still be compilable by back-then version of gcc. Actually, I should look if this change can be reverted today. Finally, the list of files you provided doesn't look scary to me. It is 12 modules out of more than 500.

In D54986#1258395, @bz wrote:

In D54986#1258387, @glebius wrote:

struct _bar {
        int x;
};

struct foo {
        struct _bar;
        int y;
};

struct foo.x = 17;

That's pretty evil! I don't think we should encourage that around the kernel. C11 anonymous unions & structs don't leave any space for ambiguity, they do quite the opposite. This extension looks pretty scary, as I may have x in bar and in baz, and then make both baz and bar member of foo.

that just fails with error: duplicate member 'x'

But it's funny given jhb in an email thread pointed out that it was you moving this globally enabled in the kernel for gcc in cc4a90c445aa04be36c3ef745cbe67fa339b94b5 . I don't think that commit did what you thought it would back then.

I can't understand why do we need the global (pre-vnet) list. Can the queue just hang off the in6_ifaddr?

Bruce, very glad to see you back!!!

• Use rcvmtxopts as Mark suggests.

In D54948#1257019, @afedorov wrote:

Maybe someone remembers this project: https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052226.html

In D54948#1256749, @zlei wrote:

Might be off-topic. I have ever had an idea, that introducing SOFT checksum offload to all soft interfaces. The upper stack will see this and hand over the calculating of the checksums to the interfaces. The soft interfaces may calculate the checksums when absolutely necessary, or let the edge physical interfaces do the stuff when the packets are leaving the host. Then we can benefits the hardware checksum, or we have better icache locality ( batch processing the mbufs ) when doing soft checksum.

What do you think ?

Question on naming. I would read "resultproc" as "result process". What does "resultprot" stands for?

This is not correct. First, the TCP_MAXSEG set with setsockopt(2) should match TCP_MAXSEG later retrieved with getsockopt(2). It refers to configured MSS. Second, tcp_maxseg() determines current possible MSS to be used with cwnd calculations. The result of tcp_maxseg() maybe different depending on current state of SACK. Randall later added tcp_fixed_maxseg() that ignores SACK. I'd leave other congestions experts to judge which one is correct for cwnd calculations. But neither tcp_fixed_maxseg() will work correctly here, as would break setsockopt/getsockopt result.

In D54573#1255018, @pouria wrote:

@glebius Can I commit it with a 1-week MFC?

I don't plan to merge my changes.

In in6_ifmtu() unroll the two level ternary operator into a more readable form.

I agree with Kostik that this nice feature should be enabled by default.

In D54820#1253193, @kib wrote:

There is a call to kern_writev() on the socket, is it true that it never returns EINTR for non-blocking socket?

And, this sounds more like the bug than a useful feature. Slow (network) syscalls must be interruptible.

JFYI: this patch will need some trivial adjustments after I land https://reviews.freebsd.org/D54725

To me the patch looks good enough. I can't approve the approach taken, that adds a future version tool to a stable/xx tree. This is up to releng as the main upgrade path gatekeeper and @jhb who requested the compatibility shim.

Looks great, thanks!

Approved!

I have very little idea about that. I'm just working on making interfaces detach more safe and I want in6_ifextra to be a single piece of memory which would have delayed reclamation.

In D54636#1250207, @pouria wrote:

@glebius should these minor changes to the manual be approved by the manpages group?