Ingo Molnar <[EMAIL PROTECTED]> writes: > * Linus Torvalds <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/