In D42664#973383, @glebius wrote:I actually planned to make it a loadable module. Given that it creates extra threads that aren't going to be used by default makes its presence questionable.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Dec 20 2023
Dec 20 2023
Dec 19 2023
Dec 19 2023
Nov 17 2023
Nov 17 2023
Nov 16 2023
Nov 16 2023
genoffset.sh: fix build break on MacOS
genoffset.sh: stop using a temporary file
Nov 7 2023
Nov 7 2023
In D42407#967685, @imp wrote:I might also note in the commit message you used a here document with the shell output expanded in the commit message... it is a bit of a surprising change based on the commit message.
Oct 30 2023
Oct 30 2023
Sep 15 2023
Sep 15 2023
Jun 1 2023
Jun 1 2023
May 31 2023
May 31 2023
tcp: Refactor tcp_get_srtt()
May 27 2023
May 27 2023
jtl added a comment to D40267: tcp: fix a bug where unshifting should be put last in tcp_get_srtt().
For what its worth...
May 9 2023
May 9 2023
jtl committed rG8a16fb47303e: locks: fix two potential overflows in the lock delay code (authored by jtl).
locks: fix two potential overflows in the lock delay code
Apr 17 2023
Apr 17 2023
Incorporate two suggestions from @jhb.
Apr 10 2023
Apr 10 2023
Apr 7 2023
Apr 7 2023
Mar 31 2023
Mar 31 2023
Updated the diff to upgrade the delay field from u_short to u_int in struct lock_delay_arg. Due to alignment requirements, this probably won't actually change the size or in-memory layout of the structure at all.
Mar 4 2023
Mar 4 2023
jtl added inline comments to D38853: Make eventratecheck (formerly ppsratecheck) safe on multi-processor systems.
Mar 3 2023
Mar 3 2023
jtl added a comment to D38853: Make eventratecheck (formerly ppsratecheck) safe on multi-processor systems.
In D38853#884786, @mjg wrote:Quite frankly I'm confused how come people keep claiming atomic ops are cheap, when it seemed it is common knowledge they are very expensive, especially so on amd64. Maybe I should do a writeup with real numbers(tm).
Mar 2 2023
Mar 2 2023
jtl added a comment to D38853: Make eventratecheck (formerly ppsratecheck) safe on multi-processor systems.
In D38853#884557, @mjg wrote:atomics already make it probably too expensive to use
jtl requested review of D38853: Make eventratecheck (formerly ppsratecheck) safe on multi-processor systems.
Dec 15 2022
Dec 15 2022
By the way, I should clarify that I am not opposed to this change; rather, my previous comment was merely intended to help explain what I view as the implications of the change and advocate that we make sure there is sufficiently broad agreement to proceed.
The rationale for the present state is found here.
Sep 28 2022
Sep 28 2022
Functionally committed in D36716
Sep 26 2022
Sep 26 2022
In D36716#833679, @tuexen wrote:How does this relate to the TCP User Timeout from RFC 793/9293?
In D36595#832812, @kib wrote:I still do not like the extra verbosity from kernel. If insisting on adding more kernel messages, you could make logging for SIGTRAP with interesting si_codes, covering both wxorx and capsicum in one shot.
Sep 23 2022
Sep 23 2022
Fix the man page description of the vm.enforce_wxorx sysctl/tunable to indicate that a value of 2 both denies mappings and sends a signal.
Addressed review feedback.
Restored defaults.
Sep 21 2022
Sep 21 2022
Added a section to the security(7) man page in an attempt to clarify the controls which will be available if this change is merged.
Sep 16 2022
Sep 16 2022
In D36595#831110, @jtl wrote:In D36595#831026, @kib wrote:IMO there is too much controls now for wxorx. There is proccontrol -m wxmap, and essentially adding yet another knob breaks it.
I'll look into this a little more.
In D36595#831026, @kib wrote:IMO there is too much controls now for wxorx. There is proccontrol -m wxmap, and essentially adding yet another knob breaks it.
Made changes based on review:
- Switch from syslog to uprintf() for reporting ELF W^X failure.
- Separate W^X logging and enforcement.
- Change test for which processes to signal. (Now, system processes, processes which are still starting, and kernel threads are exempt.)
- Switch from using SIGSEGV to SIGTRAP with a descriptive code.
Sep 15 2022
Sep 15 2022
Changes suggested in the review:
- Added entry to UPDATING.
- Updated security(7) man page.
Sep 9 2022
Sep 9 2022
In D36275#826020, @markj wrote:The diff seems ok to me, but I don't really understand why we need one callout per hash bucket. It's an extra 64KB per VNET, which isn't exactly cheap. I can see why it's conceptually simpler to implement this way, since you have a per-bucket mutex to synchronize the callout, but it still feels like overkill. I don't have any other comments on the patch itself.
Sep 22 2021
Sep 22 2021
Jun 17 2021
Jun 17 2021
May 20 2021
May 20 2021
Apr 12 2021
Apr 12 2021
jtl added a comment to D29519: Add missing sockaddr length and family validation to various protocols.
In D29519#666595, @tuexen wrote:In D29519#666585, @markj wrote:Ping? Any comments on the overall approach, or on the details of the change?
Hi Mark,
we discussed this at the last transport call. We agreed that that handling should be consistent but wanted to check until the next transport call (about two weeks from now) what the consistent way would be. My understanding is:
Apr 1 2021
Apr 1 2021
jtl added a comment to D29519: Add missing sockaddr length and family validation to various protocols.
Thanks for doing this! It looks like a very positive change, and I'm sure there was a lot of effort put into finding the right way to clean up the code.
jtl added a comment to D24316: Make sonewconn overflow messages have per-socket rate-limits and values.
In D24316#639938, @brd wrote:
Thanks for doing this so quickly!
Mar 31 2021
Mar 31 2021
FWIW, I disagree with this change. I think we should instead use atomic operations here.
jtl committed rG40d278253d20: Fetch the sigfastblock value in syscalls that wait for signals (authored by jtl).
Fetch the sigfastblock value in syscalls that wait for signals
jtl committed rGa25c17022e2d: Fetch the sigfastblock value in syscalls that wait for signals (authored by jtl).
Fetch the sigfastblock value in syscalls that wait for signals
Mar 12 2021
Mar 12 2021
jtl committed rGdbec10e08808: Fetch the sigfastblock value in syscalls that wait for signals (authored by jtl).
Fetch the sigfastblock value in syscalls that wait for signals
In D29225#654397, @kib wrote:It is strange indeed, and it sounds more like a self-inflicting action from userspace. Code in rtld or libthr should not leak sigfastblock block, but of course bugs are possible.
This is the change I am planning to commit once the regression tests finish running.
Mar 11 2021
Mar 11 2021
Jan 14 2021
Jan 14 2021
Dec 4 2020
Dec 4 2020
This does not fix the regression I am experiencing in my test setup. I am testing with a machine which uses a LAGG interface to communicate with the outside world. Shutting this interface down still makes my SSH sessions hang.
Dec 3 2020
Dec 3 2020
I just saw the discussion on the committers mailing list. First, it shows that @cy already has a proposed fix. Secondly, it shows that this is a larger issue (for example, netboot), which probably needs a different solution.
In D27464#613656, @tuexen wrote:When committing, please add a reference to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251540
Nov 20 2020
Nov 20 2020
When copying types from one CTF container to another, ensure that we
In D27246#609375, @markj wrote:I'd suggest running the DTrace test suite with this change if you haven't. make -C cddl/usr.sbin/dtrace WITH_DTRACE_TESTS= all install should install them to /usr/tests/cddl/usr.sbin/dtrace.
Nov 17 2020
Nov 17 2020
In D27246#608560, @markj wrote:Could you please re-upload with context?
Updating the diff to include context.
When copying types from one CTF container to another, ensure that we
While here, update the code in ctf_add_generic() to encode empty type names with index 0. This fixes the analogous case for type names.
In D27213#608228, @jtl wrote:In D27213#608181, @markj wrote:I can't reproduce this problem at all on head. The script appears to work properly. I remember that the use of anonymous unions in struct mbuf caused some problems, at least one of which was fixed by r305055, but that was a long time ago.
I can reproduce this problem locally. Some others can't reproduce the problem I reported in the main description. I'm not sure why, but there seems to be some non-determinism in the way symbols are loaded/resolved?
In D27213#608269, @ae wrote:It seems I found how to reproduce it on test system:
- Load systemt without any unneeded modules
- kldload dtraceall
- Run
# dtrace -n 'fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }' dtrace: description 'fbt::ip_input:entry ' matched 1 probe CPU ID FUNCTION:NAME 2 49220 ip_input:entry ix0 2 49220 ip_input:entry ix0 6 49220 ip_input:entry ix0 ^C # kldunload dtraceall # kldload ipfw # kldload dtraceall # dtrace -n 'fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }' dtrace: invalid probe specifier fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }: in action list: m_pkthdr is not a member of struct mbuf
Nov 16 2020
Nov 16 2020
In D27213#608181, @markj wrote:In D27213#608180, @jtl wrote:In D27213#608081, @ae wrote:Recently I faced with this problem on some machines:
# dtrace -n 'fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }' dtrace: invalid probe specifier fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }: in action list: m_pkthdr is not a member of struct mbufAnd it seems it is exactly related.
It does appear that problem is likely related to type resolution. However, for what its worth, this patch does not solve that problem on my test machine. So, that problem may have a different cause.
I can't reproduce this problem at all on head. The script appears to work properly. I remember that the use of anonymous unions in struct mbuf caused some problems, at least one of which was fixed by r305055, but that was a long time ago.
In D27213#608081, @ae wrote:Recently I faced with this problem on some machines:
# dtrace -n 'fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }' dtrace: invalid probe specifier fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }: in action list: m_pkthdr is not a member of struct mbufAnd it seems it is exactly related.
Nov 14 2020
Nov 14 2020
Add a regression test for the port-selection behavior fixed in r367680.
Fix implicit automatic local port selection for IPv6 during connect calls.
Nov 13 2020
Nov 13 2020
Nov 11 2020
Nov 11 2020
Nov 10 2020
Nov 10 2020
jtl updated the summary of D27164: Fix implicit automatic local port selection during connect calls.
When destroying a UMA zone which has a reserve (set with
Nov 6 2020
Nov 6 2020
Nov 5 2020
Nov 5 2020
jtl added reviewers for D18892: Phase 2 to add Proportional Rate Reduction (RFC6937) to FreeBSD: lstewart, rrs.
In general, this looks good. I have a small nit in that it seems like it would be worth considering whether it would be better to add the flag to the socket itself somehow so it could be synchronized by the socket lock. On the offchance someone did a socket operation which caused a wakeup while the TCP code was running, it seems possible that this might avoid a spurious wakeup. However, given the code in the src tree, I find it hard to reason through how this could occur.
Nov 4 2020
Nov 4 2020
In D26082#604611, @emaste wrote:I had a look at the man page and the -U option is indeed a bit confusing.
Certainly replacing the \n is the right thing to do; I will try to have a look at the src.