Ingo Molnar <mingo@elte.hu> writes:

quoted text
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Fri, 2 Nov 2007, Dave Hansen wrote:
>> > 
>> > There are certainly more of these, but here is one In the futex 
>> > userspace address, we install the current pid's vnr into a userspace 
>> > address.
>> 
>> Now, realistically, why not just say "you can't use these things 
>> across namespaces"? Does anybody really care? After all, somebody who 
>> screws this up only screws himself, not anybody else.
>
> i see two main categories of problems:
>
> - one problem is that this condition is 'invisible'.
>
> - so via this we isolate an important category of syscalls from
>   cross-namespace use perhaps forever.

I had a chance to think about this a bit more, and realized that
the problem is that futexes don't appear to work on network
filesystems, even if the network filesystems provide coherent shared
memory.

It seems to me that we need to have a call that gets a unique token
for a process for each filesystem per filesystem for use in futexes
(especially robust futexes).  Say get_fs_task_id(const char *path);

On local filesystems this could just be the pid as we use today, but
for filesystems that can be accessed from contexts with potentially
overlapping pid values this could be something else.  It is an extra
syscall in the preparation path, but it should be hardly more
expensive the current getpid().

Once we have fixed the futex infrastructure to be able to handle
futexes on network filesystems, the pid namespace case will be trivial
to implement.

Eric




-
unsubscribe notice
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/