Add prctl to set sibling thread names
in [Kernel]
|
Prev: SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() (was: Re: [Bug #14265] ifconfig: page allocation failure. order:5,ode:0x8020 w/ e100)
Next: [PATCH 2.4] net: Fix 64 bit DMA addressing for 8139cp and r8169
From: john stultz on 21 Oct 2009 21:00 On Wed, 2009-10-21 at 17:48 -0700, Arjan van de Ven wrote: > On Wed, 21 Oct 2009 16:21:37 -0700 > john stultz <johnstul(a)us.ibm.com> wrote: > > > > > Taking a very raw attempt at this, I scratched out the following > > simple implementation. I'd appreciate any review or suggestions for > > improvements. I'm not at all certain the passing of the thread pid_t > > through the unsigned long is valid, for instance, or if > > same_thread_group() is the right check to make sure we only change > > siblings and not tid from other processes. So any advice on better > > approaches would be great. > > > > + return -EINVAL; > > + > > + set_task_comm(tsk, comm); > > > you're pretty much the first now who touches ->comm from > not-the-thread-itself.... are you sure that is safe? No, I'm not sure at all :) Thanks for pointing this out. I'll see whats needed in set_task_comm(). thanks again -john -- 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: Andrew Morton on 21 Oct 2009 22:10 On Wed, 21 Oct 2009 17:52:24 -0700 john stultz <johnstul(a)us.ibm.com> wrote: > On Wed, 2009-10-21 at 17:48 -0700, Arjan van de Ven wrote: > > On Wed, 21 Oct 2009 16:21:37 -0700 > > john stultz <johnstul(a)us.ibm.com> wrote: > > > > > > > > Taking a very raw attempt at this, I scratched out the following > > > simple implementation. I'd appreciate any review or suggestions for > > > improvements. I'm not at all certain the passing of the thread pid_t > > > through the unsigned long is valid, for instance, or if > > > same_thread_group() is the right check to make sure we only change > > > siblings and not tid from other processes. So any advice on better > > > approaches would be great. > > > > > > + return -EINVAL; > > > + > > > + set_task_comm(tsk, comm); > > > > > > you're pretty much the first now who touches ->comm from > > not-the-thread-itself.... are you sure that is safe? > > No, I'm not sure at all :) > > Thanks for pointing this out. I'll see whats needed in set_task_comm(). > set_task_comm() is OK. The problem will be the unwritten rule that processes can read *their own* ->comm without task_lock(), because nobody ever alters ->comm apart from tack which owns it. You've changed that, so all the open-coded accesses to current->comm are now racy. Also, you appear to be running set_task_comm() against a task_struct without holding a reference on that task. Will a well-timed exit() cause a modify-after-free? -- 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: Arjan van de Ven on 21 Oct 2009 22:50 On Thu, 22 Oct 2009 02:49:19 +0200 Andi Kleen <andi(a)firstfloor.org> wrote: > > you're pretty much the first now who touches ->comm from > > not-the-thread-itself.... are you sure that is safe? > > It's not, there is no locking. On the other hand nothing should crash, > just users might see half rewritten data. ... with strings this is tricky though.. if the new string is longer than the old one the terminating zero might just be missed etc. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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: Andi Kleen on 24 Oct 2009 13:30 On Wed, Oct 21, 2009 at 07:48:22PM -0700, Arjan van de Ven wrote: > On Thu, 22 Oct 2009 02:49:19 +0200 > Andi Kleen <andi(a)firstfloor.org> wrote: > > > > you're pretty much the first now who touches ->comm from > > > not-the-thread-itself.... are you sure that is safe? > > > > It's not, there is no locking. On the other hand nothing should crash, > > just users might see half rewritten data. > > .. with strings this is tricky though.. if the new string is longer > than the old one the terminating zero might just be missed etc. Good point. He needs to first set the last byte to zero to avoid that. But better probably to do a proper lock on all readers. Or not add this feature at all (does it have a strong use case?) -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- 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: john stultz on 26 Oct 2009 20:00
On Sat, 2009-10-24 at 05:54 +0200, Andi Kleen wrote: > On Wed, Oct 21, 2009 at 07:48:22PM -0700, Arjan van de Ven wrote: > > On Thu, 22 Oct 2009 02:49:19 +0200 > > Andi Kleen <andi(a)firstfloor.org> wrote: > > > > > > you're pretty much the first now who touches ->comm from > > > > not-the-thread-itself.... are you sure that is safe? > > > > > > It's not, there is no locking. On the other hand nothing should crash, > > > just users might see half rewritten data. > > > > .. with strings this is tricky though.. if the new string is longer > > than the old one the terminating zero might just be missed etc. > > Good point. > He needs to first set the last byte to zero to avoid that. > But better probably to do a proper lock on all readers. Or not add > this feature at all (does it have a strong use case?) Thread naming is really helpful for debugging a large multi-threaded application. But currently it requires the threads to name themselves. In some applications there may be a dispatch thread that spawns off the siblings, and it has more context for naming the threads then the threads do themselves. So in that case, currently in order to have named threads, the application's dispatch thread assigns names, and the threads have to occasionally poll to see if they need to name themselves to something. So they can get it to work, but its ugly and a big pain. Other OSes support pthread_set_name_np() functionality, which makes things easy for them, so they've requested to see if Linux can't do something similar. thanks -john -- 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/ |