From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 0/2] Xen/mem_event: Do not rely on the toolstack being bug-free Date: Thu, 17 Jul 2014 23:42:50 +0100 Message-ID: <53C8516A.4090607@citrix.com> References: <1405602637-8321-1-git-send-email-andrew.cooper3@citrix.com> <97A500D504438F4ABC02EBA81613CC6331885B2C@xmb-aln-x02.cisco.com> <53C8317C.6020807@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4266330187996314046==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas Lengyel , Razvan Cojocaru Cc: Xen-devel , "Aravindh Puthiyaparambil (aravindp)" List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============4266330187996314046== Content-Type: multipart/alternative; boundary="------------080800070402060206050409" This is a multi-part message in MIME format. --------------080800070402060206050409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 17/07/2014 23:17, Tamas Lengyel wrote: > I've also tested the patch with LibVMI and everything works fine. The > pause/unpause reference count now does take effect, so the previous > issue I reported (a paused domain getting unpaused by > mem_event_enable) is fixed by this patch. > > One question I have, what if the toolstack wants to unconditionally > (force) unpause a domain? Right now with this patch if someone runs > 'xl pause domain' a couple times he has no other recourse then to > issue 'xl unpause domain' at least the same number of times, or to > restart the entire domain. Might be user-friendlier if there was an > override provided in case a domain got paused a million times by accident. > > Cheers, > Tamas I don't think that would be a good idea. The entire point of the proper refcounting is so bits of toolstack subsystems can guarentee that the domain stays paused during a critical set of operations. Providing a "DOMCTL_unpausedomain --force" would undermine the whole purpose of this. As already expressed, there are plenty of ways a buggy/dumb toolstack can shoot itself in the foot with regards to a domain. I include in this users with dom0 root access and `xl`. The two key points are that: 1) a buggy toolstack can't cause Xen perform an unintentional action (e.g. walking off the end of an array, as demonstrated in patch 1 of this series) and 2) several non-buggy parts of a toolstack can operate safely together with respect to a Xen resource. Any attempt to work around a buggy bit of a toolstack in Xen is effort better spent fixing the toolstack. ~Andrew --------------080800070402060206050409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 17/07/2014 23:17, Tamas Lengyel wrote:
I've also tested the patch with LibVMI and everything works fine. The pause/unpause reference count now does take effect, so the previous issue I reported (a paused domain getting unpaused by mem_event_enable) is fixed by this patch.

One question I have, what if the toolstack wants to unconditionally (force) unpause a domain? Right now with this patch if someone runs 'xl pause domain' a couple times he has no other recourse then to issue 'xl unpause domain' at least the same number of times, or to restart the entire domain. Might be user-friendlier if there was an override provided in case a domain got paused a million times by accident.

Cheers,
Tamas

I don't think that would be a good idea.  The entire point of the proper refcounting is so bits of toolstack subsystems can guarentee that the domain stays paused during a critical set of operations.  Providing a "DOMCTL_unpausedomain --force" would undermine the whole purpose of this.

As already expressed, there are plenty of ways a buggy/dumb toolstack can shoot itself in the foot with regards to a domain.  I include in this users with dom0 root access and `xl`.

The two key points are that:

1) a buggy toolstack can't cause Xen perform an unintentional action (e.g. walking off the end of an array, as demonstrated in patch 1 of this series) and
2) several non-buggy parts of a toolstack can operate safely together with respect to a Xen resource.

Any attempt to work around a buggy bit of a toolstack in Xen is effort better spent fixing the toolstack.

~Andrew
--------------080800070402060206050409-- --===============4266330187996314046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4266330187996314046==--