Re: kvm PCI assignment VFIO ramblings
On 08/26/2011 12:24 PM, Roedel, Joerg wrote: As I see it there are two options: (a) make subsequent accesses from userspace or the guest result in either a SIGBUS that userspace must either deal with or die, or (b) replace the mapping with a dummy RO mapping containing 0xff, with any trapped writes emulated as nops. The biggest problem with this approach is that it has to happen in the context of the given process. Linux can't really modify an mm which which belong to another context in a safe way. Is use_mm() insufficient? -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment VFIO ramblings
On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote: On 08/26/2011 12:24 PM, Roedel, Joerg wrote: The biggest problem with this approach is that it has to happen in the context of the given process. Linux can't really modify an mm which which belong to another context in a safe way. Is use_mm() insufficient? Yes, it introduces a set of race conditions when a process that already has an mm wants to take over another processes mm temporarily (and when use_mm is modified to actually provide this functionality). It is only save when used from kernel-thread context. One example: Process A Process B Process C . . . . -- takes A-mm . . and assignes as B-mm . . . -- Wants to take . . B-mm, but gets A-mm now This can't be secured by a lock, because it introduces potential A-B--B-A lock problem when two processes try to take each others mm. It could probably be solved by a task-real_mm pointer, havn't thought about this yet... Joerg ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment VFIO ramblings
On 08/28/2011 04:56 PM, Joerg Roedel wrote: On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote: On 08/26/2011 12:24 PM, Roedel, Joerg wrote: The biggest problem with this approach is that it has to happen in the context of the given process. Linux can't really modify an mm which which belong to another context in a safe way. Is use_mm() insufficient? Yes, it introduces a set of race conditions when a process that already has an mm wants to take over another processes mm temporarily (and when use_mm is modified to actually provide this functionality). It is only save when used from kernel-thread context. One example: Process A Process B Process C . . . . -- takes A-mm . . and assignes as B-mm. . . -- Wants to take . . B-mm, but gets A-mm now Good catch. This can't be secured by a lock, because it introduces potential A-B--B-A lock problem when two processes try to take each others mm. It could probably be solved by a task-real_mm pointer, havn't thought about this yet... Or a workqueue - you get a kernel thread context with a bit of boilerplate. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure in Linus' tree
Hi Linus, After merging the fixes tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/built-in.o: In function `.sys_call_table': (.text+0xbd00): undefined reference to `.sys_nfsservctl' arch/powerpc/kernel/built-in.o: In function `.sys_call_table': (.text+0xbd08): undefined reference to `.compat_sys_nfsservctl' Caused by commit f5b940997397 (All Arch: remove linkage for sys_nfsservctl system call) which also missed parisc. I will apply this patch for today: From: Stephen Rothwell s...@canb.auug.org.au Date: Mon, 29 Aug 2011 10:38:57 +1000 Subject: [PATCH] remove remaining references to nfsservctl These were missed in commit f5b940997397 All Arch: remove linkage for sys_nfsservctl system call due to them having no sys_ prefix (presumably). Cc: NeilBrown ne...@suse.de Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-par...@vger.kernel.org Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/parisc/kernel/syscall_table.S |2 +- arch/powerpc/include/asm/systbl.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/parisc/kernel/syscall_table.S b/arch/parisc/kernel/syscall_table.S index e66366f..3735abd 100644 --- a/arch/parisc/kernel/syscall_table.S +++ b/arch/parisc/kernel/syscall_table.S @@ -259,7 +259,7 @@ ENTRY_SAME(ni_syscall) /* query_module */ ENTRY_SAME(poll) /* structs contain pointers and an in_addr... */ - ENTRY_COMP(nfsservctl) + ENTRY_SAME(ni_syscall) /* was nfsservctl */ ENTRY_SAME(setresgid) /* 170 */ ENTRY_SAME(getresgid) ENTRY_SAME(prctl) diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h index f6736b7..fa0d27a 100644 --- a/arch/powerpc/include/asm/systbl.h +++ b/arch/powerpc/include/asm/systbl.h @@ -171,7 +171,7 @@ SYSCALL_SPU(setresuid) SYSCALL_SPU(getresuid) SYSCALL(ni_syscall) SYSCALL_SPU(poll) -COMPAT_SYS(nfsservctl) +SYSCALL(ni_syscall) SYSCALL_SPU(setresgid) SYSCALL_SPU(getresgid) COMPAT_SYS_SPU(prctl) -- 1.7.5.4 -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
