Re: KVM overflows the stack

From: Avi Kivity
Date: Thu Jul 17 2008 - 10:15:36 EST

Dave Hansen wrote:
On Wed, 2008-07-16 at 23:08 -0700, Roland Dreier wrote:
> Yes, things like kvm_lapic_state are way too big to be on the

I had a quick look at the code, and my worry about dynamic allocation
would be that handling allocation failure seems like it might get
tricky. Eg for handling struct kvm_pv_mmu_op_buffer (which is 528 bytes
on the stack in kvm_pv_mmu_op()) can you deal with an mmu op failing?

Well, you *better* be able to deal with it. :)

This code is also doing a *ton* of copy_to/from_user(). If userspace
had one of its input buffers swapped out (or one of its output buffers
not faulted in yet) and we're out of memory enough to be failing
kmallocs() then we're sure as heck also going to failing the user

I think it's a non-issue.

Yes, it's designed to be restartable. Returning 0 should be fine.

We can reduce the buffer size to 256 though. I wouldn't want an allocation in this hot path.

error compiling committee.c: too many arguments to function

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at