dtrace: Fix a kernel panic in printm().

[domagoj.stolfa_gmail.com]

Summary

When using printm(), one should always pass a scratch pointer to it.
This is achieved by calling printm with memref

  BEGIN { printm(fixed_len, memref(ptr, var_len)); }

which will return a pointer to the DTrace scratch space of size
sizeof(uintptr_t) * 2. However, one can easily call printm() as follows

  BEGIN { printm(10, (void *)NULL); }

and panic the kernel as a result. This commit does two things:

  (1) adds a new macro DTRACE_INSCRATCHPTR(mstate, ptr, howmany) which
      checks if a certain pointer is in the DTrace scratch space;
  (2) uses DTRACE_INSCRATCHPTR() to implement a check on printm()'s DIFO
      return value in order to avoid the panic and sets CPU_DTRACE_BADADDR
      if the address is not in the scratch space.

Test Plan

Run

# dtrace -n 'BEGIN { printm(10, (void *)NULL); }'

with and without the patch.

Expected output with the patch:

dtrace: description 'BEGIN ' matched 1 probe
dtrace: error on enabled probe ID 1 (ID 1: dtrace:::BEGIN): invalid address (0x0) in action #1

[markj]

sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c

521

Isn't this testing whether the pointer points outside of the scratch space? That is, this looks inverted.

7759

From the comment, I'd expect this to read if (!DTRACE_INSCRATCHPTR(....

[domagoj.stolfa_gmail.com]

That's true, it's late :). Updated the diff. Thanks!