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

[Arjan van de Ven <arjan@infradead.org>]

> 99% of the time, the kernel can deal with the same old tsk->pid that
> it's always dealt with.  Generally, the only times the kernel has to
> worry about the virtualized one is where (as Eric noted) it cross the
> user<->kernel boundary.

that's fair enough. I don't see the need for the macro abstractions
though; a current->pid and current->user_pid (or visible_pid or any
other good name) split makes sense. no need for macro abstractions at
all, just add ->user_pid in patch 1, in patch 2 assign it default to
->pid as well and patch 3 converts the places where ->pid is now given
to userspace ;)

again the DRM layer needs an audit, I'm not entirely sure if it doesn't
get pids from userspace. THe rest of the kernel mostly ought to cope
just fine.