Bug 203941 - arm64 IMPLEMENT ME: dtrace_toxic_ranges
Summary: arm64 IMPLEMENT ME: dtrace_toxic_ranges
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Some People
Assignee: Andrew Turner
Depends on:
Blocks: 203349
  Show dependency treegraph
Reported: 2015-10-21 18:51 UTC by Ed Maste
Modified: 2016-05-26 16:19 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2015-10-21 18:51:46 UTC
On arm64,

root@:~ # kldload dtraceall
IMPLEMENT ME: dtrace_toxic_ranges

Looking at sys/cddl/dev/dtrace/*/dtrace_subr.c I see only i386 setting a toxic range:

        (*func)(0, kernelbase);

All others are either the no-op

        * No toxic regions?


        printf("IMPLEMENT ME: dtrace_toxic_ranges\n");
Comment 1 Ed Maste freebsd_committer 2015-10-21 18:54:38 UTC
And for quick reference:

 * DTrace Toxic Ranges
 * DTrace supports safe loads from probe context; if the address turns out to  
 * be invalid, a bit will be set by the kernel indicating that DTrace
 * encountered a memory error, and DTrace will propagate the error to the user 
 * accordingly.  However, there may exist some regions of memory in which an   
 * arbitrary load can change system state, and from which it is impossible to  
 * recover from such a load after it has been attempted.  Examples of this may 
 * include memory in which programmable I/O registers are mapped (for which a  
 * read may have some implications for the device) or (in the specific case of 
 * UltraSPARC-I and -II) the virtual address hole.  The platform is required   
 * to make DTrace aware of these toxic ranges; DTrace will then check that     
 * target addresses are not in a toxic range before attempting to issue a      
 * safe load.
Comment 2 Andrew Turner freebsd_committer 2016-05-26 16:19:00 UTC
Fixed in https://svnweb.freebsd.org/changeset/base/300611