This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]