[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: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 8 Apr 2022 17:34:43 +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=DJN07v4BYiGlw6dV5abG68LwUphAwtTST69GxUOUivU=; b=Ae6+uuVs81LHAYtXCFSTcYah2h0pXyIxXzSgieg95eVA2ipJY9Jb8ATGOrw9jgabPSqfst5GRgDKgNOzmk4o3cOP2wJWMyVIeSPpsBap5NvqhQJXrgyg7TxERX6djP9h3tKbpw5/kWvzPaeg/yp/fZjnsz2DhL/YQtMAheS+tBTE9F7jnHvmk+rqIQwvLx8WN/EgtS87bogPTkzUz8XV5CJUlNy8bZzHa7xK5LM02g6OvWba+L8G8HCpS/Nvh6iOoO7CAAQVEHomBv8zSs73lBnzp1X0mXwABPhBrEuvlVwgrZmbcEYaOXTfqG5RtRsMjo5tEeNSkziwibDhbR0mCw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mX9c/KEYwZSzgf1i2UI5t9w+XlF0tnKsPhZTD0wDaOo6zXrwKE8CiXcvQ3Y0GHp71HUI9XdFIakCaqe4MaXD8/kUbg6zZJ03+I6byznGHrHe2hdZ6bcu4PCISWC1IIhM/be51R61oPmOu91Ig+1WAbGwnoERHLp6a2+jdcLZxzkZaNCL6nd7XVxp77noTwQ/dXOYp7f3GBCmdVN79RFlfsOAmLODY9O2eTF8Q6rrIRw7tiJPOQYcyIB0zf5hdFWWdr8u/pR8TA/DBmoiNtMwE7ducKo6N1IC8RXurvnQpJYJR4rS01LbjYX5BM2YoeWYmTq7JBrauCu2cpwxy0lvPQ==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jason Andryuk <jandryuk@xxxxxxxxx>
  • Delivery-date: Fri, 08 Apr 2022 15:35:01 +0000
  • Ironport-data: A9a23:OEf6qaBeeyMqShVW/wnjw5YqxClBgxIJ4kV8jS/XYbTApDkr0zYFy TNKCmCGa/rYamb0eY1yaoS3oRwC6JLXnYRnQQY4rX1jcSlH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMZiaA4E/raNANlFEkvU2ybuOU5NXsZ2YgHWeIdA970Ug5w7Jh0tYy6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPg28 tNNq8yAbDwsN4nFpqMDaRYJSStxaPguFL/veRBTsOSWxkzCNXDt3+9vHAc9OohwFuRfWD8Us 6ZCcXZUM07F17neLLGTE4GAguw5K8bmJsUHs2xIxjDFF/c2B5vERs0m4PcGjGxh250STJ4yY eI+awBsUj7/PyZhK1AUDokclqSswSnGJmgwRFW9+vNsvjm7IBZK+KfpGMrYfJqNX8o9tkSRo G7c7nn6Kh4fPd2bjzGC9xqEhOXCgCf6U4I6D6Cj+7hhh1j77nweDlgaWEW2pdG9i1WiQJRPJ koM4C0soKMuskuxQbHAswaQ+SDe+ERGApwJTrN8uFrlJrfoDxixQVICTiARWPkdscYSTAJty GWGzonjCmk62FGKck61+rCRpDK0HCEaK24eeCMJJTc4D8nfTJIb1UyWEIs6eEKhppisQGyrn WjWxMQrr+9L5fPnwZlX6rwub9iEgpHSBjA46QzMNo5OxlMoPdX1D2BEBLWy0BqhEGp7ZgTZ1 JTns5LHhAzrMX1rvHbQKAnqNOv0j8tpyBWG3TZS82AJrlxBAUKLc4FK+y1ZL0x0KMsCcjKBS BaN5VILtMIObCT1NPYfj2eN5yICl/WI+TPNDK68UzazSsIpKF/vEN9GOyZ8IFwBYGBzyPpia P93gO6nDGoACLQP8dZFb7x17FPf/QhnnTm7bcmil3yPiOPCDFbIGeZtGAbfNYgRsfLbyDg5B v4CbqNmPT0EC7agCsQWmKZORW03wY8TWcit+5MKLLbaSuekcUl4Y8LsLXoaU9UNt4xel/vS/ 2H7XUldyVHlgmbAJxnMYXdmAI4Dl74lxZ7nFUTA5WqV5kU=
  • Ironport-hdrordr: A9a23:74TVz6jakMSrw3xU5ltHr3Unn3BQXzh13DAbv31ZSRFFG/FwyP rAoB1L73PJYWgqNU3I+ergBEGBKUmskqKdxbNhR4tKOzOWxVdATbsSlrcKpgePJ8SQzJ8+6U 4NSdkaNDS0NykHsS+Y2njILz9D+qj/zEnAv463pB0MPGJXguNbnn9E426gYzNLrWJ9dPwE/f Snl656T23KQwVpUi33PAhMY8Hz4/nw0L72ax8PABAqrCGIkDOT8bb/VzyVxA0XXT9jyaortT GtqX2y2oyT99WAjjPM3W7a6Jpb3PPn19t4HcSJzuwYMC/lhAqEbJloH5eCoDc2iuey70tCqq iGnz4Qe+BIr1/BdGC8phXgnyHmzTYV8nfnjWSVhHPyyPaJMw4SOo5kv8Z0YxHZ400vsJVXy6 RQxV+UsJJREFfpgDn9z8KgbWAkqmOE5V4Z1cIDhX1WVoUTLJVLq5YEwU9TGJAcWArn9YEcFv V0Bs203ocbTbqjVQGZgoBT+q3tYpxqdS32AXTq+/blngS+pUoJgXfxn6ck7zU9HJFUcegx2w 2LCNUsqFh0dL5kUUtMPpZwfSKJMB2+ffvtChPlHb21LtBPB5ryw6SHlYndotvaPKA18A==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Apr 08, 2022 at 02:04:56PM +0200, Jan Beulich wrote:
> 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...

Er, sorry, s/space/newline/.

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

Right, I don't doubt it.

Thanks, Roger.



 


Rackspace

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