This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Access of global variables in the script
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Arkady <arkady dot miasnikov at gmail dot com>
- Cc: systemtap at sourceware dot org
- Date: Fri, 23 Jun 2017 13:43:18 -0400
- Subject: Re: Access of global variables in the script
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fche at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 86ED5142860
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 86ED5142860
- References: <CANA-60oAE2cSZR_kekWz=xqm=kPDbKk4i+54_1wjH3E6jwgowA@mail.gmail.com>
Hi -
> [...]
> I checked the function fullpath_struct_file in the dentry.stp. Can I
> code a better (faster) implementation than task_dentry_path() with
> inline C?
>
> A side note - task_dentry_path does not lock when traversing the
> dentry->parent... tree. Is it safe?
These two issues are related, and represent a deliberate design choice.
When one uses embedded-C code in stap, one has to shoulder the entire
burden of ensuring its safety & correctness. A pointer use bug there
can bring the machine down. Blocking for a lock can bring the machine
down.
In contrast, the same algorithm expressed within the script language
will use protected pointer dereferencing, time/space-limited
computation, and no blocking. In the worst case, the script will stop,
or produce wrong results. That is much better than the alternative.
> [...]
> semantic error: unable to find global 'rename_lock' in kernel, in
> fs/dcache.c: operator '@var' at <input>:1:36
> [...]
(Not sure about this part.)
- FChE