With the change I made to keep the current behavior for everything except swap (which is fairly well tested), are there additional concerns?

I was able to replicate it locally using llvm's c++ 9.0.1 and defining _WANT_SOCKET prior to including the header file:

Can you provide some more information on the exact error you saw? I'm 99.9% sure we successfully compiled these sources with LLVM 9.

Address comments by @jhb:

• Delete the code to declare the GELI threads as kernel FPU threads. (I'll open a separate review for that.)
• Switch the default to blocking mallocs for everything except swap requests.

In D24400#536778, @jhb wrote:

To be clear, you only tested encrypted swap? Did you do any testing with encrypted volumes meant to hold persistent data after a reboot (e.g. holding a UFS volume on a disk) and seeing how it was impacted by ENOMEM?

Rebase onto D24272.

• Address @jhb's comments.
• Add the comment requested by @bz on the reason UNIX domain sockets are restricted to 104 bytes.

Correct typo in the man page. (Thanks @bcr!)

Make the overflow rate-limit be controlled by a sysctl.

I'm going to do a tinderbox build of this + D24316 (mostly, to make sure I didn't mess up the various INET/INET6 combinations) and then commit them.

Thanks for providing the extra context on the transport call today. Overall, this change looks good. I left a few nits in in-line comments.

As discussed on the transport call today, please change both the in order and out of order data path so we call sorwakeup_locked() (when necessary) after the SACK blocks are updated.

Switch to using sbuf(9) for string creation. Also, use a constant string for "local:".

In D24272#534063, @jhb wrote:

I think this looks fine. It would be nice to use a string builder instead of memcpy/strcat, etc. like sbuf(9) to make it more robust to future changes.

FWIW, these are examples of the messages this produces:

Apr  3 19:58:34 c006 kernel: sonewconn: pcb 0xfffff805a566a200 (127.0.0.1:65432 (proto 6)): Listen queue overflow: 4 already in queue awaiting acceptance (1 occurrences)
Apr  3 19:59:44 c006 kernel: sonewconn: pcb 0xfffff80611de4000 ([::1]:65432 (proto 6)): Listen queue overflow: 4 already in queue awaiting acceptance (2 occurrences)
Apr  3 20:16:12 c006 kernel: sonewconn: pcb 0xfffff80170cde100 (local:/tmp/testsock): Listen queue overflow: 4 already in queue awaiting acceptance (1 occurrences)

In D18624#458099, @jtl wrote:

This looks like it does what is described. As I understand, the use of delivered_data will be covered by a separate review. It looks like this will slightly change the way sacked_bytes is calculated. The change is probably a good thing, but it is worth verifying (and I haven't done this yet) that the updated calculation will work correctly.

In D23517#516688, @markj wrote:

In D23517#516336, @jtl wrote:

In D23517#516299, @markj wrote:

So, the problem manifests as the laundry queue steadily growing without any swapping in response?

We noticed this when we tried enabling encrypted swap. On the console, we see a string of processes killed due to the server being out of memory. Then, eventually, the watchdog timer fires and kills the system. I don't know what triggers this cycle. It seems to happen on a small percentage of systems hours to days after boot. To the best of my knowledge, we have not been able to observe a system descend into this naturally.

We tried to recreate the problem by artificially creating memory pressure. We ran a program that allocates a lot of memory (equal to the sum of the free and inactive sizes) and sequentially writes to each page in a loop. When we did this, we saw:

1. The laundry size is growing.
2. Processes are continually killed due to low memory.
3. Finally, the watchdog kicks in and reboots the system.

Now, we may have recreated a different problem that has similar symptoms. But, at minimum, it seems like this is showing *a* bug.

I've done tests like this in the past. Indeed, if the program is dirtying pages quickly enough we might give up an attempt an OOM kill, but we should definitely be targetting the runaway process first. It's possible that we may have swapped its kernel stack out, in which case I believe we have to swap it back in to reclaim anything, since reclamation happens during SIGKILL-triggered process exit. (I don't see offhand why another thread couldn't call pmap_remove_pages() on the target process before it is swapped back in though.)

I have not tried testing with a GELI-backed swap device though. Presumably you were using one? Do you see a difference in behaviour when swap is unencrypted?

In D23517#516299, @markj wrote:

Note that the page daemon uses vmd_free_target as the PID controller set point, but its target may be larger than the instantaneous difference vmd_free_target - vmd_free_count. So if it manages to free enough pages to satisfy vm_paging_target(), but not enough to satisfy the PID controller target, it'll trigger the laundry thread's shortfall mode, which then does nothing (unless pageout_deficit happens to be bigger than the negative difference). This suggests to me that the page daemon should be storing the value of page_shortage in the vmd_shortage field. In other words, the page daemon has failed to meet its target by page_shortage pages, and the laundry thread should try and make up that difference.

In D23517#516299, @markj wrote:

So, the problem manifests as the laundry queue steadily growing without any swapping in response?

@bz will commit.

Basically commited by @bz .

In D21840#477432, @rscheff_gmx.at wrote:

TCP_INFO is not portable afaik; however, I wonder why the linux varian has a flag for "SYN_DATA" (which may get delivered to the appliacation if the TFO is present), but no flag for TFO, while this change is signaling the presence of TFO, but no SYN_DATA... Just curious...

In D19622#476255, @bz wrote:

In a later call I think your suggestion was along the lines of:

(a) if ifnet goes away nuke the recvif pointer from the queued mbufs
(b) if reassembly times out do as outlined above and skip sending ICMP error/per-IF statistics/.. if the ifnet pointer was nuked
(c) if another fragment arrives (or the last fragment to complete the packet arrives) use that ones recvif pointer as that interface is expected to still be there to pass the packet on

Now there is a gray area between (b) and (c) in which (b) could be extended to "if we cannot find an ifnet pointer in the expected place, scan the fragments of the packet in question for any ifnet pointer and use that one" for error handling. It'd be a one-time slightly more expensive operation. If there's an attack however that is kind-of the extra work you'd want to avoid. Without the extra work, you may not find out as easily what kind of problem you are running into though as you are lacking statistics. Trade-off...

In D14387#476034, @bz wrote:

This may sound like a pain but as you already say in your message, this is two changes .. First .. Second ..
Can you split them up into such? First should be really easy to review and second should then be straight forward as well by itself.

Switch to using callout_init_mtx to let the callout system acquire the pause lock.

An alternative, better, version was implemented by @mjg in rS339449.

This was largely committed by mmacy last year.

This looks like it does what is described. As I understand, the use of delivered_data will be covered by a separate review. It looks like this will slightly change the way sacked_bytes is calculated. The change is probably a good thing, but it is worth verifying (and I haven't done this yet) that the updated calculation will work correctly.

In my local tree, I added functions to generate fake machine check records and exercise the logic now found in mca_process_records(). It appears to work correctly. I *think* this is now ready to land.

Changes based on review:

• Switched to using STAILQ_CONCAT to refill the free list.
• Dropped redundant calls to resize the free list.
• Centralized the logging logic to reduce code duplication.

Incorporate feedback from @jhb.

Try 2:
Maintain the last N records in the mca_records list. N is user-configurable and defaults to -1 (unlimited; the current behavior).

In D20482#442176, @jhb wrote:

So I have had tools in the past that parsed the list from the kernel. See https://github.com/freebsd/freebsd/compare/master...bsdjhb:libsmbios_ecc. At the very least I think there should perhaps be a tunable/sysctl to control the behavior.

In D20109#437264, @hselasky wrote:

@glebius: Multicast destruction is deferred. When we destroy a multicast address we need to call the if_ioctl of the belonging network interface to remove any multicast addresses. That's the problem. I think draining is a good way to implement a safe solution instead of using refcounts. Then we ensure that the ifnet is in a certain state when the multicast destruction callbacks are invoked.

In the interests of avoiding discussion fragmentation, I am adding the feedback from the transport working group meeting today.

Accepting the inp change as transport role to unblock the review.

In D19960#429052, @bz wrote:

That said, there are vendors who list it (maybe not on the forwarding plane) but as RFC compliance supporting it:
https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/ipv6.html

I agree with @bz about ideal process. I also agree with @kristof about the practical implications of this feature. :-)

LGTM

I'm confused how a RST could have tripped this assert. In that case, len should have been 0 and ((th_flags) & (TH_SYN | TH_FIN)) == 0 should have been true (i.e. neither SYN nor FIN was set). In other words, it looks to me as if a RST should already pass the assert without tripping it. Can you explain further what I'm missing?

Thanks!

Approved.

(FYI, the revision looks incorrect. It looks like it should have been r342597.)

Approved