[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] x86/irq: Skip unmap_domain_pirq XSM during destruction


  • To: Jason Andryuk <jandryuk@xxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 8 Apr 2022 13:10:42 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6zIGZihN9QrKO1Zv8VBfev9JOsAi53q1iOoPU3YLL7s=; b=ROChJNkLD8IJfbg/22JIHSe+Pvbc1Y2LalCfK+VYeH3gn37GfR/UUKtQ+ngLRx9pzOBHhr6QR8E7pfkRHjnxqO2vph7vTqUCXyCi9iWPjTJ5+NoiVC4lcmKnIG7pHSsGCbYzyAATNxnJ8nndP75sjUkU0Rz2MGsvsvovdLh2fEJoWhTa1XiimH9GvoHSpYzIcQsH6J0Uxfa8DcF/FJNi9rH+nyyZN3Cktw4pcxR2GHe8DV0Vybird2tMZAxDdwgb8uqybLx6bHCmH3oAbdfu4x2QbTWOi+dyGCncwNqI5HGkmN5W8NHI0z9oBhrh9m8Qnb2dxW8/ewKtmceuIGQRMg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VV6dmM6g+IAKv4NY9YEVJKmyNQzZS48dizzdx/2UDNQxAGVkThQPLNeMECgUC5DAEtAs63yqqQaOsJWEjOPfJVicaxsBaZb53bYJ0K+YIayoVeTfBm8ICuv1T1G+ql1Qb6gRJBvD3EFCvkV8uCexmUzAVMpOhOS8cpEWhlYSs1e8tODzFWR3XBVECJ48lW03IN4eu9/K6VSothVTiPKPaVygxGfCnZ+O5RTYRYD2TdBQqdbBdaCoZzS2w7paitzjlENNweY9RD30L263vj2fwMMc0LXWz/7D4B3vAAJh/gwfcp0rEDMBOIsfflavJHH5h8o1hzf8DvtWHW3vsvOW/Q==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Fri, 08 Apr 2022 11:11:00 +0000
  • Ironport-data: A9a23:/cA4ga9zpSqPt9qUZVYsDrUDoH6TJUtcMsCJ2f8bNWPcYEJGY0x3n zdNCmCPPf+La2OmLtBwOtu280xSvsWHx4A2HgBs+S88E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si+Fa+Sn9T8mvU2xbuKU5NTsY0idfic5DnZ54f5fs7Rh2NQw3YDpW1rlV e7a+KUzBnf0g1aYDUpMg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJ8DO+iL 9sv+Znilo/vE7XBPfv++lrzWhVirrc/pmFigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnbbtQwo1IIr0o+JHaDh6Aht1J4h9v4aSdBBTseTLp6HHW37lwvEoB0AqJ4wIvO1wBAmi9 9RBdmpLNErawbvrnvTrEYGAhex6RCXvFJkYtXx6iynQEN4tQIzZQrWM7thdtNs1rp4eR6qOP 5VBAdZpRDbORzpvJw82NL4vnr/ytEGhKzx69k3A8MLb5ECMlVcsgdABKuH9eNaHWMFUlUawv X/d8iLyBRRyHMOb4SqI9DSrnOCntSHyXo4IBaC73vFviVyXgGcUDXU+RVa95PW0lEO6c9ZeM FAPvDojq7Ao806mRcW7WAe3yENopTZFBYAWSbdjrljQlOyEuG51G1ToUBZrNdYrqNERfQcsj GSovcLTDiZKi/qsHCf1GqivkRu+Pi0cLGknbCACTBcY79SLnLzfni4jXf44Tvfr04Sd9SXYh mnT8XNg3+l7Ydsjjf3TwLzRv967SnElpCYR7x6fYG+q5xgRiGWNN93xsgizARqtwe+kori9U JosxpD2AAMmV8jleMmxrAMlRuzBCxGtamC0vLKXN8N9nwlBAlb6FWyq3BlwJV1yLuEPciLzb UnYtGt5vcEPbSH6MPInPN3oUqzGKJQM8/y/C5g4ifIUPPBMmPKvpnkyNSZ8IUiz+KTTrU3PE cjCKpv9ZZrrIa9m0CC3V48gPUwDnUgDKZfobcmjlXyPiOPGDFbMEOttGAbeP4gRsfLfyC2Io ok3Cid/40gGOAEISnKMqtB7wJFjBSVTOK0aXOQLLrXTfVc8QDhJ5j246epJRrGJVp99z4/g1 nq8RlVZ2Bz4g3jGIh+NcXdtdPXkWpMXkJ7xFXVE0YqAs5T7XbuS0Q==
  • Ironport-hdrordr: A9a23:6hRrTa+TAdDwwvXwUwtuk+E6db1zdoMgy1knxilNoENuHfBwxv rDoB1E73LJYVYqOU3Jmbi7Sc69qFfnhORICO4qTMqftWjdyRCVxeRZg7cKrAeQeREWmtQtsJ uINpIOdOEYbmIK/PoSgjPIaurIqePvmMvD5Za8854ud3ATV0gJ1XYGNu/xKDwReOApP+tcKH LKjfA32AZINE5nJviTNz0gZazuttfLnJXpbVovAAMm0hCHiXeN5KThGxaV8x8CW3cXqI1Su1 Ttokjc3OGOovu7whjT2yv66IlXosLozp9mCNaXgsYYBz3wgkKDZZhnWZeFoDcpydvfo2oCoZ 3pmVMNLs5z43TeciWcpgbs4RDp1HIU53rr2Taj8AzeiP28YAh/J9tKhIpffBecwVEnpstA3K VC2H/cn4ZLDDvb9R6NqOTgZlVPrA6ZsHAimekcgzh0So0FcoJcqoQZ4Qd8DIoAJiTn84oqed MeQP003MwmMG9yUkqp/lWGmLeXLzcO91a9MwU/U/WuonZrdCsT9Tpb+CQd9k1wgK7VBaM0ot gsCZ4Y542mfvVmHZ6VO91xM/dfKla9Ny4kY1jiaGgOKsk8SgfwQtjMkfEI2N0=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 07, 2022 at 10:51:50AM -0400, Jason Andryuk wrote:
> xsm_unmap_domain_irq was seen denying unmap_domain_pirq when called from
> complete_domain_destroy as an RCU callback.  The source context was an
> unexpected, random domain.  Since this is a xen-internal operation,
> going through the XSM hook is inapproriate.
> 
> Check d->is_dying and skip the XSM hook when set since this is a cleanup
> operation for a domain being destroyed.
> 
> Suggested-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Signed-off-by: Jason Andryuk <jandryuk@xxxxxxxxx>
> ---
> v2:
> Style fixes
> Rely on ret=0 initialization
> 
> ---
>  xen/arch/x86/irq.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
> index 285ac399fb..de30ee7779 100644
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2340,8 +2340,14 @@ int unmap_domain_pirq(struct domain *d, int pirq)
>          nr = msi_desc->msi.nvec;
>      }
>  
> -    ret = xsm_unmap_domain_irq(XSM_HOOK, d, irq,
> -                               msi_desc ? msi_desc->dev : NULL);
> +    /*
> +     * When called by complete_domain_destroy via RCU, current is a random
> +     * domain.  Skip the XSM check since this is a Xen-initiated action.
> +     */
> +    if ( !d->is_dying )
> +        ret = xsm_unmap_domain_irq(XSM_HOOK, d, irq,
> +                                   msi_desc ? msi_desc->dev : NULL);
> +

Nit: I would remove the extra space here, but that's a question of
taste...

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

I wonder if long term we could make this cleaner, maybe by moving the
unbind so it always happen in the context of the caller of the destroy
hypercall instead of in the RCU context?

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.