All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlo Marcelo Arenas Belon <carenas-kLeDWSohozoJb6fo7hG9ng@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
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	[thread overview]
Message-ID: <20071219153021.GA2981@tapir> (raw)
In-Reply-To: <4767F333.5010907-atKUWr5tajBWk0Htik3J/w@public.gmane.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

  parent reply	other threads:[~2007-12-19 15:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-14  6:58 [PATCH] libkvm: null pointer dereference in kvm_destroy_phys_mem Carlo Marcelo Arenas Belon
2007-12-18  8:37 ` [PATCH] [RESEND] libkvm: NULL pointer dereference in kvm_destroy_phys_mem as used in kvm-56 Carlo Marcelo Arenas Belon
2007-12-18 16:20   ` Avi Kivity
     [not found]     ` <4767F333.5010907-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-19 15:30       ` Carlo Marcelo Arenas Belon [this message]
2007-12-19 15:29         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071219153021.GA2981@tapir \
    --to=carenas-kledwsohozojb6fo7hg9ng@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.