All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Don Slutz <dslutz@verizon.com>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [BUGFIX][PATCH 0/4] gdbsx: fix 3 bugs
Date: Mon, 6 Jan 2014 15:45:48 +0000	[thread overview]
Message-ID: <1389023148.31766.64.camel@kazak.uk.xensource.com> (raw)
In-Reply-To: <1388857936-664-1-git-send-email-dslutz@verizon.com>

On Sat, 2014-01-04 at 12:52 -0500, Don Slutz wrote:
> Release manager requests:
>   patch 1 should be in 4.4.0
>   patch 3 and 4 would be good to be in 4.4.0

(as acting RM in George's absence):

In all three cases what is missing is the "why" and the appropriate
analysis from
http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_code_freeze 
i.e. what is the impact of the bug (i..e what are the advantages of the
fix) and what are the risks of this changing causing further breakage?
I'm not really in a position to evaluate the risk of a change in gdbsx,
so someone needs to tell me.

I think given that gdbsx is a somewhat "peripheral" bit of code and that
it is targeted at developers (who might be better able to tolerate any
resulting issues and more able to apply subsequent fixups than regular
users) we can accept a larger risk than we would with a change to the
hypervisor itself etc (that's assuming that all of these changes cannot
potentially impact non-debugger usecases which I expect is the case from
the function names but I would like to see confirmed).

Apart from a release ack 4 of these would need an Ack from Mukesh IMHO.
TBH if he is happy with them then I see no reason not to give a release
ack as well.

>   patch 2 is optional.
> 
> While tracking down a bug in seabios/grub I found the bug in patch
> 1.
> 
> There are 2 ways that gfn will not be INVALID_GFN and yet mfn will
> be INVALID_MFN.
> 
>   1) p2m_is_readonly(gfntype) and writing memory.
>   2) the requested vaddr does not exist.
> 
> This may only be an issue for a HVM guest that is in real mode
> (I.E. no page tables).
> 
> Patch 2 is debug logging that was used to find the 2nd way.
> 
> Patch 3 and 4 are more of a cleanup bug fix.
> 
> Don Slutz (4):
>   dbg_rw_guest_mem: need to call put_gfn in error path.
>   dbg_rw_guest_mem: Enable debug log output
>   xg_read_mem: Report on error.
>   XEN_DOMCTL_gdbsx_guestmemio: always do the copyback.
> 
>  tools/debugger/gdbsx/xg/xg_main.c |  6 ++++--
>  xen/arch/x86/debug.c              | 44 ++++++++++++++++++++++++++++++---------
>  xen/arch/x86/domctl.c             |  3 +--
>  3 files changed, 39 insertions(+), 14 deletions(-)
> 

  parent reply	other threads:[~2014-01-06 15:45 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-04 17:52 [BUGFIX][PATCH 0/4] gdbsx: fix 3 bugs Don Slutz
2014-01-04 17:52 ` [BUGFIX][PATCH 1/4] dbg_rw_guest_mem: need to call put_gfn in error path Don Slutz
2014-01-05 23:09   ` Andrew Cooper
2014-01-06 12:43     ` Don Slutz
2014-01-06 13:13       ` Andrew Cooper
2014-01-06 19:50         ` Don Slutz
2014-01-07  0:41           ` Mukesh Rathor
2014-01-04 17:52 ` [PATCH 2/4] dbg_rw_guest_mem: Enable debug log output Don Slutz
2014-01-04 21:13   ` Konrad Rzeszutek Wilk
2014-01-04 21:24     ` Don Slutz
2014-01-05 18:29       ` Konrad Rzeszutek Wilk
2014-01-06 15:28       ` Ian Campbell
2014-01-06 16:41         ` Don Slutz
2014-01-06 16:44           ` Ian Campbell
2014-01-06 16:49             ` Don Slutz
2014-01-07  1:04   ` Mukesh Rathor
2014-01-04 17:52 ` [BUGFIX][PATCH 3/4] xg_read_mem: Report on error Don Slutz
2014-01-07  0:50   ` Mukesh Rathor
2014-01-04 17:52 ` [BUGFIX][PATCH 4/4] XEN_DOMCTL_gdbsx_guestmemio: always do the copyback Don Slutz
2014-01-05 23:35   ` Andrew Cooper
2014-01-06 15:43     ` Ian Campbell
2014-01-07  1:53   ` Mukesh Rathor
2014-01-07 10:00     ` Ian Campbell
2014-01-07 10:02       ` Ian Campbell
2014-01-07 16:24         ` Don Slutz
2014-01-07 23:01           ` Mukesh Rathor
2014-01-08  1:02             ` Don Slutz
2014-01-08  2:33               ` Mukesh Rathor
2014-01-07 16:26       ` Don Slutz
2014-01-07 23:10         ` Mukesh Rathor
2014-01-07 23:05       ` Mukesh Rathor
2014-01-06 15:45 ` Ian Campbell [this message]
2014-01-07  0:53   ` [BUGFIX][PATCH 0/4] gdbsx: fix 3 bugs Mukesh Rathor

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=1389023148.31766.64.camel@kazak.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=dslutz@verizon.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.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.