Re: context.stp - read session ID - function sid()

[Malte Nuhn <nuhn@physik.rwth-aachen.de>]

Josh Stone wrote:
> On 05/08/2009 08:04 AM, Malte Nuhn wrote:
>   
>> There's basically no magic in it. I checked that the session information 
>> is stored in the "signal_struct" since Kernel version 2.6.0 - so i guess
>> it should work on every machine that is running systemtap.
>>     
>
> Unfortunately, that field is going away -- see this in the kernel:
>
>   commit 1b0f7ffd0ea27cd3a0b9ca04e3df9522048c32a3
>   Author: Oleg Nesterov <oleg@redhat.com>
>   Date:   Thu Apr 2 16:58:39 2009 -0700
>
>       pids: kill signal_struct-> __pgrp/__session and friends
>
>
> Frank already committed your patch, but can you research whether there's
> a way to let this continue to work on 2.6.30+?
>
> Thanks,
>
> Josh
>   
Oh - I'm sorry - I missed that. So here is, what I could find out:

Since commit 7af5729474b5b8ad385adadab78d6e723e7655a3, there is

static inline pid_t task_session_vnr(struct task_struct *tsk)

which i guess should do the job. There are some more wrappers for tgid, 
pgrp, and pid. Perhaps one should use them in the future.

I'm sorry, I don't have have a machine with some newer kernel running at 
the moment; that's why I actually couldn't test
if the above solution really works...

I read about process namespaces @ http://lwn.net/Articles/259217/
and I'm not quite sure, what one should do (even in general) with these. 
Being exact, a call like "pid()" or "sid()"
is not "valid" anymore, since you need to specify the pid namespace. The 
easiest thing to do is to always pull out the
virtual pid implicitly. But but then, the user should at least know that 
systemtap chose the virtual one.

What do you think about that?

Malte