Message ID | 20230516051659.22194-1-xyzeng@stu.xidian.edu.cn (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | PCI: dwc: keystone: Free IRQ in `ks_pcie_remove` and the error handling section of `ks_pcie_probe` | expand |
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. > "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. > Fixes: 0790eb175ee0 ("PCI: keystone: Cleanup error_irq configuration") > Signed-off-by: Xiangyi Zeng <xyzeng@stu.xidian.edu.cn> > Reviewed-by: Dongliang Mu <dzm91@hust.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. > @@ -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(). > 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 >
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@stu.xidian.edu.cn> >> Reviewed-by: Dongliang Mu <dzm91@hust.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 >>
On Mon, May 22, 2023 at 02:07:10PM +0800, 曾祥翼 wrote: > On 17/5/2023 03:49, Bjorn Helgaas wrote: > > On Tue, May 16, 2023 at 01:16:59PM +0800, Xiangyi Zeng wrote: > > ... > > > Fixes: 0790eb175ee0 ("PCI: keystone: Cleanup error_irq configuration") > > > Signed-off-by: Xiangyi Zeng <xyzeng@stu.xidian.edu.cn> > > > Reviewed-by: Dongliang Mu <dzm91@hust.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. It's great that Dongliang has already reviewed it; I'm not suggesting you omit any of that internal review. My point is that it's best if Dongliang's email review appears on linux-pci in addition to whatever internal email list you use. The hust-os-kernel-patches Google Group is not archived and searchable the same way linux-pci@vger.kernel.org is on https://lore.kernel.org/linux-pci/. Bjorn
Heh. Presumably you sent this by mistake. (Xiangyi Zeng sent a completely different version to the HUST list a few moments ago). regards, dan carpenter
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c index 78818853af9e..f321bc2e8026 100644 --- a/drivers/pci/controller/dwc/pci-keystone.c +++ b/drivers/pci/controller/dwc/pci-keystone.c @@ -1179,12 +1179,16 @@ static int __init ks_pcie_probe(struct platform_device *pdev) num_lanes = 1; phy = devm_kzalloc(dev, sizeof(*phy) * num_lanes, GFP_KERNEL); - if (!phy) - return -ENOMEM; + if (!phy) { + ret = -ENOMEM; + goto err_alloc; + } link = devm_kzalloc(dev, sizeof(*link) * num_lanes, GFP_KERNEL); - if (!link) - return -ENOMEM; + if (!link) { + ret = -ENOMEM; + goto err_alloc; + } for (i = 0; i < num_lanes; i++) { snprintf(name, sizeof(name), "pcie-phy%d", i); @@ -1300,6 +1304,9 @@ static int __init ks_pcie_probe(struct platform_device *pdev) while (--i >= 0 && link[i]) device_link_del(link[i]); +err_alloc: + free_irq(irq, ks_pcie); + return ret; } @@ -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); 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; }