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

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

[Malte Nuhn]

Hi there,

I coded some lines to read out the session ID of the current caller.
Eventhough this piece of information is always called "session" inside 
the kernel,
it seems that the function name "sid()" is a good idea.

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.

The following patch should be applied to current file in git, which was

git log
commit 07f8225311f85de5754bb594bf6ee945425dafcc
...

Malte

diff --git a/tapset/context.stp b/tapset/context.stp
index fcb6020..a5a839a 100644
--- a/tapset/context.stp
+++ b/tapset/context.stp
@@ -64,6 +64,18 @@ function ppid:long () %{ /* pure */
 %}

 /**
+* sfunction sid - Returns the session ID of the current process.
+*
+* The session ID of a process is the process group ID of the session 
leader.
+* Session ID is stored in the signal_struct since Kernel 2.6.0
+*/
+function sid:long () %{ /* pure */
+    struct signal_struct *ss = kread( &(current->signal) );
+    THIS->__retvalue = kread ( &(ss->session) );
+    CATCH_DEREF_FAULT();
+%}
+
+/**
  * sfunction pexecname - Returns the execname of a target process's 
parent process.
  */
 function pexecname:string () %{ /* pure */

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

[Josh Stone]

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

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

[Malte Nuhn]

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

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

[Josh Stone]

On 05/11/2009 05:21 AM, Malte Nuhn wrote:
> 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?

I think the best approach for SystemTap is to provide ids from the init
namespace (with the *_nr variants), so they will still be globally
unique.  We can provide the virtual ids in separate calls, perhaps
vpid(), vsid(), etc.

Josh