Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750775AbWHPRTI (ORCPT ); Wed, 16 Aug 2006 13:19:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751228AbWHPRTH (ORCPT ); Wed, 16 Aug 2006 13:19:07 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:5257 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1750775AbWHPRTG (ORCPT ); Wed, 16 Aug 2006 13:19:06 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Andrew Morton , linux-kernel@vger.kernel.org, containers@lists.osdl.org Subject: Re: [PATCH 5/7] pid: Implement pid_nr References: <1155666193751-git-send-email-ebiederm@xmission.com> <20060816181950.GA472@oleg> <20060816210353.GA628@oleg> Date: Wed, 16 Aug 2006 11:18:48 -0600 In-Reply-To: <20060816210353.GA628@oleg> (Oleg Nesterov's message of "Thu, 17 Aug 2006 01:03:53 +0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1865 Lines: 54 Oleg Nesterov writes: > On 08/16, Eric W. Biederman wrote: >> Oleg Nesterov writes: >> >> > On 08/15, Eric W. Biederman wrote: >> >> >> >> +static inline pid_t pid_nr(struct pid *pid) >> >> +{ >> >> + pid_t nr = 0; >> >> + if (pid) >> >> + nr = pid->nr; >> >> + return nr; >> >> +} >> > >> > I think this is not safe, you need rcu locks here or the caller should >> > do some locking. >> > >> > Let's look at f_getown() (PATCH 7/7). What if original task which was >> > pointed by ->f_owner.pid has gone, another thread does fcntl(F_SETOWN), >> > and pid_nr() takes a preemtion after 'if (pid)'? In this case 'pid->nr' >> > may follow a freed memory. >> >> This isn't an rcu reference. I hold a hard reference count on >> the pid entry. So this should be safe. > > -static void f_modown(struct file *filp, unsigned long pid, > +static void f_modown(struct file *filp, struct pid *pid, enum pid_type > type, > uid_t uid, uid_t euid, int force) > { > write_lock_irq(&filp->f_owner.lock); > if (force || !filp->f_owner.pid) { > - filp->f_owner.pid = pid; > + put_pid(filp->f_owner.pid); > > This 'put_pid()' can actually free 'struct pid' if the task/group > has already gone away. Another thread doing f_getown() can access > a freed memory, no? Good point. In that case it looks like I need to hold the f_owner.lock. Something needs to serialize that. Fun. I touch the code and find a place where we didn't take a lock and accidentally relied on integer operations being atomic. I will see about working up a fix for that. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/