All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: -EINTR return in domain_relinquish_resources
Date: Thu, 22 Jan 2015 11:37:41 -0500	[thread overview]
Message-ID: <20150122163741.GA32691@l.oracle.com> (raw)
In-Reply-To: <54C02EC1.3080600@citrix.com>

On Wed, Jan 21, 2015 at 10:57:05PM +0000, Andrew Cooper wrote:
> On 21/01/2015 21:39, Andrew Cooper wrote:
> > On 21/01/2015 21:27, Konrad Rzeszutek Wilk wrote:
> >> As I was looking at some of the XSA I realized that the
> >> call-chain of:
> >>
> >>  domain_relinquish_resources
> >>    ->vcpu_destroy_pagetables
> >>      -> put_page_and_type_preemptible
> >>         -> __put_page_type
> >> 		returns -EINTR
> >>
> >> which means we end up at:
> >>  618         rc = domain_relinquish_resources(d);                                    
> >>  619         if ( rc != 0 )                                                          
> >>  620         {                                                                       
> >>  621             if ( rc == -ERESTART )                                              
> >>  622                 rc = -EAGAIN;                                                   
> >>  623             break;             <=== with rc=-EINTR
> >>  624         }                                         
> >>
> >> And return -EINTR to user-space - which loop in 
> >> 'xc_domain_destroy' is only looking for:
> >>
> >>  112 int xc_domain_destroy(xc_interface *xch,                                        
> >>  113                       uint32_t domid)                                           
> >>  114 {                                                                               
> >>  115     int ret;                                                                    
> >>  116     DECLARE_DOMCTL;                                                             
> >>  117     domctl.cmd = XEN_DOMCTL_destroydomain;                                      
> >>  118     domctl.domain = (domid_t)domid;                                             
> >>  119     do {                                                                        
> >>  120         ret = do_domctl(xch, &domctl);                                          
> >>  121     } while ( ret && (errno == EAGAIN) );                                       
> >>  122     return ret;                                                                 
> >>  123 }                                
> >>
> >> which to my reading looks like we would exit out and leave
> >> an DOMDYING_dying domain. Looking at the code it seems possible
> >> to continue on if the user does 'xl destroy <X>' guest again,
> >> but I was wondering if:
> >>
> >>  a). Should the toolstack (libxl or libxc) have the code to
> >>      handle -EINTR?
> >>
> >>  b). Or should the hypervisor convert the -EINTR to -ERESTART
> >>      (or -EAGAIN) - which most of the code (see users of
> >>      get_page_type_preemptible) do right now?
> > Good spot.
> >
> > Other areas of similar code condense EINTR into ERESTART.  I think in
> > this case it is Xen's job to turn -EINTR into -EAGAIN as this hypercall
> > specifically has preemptibility  built into its normal use.
> >
> > I wonder if there are other similar hypercall paths which need to catch
> > EINTR as well as ERESTART?

I did not see them.
> >
> > ~Andrew
> 
> Thinking about this, it occurs to me that, along with parameter
> clobbering in debug builds, we should assert that internal error codes
> never escape to guests.

Are there any other ones besides ERESTART/EINTR ?
> 
> It also occurs to me that the PV hypercall paths would both be far more
> simple (particularly the register clobbering bits) if they were written
> in C like their HVM counterparts, rather than ASM.  I will see whether I
> can find some copious free time to see about making this happen.
> 
> ~Andrew

  reply	other threads:[~2015-01-22 16:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 21:27 -EINTR return in domain_relinquish_resources Konrad Rzeszutek Wilk
2015-01-21 21:39 ` Andrew Cooper
2015-01-21 22:57   ` Andrew Cooper
2015-01-22 16:37     ` Konrad Rzeszutek Wilk [this message]
2015-01-22 10:00 ` Jan Beulich
2015-01-22 16:38   ` Konrad Rzeszutek Wilk
2015-01-23  9:11     ` Jan Beulich
2015-01-23 14:32       ` Konrad Rzeszutek Wilk
2015-01-23 14:46         ` Andrew Cooper
2015-01-23 15:34           ` Jan Beulich
2015-01-23 15:46             ` Konrad Rzeszutek Wilk
2015-01-23 16:03               ` Jan Beulich
2015-01-23 17:21                 ` Konrad Rzeszutek Wilk
2015-01-26  9:36                   ` Jan Beulich

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=20150122163741.GA32691@l.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --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.