This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Proposed task.stp additions
Mike Mason wrote:
> Given that systemtap would be the only user, I doubt we could get a
> lockless cwd query into the kernel. Don't we already have some
> lockless versions of kernel functions in the runtime?
Sort of -- you might be thinking of _stp_gettimeofday_ns(). That
function tries to emulate gettimeofday_ns() without requiring the
xtime_lock. It doesn't access any of the data that is normally
protected by xtime_lock. It's not a completely lockless implementation,
but it's guaranteed not to deadlock. It just returns zero if it can't
get it's lock after a few attempts.
Maybe your safe version of d_path() could use spin_trylock(), and return
an empty string if it's unable to acquire the right locks. But you also
have to make sure that all the symbols you need are exported, and
__d_path() isn't exported on mainline kernels.
> Just so I'm clear, probe handlers should not block in any way,
> correct? I know we've discussed that before, but I guess I just
> don't want to believe it :-) It sure limits what we can extract with
> systemtap.
Correct, and yes that limitation is painful. There's been some
brainstorming about delayed handlers that could block, but I don't know
if anyone has prototyped this yet.
>>>> BUT, as long as *everything* you do with the result of pid2task()
>>>> is protected by kread(), this is probably OK. In the rare case
>>>> that the task disappears, you may get corrupt data or an error
>>>> from an invalid dereference, but this won't impact system
>>>> stability.
>>>
>>> That's true of all the task_* functions, isn't it? If we cache
>>> task_struct pointers and pass them to the task_* functions, there's
>>> never a guarantee you'll get what you expect.
>>
>> True, but in this case you may get bad results even if you use it
>> right away.
>
> I still don't see the difference. It doesn't matter how you
> obtained the task pointer. Once you pass it to one of the task_*
> functions, it's alway possible the task no longer exists unless it's
> the current task. What am I missing?
For a probe like scheduler.cpu_on, you have both $next and $prev, and
both will stick around for the duration of the probe. But you're right
-- in general, you can't rely on a task pointer staying valid throughout
the probe.
Josh