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

[ebiederm@xmission.com (Eric W. Biederman)]

Oleg Nesterov <oleg@tv-sign.ru> writes:

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

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/