Fwd: proc_mem modification to allow use in timer probes

[Mark Wielaard]

On Mon, 2010-02-15 at 11:09 -0500, Frank Ch. Eigler wrote:
> Mark Wielaard <mjw@redhat.com> writes:
> 
> > [...] Attached is a patch that adds proc_mem function variants that take a
> > task (as returned by one of the task.stp tapset functions). [...]
> 
> (It's unfortunate to require even one embedded-c function for this.)

Yeah, I added support for comparing CONFIG_ settings in the preprocessor
which made two embedded-c functions unnecessary. Unfortunately still one
is necessary because it uses some .h preprocessor constants.

In general it would be nice to have some support for using .h
preprocessor constants in stap scripts. Maybe something like
@constant("SYMBOL", "header.h") that expands to a string or long
literal? And for handling the possible atomic (as in this script) and
rcu guarded (as in task.stp) data types in a less cumbersome way.

> > Although it seems /proc/<anypid>/statm is readable for anybody, so
> > maybe they could be marked unprivileged? I would be slightly
> > concerned that @cast/kread() could be fed an arbitrary address, that
> > happens to look like a task struct, but in reality isn't and so
> > would provide an information leak. [...]
> 
> When running in unprivileged mode, deref() (which @cast/kread
> ultimately uses) is constrained at run time to user-space addresses.

OK, that seems to take away all my concerns.

New tapset patch attached. If nobody complains I like to write
documentation for it and possibly add task_time.stp variants also.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_mem.patch
Type: text/x-patch
Size: 4541 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20100222/e8251877/attachment.bin>