lkml.org 
[lkml]   [1997]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectpatch for CLONE_PID enhancements to clone()
Hello Everybody,

I have made a patch against 2.1.57 that introduces the start of some
extra
functionality for clone() called with CLONE_PID.

I have put it at http://www.accessv.com/~peeter/patch-tid.2.1.57-2.gz
for reference for anybody who wants to examine what I am doing and
comment
on it. I could also post it to this list but the size (about 30K) may
be too
big for that. It is not advisable to use it as it is now, as I found
after
trying it that it breaks shutdown (but nothing else that I noticed :).
I have probably messed up kill_proc() wrt init, but I haven't looked
into it yet.

The idea is to allow the CLONE_PID flag to have cloned tasks (not just
init
on SMP) be able to share PIDs, and this patch makes some of the changes
that
I thought were neccessary for this. Note that nothing has been done
with
proc yet, as I don't know exactly how to handle hashing the pid/tids
into
the proc inode space.

Most of the changes in this patch are simple changes due to the
following change in sched.h. I have taken a number of fields out of
struct task struct and placed them into a separate structure called
struct process_struct, along with the addition of a 'struct
process_struct * ps' in struct task struct. When thinking about
processes that shared pids it didn't seem right that things like the
uid, gid, groups, ... were different. So, if CLONE_PID is specified in
the clone flags then threads created reference the same struct
process_struct. I have put anything that seemed like it should go into
this structure into this structure, but I would like comments about
the appropriateness of my choices and whether I have missed anything
(like
rlim ?).

As to the other changes, things like do_fork() have been modified to
set the tid field, and some of the system calls that had pid arguments
have new varients that take both a pid, and a tid (sys_kill,
sys_wait4, ...), but these have not been exposed to the user yet via the

syscall mechanisms.

Here is the new structure in question:

struct process_struct {
/* new fields:
*/
int last_tid, next_safe;
int count;
spinlock_t pslock;
/* things that were in task_struct:
*/
int pgrp;
int tty_old_pgrp;
int session;
/* boolean value for session group leader */
int leader;
int ngroups;
gid_t groups[NGROUPS];
unsigned short uid,euid,suid,fsuid;
unsigned short gid,egid,sgid,fsgid;
struct tty_struct *tty; /* NULL if no tty */
};
I have also added an 'int tid' field to task_struct for holding the
thread id. This seemed much simpler than encoding the tid in the upper
pid bits, and doesn't break any experimental code that is currently
using those bits for other stuff. Within process_struct are also a few
new fields that weren't in task_struct: last_tid, next_safe, count,
and pslock.

o last_tid, and next_safe are comparable to the global next_safe

and last_pid variables in fork.c for the do_fork() pid
allocation.
o count is a for a reference count on the process struct so that
it
doesn't get deleted while some other task is referencing it.
o pslock is for SMP locking of this structure. Note that I have
only started putting locks in a few places so far. However if
this patch was integrated into the kernel nothing should break

SMP-wise because nothing should be using the CLONE_PID clone()

flag.

I would appreciate any comments and suggestions. Thank you,

Peeter


\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans