Attach my own pid

Attach my own pid

[Nitin Varyani]

Hi,
     The linux kernel attaches a pid to newly forked process. I want to
create a facility by which a process has the option of attaching a new pid
to its child which is not in the pid space.
      Any suggestions of how this can be achieved?
Nitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160320/bcee2b7d/attachment.html 

Attach my own pid

[Valdis.Kletnieks at vt.edu]

On Sun, 20 Mar 2016 02:07:29 -0700, Nitin Varyani said:

>      The linux kernel attaches a pid to newly forked process. I want to
> create a facility by which a process has the option of attaching a new pid
> to its child which is not in the pid space.

Not at all sure what you mean by "not in the pid space", or what you're
trying to achieve by doing it.

But "pid namespaces" may be what you're looking for.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160320/9be9132a/attachment.bin 

Attach my own pid

[Nitin Varyani]

I am reframing my question:
Sub-task 1: Until now, parent process cannot control the pid of the forked
child. A pid gets assigned as a sequential number by the kernel at the time
the process is forked . I want to modify kernel in such a way that parent
process can control the pid of the forked child.

Sub-task 2: On Linux, you can find the maximum PID value for your system
with the following command:

$ cat /proc/sys/kernel/pid_max

Suppose pid_max=2000 for a system. I want that the parent process should be
able to assign a pid which is greater that 2000 to the forked child.

On Mon, Mar 21, 2016 at 12:03 AM, <Valdis.Kletnieks@vt.edu> wrote:

> On Sun, 20 Mar 2016 02:07:29 -0700, Nitin Varyani said:
>
> >      The linux kernel attaches a pid to newly forked process. I want to
> > create a facility by which a process has the option of attaching a new
> pid
> > to its child which is not in the pid space.
>
> Not at all sure what you mean by "not in the pid space", or what you're
> trying to achieve by doing it.
>
> But "pid namespaces" may be what you're looking for.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/ae747cac/attachment.html 

Attach my own pid

[Valdis.Kletnieks at vt.edu]

On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:

> Sub-task 1: Until now, parent process cannot control the pid of the forked
> child. A pid gets assigned as a sequential number by the kernel at the time
> the process is forked . I want to modify kernel in such a way that parent
> process can control the pid of the forked child.

What does controlling the pid gain you?  To what purpose?

> Sub-task 2: On Linux, you can find the maximum PID value for your system
> with the following command:
>
> $ cat /proc/sys/kernel/pid_max
>
> Suppose pid_max=2000 for a system. I want that the parent process should be
> able to assign a pid which is greater that 2000 to the forked child.

Again, why would you want to do that?

Anyhow...

echo 3000 > /proc/sys/kernel/pid_max
fork a process that gets a pid over 2000.

Done.

Note that on 32 bit systems, using a pid_max of over 32768 will cause
various things in /proc to blow up.

I suspect that you need to think harder about what problem you're actually
trying to solve here - what will you do with a controlled child PID? Why does
it even matter?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/f5b6fdbd/attachment-0001.bin 

Attach my own pid

[Nitin Varyani]

I am trying to create a distributed pid space.

0 to 2000 Computer 1
2001 to 4000 Computer 2
4001 to 6000 Computer 3

and so on...

I am running a master user-level process at Computer 1 which sends a
process context like code, data, registers, PC, etc as well as *"pid"* to
slave processes running at other computers. The responsibility of the slave
process is to fork a new process on order of master process and attach *"pid"
*given by the master to the new process it has forked. Any system call on
slave nodes will have an initial check of " Whether the process belongs to
local node or to the master node?". That is, if kernel at Computer 2 pid of
the process is 1500



On Mon, Mar 21, 2016 at 12:23 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:
>
> > Sub-task 1: Until now, parent process cannot control the pid of the
> forked
> > child. A pid gets assigned as a sequential number by the kernel at the
> time
> > the process is forked . I want to modify kernel in such a way that parent
> > process can control the pid of the forked child.
>
> What does controlling the pid gain you?  To what purpose?
>
> > Sub-task 2: On Linux, you can find the maximum PID value for your system
> > with the following command:
> >
> > $ cat /proc/sys/kernel/pid_max
> >
> > Suppose pid_max=2000 for a system. I want that the parent process should
> be
> > able to assign a pid which is greater that 2000 to the forked child.
>
> Again, why would you want to do that?
>
> Anyhow...
>
> echo 3000 > /proc/sys/kernel/pid_max
> fork a process that gets a pid over 2000.
>
> Done.
>
> Note that on 32 bit systems, using a pid_max of over 32768 will cause
> various things in /proc to blow up.
>
> I suspect that you need to think harder about what problem you're actually
> trying to solve here - what will you do with a controlled child PID? Why
> does
> it even matter?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/f5b9d9b9/attachment-0001.html 

Attach my own pid

[Nitin Varyani]

.....Continued.... That is, if kernel at Computer 2 finds that pid of a
process requesting a system call is 1500, the request is forwarded to slave
daemon which in turn contacts with the master daemon. Master daemon
requests the kernel for the system call and sends the result back to slave
daemon.

On Mon, Mar 21, 2016 at 4:01 PM, Nitin Varyani <varyani.nitin1@gmail.com>
wrote:

> I am trying to create a distributed pid space.
>
> 0 to 2000 Computer 1
> 2001 to 4000 Computer 2
> 4001 to 6000 Computer 3
>
> and so on...
>
> I am running a master user-level process at Computer 1 which sends a
> process context like code, data, registers, PC, etc as well as *"pid"* to
> slave processes running at other computers. The responsibility of the slave
> process is to fork a new process on order of master process and attach *"pid"
> *given by the master to the new process it has forked. Any system call on
> slave nodes will have an initial check of " Whether the process belongs to
> local node or to the master node?". That is, if kernel at Computer 2 pid of
> the process is 1500
>
>
>
> On Mon, Mar 21, 2016 at 12:23 PM, <Valdis.Kletnieks@vt.edu> wrote:
>
>> On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:
>>
>> > Sub-task 1: Until now, parent process cannot control the pid of the
>> forked
>> > child. A pid gets assigned as a sequential number by the kernel at the
>> time
>> > the process is forked . I want to modify kernel in such a way that
>> parent
>> > process can control the pid of the forked child.
>>
>> What does controlling the pid gain you?  To what purpose?
>>
>> > Sub-task 2: On Linux, you can find the maximum PID value for your system
>> > with the following command:
>> >
>> > $ cat /proc/sys/kernel/pid_max
>> >
>> > Suppose pid_max=2000 for a system. I want that the parent process
>> should be
>> > able to assign a pid which is greater that 2000 to the forked child.
>>
>> Again, why would you want to do that?
>>
>> Anyhow...
>>
>> echo 3000 > /proc/sys/kernel/pid_max
>> fork a process that gets a pid over 2000.
>>
>> Done.
>>
>> Note that on 32 bit systems, using a pid_max of over 32768 will cause
>> various things in /proc to blow up.
>>
>> I suspect that you need to think harder about what problem you're actually
>> trying to solve here - what will you do with a controlled child PID? Why
>> does
>> it even matter?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/3ab3b93b/attachment.html 

Attach my own pid

[Nitin Varyani]

A representative process, that is, a process without any user stack,
register values, PC, etc, with *"pid" *is maintained at the master node.
Now, the process which was migrated to a remote node, in this example
Computer 2, and having process id *"pid", *decides to fork(). It is a
system call and is forwarded in the same way to master process. This
request is forwarded to the representative process with process id *"pid"*.
The representative process forks() leading to a new representative process
with process id *"cpid". *This "cpid" is forwarded to master process which
forwards it to slave process. The slave process forwards *"cpid"* to the
remote process with process id *"pid"*. The remote process with process id
*"pid"* now forks a child and attaches *"cpid" * to its child.

This is overview of what I want to achieve. A small correction in my last
mail.

.....Continued.... That is, if kernel at Computer 2 finds that pid of a
process requesting a system call is 1500, the request is forwarded to slave
daemon which in turn contacts with the master daemon. Master daemon
forwards this information to corresponding representative process which
requests the kernel for the system call and sends the result back to slave
daemon.

On Mon, Mar 21, 2016 at 4:03 PM, Nitin Varyani <varyani.nitin1@gmail.com>
wrote:

> .....Continued.... That is, if kernel at Computer 2 finds that pid of a
> process requesting a system call is 1500, the request is forwarded to slave
> daemon which in turn contacts with the master daemon. Master daemon
> requests the kernel for the system call and sends the result back to slave
> daemon.
>
> On Mon, Mar 21, 2016 at 4:01 PM, Nitin Varyani <varyani.nitin1@gmail.com>
> wrote:
>
>> I am trying to create a distributed pid space.
>>
>> 0 to 2000 Computer 1
>> 2001 to 4000 Computer 2
>> 4001 to 6000 Computer 3
>>
>> and so on...
>>
>> I am running a master user-level process at Computer 1 which sends a
>> process context like code, data, registers, PC, etc as well as *"pid"*
>> to slave processes running at other computers. The responsibility of the
>> slave process is to fork a new process on order of master process and
>> attach *"pid" *given by the master to the new process it has forked. Any
>> system call on slave nodes will have an initial check of " Whether the
>> process belongs to local node or to the master node?". That is, if kernel
>> at Computer 2 pid of the process is 1500
>>
>>
>>
>> On Mon, Mar 21, 2016 at 12:23 PM, <Valdis.Kletnieks@vt.edu> wrote:
>>
>>> On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:
>>>
>>> > Sub-task 1: Until now, parent process cannot control the pid of the
>>> forked
>>> > child. A pid gets assigned as a sequential number by the kernel at the
>>> time
>>> > the process is forked . I want to modify kernel in such a way that
>>> parent
>>> > process can control the pid of the forked child.
>>>
>>> What does controlling the pid gain you?  To what purpose?
>>>
>>> > Sub-task 2: On Linux, you can find the maximum PID value for your
>>> system
>>> > with the following command:
>>> >
>>> > $ cat /proc/sys/kernel/pid_max
>>> >
>>> > Suppose pid_max=2000 for a system. I want that the parent process
>>> should be
>>> > able to assign a pid which is greater that 2000 to the forked child.
>>>
>>> Again, why would you want to do that?
>>>
>>> Anyhow...
>>>
>>> echo 3000 > /proc/sys/kernel/pid_max
>>> fork a process that gets a pid over 2000.
>>>
>>> Done.
>>>
>>> Note that on 32 bit systems, using a pid_max of over 32768 will cause
>>> various things in /proc to blow up.
>>>
>>> I suspect that you need to think harder about what problem you're
>>> actually
>>> trying to solve here - what will you do with a controlled child PID? Why
>>> does
>>> it even matter?
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/8087ab47/attachment.html 

Attach my own pid

[Nitin Varyani]

struct task_struct {
volatile long state;
void *stack;
...
*pid_t pid;*
...
}
You mean to say that just mapping the *pid_t pid*  will do the job. Does
the linux kernel not store pid somewhere else while forking a child?

On Mon, Mar 21, 2016 at 4:18 PM, Pranay Srivastava <pranjas@gmail.com>
wrote:

> Nitin,
>
>
> On Mon, Mar 21, 2016 at 4:03 PM, Nitin Varyani <varyani.nitin1@gmail.com>
> wrote:
> > .....Continued.... That is, if kernel at Computer 2 finds that pid of a
> > process requesting a system call is 1500, the request is forwarded to
> slave
> > daemon which in turn contacts with the master daemon. Master daemon
> requests
> > the kernel for the system call and sends the result back to slave daemon.
>
> I don't think doing this by pid is better. It might suit you currently
> but in the long run?
> If you are able to send the whole context, why not map that pid to
> your context internally instead of relying
> on pid which is also visible outside your context.
>
> >
> > On Mon, Mar 21, 2016 at 4:01 PM, Nitin Varyani <varyani.nitin1@gmail.com
> >
> > wrote:
> >>
> >> I am trying to create a distributed pid space.
> >>
> >> 0 to 2000 Computer 1
> >> 2001 to 4000 Computer 2
> >> 4001 to 6000 Computer 3
> >>
>
> your pid 2000 shouldn't have to be same pid 2000 on another node. You
> just need the context right?
>
> >> and so on...
> >>
> >> I am running a master user-level process at Computer 1 which sends a
> >> process context like code, data, registers, PC, etc as well as "pid" to
> >> slave processes running at other computers. The responsibility of the
> slave
> >> process is to fork a new process on order of master process and attach
> "pid"
> >> given by the master to the new process it has forked. Any system call on
> >> slave nodes will have an initial check of " Whether the process belongs
> to
> >> local node or to the master node?". That is, if kernel at Computer 2
> pid of
> >> the process is 1500
> >>
> >>
> >>
> >> On Mon, Mar 21, 2016 at 12:23 PM, <Valdis.Kletnieks@vt.edu> wrote:
> >>>
> >>> On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:
> >>>
> >>> > Sub-task 1: Until now, parent process cannot control the pid of the
> >>> > forked
> >>> > child. A pid gets assigned as a sequential number by the kernel at
> the
> >>> > time
> >>> > the process is forked . I want to modify kernel in such a way that
> >>> > parent
> >>> > process can control the pid of the forked child.
> >>>
> >>> What does controlling the pid gain you?  To what purpose?
> >>>
> >>> > Sub-task 2: On Linux, you can find the maximum PID value for your
> >>> > system
> >>> > with the following command:
> >>> >
> >>> > $ cat /proc/sys/kernel/pid_max
> >>> >
> >>> > Suppose pid_max=2000 for a system. I want that the parent process
> >>> > should be
> >>> > able to assign a pid which is greater that 2000 to the forked child.
> >>>
> >>> Again, why would you want to do that?
> >>>
> >>> Anyhow...
> >>>
> >>> echo 3000 > /proc/sys/kernel/pid_max
> >>> fork a process that gets a pid over 2000.
> >>>
> >>> Done.
> >>>
> >>> Note that on 32 bit systems, using a pid_max of over 32768 will cause
> >>> various things in /proc to blow up.
> >>>
> >>> I suspect that you need to think harder about what problem you're
> >>> actually
> >>> trying to solve here - what will you do with a controlled child PID?
> Why
> >>> does
> >>> it even matter?
> >>
> >>
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
>
>
> --
>         ---P.K.S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/c924efa4/attachment-0001.html 

Attach my own pid

[Pranay Srivastava]

On Mon, Mar 21, 2016 at 4:34 PM, Nitin Varyani <varyani.nitin1@gmail.com> wrote:
> struct task_struct {
> volatile long state;
> void *stack;
> ...
> pid_t pid;
> ...
> }
> You mean to say that just mapping the pid_t pid  will do the job. Does the
> linux kernel not store pid somewhere else while forking a child?

No I mean you can translate the pid chosen by kernel and then have a
policy to map it within your framework. That just translates onto a
possible different pid or may be same on another node. That way your
framework goes independent of what the kernel is doing.

Like for example nfs, translates the inode to a file handle internally
but that framework is independent of what happens on both nodes.

>
> On Mon, Mar 21, 2016 at 4:18 PM, Pranay Srivastava <pranjas@gmail.com>
> wrote:
>>
>> Nitin,
>>
>>
>> On Mon, Mar 21, 2016 at 4:03 PM, Nitin Varyani <varyani.nitin1@gmail.com>
>> wrote:
>> > .....Continued.... That is, if kernel at Computer 2 finds that pid of a
>> > process requesting a system call is 1500, the request is forwarded to
>> > slave
>> > daemon which in turn contacts with the master daemon. Master daemon
>> > requests
>> > the kernel for the system call and sends the result back to slave
>> > daemon.
>>
>> I don't think doing this by pid is better. It might suit you currently
>> but in the long run?
>> If you are able to send the whole context, why not map that pid to
>> your context internally instead of relying
>> on pid which is also visible outside your context.
>>
>> >
>> > On Mon, Mar 21, 2016 at 4:01 PM, Nitin Varyani
>> > <varyani.nitin1@gmail.com>
>> > wrote:
>> >>
>> >> I am trying to create a distributed pid space.
>> >>
>> >> 0 to 2000 Computer 1
>> >> 2001 to 4000 Computer 2
>> >> 4001 to 6000 Computer 3
>> >>
>>
>> your pid 2000 shouldn't have to be same pid 2000 on another node. You
>> just need the context right?
>>
>> >> and so on...
>> >>
>> >> I am running a master user-level process at Computer 1 which sends a
>> >> process context like code, data, registers, PC, etc as well as "pid" to
>> >> slave processes running at other computers. The responsibility of the
>> >> slave
>> >> process is to fork a new process on order of master process and attach
>> >> "pid"
>> >> given by the master to the new process it has forked. Any system call
>> >> on
>> >> slave nodes will have an initial check of " Whether the process belongs
>> >> to
>> >> local node or to the master node?". That is, if kernel at Computer 2
>> >> pid of
>> >> the process is 1500
>> >>
>> >>
>> >>
>> >> On Mon, Mar 21, 2016 at 12:23 PM, <Valdis.Kletnieks@vt.edu> wrote:
>> >>>
>> >>> On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:
>> >>>
>> >>> > Sub-task 1: Until now, parent process cannot control the pid of the
>> >>> > forked
>> >>> > child. A pid gets assigned as a sequential number by the kernel at
>> >>> > the
>> >>> > time
>> >>> > the process is forked . I want to modify kernel in such a way that
>> >>> > parent
>> >>> > process can control the pid of the forked child.
>> >>>
>> >>> What does controlling the pid gain you?  To what purpose?
>> >>>
>> >>> > Sub-task 2: On Linux, you can find the maximum PID value for your
>> >>> > system
>> >>> > with the following command:
>> >>> >
>> >>> > $ cat /proc/sys/kernel/pid_max
>> >>> >
>> >>> > Suppose pid_max=2000 for a system. I want that the parent process
>> >>> > should be
>> >>> > able to assign a pid which is greater that 2000 to the forked child.
>> >>>
>> >>> Again, why would you want to do that?
>> >>>
>> >>> Anyhow...
>> >>>
>> >>> echo 3000 > /proc/sys/kernel/pid_max
>> >>> fork a process that gets a pid over 2000.
>> >>>
>> >>> Done.
>> >>>
>> >>> Note that on 32 bit systems, using a pid_max of over 32768 will cause
>> >>> various things in /proc to blow up.
>> >>>
>> >>> I suspect that you need to think harder about what problem you're
>> >>> actually
>> >>> trying to solve here - what will you do with a controlled child PID?
>> >>> Why
>> >>> does
>> >>> it even matter?
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Kernelnewbies mailing list
>> > Kernelnewbies at kernelnewbies.org
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> >
>>
>>
>>
>> --
>>         ---P.K.S
>
>



-- 
        ---P.K.S

Attach my own pid

[Valdis.Kletnieks at vt.edu]

On Mon, 21 Mar 2016 16:01:41 +0530, Nitin Varyani said:

> I am running a master user-level process at Computer 1 which sends a
> process context like code, data, registers, PC, etc as well as *"pid"* to
> slave processes running at other computers. The responsibility of the slave
> process is to fork a new process on order of master process and attach *"pid"
> *given by the master to the new process it has forked. Any system call on
> slave nodes will have an initial check of " Whether the process belongs to
> local node or to the master node?". That is, if kernel at Computer 2 pid of
> the process is 1500

None of that requires actually controlling the PID of the child.

Consider this code:


int child_pid[5], j;
pid_t child;

for (j=0;j<5;j++) {
	child =  fork();
	if (child == 0)
		go_init_worker_process();
	else
		child_pid[j] = child;
}

Now you have 5 children, and know what process IDs they are, without
having to do any kernel hacking@all.  This has been a long-understood
idiom in the Unix/Linux world - I remember first seeing it on SunOS 3.2 back
in 1985 or so...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/15de2b1a/attachment.bin 

Attach my own pid

[Bernd Petrovitsch]

On Die, 2016-03-22 at 01:26 -0400, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 21 Mar 2016 16:01:41 +0530, Nitin Varyani said:
> 
> > I am running a master user-level process at Computer 1 which sends a
> > process context like code, data, registers, PC, etc as well as *"pid"* to
> > slave processes running at other computers. The responsibility of the slave
> > process is to fork a new process on order of master process and attach *"pid"
> > *given by the master to the new process it has forked. Any system call on
> > slave nodes will have an initial check of " Whether the process belongs to
> > local node or to the master node?". That is, if kernel at Computer 2 pid of
> > the process is 1500
> 
> None of that requires actually controlling the PID of the child.

Well, I think that the OP wants to map the PIDs with a fixed offset per
host. So e.g. the local PID == 14 becomes 20014 on all other nodes.
At least for debugging it's easier than some random mappings;-)

As for top post: TTBOMK there is no SysCall for doing that.
* Perhaps one can achieve something similar with containers - one
  container per remote host or so (but I never used containers actively
  myself) or (ab)use KVM (does vServer still live?) for local
  "pseudo-VMs" (and use there the original PIDs - or so).
* The manual page of clone(2) doesn't reveal to me if it's possible to
  wish for a PID.
* You could clone (pun not intended;-) the fork() syscall and add an
  parameter - the PID - to it (and e.g. return -1 if it's already used).

BTW I don't know how the rest of the kernel reacts to such artifical
PIDs (but you will see;-) outside the "official range".

MfG,
	Bernd
-- 
"What happens when you read some doc and either it doesn't answer your
question or is demonstrably wrong? In Linux, you say "Linux sucks" and
go read the code. In Windows/Oracle/etc you say "Windows sucks" and
start banging your head against the wall."    - Denis Vlasenko on lkml

Attach my own pid

[Nitin Varyani]

If I do the following thing:

struct pid remote_struct_pid;
remote_struct_pid.numbers[0].nr=*my_pid*;
p = copy_process(clone_flags, stack_start, stack_size, child_tidptr,
*remote_struct_pid*, trace, tls);

and modify the copy_process function little bit (marked in BOLD), it may
serve my objective.

if (pid != &init_struct_pid *&& pid == NULL*) {
                 retval = -ENOMEM;
                 pid = alloc_pid(p->nsproxy->pid_ns);
                 if (!pid)
                         goto bad_fork_cleanup_io;
         }

         p->pid = pid_nr(pid);

The pids by kernel are allocated in the range (RESERVED_PIDS,
PID_MAX_DEFAULT) and I will choose *my_pid* outside this range.
I will have to modify system calls/kernel to cater to such processes.


On Tue, Mar 22, 2016 at 3:55 PM, Bernd Petrovitsch <
bernd@petrovitsch.priv.at> wrote:

> On Die, 2016-03-22 at 01:26 -0400, Valdis.Kletnieks at vt.edu wrote:
> > On Mon, 21 Mar 2016 16:01:41 +0530, Nitin Varyani said:
> >
> > > I am running a master user-level process at Computer 1 which sends a
> > > process context like code, data, registers, PC, etc as well as *"pid"*
> to
> > > slave processes running at other computers. The responsibility of the
> slave
> > > process is to fork a new process on order of master process and attach
> *"pid"
> > > *given by the master to the new process it has forked. Any system call
> on
> > > slave nodes will have an initial check of " Whether the process
> belongs to
> > > local node or to the master node?". That is, if kernel at Computer 2
> pid of
> > > the process is 1500
> >
> > None of that requires actually controlling the PID of the child.
>
> Well, I think that the OP wants to map the PIDs with a fixed offset per
> host. So e.g. the local PID == 14 becomes 20014 on all other nodes.
> At least for debugging it's easier than some random mappings;-)
>
> As for top post: TTBOMK there is no SysCall for doing that.
> * Perhaps one can achieve something similar with containers - one
>   container per remote host or so (but I never used containers actively
>   myself) or (ab)use KVM (does vServer still live?) for local
>   "pseudo-VMs" (and use there the original PIDs - or so).
> * The manual page of clone(2) doesn't reveal to me if it's possible to
>   wish for a PID.
> * You could clone (pun not intended;-) the fork() syscall and add an
>   parameter - the PID - to it (and e.g. return -1 if it's already used).
>
> BTW I don't know how the rest of the kernel reacts to such artifical
> PIDs (but you will see;-) outside the "official range".
>
> MfG,
>         Bernd
> --
> "What happens when you read some doc and either it doesn't answer your
> question or is demonstrably wrong? In Linux, you say "Linux sucks" and
> go read the code. In Windows/Oracle/etc you say "Windows sucks" and
> start banging your head against the wall."    - Denis Vlasenko on lkml
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160327/30b05932/attachment.html 

Attach my own pid

[Nitin Varyani]

rather this will also suffice

if (* pid == NULL*) {
                 retval = -ENOMEM;
                 pid = alloc_pid(p->nsproxy->pid_ns);
                 if (!pid)
                         goto bad_fork_cleanup_io;
         }

         p->pid = pid_nr(pid);

On Sun, Mar 27, 2016 at 4:57 PM, Nitin Varyani <varyani.nitin1@gmail.com>
wrote:

> If I do the following thing:
>
> struct pid remote_struct_pid;
> remote_struct_pid.numbers[0].nr=*my_pid*;
> p = copy_process(clone_flags, stack_start, stack_size, child_tidptr,
> *remote_struct_pid*, trace, tls);
>
> and modify the copy_process function little bit (marked in BOLD), it may
> serve my objective.
>
> if (pid != &init_struct_pid *&& pid == NULL*) {
>                  retval = -ENOMEM;
>                  pid = alloc_pid(p->nsproxy->pid_ns);
>                  if (!pid)
>                          goto bad_fork_cleanup_io;
>          }
>
>          p->pid = pid_nr(pid);
>
> The pids by kernel are allocated in the range (RESERVED_PIDS,
> PID_MAX_DEFAULT) and I will choose *my_pid* outside this range.
> I will have to modify system calls/kernel to cater to such processes.
>
>
> On Tue, Mar 22, 2016 at 3:55 PM, Bernd Petrovitsch <
> bernd at petrovitsch.priv.at> wrote:
>
>> On Die, 2016-03-22 at 01:26 -0400, Valdis.Kletnieks at vt.edu wrote:
>> > On Mon, 21 Mar 2016 16:01:41 +0530, Nitin Varyani said:
>> >
>> > > I am running a master user-level process at Computer 1 which sends a
>> > > process context like code, data, registers, PC, etc as well as
>> *"pid"* to
>> > > slave processes running at other computers. The responsibility of the
>> slave
>> > > process is to fork a new process on order of master process and
>> attach *"pid"
>> > > *given by the master to the new process it has forked. Any system
>> call on
>> > > slave nodes will have an initial check of " Whether the process
>> belongs to
>> > > local node or to the master node?". That is, if kernel at Computer 2
>> pid of
>> > > the process is 1500
>> >
>> > None of that requires actually controlling the PID of the child.
>>
>> Well, I think that the OP wants to map the PIDs with a fixed offset per
>> host. So e.g. the local PID == 14 becomes 20014 on all other nodes.
>> At least for debugging it's easier than some random mappings;-)
>>
>> As for top post: TTBOMK there is no SysCall for doing that.
>> * Perhaps one can achieve something similar with containers - one
>>   container per remote host or so (but I never used containers actively
>>   myself) or (ab)use KVM (does vServer still live?) for local
>>   "pseudo-VMs" (and use there the original PIDs - or so).
>> * The manual page of clone(2) doesn't reveal to me if it's possible to
>>   wish for a PID.
>> * You could clone (pun not intended;-) the fork() syscall and add an
>>   parameter - the PID - to it (and e.g. return -1 if it's already used).
>>
>> BTW I don't know how the rest of the kernel reacts to such artifical
>> PIDs (but you will see;-) outside the "official range".
>>
>> MfG,
>>         Bernd
>> --
>> "What happens when you read some doc and either it doesn't answer your
>> question or is demonstrably wrong? In Linux, you say "Linux sucks" and
>> go read the code. In Windows/Oracle/etc you say "Windows sucks" and
>> start banging your head against the wall."    - Denis Vlasenko on lkml
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160327/c09832e2/attachment-0001.html 

Attach my own pid

[Mike Krinkin]

On Sun, Mar 20, 2016 at 02:07:29AM -0700, Nitin Varyani wrote:
> Hi,
>      The linux kernel attaches a pid to newly forked process. I want to
> create a facility by which a process has the option of attaching a new pid
> to its child which is not in the pid space.
>       Any suggestions of how this can be achieved?
> Nitin

Don't know what you are trying to accomplish, but have a look at this:

https://criu.org/Pid_restore

> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies