Bug 23512 - regression in --privilege=stapusr operation
Summary: regression in --privilege=stapusr operation
Status: NEW
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-10 23:40 UTC by Frank Ch. Eigler
Modified: 2021-11-10 09:00 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2018-08-10 23:40:51 UTC
My commits for PR23160,PR14690 have caused a regression in the way privilege-testing of elaboration of embedded-c tapset functions is handled.  New code changes the timing at which the /* unprivileged */ type pragmas are processed.  Now they can fail for functions like kernel_string() even though they are not called, even transitively, from the end-user script.  This breaks e.g. the unprivileged-myproc test cases.

It turns out we run symbol elaboration in an overly inclusive manner.  Any function defined in a tapset file chosen for inclusion is fully processed, even though it may not be transitively called at all.  This represents perhaps considerable wasted translation effort, esp. considering expensive constructs like @cast().  We should not spend any serious efforts processing parts of tapsets that are not reachable from the end-user script.  This suggests the resolve_syms pass must be iterative/relaxation-based, like the optimization passes later on.
Comment 1 agentzh 2018-08-11 18:49:08 UTC
+1 for the change "resolve_syms pass must be iterative/relaxation-based". I also need it badly for passing stat/array references around via explicit assignments (`=`).