I've been able to trigger an sbwait() assertion failure in the receive path when running KTLS tests, but only when running tests in parallel in QEMU. I believe the problem is the following: KTLS introduces a state for received data wherein it is being decrypted but is not yet queued in the socket buffer. In this case (sb_tlsdcc != 0), we can end up calling sbwait() with CANTRECVMORE set because that sleep/wakeup mechanism is used to signal completion of decryption operations.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 5 2024
Feb 18 2024
Jan 16 2024
Jan 6 2024
Dec 20 2023
Nov 24 2023
Oct 18 2023
Sep 16 2023
Sep 10 2023
Thanks, Mark, I will send you two commits as requested. Thanks again for all your help!
Sep 9 2023
Looks good to me. Thanks for working on this.
Reformat to ahere to suggested style...
Sep 8 2023
Aug 25 2023
Aug 3 2023
Mar 20 2023
Feb 16 2023
Dec 13 2022
Jul 28 2022
Jul 22 2022
Apr 19 2022
Mar 25 2022
Jan 21 2022
Jan 10 2022
Nov 9 2021
Oct 10 2021
Sep 23 2021
May 26 2021
May 1 2021
Mar 16 2021
Feb 23 2021
Feb 19 2021
Jan 5 2021
Dec 4 2020
Sep 21 2020
Jun 23 2020
May 28 2020
May 24 2020
Apr 7 2020
Feb 24 2020
Feb 14 2020
Nov 20 2019
Jun 21 2019
May 17 2019
Mar 21 2019
In D13759#397131, @bcr wrote:Is this still open? I'm not sure manpages needs to approve much here. I'm OK with the change from the doc (comment) side.
Jan 2 2019
Dec 20 2018
Is this still open? I'm not sure manpages needs to approve much here. I'm OK with the change from the doc (comment) side.
Aug 31 2018
Aug 16 2018
Aug 14 2018
I'm keeping the sysctls around, though without COMPAT_FREEBSD11 (or with BURN_BRIDGES), they're read-only. This preserves the expected behavior for programs that want to find out what they're allowed to do before attempting it (e.g. rc.d/hostname and rc.d/zfs). But they will no longer be used to set global permissions for jails.
Aug 1 2018
May 15 2018
Apr 27 2018
Mar 29 2018
Mar 22 2018
Once again, this time actually updating the diff...
As suggested by bz@, I've only removed the sysctls #ifdef BURN_BRIDGES.
Feb 7 2018
Jan 5 2018
In D13759#288265, @jilles wrote:It is already possible to disable swapping out kernel stacks via sysctl vm.swap_enabled (which has a wrong description) and configure it via sysctls vm.swap_idle_threshold1 and vm.swap_idle_threshold2. What is the problem you are trying to solve?
Note that a second effect of swapping out is that ps will not attempt to read arguments and environment from the memory of a "swapped out" process. This will make it more likely that the memory containing these will stay paged out.
If your problem is with paging in general, the "laundry" changes to the VM system in FreeBSD 12 may be useful for you. Basically, these changes allow the system to balance better between paging out things (known as "laundering"; usually to swap but could be to files or devices) and discarding cached data (usually from files).
Jan 4 2018
It is already possible to disable swapping out kernel stacks via sysctl vm.swap_enabled (which has a wrong description) and configure it via sysctls vm.swap_idle_threshold1 and vm.swap_idle_threshold2. What is the problem you are trying to solve?
In D13759#288136, @jilles wrote:For a long time, "swapping out" a process has only made its U area (later, only the kernel stack) pageable. This is a few pages per thread. Therefore, comparing vmspace_resident_count does not seem to make much sense.
For a long time, "swapping out" a process has only made its U area (later, only the kernel stack) pageable. This is a few pages per thread. Therefore, comparing vmspace_resident_count does not seem to make much sense.
Fixed indentation and typo on comment.
updated comment as requested.
indentation fixed
Added whole-process swapping limit