From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47052 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQPbW-0006er-7W for qemu-devel@nongnu.org; Wed, 08 Dec 2010 14:23:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQPbU-0000ft-GP for qemu-devel@nongnu.org; Wed, 08 Dec 2010 14:23:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQPbU-0000fZ-9b for qemu-devel@nongnu.org; Wed, 08 Dec 2010 14:23:04 -0500 Message-ID: <4CFFDB13.2010609@redhat.com> Date: Wed, 08 Dec 2010 20:22:59 +0100 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH v5 09/21] virtagent: add va.getdmesg RPC References: <1291399402-20366-1-git-send-email-mdroth@linux.vnet.ibm.com> <1291399402-20366-10-git-send-email-mdroth@linux.vnet.ibm.com> <4CFE4699.5070000@redhat.com> <4CFE6F94.7090208@linux.vnet.ibm.com> In-Reply-To: <4CFE6F94.7090208@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, abeekhof@redhat.com, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com On 12/07/10 18:32, Michael Roth wrote: > On 12/07/2010 08:37 AM, Jes Sorensen wrote: >> On 12/03/10 19:03, Michael Roth wrote: >>> +static xmlrpc_value *va_getdmesg(xmlrpc_env *env, >>> + xmlrpc_value *param, >>> + void *user_data) >>> +{ >>> + char *dmesg_buf = NULL, cmd[256]; >>> + int ret; >>> + xmlrpc_value *result = NULL; >>> + FILE *pipe; >>> + >>> + SLOG("va_getdmesg()"); >>> + >>> + dmesg_buf = qemu_mallocz(VA_DMESG_LEN + 2048); >>> + sprintf(cmd, "dmesg -s %d", VA_DMESG_LEN); >> >> What happens if the guest's dmesg buffer is larger than your hardcoded >> value? > > It'll end up getting truncated by the fread() later: > > ret = fread(dmesg_buf, sizeof(char), VA_DMESG_LEN, pipe); > > That's where the dmesg -s VA_DMESG_LEN comes into play, it should size > things such that we can buffer up till the end of the dmesg output. > > This param is kind of quirky though, size doesn't seem to have an affect > for anything below 4KB, but if we stick with VA_DMESG_LEN >= 4KB this > should cover us, unless it's a distro-specific. But it should blow > anything up, at least. I am wary of these hard coded constants. Isn't there a way to set the kernel's dmesg buffer size, or is that only a compile time option? Cheers, Jes