[PATCH] PCI: Put the IVRS table in AMD ACS quirk handler

[PATCH] PCI: Put the IVRS table in AMD ACS quirk handler

[Hanjun Guo]

The acpi_get_table() should be coupled with acpi_put_table() if
the mapped table is not used at runtime to release the table
mapping.

In pci_quirk_amd_sb_acs(), IVRS table is just used for checking
AMD IOMMU is supported, not used at runtime, put the table after
using it.

Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
---
 drivers/pci/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 812bfc3..487ed4d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4409,6 +4409,8 @@ static int pci_quirk_amd_sb_acs(struct pci_dev *dev, u16 acs_flags)
 	if (ACPI_FAILURE(status))
 		return -ENODEV;
 
+	acpi_put_table(header);
+
 	/* Filter out flags not applicable to multifunction */
 	acs_flags &= (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_EC | PCI_ACS_DT);
 
-- 
1.7.12.4

Re: [PATCH] PCI: Put the IVRS table in AMD ACS quirk handler

[Bjorn Helgaas]

[+cc Alex, Don]

On Wed, Jul 22, 2020 at 05:44:28PM +0800, Hanjun Guo wrote:
> The acpi_get_table() should be coupled with acpi_put_table() if
> the mapped table is not used at runtime to release the table
> mapping.
> 
> In pci_quirk_amd_sb_acs(), IVRS table is just used for checking
> AMD IOMMU is supported, not used at runtime, put the table after
> using it.
> 
> Signed-off-by: Hanjun Guo <guohanjun@huawei.com>

Applied to pci/virtualization for v5.9, thanks!

I added this:

  Fixes: 15b100dfd1c9 ("PCI: Claim ACS support for AMD southbridge devices")

but I didn't add a stable tag.  Does this cause any issue that would
warrant a stable tag?

> ---
>  drivers/pci/quirks.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 812bfc3..487ed4d 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -4409,6 +4409,8 @@ static int pci_quirk_amd_sb_acs(struct pci_dev *dev, u16 acs_flags)
>  	if (ACPI_FAILURE(status))
>  		return -ENODEV;
>  
> +	acpi_put_table(header);
> +
>  	/* Filter out flags not applicable to multifunction */
>  	acs_flags &= (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_EC | PCI_ACS_DT);
>  
> -- 
> 1.7.12.4
> 

Re: [PATCH] PCI: Put the IVRS table in AMD ACS quirk handler

[Hanjun Guo]

On 2020/7/30 7:02, Bjorn Helgaas wrote:
> [+cc Alex, Don]
> 
> On Wed, Jul 22, 2020 at 05:44:28PM +0800, Hanjun Guo wrote:
>> The acpi_get_table() should be coupled with acpi_put_table() if
>> the mapped table is not used at runtime to release the table
>> mapping.
>>
>> In pci_quirk_amd_sb_acs(), IVRS table is just used for checking
>> AMD IOMMU is supported, not used at runtime, put the table after
>> using it.
>>
>> Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
> 
> Applied to pci/virtualization for v5.9, thanks!
> 
> I added this:
> 
>    Fixes: 15b100dfd1c9 ("PCI: Claim ACS support for AMD southbridge devices")
> 
> but I didn't add a stable tag.  Does this cause any issue that would
> warrant a stable tag?

We don't have one when I was sending same function patch for ACPI
subsystem, so I think it's OK to without a stable tag for this
patch as well.

Thanks
Hanjun

Re: [PATCH] PCI: Put the IVRS table in AMD ACS quirk handler

[Don Dutile]

On 7/30/20 2:14 AM, Hanjun Guo wrote:
> On 2020/7/30 7:02, Bjorn Helgaas wrote:
>> [+cc Alex, Don]
>>
>> On Wed, Jul 22, 2020 at 05:44:28PM +0800, Hanjun Guo wrote:
>>> The acpi_get_table() should be coupled with acpi_put_table() if
>>> the mapped table is not used at runtime to release the table
>>> mapping.
>>>
>>> In pci_quirk_amd_sb_acs(), IVRS table is just used for checking
>>> AMD IOMMU is supported, not used at runtime, put the table after
>>> using it.
>>>
>>> Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
>>
>> Applied to pci/virtualization for v5.9, thanks!
>>
>> I added this:
>>
>>    Fixes: 15b100dfd1c9 ("PCI: Claim ACS support for AMD southbridge devices")
>>
>> but I didn't add a stable tag.  Does this cause any issue that would
>> warrant a stable tag?
>
For most of our (bug-fix & functional backport tooling) we focus on 'Fixes' and not
specific stable tagging, since our kernel becomes quite a mix of upstream once we venture much past the RHEL-X.0 GA.
I have seen others that use/reference the stable trees as another sanity check; or a way to
modify a RHEL kernel source into their own private use. Thus, RHEL doesn't have as strong a dependency on stable, as much as it does upstream-tip.

> We don't have one when I was sending same function patch for ACPI
> subsystem, so I think it's OK to without a stable tag for this
> patch as well.
>
> Thanks
> Hanjun
>