[lkml]   [2008]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: KVM overflows the stack
    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
    >> stack.
    >> 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
    > copies.
    > 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

     \ /
      Last update: 2008-07-17 16:17    [W:0.022 / U:8.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site