kvm-userland mm count skew
PATCH 1/1 kvm-userland mm count skew
I still can't see how it could be possibly make a difference for the mm_count if the kvm module is compiled inside the kernel or as an external module, the reference counting there hasn't changed since ages. The mmdrop fires only in the first overflow so even if I'm right it probably wasn't much destabilizing to go negative given it happened at mm destruction time.
kernel/hack-module.awk +0 -2
@@ -33,8 +33,6 @@ vmx_load_host_state = 0 } -/atomic_inc\(&kvm->mm->mm_count\);/ { $0 = "//" $0 } - /^\t\.fault = / { fcn = gensub(/,/, "", "g", $3) $0 = "\t.VMA_OPS_FAULT(fault) = VMA_OPS_FAULT_FUNC(" fcn "),"
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Andrea Arcangeli
I still can't see how it could be possibly make a difference for the
mm_countif the kvm module is compiled inside the kernel or as an external module, the reference counting there hasn't changed since ages. The mmdrop fires only in the first overflow so even if I'm right it probably wasn't much destabilizing to go negative given it happened at mm destruction time.
It's this bit:
Quoted 8 lines
/*
__mmdrop()is not exported before 2.6.25 */
#include <linux/sched.h>#if
LINUX_VERSION_CODE<KERNEL_VERSION(2,6,25)#define mmdrop(x) do { (void)(x); } while (0)
#endif
Signature · 7 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): 4795F26E.9090807-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 11 lines · Avi Kivity
Quoted 8 lines · Andrea Arcangeli
I still can't see how it could be possibly make a difference for the
mm_countif the kvm module is compiled inside the kernel or as an external module, the reference counting there hasn't changed since ages. The mmdrop fires only in the first overflow so even if I'm right it probably wasn't much destabilizing to go negative given it happened at mm destruction time.It's this bit:
Ok. But the atomic_inc removal isn't conditional to < 2.6.25, so it still doesn't look good to me. it would look better if we would unconditionally define mmdrop to nop in the external module compile. The other problem is that I don't see why atomic_inc/mmdrop are needed at all if the external module is safe, so why don't we drop them? In ->release->kvm_destroy_vm it seems the kvm->mm is never used anyway.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · Andrea Arcangeli
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Andrea Arcangeli
I still can't see how it could be possibly make a difference for the
mm_countif the kvm module is compiled inside the kernel or as an external module, the reference counting there hasn't changed since ages. The mmdrop fires only in the first overflow so even if I'm right it probably wasn't much destabilizing to go negative given it happened at mm destruction time.
Quoted 5 lines
Quoted 2 lines
It's this bit:
Ok. But the
atomic_incremoval isn't conditional to < 2.6.25, so it still doesn't look good to me.
Right. Not hurting in practice since 2.6.25 has yet to be released, but it needs fixing.
Quoted 7 lines
it would look better if we would
unconditionally define mmdrop to nop in the external module compile. The other problem is that I don't see why atomic_inc/mmdrop are needed at all if the external module is safe, so why don't we drop them? In ->release->kvm_destroy_vm it seems thekvm->mmis never used anyway.
The external module isn't safe, it just works in practice.
The meaning of hvas and ->mmap_sem (and mmu notifiers) is dependent on ->mm, so we must be sure that kvm doesn't get called with the wrong mm. Switching to a syscall based API would also cure this, but it's a lot more work.
Signature · 7 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/