From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM overflows the stack Date: Thu, 17 Jul 2008 17:15:23 +0300 Message-ID: <487F53FB.20708@qumranet.com> References: <1206479576.7562.21.camel@nimitz.home.sr71.net> <47EA1C63.8010202@qumranet.com> <1206550329.7883.5.camel@nimitz.home.sr71.net> <47EA80AC.4070204@qumranet.com> <1206551794.7883.7.camel@nimitz.home.sr71.net> <47EB6AAC.3040607@qumranet.com> <47EB7281.6070300@qumranet.com> <1206629709.7883.30.camel@nimitz.home.sr71.net> <47EBB63E.2060306@qumranet.com> <1212445810.8211.9.camel@nimitz.home.sr71.net> <48469BDA.3050206@qumranet.com> <1212738105.7837.3.camel@nimitz> <48512028.3070104@qumranet.com> <1216148242.25942.6.camel@nimitz> <1216244660.8711.6.camel@nimitz> <1216248527.11664.9.camel@nimitz> <487EDE26.8040201@qumranet.com> <1216303561.11664.52.camel@nimitz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roland Dreier , "linux-kernel@vger.kernel.org" , kvm-devel , "Anthony N. Liguori [imap]" To: Dave Hansen Return-path: Received: from il.qumranet.com ([212.179.150.194]:50037 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755043AbYGQOPY (ORCPT ); Thu, 17 Jul 2008 10:15:24 -0400 In-Reply-To: <1216303561.11664.52.camel@nimitz> Sender: kvm-owner@vger.kernel.org List-ID: 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