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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Nov 2009 09:04:47 +0900 (JST) From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> To: john stultz <johnstul@...ibm.com> Cc: kosaki.motohiro@...fujitsu.com, Sean Foley <Sean_Foley@...ibm.com>, Andrew Morton <akpm@...ux-foundation.org>, Andi Kleen <andi@...stfloor.org>, Arjan van de Ven <arjan@...radead.org>, Darren Hart <dvhltc@...ibm.com>, lkml <linux-kernel@...r.kernel.org>, Mike Fulton <fultonm@...ibm.com> Subject: Re: [RFC][PATCH] Add prctl to set sibling thread names > On Tue, 2009-11-10 at 14:27 +0900, KOSAKI Motohiro wrote: > > Hi Sean, John, > > > > > Kosaki, > > > Here are a couple of use cases previously posted to this thread on the linux kernel mailing list: > > > > > > dispatch thread adds context to thread names: > > > http://marc.info/?l=linux-kernel&m=125660141231348&w=2 > > > > > > java language support: > > > http://marc.info/?l=linux-kernel&m=125666430720863&w=2 > > > > > > > > > > > > Here are some various specific use cases from the web: > > > > > > Attaching additional info to thread names when used for different purposes: > > > http://osdir.com/ml/java.jsr.166-concurrency/2006-12/msg00105.html > > > > > > Threads obtained from thread pools being reassigned new names: > > > http://haacked.com/archive/2004/06/07/546.aspx > > > http://bytes.com/topic/c-sharp/answers/637152-naming-backgroundworker-thread > > > > > > Renaming threads scattered across third-party libraries by enumerating them and renaming them dynamically: > > > http://stackoverflow.com/questions/467224/renaming-threads-in-java > > > > Okey, good explanation. thanks! > > > > So, I would suggested to extend /proc/{pid}/cmdline instead using task->comm. > > because > > - task->comm has nasty locking rule. It is harder to change SMP safe. > > I cc'ed you on the updated patch which addresses this. Please let me > know if you have specific concerns there. > > > - ps (and other procps tools) already support /proc/{pid}/cmdline. > > - task->comm is restrected 16 character length, /proc/cmdline isn't. > > Part of the reason to use comm is that most tools like perf or oprofile, > use comm, instead of cmd. Ah, good reason. Okey, I will revew your new patch. thanks. > Additionally, looking at cmdline, that's per > mm not per task, right? So it wouldn't really work for thread names. Currently, yes. I meaned I think you can enhance it ;) > Please correct me if I'm not seeing what you're really suggesting. -- 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