lkml.org 
[lkml]   [2006]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Containers] [PATCH 5/7] pid: Implement pid_nr
Date
Dave Hansen <haveblue@us.ibm.com> writes:

> On Tue, 2006-08-15 at 13:00 -0600, Eric W. Biederman wrote:
>> Dave Hansen <haveblue@us.ibm.com> writes:
>>
>> > On Tue, 2006-08-15 at 12:23 -0600, Eric W. Biederman wrote:
>> >> +static inline pid_t pid_nr(struct pid *pid)
>> >> +{
>> >> + pid_t nr = 0;
>> >> + if (pid)
>> >> + nr = pid->nr;
>> >> + return nr;
>> >> +}
>> >
>> > When is it valid to be passing around a NULL 'struct pid *'?
>>
>> When you don't have one at all. Look at the fcntl case a few
>> patches later, or even the spawnpid case.
>
> Does the fcntl() one originate from anywhere other than find_pid() in
> f_setown()? It seems like, perhaps, the error checking is being done at
> the wrong level.

Yes. It is normally NULL as file handles don't usually have a process
to send a signal to.

>> Then of course there is the later chaos when we get to pid spaces
>> where depending on the pid namespace you are in when you call this
>> on a given struct pid sometimes you will get a pid value and sometimes
>> you won't.
>
> OK, I think it is makes sense to me to say 'get_pid(tsk, pidspace)' and
> get back a NULL 'struct pid' if that task isn't visible in that
> namespace. However, I don't get how it is handy to be able to defer the
> fact that the pid wasn't found until you go do a pid_nr() on that NULL.

If having a pid to signal is optional, which it almost always is,
being able to handle that case easily and return a 0 to user space is helpful.

So far it is my assumption that everything that looks up a pid and converts
a pid to a number will do it with respect to the current processes pidspace.
A very reasonable assumption and only with siginfo have I found a case where
it looks like I might not be able to implement it that way.

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/

\
 
 \ /
  Last update: 2006-08-16 08:33    [W:0.033 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site