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

Re: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Wed, 25 Jun 2025 07:16:35 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=50UXk7v/g9AC4US9wrzKl3fIkcen8nYuLvGMZhtnf5M=; b=VxzTUTY9OBqCEJlAeSK765g2tR5ayqSDADzLDR8opqZQ3OJirDcg72kclWoB+CxLL6YijaZXOhJRpfTIIldEEkBMyEaHuF8Xcah/qR3MjvhydU1YlRtq0YBE8gq3HdDlsaFkAB90jIXymQhvsgirxReqWo5TzpB/4+LtLr/Ty/qSfqGuK3aQa8TUmQ3Dkit8MZy8lDv7Jf0N8C2f90lyiP9RqRa537Z/trYINoU7EYIATq1JEDqKuKt68q9FiqbyxrXjtUjmD/CXnWhcWCoGDvUxEPGdTABpe6oCT9alSACtnBwkc5tR9FMq5nsnrmsGifODFTjsUTgttZ/LrCm24A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KGbjalnRBi203WN8q4mPFY9SD5pyVecyEx9Y0GZJeY9P3WFQVA2QJhLlI43FehqH+kWleWqaoM6jmKSRqYd6NiB2ldaqC9tdeYdsUroTRJ6bxtsHiBnMHqOm3PCBxGs1A7Mxgqkn6+wh/xt1H4w37Z/AK4dto2fNaaARNwp7Ya+mb6iNCINIVv34d3o+m4B+WOW0W+3htcgvS691RkCZ83bDTSgB5kPjZReofn2fr6bnbu++A4po354yMo09VC4ap+MUKWFtScs4kN8V7gikhVbGLrmGS5AO4gFIKDI1IbIBmDezAk+QNlS/SwhzGO4LvA4Gg5AnjLGZAcmre3wcMA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Wed, 25 Jun 2025 07:16:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb23yeMT8YFCMR3kaLDqQP1+DTK7QJCD4AgAme+gD//4QlAIAB4iSA
  • Thread-topic: [PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails

On 2025/6/24 18:17, Jan Beulich wrote:
> On 24.06.2025 11:49, Chen, Jiqian wrote:
>> On 2025/6/18 22:45, Jan Beulich wrote:
>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>> --- a/xen/drivers/vpci/msi.c
>>>> +++ b/xen/drivers/vpci/msi.c
>>>> @@ -193,6 +193,33 @@ static void cf_check mask_write(
>>>>      msi->mask = val;
>>>>  }
>>>>  
>>>> +static int cf_check cleanup_msi(struct pci_dev *pdev)
>>>> +{
>>>> +    int rc;
>>>> +    unsigned int end, size;
>>>> +    struct vpci *vpci = pdev->vpci;
>>>> +    const unsigned int msi_pos = pdev->msi_pos;
>>>> +    const unsigned int ctrl = msi_control_reg(msi_pos);
>>>> +
>>>> +    if ( !msi_pos || !vpci->msi )
>>>> +        return 0;
>>>> +
>>>> +    if ( vpci->msi->masking )
>>>> +        end = msi_pending_bits_reg(msi_pos, vpci->msi->address64);
>>>> +    else
>>>> +        end = msi_mask_bits_reg(msi_pos, vpci->msi->address64) - 2;
>>>> +
>>>> +    size = end - ctrl;
>>>> +
>>>> +    rc = vpci_remove_registers(vpci, ctrl, size);
>>>> +    if ( rc )
>>>> +        return rc;
>>>
>>> This is a difficult one: It's not a good idea to simply return here, yet
>>> at the same time the handling of the register we're unable to remove may
>>> still require e.g. ...
>>>
>>>> +    XFREE(vpci->msi);
>>>
>>> ... this. There may therefore be more work required, such that in the
>>> end we're able to ...
>>>
>>>> +    return vpci_add_register(pdev->vpci, vpci_hw_read16, NULL, ctrl, 2, 
>>>> NULL);
>>>
>>> ... try this at least on a best effort basis.
>>>
>>> More generally: I don't think failure here (or in other .cleanup hook
>>> functions) may go entirely silently.
>> Does below meet your modification expectations?
> 
> Not sure, sorry. By "more" I really meant "more" (which may just be code
> auditing, results of which would need writing down, but which may also
> involve further code changes; see below).
> 
>>     rc = vpci_remove_registers(vpci, ctrl, size);
>>     if ( rc )
>>         printk(XENLOG_ERR "%pd %pp: remove msi handlers fail rc=%d\n",
>>                pdev->domain, &pdev->sbdf, rc);
>>
>>     XFREE(vpci->msi);
> 
> As I tried to indicate in my earlier reply, the freeing of this struct is
> safe only if the failure above would not leave any register handlers in
> place which still (without appropriate checking) use this struct.
Hmm, but all handlers added in init_msi() use this struct.
So it doesn't exist the case that when above unable to remove all handlers and 
still require xfree this struct.

> 
>>     /*
>>      * The driver may not traverse the capability list and think device
>>      * supports MSI by default. So here let the control register of MSI
>>      * be Read-Only is to ensure MSI disabled.
>>      */
>>     rc = vpci_add_register(vpci, vpci_hw_read16, NULL, ctrl, 2, NULL);
> 
> You're losing the earlier error here, if there was one. If this one
> succeeds, ...
But if return the earlier error to the caller, this device will be unusable, 
then still adding this handler when above failing to remove handlers is useless.

> 
>>     if ( rc )
>>         printk(XENLOG_ERR "%pd %pp: add dummy msi ctrl handler fail rc=%d\n",
>>                pdev->domain, &pdev->sbdf, rc);
>>
>>     return rc;
> 
> ... the caller would (wrongly) get success back.
> 
> Jan

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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