Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Arjan van de Ven]

> > hmm wonder if it's not just a lot simpler to introduce a split in
> > "kernel pid" and "userspace pid", and have current->pid and
> > current->user_pid for that.
> > 
> > Using accessor macros doesn't sound like it gains much here.. (but then
> > I've not seen the full picture and you have)
> 
> My first instinct was to introduce functions like get_user_pid() and
> get_kernel_pid() which would effectively introduce the same split.
> Doing that, we could keep from even referencing ->user_pid in normal
> code, and keep things small and simpler for people like the embedded
> folks.

well I don't see the point for the abstraction... get_kernel_pid() is no
better or worse than using current->pid directly, unless you want to do
"deep magic". 

> For the particular application that we're thinking of, we really don't
> want "user pid" and "kernel pid" we want "virtualized" and
> "unvirtualized", or "regular old pid" and "fancy new virtualized pid".

same thing, different name :)

> So, like in the global pidspace (which can see all pids and appears to
> applications to be just like normal) you end up returning "kernel" pids
> to userspace.  That didn't seem to make sense.  

hmm this is scary. If you don't have "unique" pids inside the kernel a
lot of stuff will subtly break. DRM for example (which has the pid
inside locking to track ownership and recursion), but I'm sure there's
many many cases like that. I guess the address of the task struct is the
ultimate unique pid in this sense.... but I suspect the way to get there
is first make a ->user_pid field, and switch all userspace visible stuff
to that, and then try to get rid of ->pid users one by one by
eliminating their uses... 

but I'm really afraid that if you make the "fake" pid visible to normal
kernel code, too much stuff will go bonkers and end up with an eternal
stream of security hazards. "Magic" hurts here, and if you don't do
magic I don't see a reason to add an abstraction which in itself doesn't
mean anything or doesn't abstract anything....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/