Re: [PATCH 1/9] exec_path 1/9: introduce ->exec_path and switch /proc/*/exe

[Alexey Dobriyan <adobriyan@gmail.com>]

On Fri, Jun 05, 2009 at 09:48:02AM -0700, Linus Torvalds wrote:
> On Fri, 5 Jun 2009, Alexey Dobriyan wrote:
> > 
> > It's borrowed by kernel thread of course, not userspace task.
> 
> .. and even if it is, what's the problem? 

The problem is task_struct <=> mm_struct relationship is muzzled
for various reasons, and to not depend on subtleties of who-owns-mm-struct
of the day, ->exec_path is placed onto task_struct.

Done this, ->exec_path simply stop depend on other current and future
hacks, and only defined by what binfmt loader did.

> That kernel thread has borroed whe VM for a while. It effectively _is_ a 
> thread of the process now.

See? Thread is what you get via CLONE_THREAD.

> So it's technically not even wrong to 
> explicitly allow things like /proc/*/exe to see it as such.

This knowledge is some implementation detail, how AIO is implemented and
how kernel threads access userpace VM. But you're going to expose it
by not checking for kernel-threadness or something.

> But you can hide it by just checking some flag in the thread structure if 
> you really want to.
> 
> But when creating a regular thread, you should _not_ need to take a 
> spinlock and duplicate the executable path!

Since task_struct is literally copied during clone, _that_ line,
can be easily changed to just

	path_get(&p->exec_path);

But for consistency and to not give bad example it was written
with honest locking.