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: KOSAKI Motohiro on 5 Nov 2009 06:40 > 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? John, I'd prefer to suggested another design. How about this? 1. remove pid argument from prctl 2. cancel pthread_setname_np() 3. instead, create pthread_attr_setname_np() 4. pthread_create() change own thread name by pthread_attr. It avoid many racy problem automatically. -- 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: KOSAKI Motohiro on 5 Nov 2009 06:41 > KOSAKI Motohiro wrote: > >> KOSAKI Motohiro wrote: > >> > >>> John, I'd prefer to suggested another design. > >>> How about this? > >>> > >>> 1. remove pid argument from prctl > >>> 2. cancel pthread_setname_np() > >>> 3. instead, create pthread_attr_setname_np() > >>> 4. pthread_create() change own thread name by pthread_attr. > >>> > >>> It avoid many racy problem automatically. > >> Perhaps, but it also greatly reduces the flexibility of the > >> implementation by restricting name changes to create time. > > > > Hm. > > if your program really need to change another thread name, can you please tell us > > why it is necessary and when it is used? > > I think John's previous mails covered that pretty well. As for doing the > name change at create time, or sometime later, it just seems to me that > the flexibility of doing so later is worth having. While I know we don't > have to follow other systems implementations, in this case > pthread_setname_np() seems a reasonable model to follow to me. You only said your mode is more flexible. but I want to know _why_ this flexibiliby is necessay. please tell us concrete use-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/
From: Darren Hart on 5 Nov 2009 06:41 KOSAKI Motohiro wrote: > John, I'd prefer to suggested another design. > How about this? > > 1. remove pid argument from prctl > 2. cancel pthread_setname_np() > 3. instead, create pthread_attr_setname_np() > 4. pthread_create() change own thread name by pthread_attr. > > > It avoid many racy problem automatically. Perhaps, but it also greatly reduces the flexibility of the implementation by restricting name changes to create time. -- Darren Hart IBM Linux Technology Center Real-Time Linux Team -- 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: KOSAKI Motohiro on 5 Nov 2009 06:41 > KOSAKI Motohiro wrote: > > > John, I'd prefer to suggested another design. > > How about this? > > > > 1. remove pid argument from prctl > > 2. cancel pthread_setname_np() > > 3. instead, create pthread_attr_setname_np() > > 4. pthread_create() change own thread name by pthread_attr. > > > > It avoid many racy problem automatically. > > Perhaps, but it also greatly reduces the flexibility of the > implementation by restricting name changes to create time. Hm. if your program really need to change another thread name, can you please tell us why it is necessary and when it is used? -- 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: Darren Hart on 5 Nov 2009 06:41
KOSAKI Motohiro wrote: >> KOSAKI Motohiro wrote: >> >>> John, I'd prefer to suggested another design. >>> How about this? >>> >>> 1. remove pid argument from prctl >>> 2. cancel pthread_setname_np() >>> 3. instead, create pthread_attr_setname_np() >>> 4. pthread_create() change own thread name by pthread_attr. >>> >>> It avoid many racy problem automatically. >> Perhaps, but it also greatly reduces the flexibility of the >> implementation by restricting name changes to create time. > > Hm. > if your program really need to change another thread name, can you please tell us > why it is necessary and when it is used? > I think John's previous mails covered that pretty well. As for doing the name change at create time, or sometime later, it just seems to me that the flexibility of doing so later is worth having. While I know we don't have to follow other systems implementations, in this case pthread_setname_np() seems a reasonable model to follow to me. -- Darren Hart IBM Linux Technology Center Real-Time Linux Team -- 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/ |