[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: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 8 Apr 2022 14:04:56 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=yH5xe4LQ4xyMXtmT0Qwo490/x3HABlNRcuLEch+8eoI=; b=mWBLVmwUUQuzqQMx/0T4y2FooGbxCfYqx3ck2bjnwiiSsV44CYfAFUDTH5K+9QZzdBWhyquCunsX9jL1WTuVn7fWHMxLBLI5jJ9K8NeBWvBip8XTU2bEd5n+O7wd0LCXx2lY7qO33yByUBVwq5n02+TUHuov1NHPr1RMjN0KQNuSYnCRN5MyDMOKt1ILLRNcNM2ZpcLeZ9espOaOt3y8/+Ak9Ay432snmibVt2LfA/X/ePXOlRSaPzcmALeNqZEE7FazR3nrL4jqJWiVx/EGhzK1QrRKcA7BnP9YRf2hDFBIntfADomHNNhQRGf647IJRoa2WM7w7K81UWWJuia8kg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hCjejnPeU0SX3ejVPBQ0b82WZA9oMnb801FHwneWDl0NtSpiDV8PtVTsSJDdsrdRFK0i9yTy5VXucpurIbrlutDdLznPI8hiLhRypbuVsuqOeAKL9/SMW/8s4Y45BQ1g0a6cL+QqfKWonK6RQpiN1lJk7EiCu4KTxI2dPGxksoPJfxr8fTj6LI4eAPv1agw/KWfinpe2Hj4Im3XsbRA9PColpG2P7nXt7x0KcNXKX8z/kQmGE/dfPuyKuic/DoOmyNt8XkkElGjLXcFyP6hag/sxm/twRt4xD5My2ZVrBlEChbyXQER1eX2O0vhW6aX72079yzasIJorad30ebaHyg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jason Andryuk <jandryuk@xxxxxxxxx>
  • Delivery-date: Fri, 08 Apr 2022 12:05:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.04.2022 13:10, Roger Pau Monné wrote:
> 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...

Which extra space are you referring to? The only candidate I can spot
are the two adjacent spaces in the comment, between the two sentences.
But that's several lines up. And I think we have examples of both
single and double spaces in the code base for such cases. I know I'm
not even consistent myself in this regard - the longer a comment gets,
the more likely I am to use two spaces between sentences.

> 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?

This would be nice, but when I looked at this long ago it didn't seem
straightforward to achieve.

Jan




 


Rackspace

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