All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Juergen Gross" <jgross@suse.com>,
	"Kevin Tian" <kevin.tian@intel.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>, "Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Dario Faggioli" <dfaggioli@suse.com>,
	"Ross Lagerwall" <ross.lagerwall@citrix.com>,
	"Meng Xu" <mengxu@cis.upenn.edu>,
	"Jun Nakajima" <jun.nakajima@intel.com>,
	xen-devel@lists.xenproject.org,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/8] xen: don't let keyhandlers block indefinitely on locks
Date: Fri, 14 Feb 2020 10:37:18 +0100	[thread overview]
Message-ID: <479abfd7-8fc2-526d-ed72-033aadc96f7c@suse.com> (raw)
In-Reply-To: <1f5db5a6-e5c3-4d63-fdb4-e027d38bea18@citrix.com>

On 13.02.2020 19:38, Andrew Cooper wrote:
> On 13/02/2020 12:54, Juergen Gross wrote:
>> Keyhandlers dumping hypervisor information to the console often need
>> to take locks while accessing data. In order to not block in case of
>> system inconsistencies it is convenient to use trylock variants when
>> obtaining the locks. On the other hand a busy system might easily
>> encounter held locks, so this patch series is adding special trylock
>> variants with a timeout used by keyhandlers.
> 
> This is a backwards step.
> 
> Keyhandlers are for debugging purposes.  When debugging it is far more 
> important to get the requested data, than almost anything else.
> 
> The system will cope with a multi-second outage occurring approximately 
> never.  A person debugging who can't get the data has no chance of 
> fixing whatever problem they are looking for.
> 
> This series seems to be breaking the one critical usecase for 
> keyhandlers, to fix what - not let debugging get in the way of the 
> smooth running of the system?  A system in need of debugging in the 
> first place has bigger problems than needing to run smoothly.

I certainly accept what you say further up, but I don't think this
last statement is universally true. There may be a single guest in
trouble, which - to find out about its state - some debugging keys
may want issuing. Disturbing the host and all other guests for this
is not a good idea imo.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2020-02-14  9:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13 12:54 [Xen-devel] [PATCH 0/8] xen: don't let keyhandlers block indefinitely on locks Juergen Gross
2020-02-13 12:54 ` [Xen-devel] [PATCH 1/8] xen: make rangeset_printk() static Juergen Gross
2020-02-13 14:00   ` Jan Beulich
2020-02-13 12:54 ` [Xen-devel] [PATCH 2/8] xen: add using domlist_read_lock in keyhandlers Juergen Gross
2020-02-13 14:01   ` Jan Beulich
2020-02-13 14:09   ` George Dunlap
2020-02-18  5:42   ` Tian, Kevin
2020-02-13 12:54 ` [Xen-devel] [PATCH 3/8] xen/sched: don't use irqsave locks in dumping functions Juergen Gross
2020-02-19 12:40   ` Dario Faggioli
2020-02-19 14:27   ` Jan Beulich
2020-02-19 15:02     ` Jürgen Groß
2020-02-19 15:47       ` Dario Faggioli
2020-02-13 12:54 ` [Xen-devel] [PATCH 4/8] xen: add locks with timeouts for keyhandlers Juergen Gross
2020-03-05 15:25   ` Jan Beulich
2020-03-06  8:08     ` Jürgen Groß
2020-03-06  8:15       ` Jürgen Groß
2020-02-13 12:54 ` [Xen-devel] [PATCH 5/8] xen/sched: use keyhandler locks when dumping data to console Juergen Gross
2020-02-19 14:31   ` Dario Faggioli
2020-02-19 15:09     ` Jürgen Groß
2020-02-13 12:54 ` [Xen-devel] [PATCH 6/8] xen/common: " Juergen Gross
2020-02-13 12:54 ` [Xen-devel] [PATCH 7/8] xen/drivers: " Juergen Gross
2020-02-13 12:54 ` [Xen-devel] [PATCH 8/8] xen/x86: " Juergen Gross
2020-02-13 18:38 ` [Xen-devel] [PATCH 0/8] xen: don't let keyhandlers block indefinitely on locks Andrew Cooper
2020-02-14  6:05   ` Jürgen Groß
2020-02-14  9:37   ` Jan Beulich [this message]
2020-02-19 12:14     ` Julien Grall

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=479abfd7-8fc2-526d-ed72-033aadc96f7c@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dfaggioli@suse.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mengxu@cis.upenn.edu \
    --cc=roger.pau@citrix.com \
    --cc=ross.lagerwall@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.