On Thu, 2011-04-21 at 10:29 +0900, KOSAKI Motohiro wrote: > > 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? > > The problem is, there is no documented as well. Okay, I recognized you > introduced new locking rule for task->comm. But there is no documented > it. Thus, We have no way to review current callsites are correct or not. > Can you please do it? And, I have a question. Do you mean now task->comm > reader don't need task_lock() even if it is another thread? > > _if_ every task->comm reader have to realize it has a chance to read > incomplete/invalid comm, task_lock() doesn't makes any help. Sorry if this somehow got off on the wrong foot. Its just surprising to see such passion bubble up after almost two years of quiet since the proc patch went in. So I'm not proposing comm be totally lock free (Dave Hansen might do that for me, we'll see :) but when the original patch was proposed, the idea that transient empty or incomplete comms would be possible was brought up and didn't seem to be a big enough issue at the time to block it from being merged. Its just having a more specific case where these transient null/incomplete comms causes an issue would help prioritize the need for correctness. In the meantime, I'll put some effort into trying to protect unlocked current->comm acccess using get_task_comm() where possible. Won't happen in a day, and help would be appreciated. When we hit the point where the remaining places are where the task_lock can't be taken, we can either live with the possible incomplete comm or add a new lock to protect just the comm. thanks -john -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>