From: john stultz <johnstul@us.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Nazarewicz <mina86@mina86.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] break out page allocation warning code
Date: Wed, 20 Apr 2011 13:34:55 -0700 [thread overview]
Message-ID: <1303331695.2796.159.camel@work-vm> (raw)
In-Reply-To: <alpine.DEB.2.00.1104201317410.31768@chino.kir.corp.google.com>
On Wed, 2011-04-20 at 13:24 -0700, David Rientjes wrote:
> On Wed, 20 Apr 2011, KOSAKI Motohiro wrote:
>
> > > That was true a while ago, but you now need to protect every thread's
> > > ->comm with get_task_comm() or ensuring task_lock() is held to protect
> > > against /proc/pid/comm which can change other thread's ->comm. That was
> > > different before when prctl(PR_SET_NAME) would only operate on current, so
> > > no lock was needed when reading current->comm.
> >
> > Right. /proc/pid/comm is evil. We have to fix it. otherwise we need change
> > all of current->comm user. It's very lots!
> >
>
> Fixing it in this case would be removing it and only allowing it for
> current via the usual prctl() :) The code was introduced in 4614a696bd1c
> (procfs: allow threads to rename siblings via /proc/pid/tasks/tid/comm) in
> December 2009 and seems to originally be meant for debugging. We simply
> can't continue to let it modify any thread's ->comm unless we change the
> over 300 current->comm deferences in the kernel.
>
> I'd prefer that we remove /proc/pid/comm entirely or at least prevent
> writing to it unless CONFIG_EXPERT.
Eeeh. That's probably going to be a tough sell, as I think there is
wider interest in what it provides. Its useful for debugging
applications not kernels, so I doubt folks will want to rebuild their
kernel to try to analyze a java issue.
So I'm well aware that there is the chance that you catch the race and
read an incomplete/invalid comm (it was discussed at length when the
change went in), but somewhere I've missed how that's causing actual
problems. Other then just being "evil" and having the documented race,
could you clarify what the issue is that your hitting?
thanks
-john
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-04-20 20:35 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 17:04 [PATCH 1/2] break out page allocation warning code Dave Hansen
2011-04-15 17:04 ` [PATCH 2/2] print vmalloc() state after allocation failures Dave Hansen
2011-04-15 17:20 ` Michal Nazarewicz
2011-04-15 17:44 ` Dave Hansen
2011-04-17 0:03 ` David Rientjes
2011-04-18 15:21 ` Dave Hansen
2011-04-17 0:02 ` [PATCH 1/2] break out page allocation warning code David Rientjes
2011-04-18 15:10 ` Dave Hansen
2011-04-18 20:25 ` David Rientjes
2011-04-18 20:57 ` Dave Hansen
2011-04-19 21:23 ` David Rientjes
2011-04-18 21:03 ` Dave Hansen
2011-04-18 21:22 ` Dave Hansen
2011-04-19 0:44 ` KOSAKI Motohiro
2011-04-19 21:21 ` David Rientjes
2011-04-20 0:39 ` KOSAKI Motohiro
2011-04-20 20:24 ` David Rientjes
2011-04-20 20:34 ` john stultz [this message]
2011-04-21 1:29 ` KOSAKI Motohiro
2011-04-25 4:21 ` KOSAKI Motohiro
2011-04-26 19:27 ` john stultz
2011-04-27 23:51 ` David Rientjes
2011-04-28 0:32 ` john stultz
2011-04-28 1:29 ` john stultz
2011-04-28 22:48 ` David Rientjes
2011-04-28 23:48 ` john stultz
2011-04-29 0:04 ` john stultz
2011-04-26 21:25 ` john stultz
2011-04-28 3:05 ` KOSAKI Motohiro
2011-04-20 1:41 ` Dave Hansen
2011-04-20 1:50 ` KOSAKI Motohiro
2011-04-20 2:19 ` KOSAKI Motohiro
2011-04-20 2:46 ` Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2011-04-19 16:21 Dave Hansen
2011-04-08 20:22 Dave Hansen
2011-04-08 20:37 ` David Rientjes
2011-04-08 20:43 ` Dave Hansen
2011-04-08 20:54 ` Michał Nazarewicz
2011-04-08 21:02 ` Dave Hansen
2011-04-11 10:20 ` Michal Nazarewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1303331695.2796.159.camel@work-vm \
--to=johnstul@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mina86@mina86.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).