FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-02-17T20:22:05Z 2026-02-17T20:22:05Z Mark Johnston markj@FreeBSD.org 2026-02-17T17:37:42Z urn:sha1:afd64316c869eb00dde4d6b4af61bca0cb2197f1 MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D52475 2026-01-13T17:07:37Z Mark Johnston markj@FreeBSD.org 2026-01-13T15:35:05Z urn:sha1:66eedcb0224df03e56513f3caf1df93a52b6a919 This is supposed to be a dtrace_id_t, which is a uint32_t, while id_t is a uint64_t. sdt.h avoids depending on dtrace.h so we can't use dtrace_id_t directly. Bump __FreeBSD_version since the layout of structures in the SDT probe linker set has changed. Sponsored by: NetApp, Inc. Sponsored by: Klara, Inc. 2025-11-17T16:11:56Z Martin Matuska mm@FreeBSD.org 2025-11-16T11:15:14Z urn:sha1:4303bde4297a3d19cabdb08ce1550f682578d2ba Fix Makefiles Update zfs_config.h and zfs_gitrev.h 2025-10-29T17:52:42Z Konrad Witaszczyk def@FreeBSD.org 2025-10-28T16:09:24Z urn:sha1:2acdec9e4d915ec61d0ca45b408f9beb7aa4b772 LINKER_EACH_FUNCTION_NAMEVAL() stops processing the symbol table if a callback function returns a non-zero value. The fbt_provide_module_function() callback should not return 1 when ignoring symbols. Instead, always return 0, as in dtrace/x86. Fixes: 30b68ecda84e ("Changes that improve DTrace FBT reliability on freebsd/arm64:") Reviewed by: markj, oshogbo Approved by: oshogbo (mentor) Obtained from: CheriBSD Differential Revision: https://reviews.freebsd.org/D53399 2025-09-18T22:09:49Z Mark Johnston markj@FreeBSD.org 2025-09-17T15:29:48Z urn:sha1:bf115203bb8a61bd03ba23931ff0b5bf931b7d1b dtrace_xcall() is just a thin wrapper around smp_rendezvous_cpus(). There's no need for six identical implementations to live in MD layers. No functional change intended. MFC after: 2 weeks 2025-07-28T20:32:39Z Mark Johnston markj@FreeBSD.org 2025-07-28T19:30:37Z urn:sha1:9a6ba186e0ca4269021d8843dbc8409ea78da4a6 Suppose a kernel module A defines an SDT provider and probes, and kernel linker file B, dependant on A, contains tracepoints for those probes. When sdt.ko is loaded, it iterates over all loaded KLDs to initialize probe structures and register them with dtrace. In particular it uses linker_file_foreach(), which is not sorted; in the above scenario, B may be visited before A. Thus, it's possible for sdt_kld_load_probes() to try to add tracepoints to an uninitialized SDT probe. An example of the above arises when pfsync, pf, and sdt are loaded in that exact order after commit 4bb3b36577645. Fix this by initializing probe structures in the first pass over loaded KLDs. Then, the second pass can safely add tracepoints to any probe structure. Note that the scenario where B and A are loaded after sdt.ko is already handled properly, as there, the kld_load eventhandler is responsible for registering probes with dtrace, and that eventhandler fires for dependencies before it does for the dependent KLD. This presumes, however, that there are no cycles in the dependency graph. Reported by: jenkins MFC after: 2 weeks 2025-06-11T16:39:02Z Brooks Davis brooks@FreeBSD.org 2025-06-11T16:39:02Z urn:sha1:e453e498cbb88570a3ff7b3679de65c88707da95 Switch to using sys/stdarg.h for va_list type and va_* builtins. Make an attempt to insert the include in a sensible place. Where style(9) was followed this is easy, where it was ignored, aim for the first block of sys/*.h headers and don't get too fussy or try to fix other style bugs. Reviewed by: imp Exp-run by: antoine (PR 286274) Pull Request: https://github.com/freebsd/freebsd-src/pull/1595 2025-06-04T21:13:08Z Mark Johnston markj@FreeBSD.org 2025-06-04T21:13:08Z urn:sha1:98ef590f77392159938d2e6f9fd45bf31d10b9c1 It's unused, and the naked strcpy() was susceptible to buffer overflow if one creates, say, a probe called "profile-2000000000ns". Reported by: CHERI MFC after: 1 week Sponsored by: Innovate UK 2025-03-10T03:01:13Z Mark Johnston markj@FreeBSD.org 2025-03-10T03:01:13Z urn:sha1:36ae5ce2f2fda35763c2655a19bf1b0ee22fdf3c This routine returns a monotonic count of the number of nanoseconds elapsed since the previous call. On arm64 it uses the generic system timer. The implementation multiplies the counter value by 10**9 then divides by the counter frequency, but this multiplication can overflow. This can result in trace records with non-monotonic timestamps, which breaks libdtrace's temporal ordering algorithm. An easy fix is to reverse the order of operations, since the counter frequency will in general be smaller than 10**9. (In fact, it's mandated to be 1Ghz in ARMv9, which makes life simple.) However, this can give a fair bit of error. Adopt the calculation used on amd64, with tweaks to handle frequencies as low as 1MHz: the ARM generic timer documentation suggests that ARMv8 timers are typically in the 1MHz-50MHz range, which is true on arm64 systems that I have access to. MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D49244 2025-01-29T03:12:46Z Mark Johnston markj@FreeBSD.org 2025-01-29T03:11:48Z urn:sha1:94fb5ab9043cbe6188cf30f51f7e85739ba41503 The change is clearly wrong as it removes a dereference of the pointer into the stack. Just revert for now. This reverts commit 70c067062217a5295ed321427b91cfd857c18b77. Reported by: jrtc27