- User Since
- Oct 29 2015, 5:25 PM (260 w, 6 d)
Apr 23 2020
Apr 20 2020
With the change I made to keep the current behavior for everything except swap (which is fairly well tested), are there additional concerns?
Apr 18 2020
Apr 17 2020
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.
Apr 16 2020
Apr 14 2020
Apr 13 2020
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.
Rebase onto D24272.
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.
Apr 9 2020
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.
Apr 6 2020
Switch to using sbuf(9) for string creation. Also, use a constant string for "local:".
Apr 3 2020
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)
Mar 12 2020
Mar 9 2020
Feb 27 2020
Feb 10 2020
Feb 7 2020
Feb 6 2020
Feb 5 2020
Oct 24 2019
@bz will commit.
Basically commited by @bz .
Oct 1 2019
Sep 27 2019
Sep 26 2019
Sep 18 2019
Switch to using callout_init_mtx to let the callout system acquire the pause lock.
Sep 17 2019
Sep 14 2019
Sep 13 2019
Sep 3 2019
This was largely committed by mmacy last year.
Aug 19 2019
Aug 10 2019
Aug 9 2019
Jul 29 2019
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.
Jul 18 2019
Jun 19 2019
Jun 12 2019
Jun 8 2019
Jun 7 2019
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.
Jun 6 2019
Jun 5 2019
May 31 2019
Incorporate feedback from @jhb.
Maintain the last N records in the mca_records list. N is user-configurable and defaults to -1 (unlimited; the current behavior).
May 24 2019
May 23 2019
In the interests of avoiding discussion fragmentation, I am adding the feedback from the transport working group meeting today.
Apr 25 2019
Accepting the inp change as transport role to unblock the review.
Apr 18 2019
I agree with @bz about ideal process. I also agree with @kristof about the practical implications of this feature. :-)
Apr 13 2019
Mar 18 2019
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?
Feb 21 2019
Feb 12 2019
(FYI, the revision looks incorrect. It looks like it should have been r342597.)