[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090910060627.GA24343@us.ibm.com>
Date: Wed, 9 Sep 2009 23:06:28 -0700
From: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
To: linux-kernel@...r.kernel.org
Cc: Oren Laadan <orenl@...columbia.edu>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Pavel Emelyanov <xemul@...nvz.org>,
Andrew Morton <akpm@...l.org>, torvalds@...ux-foundation.org,
mikew@...gle.com, mingo@...e.hu, hpa@...or.com,
Nathan Lynch <nathanl@...tin.ibm.com>, arnd@...db.de,
container@...ibm.com, sukadev@...ibm.com
Subject: [RFC][v6][PATCH 0/9] clone_with_pids() syscall
=== NEW CLONE() SYSTEM CALL:
To support application checkpoint/restart, a task must have the same pid it
had when it was checkpointed. When containers are nested, the tasks within
the containers exist in multiple pid namespaces and hence have multiple pids
to specify during restart.
This patchset implements a new system call, clone_with_pids() that lets a
process specify the pids of the child process.
Patches 1 through 6 are helpers and we believe they are needed for application
restart, regardless of the kernel implementation of application restart.
Patch 8 defines a prototype of the new system call. Patch 9 adds some
documentation on the new system call.
Changelog[v6]:
- [Nathan Lynch, Arnd Bergmann, H. Peter Anvin, Linus Torvalds]
Change 'pid_set.pids' to 'pid_t pids[]' so sizeof(struct pid_set) is
constant across architectures (Patches 7, 8).
- [Nathan Lynch] Change pid_set.num_pids to unsigned and remove
'unum_pids < 0' check (Patches 7,8)
- [Pavel Machek] New patch (Patch 9) to add some documentation.
Changelog[v5]:
- Make 'pid_max' a property of pid_ns (Integrated Serge Hallyn's patch
into this set)
- (Eric Biederman): Avoid the new function, set_pidmap() - added
couple of checks on 'target_pid' in alloc_pidmap() itself.
=== IMPORTANT TODO:
clone() system call has another limitation - all available bits in clone-flags
are in use and any new clone-flag will need a variant of the clone() system
call.
It appears to make sense to try and extend this new system call to address
this limitation as well. The basic requirements of a new clone system call
could then be summarized as:
- do everything clone() does today, and
- give application an ability to choose pids for the child process
in all ancestor pid namespaces, and
- allow more clone_flags
Contstraints:
- system-calls are restricted to 6 parameters and clone() already
takes 5 parameters, any extension to clone() interface would require
one or more copy_from_user().
- does copy_from_user() of a few words have a significant impact on
the total cost of clone() ?
Based on these requirements and constraints, we have been exploring a couple
of system call interfaces and appreciate any iput.
1. =====
#if 64bit
#define CLONE_FLAGS_WORDS 1
#else
#define CLONE_FLAGS_WORDS 2
#endif
struct pid_set {
int num_pids;
pid_t pids[];
};
typedef struct {
unsigned long flags[CLONE_FLAGS_WORDS];
} clone_flags_t;
int clone_extended(clone_flags_t *flags, void *child_stack, int *unused,
int *parent_tid, int *child_tid, struct pid_set *pid_set);
Pros:
- extendible clone_flags (like sigset_t)
Cons:
- copy_from_user() needed on all architectures (we maybe able
to play some tricks with 'clone_flags_t' to avoid the copy
on 64-bit archtitectures till N_CLONE_FLAGS exceeds 64).
- Both applications and kernel must use interfaces equivalent
to sigsetops(3) to test/set/clear clone flags.
2. ======
struct clone_info {
int num_clone_high_words;
int *flags_high;
struct pid_set pid_set;
}
int clone_extended(int flags_low, void *child_stack, void *unused,
int *parent_tid, int *child_tid, struct clone_info *clone_info);
Pros:
- copy_from_user() needed only for new flags and pid_set
Cons:
- splitting the high and low clone-flags is awkward ?
Signed-off-by: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists