[DTrace-devel] [PATCH 3/7] dtrace: add default options and apply path options earlier

[Eugene Loh]

On 5/11/23 07:25, Nick Alcock wrote:

> On 9 May 2023, Eugene Loh via DTrace-devel stated:
>
>> I'm having problems getting my head around this patch (and therefore subsequent patches).  Maybe I'll try a few questions:
>>
>> 1)  What does procfspath have to do with this patch?  Was procfspath broken?  If so, is there now a test to show that it's fixed?
> The procfspath is used by (existing) code in dt_vopen():

I'm mildly curious about this point.  It seems to me that procfs_path[] 
is not used until dt_vopen() is over.

> thus changes to
> the procfspath do not take effect for that use (but do for later uses).
> So in effect it was broken, yes: if you mounted /proc somewhere else you
> would find you couldn't tell dtrace where it was soon enough to affect
> the dt_vopen() call.
>
> No test because there is more breakage: the BPF rewrite introduced many,
> many places that just hardwire /proc as /proc rather than using the
> option. They all need fixing before we can observe less breakage :)

Okay.  So maybe the hardwiring is the point.  E.g., dt_vopen() uses 
"/proc/sys/kernel/perf_event_max_stack".

> (This was just a note, really -- there is *other* observable breakage
> now, the CTF stuff.)