linux-kernel - Re: [PATCH] PCI: dwc: keystone: Free IRQ in `ks_pcie_remove` and the error handling section of `ks_pcie

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 May 2023 14:07:10 +0800
From:   曾祥翼 <xyzeng@....xidian.edu.cn>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Rob Herring <robh@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Kishon Vijay Abraham I <kishon@...com>,
        hust-os-kernel-patches@...glegroups.com,
        Dongliang Mu <dzm91@...t.edu.cn>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: dwc: keystone: Free IRQ in `ks_pcie_remove` and the
 error handling section of `ks_pcie_probe`

On 17/5/2023 03:49, Bjorn Helgaas wrote:
> On Tue, May 16, 2023 at 01:16:59PM +0800, Xiangyi Zeng wrote:
>> Smatch complains that:
>> drivers/pci/controller/dwc/pci-keystone.c:1303 ks_pcie_probe() warn:
>> 'irq' from request_irq() not released on lines: 1183,1187,1303.
> Make this the entire warning line from smatch with no extra newlines
> inserted.
Thank you for the suggestion. I will put the warning in one line.
>> "ks-pcie-error-irq" was requested in the `ks_pcie_probe` function, but
>> was not freed neither in the error handling part of `ks_pcie_probe`
>> nor in the `ks_pcie_remove` function.
>>
>> Fix this by adding `free_irq` in `ks_pcie_remove` and in a new error
>> handling label `err_alloc` after `err_link` in `ks_pcie_probe`. In
>> `ks_pcie_probe`, if `phy` or `link` memory allocation fails, we will
>> fall to `err_alloc`. If any other error occurs that leads to
>> `err_get_sync` or `err_link`, we end up going to `err_alloc`.
> I think the backticks (`) are markdown that makes these "code".
> Personally I think ks_pcie_probe() is more readable than
> `ks_pcie_probe` since most people (I think) read these in plain-ASCII
> situations.  And using backticks for labels and local variables seems
> like overkill.
>
Sorry for my wrong usage of backticks. I agree that it would be more
readable to use plain-ASCII names for functions and variables. I will
make sure to update the comment message and the subject.
>> Fixes: 0790eb175ee0 ("PCI: keystone: Cleanup error_irq configuration")
>> Signed-off-by: Xiangyi Zeng <xyzeng@....xidian.edu.cn>
>> Reviewed-by: Dongliang Mu <dzm91@...t.edu.cn>
> It's best if the Reviewed-by tag is not added until Dongliang sends
> email with that tag directly to the mailing list.  Internal reviews
> before posting to the mailing list aren't worth much.
In our internal review process, only the patch with the Reviewed-by
tag can be submitted to the mailing list. You can check this in our
google group.
https://groups.google.com/g/hust-os-kernel-patches/c/bt397rzVL24/m/l52XYbG4AgAJ
We will consider omitting this tag when sending to the kernel mailing
list in the future.
>> @@ -1309,12 +1316,14 @@ static int __exit ks_pcie_remove(struct platform_device *pdev)
>>   	struct device_link **link = ks_pcie->link;
>>   	int num_lanes = ks_pcie->num_lanes;
>>   	struct device *dev = &pdev->dev;
>> +	int irq = platform_get_irq(pdev, 0);
> I think it's better to save the irq we looked up in ks_pcie_probe()
> and free *that*.  It's probably the same thing you get by calling
> platform_get_irq() again, but it seems cleaner to me to save what we
> got in ks_pcie_probe().
Thanks for your guidance. I agree with saving the irq to make code cleaner.
I will change it in the next version.
>>   	pm_runtime_put(dev);
>>   	pm_runtime_disable(dev);
>>   	ks_pcie_disable_phy(ks_pcie);
>>   	while (num_lanes--)
>>   		device_link_del(link[num_lanes]);
>> +	free_irq(irq, ks_pcie);
>>   
>>   	return 0;
>>   }
>> -- 
>> 2.34.1
>>