sched: export sched_set/getaffinity to modules
in [Kernel]
|
Prev: [PATCH repost] sched: export sched_set/getaffinity to modules
Next: [PATCH 15/16] staging/wlags49_h2: use ARRAY_SIZE
From: Michael S. Tsirkin on 26 Jul 2010 16:10 On Mon, Jul 26, 2010 at 08:08:34PM +0200, Oleg Nesterov wrote: > On 07/26, Sridhar Samudrala wrote: > > > > I have been testing out a similar patch that uses kernel_thread() without CLONE_FILES > > flag rather than create_kthread() and then closing the files. > > !CLONE_FILES can't help. copy_files() does dup_fd() in this case. > The child still inherits the files. > > > Either version should be fine. > > I think neither version is fine ;) > > exit_files() is not enough too. How about the signals, As I said, signals are unimportant as we are using this thread to base a worker on - it sleeps uninterruptibly. > reparenting? That's actually a feature: it lets us find out which process owns the device using the thread by looking at the parent. > > I already forgot all details, probably I missed somethig. But it > seems to me that it is better to just export get/set affinity and > forget about all complications. > > Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael S. Tsirkin on 26 Jul 2010 16:40 On Mon, Jul 26, 2010 at 08:08:34PM +0200, Oleg Nesterov wrote: > On 07/26, Sridhar Samudrala wrote: > > > > I have been testing out a similar patch that uses kernel_thread() without CLONE_FILES > > flag rather than create_kthread() and then closing the files. > > !CLONE_FILES can't help. copy_files() does dup_fd() in this case. > The child still inherits the files. > > > Either version should be fine. > > I think neither version is fine ;) > > exit_files() is not enough too. How about the signals, reparenting? > > > I already forgot all details, probably I missed somethig. But it > seems to me that it is better to just export get/set affinity and > forget about all complications. > > Oleg. Almost forgot, we need the same for priority. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael S. Tsirkin on 27 Jul 2010 01:10 On Mon, Jul 26, 2010 at 08:08:34PM +0200, Oleg Nesterov wrote: > On 07/26, Sridhar Samudrala wrote: > > > > I have been testing out a similar patch that uses kernel_thread() without CLONE_FILES > > flag rather than create_kthread() and then closing the files. > > !CLONE_FILES can't help. copy_files() does dup_fd() in this case. > The child still inherits the files. > > > Either version should be fine. > > I think neither version is fine ;) > > exit_files() is not enough too. How about the signals, reparenting? > > > I already forgot all details, probably I missed somethig. But it > seems to me that it is better to just export get/set affinity and > forget about all complications. > > Oleg. Peter, could you please indicate whether you think this is the way to go, too? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael S. Tsirkin on 27 Jul 2010 11:50 On Mon, Jul 26, 2010 at 08:08:34PM +0200, Oleg Nesterov wrote: > On 07/26, Sridhar Samudrala wrote: > > > > I have been testing out a similar patch that uses kernel_thread() without CLONE_FILES > > flag rather than create_kthread() and then closing the files. > > !CLONE_FILES can't help. copy_files() does dup_fd() in this case. > The child still inherits the files. > > > Either version should be fine. > > I think neither version is fine ;) > > exit_files() is not enough too. How about the signals, reparenting? > > > I already forgot all details, probably I missed somethig. But it > seems to me that it is better to just export get/set affinity and > forget about all complications. > > Oleg. Oleg, so can I attach your Ack to the patch in question, and merge it all through net-next? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 30 Jul 2010 10:30
Sorry for the delay, I can't be responsive these days... On 07/27, Michael S. Tsirkin wrote: > > On Mon, Jul 26, 2010 at 08:08:34PM +0200, Oleg Nesterov wrote: > > On 07/26, Sridhar Samudrala wrote: > > > > > > I have been testing out a similar patch that uses kernel_thread() without CLONE_FILES > > > flag rather than create_kthread() and then closing the files. > > > > !CLONE_FILES can't help. copy_files() does dup_fd() in this case. > > The child still inherits the files. > > > > > Either version should be fine. > > > > I think neither version is fine ;) > > > > exit_files() is not enough too. How about the signals, reparenting? > > > > > > I already forgot all details, probably I missed somethig. But it > > seems to me that it is better to just export get/set affinity and > > forget about all complications. > > > > Oleg. > > Oleg, so can I attach your Ack to the patch in question, and merge > it all through net-next? Well, I do not think you need my ack ;) But I must admit, I personally dislike this idea. A kernel thread which is the child of the user-space process, and in fact it is not the "real" kernel thread. I think this is against the common case. If you do not care the signals/reparenting, why can't you fork the user-space process which does all the work via ioctl's ? OK, I do not understand the problem domain, probably this can't work. Anyway, the patch looks buggy to me. Starting from create_kthread(&create); wait_for_completion(&create.done); At least you should check create_kthread() suceeds, otherwise wait_for_completion() will hang forever. OTOH, if it suceeds then wait_for_completion() is not needed. But this is minor. create_kthread()->kernel_thread() uses CLONE_VM, this means that the child will share ->mm. And this means that if the parent recieves the coredumping signal it will hang forever in kernel space waiting until this child exits. This is just the immediate surprise I can see with this approach, I am afraid there is something else. And once again. We are doing this hacks only because we lack a couples of exports (iiuk). This is, well, a bit strange ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |