Re: dtracing unlink

[Chuck Silvers <chuq%chuq.com@localhost>]

On Tue, Oct 31, 2023 at 10:17:25PM -0700, bch wrote:
> > I think we can just use SMAP_DISABLE/SMAP_ENABLE like in the standard
> > copyinstr() in sys/arch/amd64/amd64/copy.S.
> 
> 
> Yeah - I saw that, saw the registered function, the release notes…
> 
> I followed the hint in the notes, and the aesthetic on the page. The call
> does the same thing as the macros, but via a call/return. Literally the
> same thing - so the proper hotpatching is still applied. It saves seeing
> the SHOUTING_MACRO and the #include to get the macro in scope, but
> otherwise, ~same thing as I see it, and I’m not otherwise invested. Notable
> - this case and a single Xen spot are the only use of
> smap_disable()/smap_enable() - if we’re just going the macro route, should
> the function just be deleted?

it would be better if dtrace could use the SMAP_DISABLE/SMAP_ENABLE hotpatch
macros like the base kernel copy.S does, but hotpatching does not currently
work for kernel modules, only for the base kernel.  so at the moment
it's expedient to just call a hotpatched function in the base kernel like
you proposed.

further, any function that is called in dtrace probe context should have a
name starting with "dtrace_" so that the fbt provider will avoid creating
fbt probes for those functions.

I committed a patch like the above and verified that the dtrace script
from wiz works now.

-Chuck