diff --git a/website/content/en/status/report-2025-07-2025-09/drm-drivers-slowdowns_fixes.adoc b/website/content/en/status/report-2025-07-2025-09/drm-drivers-slowdowns_fixes.adoc index 42bc045d9e..5358c1de53 100644 --- a/website/content/en/status/report-2025-07-2025-09/drm-drivers-slowdowns_fixes.adoc +++ b/website/content/en/status/report-2025-07-2025-09/drm-drivers-slowdowns_fixes.adoc @@ -1,40 +1,40 @@ === DRM Drivers Slowdowns and Freezes Fixes Links: + link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277476[Main PR] URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277476 + link:https://github.com/freebsd/drm-kmod/issues/302[drm-kmod GitHub issue] URL: https://github.com/freebsd/drm-kmod/issues/302 Contact: Olivier Certner Owners of AMD GPUs using the amdgpu DRM driver from the `drm-kmod` ports, especially starting with v5.15 (`drm-515-kmod`), have been experiencing gradual slowdowns and freezes since at least May 2024. Code analysis suggests that recent Intel-based GPUs (gen 13+) may also be affected. We are pleased to announce that, to the best of our knowledge, all these problems have been fixed. We encourage people to test the latest FreeBSD code on branches `main`, `stable/15` or `stable/14`. The fixes will be included in the upcoming 15.0 and 14.4 releases. Errata notices and patches may be issued for 14.3 in order for people not to have to wait until 14.4 (whose release should tentatively happen next March). An additional fix will find its way in the `drm-kmod` ports (see below). Investigations revealed that the crux of all these problems has been bad handling of too frequent, and generally not really necessary, physically contiguous memory allocation requests in fast paths. Basically, the DRM's TTM component tries to allocate pools of graphics memory pages that are as much as possible physically contiguous in order to reduce the number of corresponding TLB entries. It does it in a loop that first tries to allocate pages of higher order with the `__GFP_NORETRY` flag, gradually falling back to smallest ones (see `ttm_pool_alloc()`). The first problem is that our LinuxKPI did not handle Linux's `__GFP_NORETRY` flag and would try hard to fulfill the first requests, i.e., those with highest order pages, using expensive mechanisms to obtain or produce contiguous memory if not readily available. A first fix by Mathieu (`sigsys` at `gmail` with regular company suffix) removed memory compaction from this process (foregoing calls to `vm_page_reclaim_contig()`). This fix was then completed by stopping the VM system from trying to break memory reservations, which are pieces of a speculative mechanism that tries to automatically provoke the use of superpages. Another problem came from evolutions of our LinuxKPI. In order to better comply with what Linux does, `kmalloc()` was changed to always return physically contiguous memory. Unfortunately, `kvzalloc()`, which relied on `kmalloc()` in our implementation (which was conceptually wrong, but initially harmless in practice), was not switched to rely on `kvmalloc()` in the process, effectively turning large memory allocations of zeroed pages into costly physically contiguous ones. Some rough profiling of slowdowns was done using `dtrace`. It revealed that a fair amount of execution time of the failing allocations came from attempting multiple allocation on the same NUMA domain, and that of succeeding ones came from useless changes to page attributes, triggering expensive TLB shootdowns. -An analysis of the VM domainset iterators code revealed multiple flaws, in particular leading to re-examining the same domain multiple times (up to 4 times for the common case of machines with a single domain) without any additional guarantees of success for new attemps. +An analysis of the VM domainset iterators code revealed multiple flaws, in particular leading to re-examining the same domain multiple times (up to 4 times for the common case of machines with a single domain) without any additional guarantees of success for new attempts. Some other VM domainset problems have been fixed in the process, such as ensuring that allocation requests prefer domains not on a low memory condition in all situations. Finally, concerning specifically the amdgpu driver and affecting only Carrizo, Polaris and Vega M based AMD GPUs, a temporary allocation that was unnecessarily physically contiguous was replaced with a regular one, making the remaining, relatively short but noticeable freezes disappear. By contrast with those evoked above, this change is to the `drm-kmod` ports' code, and is to be included at the ports' next version bump in the ports tree (expected ports versions: `5.10.163_9`, `5.15.160_6`, `6.1.128_6` and `6.6.25_7` respectively for `drm-510-kmod`, `drm-515-kmod`, `drm-61-kmod` and `drm-66-kmod`). This work was sponsored by the FreeBSD Foundation as part of the Laptop Project. Sponsor: The FreeBSD Foundation diff --git a/website/content/en/status/report-2025-07-2025-09/group-changes.adoc b/website/content/en/status/report-2025-07-2025-09/group-changes.adoc index 2eba794c5e..8d41d0edbe 100644 --- a/website/content/en/status/report-2025-07-2025-09/group-changes.adoc +++ b/website/content/en/status/report-2025-07-2025-09/group-changes.adoc @@ -1,44 +1,44 @@ === Process Credentials' Groups-Related Changes in FreeBSD 15 Links: + link:https://www.freebsd.org/status/report-2025-04-2025-06/#_ucred_group_changes_in_freebsd_15_0[T2 2025 Status Report] URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_ucred_group_changes_in_freebsd_15_0 + link:https://cgit.freebsd.org/src/commit/?id=9dc1ac869196[initgroups(3): Backwards-compatible implementation and manual page update ] URL: https://cgit.freebsd.org/src/commit/?id=9dc1ac869196 + link:https://cgit.freebsd.org/src/commit/?id=4be38acc826f[Main commit changing getgroups(2)'s manual page] URL: https://cgit.freebsd.org/src/commit/?id=4be38acc826f + link:https://cgit.freebsd.org/src/commit/?id=6d22cd6b5f8b[Main commit changing setgroups(2)'s manual page] URL: https://cgit.freebsd.org/src/commit/?id=6d22cd6b5f8b Contact: Olivier Certner + Contact: Kyle Evans Starting with FreeBSD 15: . [[setgroups_getgroups]]The behavior of the man:setgroups[2] and man:getgroups[2] system calls function has slightly changed. + Out of caution, even if almost all existing applications will continue to work undisturbed, we advise auditing those that you are maintaining or using as explained below. . [[initgroups]]How processes' group membership is derived from the password and group databases on login has slightly changed: The login user's initial numerical group ID from the password database is now automatically added to the supplementary groups set, even if that user is not explicitly listed as a member of the corresponding group in the group database. . [[kernel]]The kernel stores the effective group ID in a new specific field of `struct ucred` (`cr_gid`) instead of in the same array as supplementary groups (`cr_ngroups[]`). The man:setgroups[2] and man:getgroups[2] system calls will operate only on the calling process' supplementary groups, not featuring the effective group ID as the first element of their array argument. The man:initgroups[3] function's implementation is unchanged and still relies on man:setgroups[2], with the consequence that it **does not** set the process' effective group ID **anymore**, instead including its `basegid` argument in the supplementary groups set. One of the reasons for these changes is to have FreeBSD behave exactly like GNU/Linux systems, NetBSD, OpenBSD and illumos-based operating systems. Consequently, almost all portable applications should already be compliant with FreeBSD's new behavior and will continue to work correctly or even get fixed in the process (see the previous status report linked above for an example with OpenSSH). However, porters, system administrators and users are advised to audit their applications that are using man:setgroups[2], man:getgroups[2] and man:initgroups[3], watching out for the following points: * Applications should already be using man:setgid[2] or man:setegid[2] in addition to man:setgroups[2] or man:initgroups[3] to set the effective group ID. + If this is not the case, these calls must be added, as otherwise affected applications will stop setting the effective group ID starting from FreeBSD 15. * Applications using man:getgroups[2] should not be treating the first element of the returned array specially, but as any other supplementary group. + If nonetheless they do, they have to be modified to obtain the effective group ID via man:getegid[2] instead and to treat all groups returned by man:getgroups[2] as supplementary groups only. Manual pages of all changed functions have been modified in `stable/14` and `stable/15` to describe and contrast the old and new behaviors, and have grown new `SECURITY CONSIDERATIONS` sections stating the reasons for the changes and the points to watch out for. Backwards-compatible implementations of changed functions are provided so that applications compiled on FreeBSD 14 or earlier continue to see the old behaviors and work as before. They are available if and only if the kernel was compiled with `COMPAT_FREEBSD14`, which is the case of the default `GENERIC` kernel. We have normally fixed all unwanted impacts of storing the effective group ID separately from the supplementary groups in the kernel, such as: -* Some security policies or access checks would either ignore the effective group ID or the first supplementary group (with lowest numerical ID), affecting process visibility restrictions based on group IDs, the "can debug" and "can export KTLS keys" checks, the man:mac_do[4] and man:mac_bsdextended[4] security policies, and access crontrol to some hardware facilities (tracing: man:hwt[4]; performance monitoring: man:hwpmc[4]) and to NFS-served shares. +* Some security policies or access checks would either ignore the effective group ID or the first supplementary group (with lowest numerical ID), affecting process visibility restrictions based on group IDs, the "can debug" and "can export KTLS keys" checks, the man:mac_do[4] and man:mac_bsdextended[4] security policies, and access control to some hardware facilities (tracing: man:hwt[4]; performance monitoring: man:hwpmc[4]) and to NFS-served shares. * Reporting of process' credentials would omit the effective group ID, affecting all variants of `procstat -s` (on live processes, core files, or system core dump), man:ddb[4]. Sponsor: The FreeBSD Foundation diff --git a/website/content/en/status/report-2025-07-2025-09/valgrind.adoc b/website/content/en/status/report-2025-07-2025-09/valgrind.adoc index ea8fb619fc..9a8a2e1193 100644 --- a/website/content/en/status/report-2025-07-2025-09/valgrind.adoc +++ b/website/content/en/status/report-2025-07-2025-09/valgrind.adoc @@ -1,53 +1,53 @@ === Valgrind: preparing for 15.0-RELEASE Links: + link:https://www.valgrind.org/[Valgrind Home Page] URL: link:https://www.valgrind.org/[] + link:https://www.valgrind.org/docs/manual/dist.news.html[Valgrind News] URL: link:https://www.valgrind.org/docs/manual/dist.news.html[] + link:https://github.com/paulfloyd/freebsdarm64_valgrind[arm64 port] URL: link:https://github.com/paulfloyd/freebsdarm64_valgrind[] Contact: Paul Floyd I have not submitted any reports for over a year. On the whole that is good news as it means that there have not been any major issues. Back then I said that aarch64 support was about to land and indeed it did in mid April 2024. I added a nice little script for use with Valgrind called `vgscript`. This works in a similar manner to `pstack` (or `bstack` on FreeBSD) in that you give it a PID and it will generate a stack trace for that process. If you use `bstack` with a Valgrind process you will see the Valgrind call stack which is probably of no use to you. If you run `vgstack` with a Valgrind PID it will print the call stack of the test exe running under Valgrind. If you use Valgrind regularly could you take a look and answer the survey that I posted on the forums (if you have not done so already). Here is the link:https://forums.freebsd.org/threads/valgrind-feature-poll.98707/#post-716085[link]. Valgrind 3.26 is due out at the end of October 2025 and package:devel/valgrind[] will be updated shortly after that. package:devel/valgrind-devel[] will get one (or maybe more) updates as I fix issues with FreeBSD 15.0. The outstanding issues that I have on FreeBSD 15.0 are * aarch64: there is a problem when using Valgrind with gdb/vgdb. Hitting ctrl-c to interrupt the process running under Valgrind does not work and Valgrind crashes with an assert. * aarch64: a known old issue that was infrequent regarding initialisation of thread memory now seems to occur much more often. * amd64: maybe similar to the first issue with gdb/vgdb and interrupting a process, but this time I'm seeing `select` return an 'impossible' value. * amd64: a test for `setcred` is getting an extra "Conditional jump" error message. Most of the above are not too serious unless you are a heavy user of gdb/vgdb. Here is a list of bugfixes since my last report, Q1 2024. * Several suppressions added for libc, libc++ and libstdc++ functions * Improvements to `setcontest` argument checking * Some more `aio_*` fixes * Syscall `_sysctlname` was checking the wrong length of the name argument -* New syscall wrappers for `kcmp`, `getrlimitusage`, `close_range`, `fchroot`, `setcred`, `exterrctl`, `inotify_add_watch_at`, `inotify_rm_awtch`, `jail_attach_jd` and `jail_remove_jd` +* New syscall wrappers for `kcmp`, `getrlimitusage`, `close_range`, `fchroot`, `setcred`, `exterrctl`, `inotify_add_watch_at`, `inotify_rm_watch`, `jail_attach_jd` and `jail_remove_jd` * Started adding better `ioctl` argument checking * Fixes to Valgrinds self-checking modes * Support aarch64 auxv AT_HWCAP, AT_CHERI_STATS, AT_HWCAP3 and AT_HWCAP4 * Valgrind file descriptor checking has been significantly enhanced and this includes FreeBSD * Some old code that I could never test for FreeBSD 10 has been removed * Removed as much as possible FreeBSD version dependent code. This reduces everyday maintenance at the cost of making version-independent regression tests more difficult * Turn off check for lock created during text handling that will deliberately leak * Syscall `sigwait` was not correctly dealing with its atypical return value * Improved checking of `utrace` syscall arguments * amd64: syscall arguments 7 and 8 were swapped (it turns out that argument 8 is never needed and has been removed) * amd64: added `sysarch` subcommands `AMD64_SET_TLSBASE` and `AMD_GET_TLSBASE` * Reduced warnings that get printed in quiet (-q) mode * Improved checking done by `sysctl` kern.proc.pathname * Handle `mmap` MAP_STACK and MAP_GUARD * Syscalls `open*` now produce an error if you try to open the guest exe for writing * Syscalls `sigwait` and `sigwaitingfo` were too lax in accepting NULL arguments * Many of the `*at` system calls (like `faccessat`) were not checking that the directory fd is not one of the file descriptors reserved for Valgrind's use * Function `memalign` now accepts a size of zero