Date:	Thu, 21 Apr 2011 10:29:49 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	kosaki.motohiro@...fujitsu.com,
	David Rientjes <rientjes@...gle.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>,
	Michal Nazarewicz <mina86@...a86.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/2] break out page allocation warning code

> 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.



And one correction.
------------------------------------------------------------------
static ssize_t comm_write(struct file *file, const char __user *buf,
                                size_t count, loff_t *offset)
{
        struct inode *inode = file->f_path.dentry->d_inode;
        struct task_struct *p;
        char buffer[TASK_COMM_LEN];

        memset(buffer, 0, sizeof(buffer));
        if (count > sizeof(buffer) - 1)
                count = sizeof(buffer) - 1;
        if (copy_from_user(buffer, buf, count))
                return -EFAULT;

        p = get_proc_task(inode);
        if (!p)
                return -ESRCH;

        if (same_thread_group(current, p))
                set_task_comm(p, buffer);
        else
                count = -EINVAL;
------------------------------------------------------------------

This code doesn't have proper credential check. IOW, you forgot to
pthread_setuid_np() case.




--
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