lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 26 Jul 2010 20:12:30 +0300 From: "Michael S. Tsirkin" <mst@...hat.com> To: Oleg Nesterov <oleg@...hat.com> Cc: Peter Zijlstra <peterz@...radead.org>, Sridhar Samudrala <sri@...ibm.com>, Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>, netdev <netdev@...r.kernel.org>, lkml <linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, Dmitri Vorobiev <dmitri.vorobiev@...ial.com>, Jiri Kosina <jkosina@...e.cz>, Thomas Gleixner <tglx@...utronix.de>, Andi Kleen <ak@...ux.intel.com> Subject: Re: [PATCH repost] sched: export sched_set/getaffinity to modules On Fri, Jul 02, 2010 at 11:06:37PM +0200, Oleg Nesterov wrote: > On 07/02, Peter Zijlstra wrote: > > > > On Fri, 2010-07-02 at 11:01 -0700, Sridhar Samudrala wrote: > > > > > > Does it (Tejun's kthread_clone() patch) also inherit the > > > cgroup of the caller? > > > > Of course, its a simple do_fork() which inherits everything just as you > > would expect from a similar sys_clone()/sys_fork() call. > > Yes. And I'm afraid it can inherit more than we want. IIUC, this is called > from ioctl(), right? > > Then the new thread becomes the natural child of the caller, and it shares > ->mm with the parent. And files, dup_fd() without CLONE_FS. > > Signals. Say, if you send SIGKILL to this new thread, it can't sleep in > TASK_INTERRUPTIBLE or KILLABLE after that. And this SIGKILL can be sent > just because the parent gets SIGQUIT or abother coredumpable signal. > Or the new thread can recieve SIGSTOP via ^Z. > > Perhaps this is OK, I do not know. Just to remind that kernel_thread() > is merely clone(CLONE_VM). > > Oleg. With some machinery to stop it later, yes. Oleg, how does the below look to you? Here I explicitly drop the fds so we don't share them. CLONE_VM takes care of sharing the mm I think. About signals - for the vhost-net use this is OK as we use uninterruptible sleep anyway (like the new kthread_worker does). This code seems to work fine for me so far - any comments? --- diff --git a/include/linux/kthread.h b/include/linux/kthread.h index aabc8a1..72c7b17 100644 --- a/include/linux/kthread.h +++ b/include/linux/kthread.h @@ -9,6 +9,11 @@ struct task_struct *kthread_create(int (*threadfn)(void *data), const char namefmt[], ...) __attribute__((format(printf, 3, 4))); +struct task_struct *kthread_create_inherit(int (*threadfn)(void *data), + void *data, + const char namefmt[], ...) + __attribute__((format(printf, 3, 4))); + /** * kthread_run - create and wake a thread. * @threadfn: the function to run until signal_pending(current). diff --git a/kernel/kthread.c b/kernel/kthread.c index 83911c7..b81588c 100644 --- a/kernel/kthread.c +++ b/kernel/kthread.c @@ -149,6 +149,38 @@ struct task_struct *kthread_create(int (*threadfn)(void *data), } EXPORT_SYMBOL(kthread_create); +/* Same as kthread_create, but inherit attributes (cgroups, priority, CPU mask) + * from current. */ +struct task_struct *kthread_create_inherit(int (*threadfn)(void *data), + void *data, + const char namefmt[], + ...) +{ + struct kthread_create_info create; + + create.threadfn = threadfn; + create.data = data; + init_completion(&create.done); + + create_kthread(&create); + wait_for_completion(&create.done); + + if (!IS_ERR(create.result)) { + va_list args; + + /* Don't share files with parent as drivers use release for + * close on exit, etc. */ + exit_files(create.result); + + va_start(args, namefmt); + vsnprintf(create.result->comm, sizeof(create.result->comm), + namefmt, args); + va_end(args); + } + return create.result; +} +EXPORT_SYMBOL(kthread_create_inherit); + /** * kthread_bind - bind a just-created kthread to a cpu. * @p: thread created by kthread_create(). -- 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