Re: [PATCH 5/7] pid: Implement pid_nr

[Oleg Nesterov <oleg@tv-sign.ru>]

On 08/16, Eric W. Biederman wrote:
> Oleg Nesterov <oleg@tv-sign.ru> 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?

> What is an rcu reference is going from struct pid to the task
> it points to.

Yes, you are right... But I'd say it is going form task to pid :)

Oleg.