From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlo Marcelo Arenas Belon Subject: Re: [PATCH] [RESEND] libkvm: NULL pointer dereference in kvm_destroy_phys_mem as used in kvm-56 Date: Wed, 19 Dec 2007 09:30:21 -0600 Message-ID: <20071219153021.GA2981@tapir> References: <20071214065827.GA12031@tapir> <20071218083753.GA15987@tapir> <4767F333.5010907@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Avi Kivity Return-path: Content-Disposition: inline In-Reply-To: <4767F333.5010907-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Tue, Dec 18, 2007 at 06:20:03PM +0200, Avi Kivity wrote: > Carlo Marcelo Arenas Belon wrote: > > The following patch eliminates the uninitialized mem pointer, using > > instead the corresponding entry from the slots array to fix : > > > > libkvm.c:580: warning: 'mem' is used uninitialized in this function if this part of the patch is applied.. > > Also changes the formatting type for phys_addr to long to prevent : > > > > libkvm.c:581: warning: format '%llx' expects type 'long long unsigned int' > > , but argument 5 has type 'long unsigned int' this warning will be triggered in the next compile. > Applied, thanks. But please avoid unrelated changes in the same patch > in the future. sorry about that, will do, even if I disagree there were unrelated as explained above. so just to be clear on this?, would you rather have these changes in a patch series, or as unrelated patches with the second one fixing a formatting issue that the first one triggered? if the later, how to handle in that case the dependency so that they don't get applied in incorrect order triggering conflicts? I understand that the first part of it has higher importance than the second one, but I would rather have them applied together as they make IMHO more sense as an atomic change. Carlo ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace