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: Tejun Heo on 30 Jul 2010 10:40 Hello, On 07/30/2010 04:19 PM, Oleg Nesterov wrote: > 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. Having kernel threads which are children of user process is plain scary considering the many things parent/children relationship implies and various bugs and security vulnerabilities in the area. I can't pinpoint any problem but I think we really shouldn't be adding something like this for this specific use case. If we can get away with exporting a few symbols, let's go that way. Thanks. -- tejun -- 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 1 Aug 2010 05:00 On Fri, Jul 30, 2010 at 04:19:01PM +0200, Oleg Nesterov wrote: > 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. Oleg, I mean Ack the exporting of get/set affinity. Thanks! -- 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 2 Aug 2010 11:10 On 08/01, Michael S. Tsirkin wrote: > > Oleg, I mean Ack the exporting of get/set affinity. Ah, I misunderstood. Yes, I believe the exporting is the lesser evil. Please feel free to add my ack. 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: Peter Zijlstra on 4 Aug 2010 06:50
On Tue, 2010-07-27 at 07:55 +0300, Michael S. Tsirkin wrote: > Peter, could you please indicate whether you think this is the way to > go, too? I really dislike it, as you indicated, you now want priority too.. It seems the problem is that we normally don't consider work done by kernel threads for user processes part of that process. I'm not sure what work you're doing, but I'm pretty sure there's similar things already in the kernel -- think about the work done by encryption threads for encrypted sockets and stuff. If you want proper containment of work caused by a process, I'd suggest you start by looking at curing the general problem, instead of special casing this one case. -- 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/ |