| Message ID | tencent_F1132FBA08580D482F6A1EF7605710E5F005@qq.com (mailing list archive) |
|---|---|
| State | Under Review |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | [v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region | expand |
On Tue, Jan 07, 2025 at 09:51:23PM +0800, kingdix10@qq.com wrote: > From: King Dix <kingdix10@qq.com> > > When using devm_request_mem_region to request a resource, if the passed > variable is a stack string variable, it will lead to an oops issue when > executing the command cat /proc/iomem. > > Fix this by replacing outbound_name with the name of the previously > requested resource. Thanks a lot for doing this work! Add "()" after function names in subject and commit log. Please include a couple lines of the oops message to help people connect the problem with the fix. I suppose you found this by tripping over it. Can you look through the other callers of devm_request_mem_region() and similar interfaces, at least in drivers/pci, and make sure there are no other similar errors? > Fixes: 2a6d0d63d999 ("PCI: rcar: Add endpoint mode support") > > Signed-off-by: King Dix <kingdix10@qq.com> > Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > --- > Changes in v4: > - Add more information to the comment. > Changes in v3: > - Fix the spelling issue in the comment. > Changes in v2: > - Fix the code indentation issue. > --- > drivers/pci/controller/pcie-rcar-ep.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/controller/pcie-rcar-ep.c b/drivers/pci/controller/pcie-rcar-ep.c > index 047e2cef5afc..c5e0d025bc43 100644 > --- a/drivers/pci/controller/pcie-rcar-ep.c > +++ b/drivers/pci/controller/pcie-rcar-ep.c > @@ -107,7 +107,7 @@ static int rcar_pcie_parse_outbound_ranges(struct rcar_pcie_endpoint *ep, > } > if (!devm_request_mem_region(&pdev->dev, res->start, > resource_size(res), > - outbound_name)) { > + res->name)) { > dev_err(pcie->dev, "Cannot request memory region %s.\n", > outbound_name); > return -EIO; > -- > 2.43.0 >
On Tue, 2025-01-07 at 16:56 -0600, Bjorn Helgaas wrote: > On Tue, Jan 07, 2025 at 09:51:23PM +0800, kingdix10@qq.com wrote: > > From: King Dix <kingdix10@qq.com> > > > > When using devm_request_mem_region to request a resource, if the > > passed > > variable is a stack string variable, it will lead to an oops issue > > when > > executing the command cat /proc/iomem. > > > > Fix this by replacing outbound_name with the name of the previously > > requested resource. > > Thanks a lot for doing this work! > > Add "()" after function names in subject and commit log. > Thanks for your review. I will fix the issue right now. > Please include a couple lines of the oops message to help people > connect the problem with the fix. > This is a potential issue that I found while analyzing the code. I don't have the conditions to reproduce this issue, but I can write a driver to reproduce this issue in QEMU and obtain logs for reference. > I suppose you found this by tripping over it. Can you look through > the other callers of devm_request_mem_region() and similar > interfaces, > at least in drivers/pci, and make sure there are no other similar > errors? > I've already checked that there are only a few calls of devm_request_mem_region() under the drivers/pci directory, and they are all correct. > > Fixes: 2a6d0d63d999 ("PCI: rcar: Add endpoint mode support") > > > > Signed-off-by: King Dix <kingdix10@qq.com> > > Reviewed-by: Lad Prabhakar > > <prabhakar.mahadev-lad.rj@bp.renesas.com> > > Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > --- > > Changes in v4: > > - Add more information to the comment. > > Changes in v3: > > - Fix the spelling issue in the comment. > > Changes in v2: > > - Fix the code indentation issue. > > --- > > drivers/pci/controller/pcie-rcar-ep.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/pci/controller/pcie-rcar-ep.c > > b/drivers/pci/controller/pcie-rcar-ep.c > > index 047e2cef5afc..c5e0d025bc43 100644 > > --- a/drivers/pci/controller/pcie-rcar-ep.c > > +++ b/drivers/pci/controller/pcie-rcar-ep.c > > @@ -107,7 +107,7 @@ static int > > rcar_pcie_parse_outbound_ranges(struct rcar_pcie_endpoint *ep, > > } > > if (!devm_request_mem_region(&pdev->dev, res->start, > > resource_size(res), > > - outbound_name)) { > > + res->name)) { > > dev_err(pcie->dev, "Cannot request memory region %s.\n", > > outbound_name); > > return -EIO; > > -- > > 2.43.0 > >
> -----Original Message----- > From: kingdix10@qq.com <kingdix10@qq.com> > Sent: 08 January 2025 04:59 > Subject: Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling > devm_request_mem_region > > On Tue, 2025-01-07 at 16:56 -0600, Bjorn Helgaas wrote: > > On Tue, Jan 07, 2025 at 09:51:23PM +0800, kingdix10@qq.com wrote: > > > From: King Dix <kingdix10@qq.com> > > > > > > When using devm_request_mem_region to request a resource, if the > > > passed variable is a stack string variable, it will lead to an oops > > > issue when executing the command cat /proc/iomem. > > > > > > Fix this by replacing outbound_name with the name of the previously > > > requested resource. > > > > Thanks a lot for doing this work! > > > > Add "()" after function names in subject and commit log. > > > > Thanks for your review. I will fix the issue right now. > > > Please include a couple lines of the oops message to help people > > connect the problem with the fix. Maybe Prabhakar should be able to provide Oops log, as it is tested on real platform?? > > > > Fixes: 2a6d0d63d999 ("PCI: rcar: Add endpoint mode support") > > > Signed-off-by: King Dix <kingdix10@qq.com> > > > Reviewed-by: Lad Prabhakar > > > <prabhakar.mahadev-lad.rj@bp.renesas.com> > > > Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Cheers, Biju
On Wed, Jan 8, 2025 at 10:45 AM Biju Das <biju.das.jz@bp.renesas.com> wrote: > > > > > -----Original Message----- > > From: kingdix10@qq.com <kingdix10@qq.com> > > Sent: 08 January 2025 04:59 > > Subject: Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling > > devm_request_mem_region > > > > On Tue, 2025-01-07 at 16:56 -0600, Bjorn Helgaas wrote: > > > On Tue, Jan 07, 2025 at 09:51:23PM +0800, kingdix10@qq.com wrote: > > > > From: King Dix <kingdix10@qq.com> > > > > > > > > When using devm_request_mem_region to request a resource, if the > > > > passed variable is a stack string variable, it will lead to an oops > > > > issue when executing the command cat /proc/iomem. > > > > > > > > Fix this by replacing outbound_name with the name of the previously > > > > requested resource. > > > > > > Thanks a lot for doing this work! > > > > > > Add "()" after function names in subject and commit log. > > > > > > > Thanks for your review. I will fix the issue right now. > > > > > Please include a couple lines of the oops message to help people > > > connect the problem with the fix. > > Maybe Prabhakar should be able to provide Oops log, as it is tested on real platform?? > It doesn't Oops out, it just prints a null string. Below are the logs from RZ/G2M: $ cat /proc/iomem 30000000-37ffffff : �� 38000000-3fffffff : �� 48000000-bfffffff : System RAM 48210000-496affff : Kernel code 496b0000-4987ffff : reserved 49880000-49a8ffff : Kernel data b9eca000-b9ed8fff : reserved ba000000-bfffffff : reserved e6020000-e602000b : e6020000.watchdog watchdog@e6020000 e6050000-e605004f : e6050000.gpio gpio@e6050000 e6051000-e605104f : e6051000.gpio gpio@e6051000 e6052000-e605204f : e6052000.gpio gpio@e6052000 e6053000-e605304f : e6053000.gpio gpio@e6053000 e6054000-e605404f : e6054000.gpio gpio@e6054000 e6055000-e605504f : e6055000.gpio gpio@e6055000 e6055400-e605544f : e6055400.gpio gpio@e6055400 e6055800-e605584f : e6055800.gpio gpio@e6055800 e6060000-e606050b : e6060000.pinctrl pinctrl@e6060000 e6198000-e61980ff : e6198000.thermal thermal@e6198000 e61a0000-e61a00ff : e6198000.thermal thermal@e6198000 e61a8000-e61a80ff : e6198000.thermal thermal@e6198000 e61c0000-e61c01ff : e61c0000.interrupt-controller interrupt-controller@e61c0000 e6510000-e651003f : e6510000.i2c i2c@e6510000 e6540000-e654005f : e6540000.serial e6590000-e65901ff : e6590000.usb usb@e6590000 e65a0000-e65a00ff : e65a0000.dma-controller dma-controller@e65a0000 e65b0000-e65b00ff : e65b0000.dma-controller dma-controller@e65b0000 e65ee000-e65ee08f : e65ee000.usb-phy usb-phy@e65ee000 e66d8000-e66d803f : e66d8000.i2c i2c@e66d8000 e6700000-e670ffff : e6700000.dma-controller dma-controller@e6700000 e6800000-e68007ff : e6800000.ethernet ethernet@e6800000 e6c30000-e6c30fff : e6c30000.can can@e6c30000 e6c38000-e6c38fff : e6c38000.can can@e6c38000 e6e30000-e6e30007 : e6e30000.pwm pwm@e6e30000 e6e88000-e6e8803f : e6e88000.serial e7300000-e730ffff : e7300000.dma-controller dma-controller@e7300000 e7310000-e731ffff : e7310000.dma-controller dma-controller@e7310000 ec500000-ec500fff : ec500000.sound scu ec540000-ec540fff : ec500000.sound ssiu ec541000-ec54127f : ec500000.sound ssi ec5a0000-ec5a00ff : ec500000.sound adg ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000 ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000 ec760000-ec7601ff : ec500000.sound audmapp ee020000-ee0203ff : ee020000.usb usb@ee020000 ee080000-ee0800ff : ee080000.usb usb@ee080000 ee080100-ee0801ff : ee080100.usb usb@ee080100 ee080200-ee0808ff : ee080200.usb-phy usb-phy@ee080200 ee0a0000-ee0a00ff : ee0a0000.usb usb@ee0a0000 ee0a0100-ee0a01ff : ee0a0100.usb usb@ee0a0100 ee0a0200-ee0a08ff : ee0a0200.usb-phy usb-phy@ee0a0200 ee100000-ee101fff : ee100000.mmc mmc@ee100000 ee140000-ee141fff : ee140000.mmc mmc@ee140000 ee160000-ee161fff : ee160000.mmc mmc@ee160000 fe000000-fe07ffff : fe000000.pcie-ep apb-base fe100000-fe1fffff : �� fe200000-fe3fffff : �� fe940000-fe9423ff : fe940000.fdp1 fdp1@fe940000 fe960000-fe967fff : fe960000.vsp vsp@fe960000 fe9a0000-fe9a7fff : fe9a0000.vsp vsp@fe9a0000 fea20000-fea24fff : fea20000.vsp vsp@fea20000 fea28000-fea2cfff : fea28000.vsp vsp@fea28000 fea30000-fea34fff : fea30000.vsp vsp@fea30000 fead0000-feadffff : fead0000.hdmi hdmi@fead0000 feb00000-feb6ffff : feb00000.display display@feb00000 600000000-67fffffff : System RAM 67b140000-67f5fffff : reserved 67f64d000-67f64dfff : reserved 67f64e000-67f6ddfff : reserved 67f6df000-67f6e2fff : reserved 67f6e3000-67f7e6fff : reserved 67f7e7000-67f843fff : reserved 67f844000-67fffffff : reserved With the patch applied: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 48000000-bfffffff : System RAM 48210000-496affff : Kernel code 496b0000-4987ffff : reserved 49880000-49a8ffff : Kernel data b9eca000-b9ed8fff : reserved ba000000-bfffffff : reserved e6020000-e602000b : e6020000.watchdog watchdog@e6020000 e6050000-e605004f : e6050000.gpio gpio@e6050000 e6051000-e605104f : e6051000.gpio gpio@e6051000 e6052000-e605204f : e6052000.gpio gpio@e6052000 e6053000-e605304f : e6053000.gpio gpio@e6053000 e6054000-e605404f : e6054000.gpio gpio@e6054000 e6055000-e605504f : e6055000.gpio gpio@e6055000 e6055400-e605544f : e6055400.gpio gpio@e6055400 e6055800-e605584f : e6055800.gpio gpio@e6055800 e6060000-e606050b : e6060000.pinctrl pinctrl@e6060000 e6198000-e61980ff : e6198000.thermal thermal@e6198000 e61a0000-e61a00ff : e6198000.thermal thermal@e6198000 e61a8000-e61a80ff : e6198000.thermal thermal@e6198000 e61c0000-e61c01ff : e61c0000.interrupt-controller interrupt-controller@e61c0000 e6510000-e651003f : e6510000.i2c i2c@e6510000 e6540000-e654005f : e6540000.serial e6590000-e65901ff : e6590000.usb usb@e6590000 e65a0000-e65a00ff : e65a0000.dma-controller dma-controller@e65a0000 e65b0000-e65b00ff : e65b0000.dma-controller dma-controller@e65b0000 e65ee000-e65ee08f : e65ee000.usb-phy usb-phy@e65ee000 e66d8000-e66d803f : e66d8000.i2c i2c@e66d8000 e6700000-e670ffff : e6700000.dma-controller dma-controller@e6700000 e6800000-e68007ff : e6800000.ethernet ethernet@e6800000 e6c30000-e6c30fff : e6c30000.can can@e6c30000 e6c38000-e6c38fff : e6c38000.can can@e6c38000 e6e30000-e6e30007 : e6e30000.pwm pwm@e6e30000 e6e88000-e6e8803f : e6e88000.serial e7300000-e730ffff : e7300000.dma-controller dma-controller@e7300000 e7310000-e731ffff : e7310000.dma-controller dma-controller@e7310000 ec500000-ec500fff : ec500000.sound scu ec540000-ec540fff : ec500000.sound ssiu ec541000-ec54127f : ec500000.sound ssi ec5a0000-ec5a00ff : ec500000.sound adg ec700000-ec70ffff : ec700000.dma-controller dma-controller@ec700000 ec720000-ec72ffff : ec720000.dma-controller dma-controller@ec720000 ec760000-ec7601ff : ec500000.sound audmapp ee020000-ee0203ff : ee020000.usb usb@ee020000 ee080000-ee0800ff : ee080000.usb usb@ee080000 ee080100-ee0801ff : ee080100.usb usb@ee080100 ee080200-ee0808ff : ee080200.usb-phy usb-phy@ee080200 ee0a0000-ee0a00ff : ee0a0000.usb usb@ee0a0000 ee0a0100-ee0a01ff : ee0a0100.usb usb@ee0a0100 ee0a0200-ee0a08ff : ee0a0200.usb-phy usb-phy@ee0a0200 ee100000-ee101fff : ee100000.mmc mmc@ee100000 ee140000-ee141fff : ee140000.mmc mmc@ee140000 ee160000-ee161fff : ee160000.mmc mmc@ee160000 fe000000-fe07ffff : fe000000.pcie-ep apb-base fe100000-fe1fffff : memory0 fe200000-fe3fffff : memory1 fe940000-fe9423ff : fe940000.fdp1 fdp1@fe940000 fe960000-fe967fff : fe960000.vsp vsp@fe960000 fe9a0000-fe9a7fff : fe9a0000.vsp vsp@fe9a0000 fea20000-fea24fff : fea20000.vsp vsp@fea20000 fea28000-fea2cfff : fea28000.vsp vsp@fea28000 fea30000-fea34fff : fea30000.vsp vsp@fea30000 fead0000-feadffff : fead0000.hdmi hdmi@fead0000 feb00000-feb6ffff : feb00000.display display@feb00000 600000000-67fffffff : System RAM 67b140000-67f5fffff : reserved 67f64d000-67f64dfff : reserved 67f64e000-67f6ddfff : reserved 67f6df000-67f6e2fff : reserved 67f6e3000-67f7e6fff : reserved 67f7e7000-67f843fff : reserved 67f844000-67fffffff : reserved Cheers, Prabhakar
Hi Prabhakar, > -----Original Message----- > From: Lad, Prabhakar <prabhakar.csengg@gmail.com> > Sent: 08 January 2025 10:51 > Subject: Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling > devm_request_mem_region > > On Wed, Jan 8, 2025 at 10:45 AM Biju Das <biju.das.jz@bp.renesas.com> wrote: > > > > > > > > > -----Original Message----- > > > From: kingdix10@qq.com <kingdix10@qq.com> > > > Sent: 08 January 2025 04:59 > > > Subject: Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name > > > parameter when calling devm_request_mem_region > > > > > > On Tue, 2025-01-07 at 16:56 -0600, Bjorn Helgaas wrote: > > > > On Tue, Jan 07, 2025 at 09:51:23PM +0800, kingdix10@qq.com wrote: > > > > > From: King Dix <kingdix10@qq.com> > > > > > > > > > > When using devm_request_mem_region to request a resource, if the > > > > > passed variable is a stack string variable, it will lead to an > > > > > oops issue when executing the command cat /proc/iomem. > > > > > > > > > > Fix this by replacing outbound_name with the name of the > > > > > previously requested resource. > > > > > > > > Thanks a lot for doing this work! > > > > > > > > Add "()" after function names in subject and commit log. > > > > > > > > > > Thanks for your review. I will fix the issue right now. > > > > > > > Please include a couple lines of the oops message to help people > > > > connect the problem with the fix. > > > > Maybe Prabhakar should be able to provide Oops log, as it is tested on real platform?? > > > It doesn't Oops out, it just prints a null string. Below are the logs from RZ/G2M: > > $ cat /proc/iomem > 30000000-37ffffff : > 38000000-3fffffff : > 48000000-bfffffff : System RAM > 48210000-496affff : Kernel code > 496b0000-4987ffff : reserved > 49880000-49a8ffff : Kernel data > b9eca000-b9ed8fff : reserved > ba000000-bfffffff : reserved > e6020000-e602000b : e6020000.watchdog watchdog@e6020000 e6050000-e605004f : e6050000.gpio > gpio@e6050000 e6051000-e605104f : e6051000.gpio gpio@e6051000 e6052000-e605204f : e6052000.gpio > gpio@e6052000 e6053000-e605304f : e6053000.gpio gpio@e6053000 e6054000-e605404f : e6054000.gpio > gpio@e6054000 e6055000-e605504f : e6055000.gpio gpio@e6055000 e6055400-e605544f : e6055400.gpio > gpio@e6055400 e6055800-e605584f : e6055800.gpio gpio@e6055800 e6060000-e606050b : e6060000.pinctrl > pinctrl@e6060000 e6198000-e61980ff : e6198000.thermal thermal@e6198000 e61a0000-e61a00ff : > e6198000.thermal thermal@e6198000 e61a8000-e61a80ff : e6198000.thermal thermal@e6198000 e61c0000- > e61c01ff : e61c0000.interrupt-controller interrupt-controller@e61c0000 e6510000-e651003f : > e6510000.i2c i2c@e6510000 e6540000-e654005f : e6540000.serial e6590000-e65901ff : e6590000.usb > usb@e6590000 e65a0000-e65a00ff : e65a0000.dma-controller dma-controller@e65a0000 e65b0000-e65b00ff : > e65b0000.dma-controller dma-controller@e65b0000 e65ee000-e65ee08f : e65ee000.usb-phy usb-phy@e65ee000 > e66d8000-e66d803f : e66d8000.i2c i2c@e66d8000 e6700000-e670ffff : e6700000.dma-controller dma- > controller@e6700000 e6800000-e68007ff : e6800000.ethernet ethernet@e6800000 e6c30000-e6c30fff : > e6c30000.can can@e6c30000 e6c38000-e6c38fff : e6c38000.can can@e6c38000 > e6e30000-e6e30007 : e6e30000.pwm pwm@e6e30000 e6e88000-e6e8803f : e6e88000.serial e7300000-e730ffff : > e7300000.dma-controller dma-controller@e7300000 e7310000-e731ffff : e7310000.dma-controller dma- > controller@e7310000 ec500000-ec500fff : ec500000.sound scu ec540000-ec540fff : ec500000.sound ssiu > ec541000-ec54127f : ec500000.sound ssi ec5a0000-ec5a00ff : ec500000.sound adg ec700000-ec70ffff : > ec700000.dma-controller dma-controller@ec700000 ec720000-ec72ffff : ec720000.dma-controller dma- > controller@ec720000 ec760000-ec7601ff : ec500000.sound audmapp ee020000-ee0203ff : ee020000.usb > usb@ee020000 ee080000-ee0800ff : ee080000.usb usb@ee080000 ee080100-ee0801ff : ee080100.usb > usb@ee080100 ee080200-ee0808ff : ee080200.usb-phy usb-phy@ee080200 ee0a0000-ee0a00ff : ee0a0000.usb > usb@ee0a0000 ee0a0100-ee0a01ff : ee0a0100.usb usb@ee0a0100 ee0a0200-ee0a08ff : ee0a0200.usb-phy usb- > phy@ee0a0200 ee100000-ee101fff : ee100000.mmc mmc@ee100000 ee140000-ee141fff : ee140000.mmc > mmc@ee140000 ee160000-ee161fff : ee160000.mmc mmc@ee160000 fe000000-fe07ffff : fe000000.pcie-ep apb- > base fe100000-fe1fffff : fe200000-fe3fffff : fe940000-fe9423ff : fe940000.fdp1 fdp1@fe940000 > fe960000-fe967fff : fe960000.vsp vsp@fe960000 fe9a0000-fe9a7fff : fe9a0000.vsp vsp@fe9a0000 fea20000- > fea24fff : fea20000.vsp vsp@fea20000 fea28000-fea2cfff : fea28000.vsp vsp@fea28000 fea30000-fea34fff : > fea30000.vsp vsp@fea30000 fead0000-feadffff : fead0000.hdmi hdmi@fead0000 feb00000-feb6ffff : > feb00000.display display@feb00000 600000000-67fffffff : System RAM > 67b140000-67f5fffff : reserved > 67f64d000-67f64dfff : reserved > 67f64e000-67f6ddfff : reserved > 67f6df000-67f6e2fff : reserved > 67f6e3000-67f7e6fff : reserved > 67f7e7000-67f843fff : reserved > 67f844000-67fffffff : reserved > > With the patch applied: > > $ cat /proc/iomem > 30000000-37ffffff : memory2 > 38000000-3fffffff : memory3 > 48000000-bfffffff : System RAM > 48210000-496affff : Kernel code > 496b0000-4987ffff : reserved > 49880000-49a8ffff : Kernel data > b9eca000-b9ed8fff : reserved > ba000000-bfffffff : reserved > e6020000-e602000b : e6020000.watchdog watchdog@e6020000 e6050000-e605004f : e6050000.gpio > gpio@e6050000 e6051000-e605104f : e6051000.gpio gpio@e6051000 e6052000-e605204f : e6052000.gpio > gpio@e6052000 e6053000-e605304f : e6053000.gpio gpio@e6053000 e6054000-e605404f : e6054000.gpio > gpio@e6054000 e6055000-e605504f : e6055000.gpio gpio@e6055000 e6055400-e605544f : e6055400.gpio > gpio@e6055400 e6055800-e605584f : e6055800.gpio gpio@e6055800 e6060000-e606050b : e6060000.pinctrl > pinctrl@e6060000 e6198000-e61980ff : e6198000.thermal thermal@e6198000 e61a0000-e61a00ff : > e6198000.thermal thermal@e6198000 e61a8000-e61a80ff : e6198000.thermal thermal@e6198000 e61c0000- > e61c01ff : e61c0000.interrupt-controller interrupt-controller@e61c0000 e6510000-e651003f : > e6510000.i2c i2c@e6510000 e6540000-e654005f : e6540000.serial e6590000-e65901ff : e6590000.usb > usb@e6590000 e65a0000-e65a00ff : e65a0000.dma-controller dma-controller@e65a0000 e65b0000-e65b00ff : > e65b0000.dma-controller dma-controller@e65b0000 e65ee000-e65ee08f : e65ee000.usb-phy usb-phy@e65ee000 > e66d8000-e66d803f : e66d8000.i2c i2c@e66d8000 e6700000-e670ffff : e6700000.dma-controller dma- > controller@e6700000 e6800000-e68007ff : e6800000.ethernet ethernet@e6800000 e6c30000-e6c30fff : > e6c30000.can can@e6c30000 e6c38000-e6c38fff : e6c38000.can can@e6c38000 > e6e30000-e6e30007 : e6e30000.pwm pwm@e6e30000 e6e88000-e6e8803f : e6e88000.serial e7300000-e730ffff : > e7300000.dma-controller dma-controller@e7300000 e7310000-e731ffff : e7310000.dma-controller dma- > controller@e7310000 ec500000-ec500fff : ec500000.sound scu ec540000-ec540fff : ec500000.sound ssiu > ec541000-ec54127f : ec500000.sound ssi ec5a0000-ec5a00ff : ec500000.sound adg ec700000-ec70ffff : > ec700000.dma-controller dma-controller@ec700000 ec720000-ec72ffff : ec720000.dma-controller dma- > controller@ec720000 ec760000-ec7601ff : ec500000.sound audmapp ee020000-ee0203ff : ee020000.usb > usb@ee020000 ee080000-ee0800ff : ee080000.usb usb@ee080000 ee080100-ee0801ff : ee080100.usb > usb@ee080100 ee080200-ee0808ff : ee080200.usb-phy usb-phy@ee080200 ee0a0000-ee0a00ff : ee0a0000.usb > usb@ee0a0000 ee0a0100-ee0a01ff : ee0a0100.usb usb@ee0a0100 ee0a0200-ee0a08ff : ee0a0200.usb-phy usb- > phy@ee0a0200 ee100000-ee101fff : ee100000.mmc mmc@ee100000 ee140000-ee141fff : ee140000.mmc > mmc@ee140000 ee160000-ee161fff : ee160000.mmc mmc@ee160000 fe000000-fe07ffff : fe000000.pcie-ep apb- > base fe100000-fe1fffff : memory0 fe200000-fe3fffff : memory1 fe940000-fe9423ff : fe940000.fdp1 > fdp1@fe940000 fe960000-fe967fff : fe960000.vsp vsp@fe960000 fe9a0000-fe9a7fff : fe9a0000.vsp > vsp@fe9a0000 fea20000-fea24fff : fea20000.vsp vsp@fea20000 fea28000-fea2cfff : fea28000.vsp > vsp@fea28000 fea30000-fea34fff : fea30000.vsp vsp@fea30000 fead0000-feadffff : fead0000.hdmi > hdmi@fead0000 feb00000-feb6ffff : feb00000.display display@feb00000 600000000-67fffffff : System RAM > 67b140000-67f5fffff : reserved > 67f64d000-67f64dfff : reserved > 67f64e000-67f6ddfff : reserved > 67f6df000-67f6e2fff : reserved > 67f6e3000-67f7e6fff : reserved > 67f7e7000-67f843fff : reserved > 67f844000-67fffffff : reserved Thanks for the logs. Cool, basically Before patch: fe000000-fe07ffff : fe000000.pcie-ep apb-base fe100000-fe1fffff : fe200000-fe3fffff : After applying the patch: fe000000-fe07ffff : fe000000.pcie-ep apb-base fe100000-fe1fffff : memory0 fe200000-fe3fffff : memory1 kingdix10@qq.com, maybe you need to update commit description referring oops. Cheers, Biju
Hi Biju, On Wed, Jan 8, 2025 at 11:57 AM Biju Das <biju.das.jz@bp.renesas.com> wrote: > > From: Lad, Prabhakar <prabhakar.csengg@gmail.com> > > On Wed, Jan 8, 2025 at 10:45 AM Biju Das <biju.das.jz@bp.renesas.com> wrote: > > > > From: kingdix10@qq.com <kingdix10@qq.com> > > > > Sent: 08 January 2025 04:59 > > > > Subject: Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name > > > > parameter when calling devm_request_mem_region > > > > > > > > On Tue, 2025-01-07 at 16:56 -0600, Bjorn Helgaas wrote: > > > > > On Tue, Jan 07, 2025 at 09:51:23PM +0800, kingdix10@qq.com wrote: > > > > > > From: King Dix <kingdix10@qq.com> > > > > > > > > > > > > When using devm_request_mem_region to request a resource, if the > > > > > > passed variable is a stack string variable, it will lead to an > > > > > > oops issue when executing the command cat /proc/iomem. > > > > > > > > > > > > Fix this by replacing outbound_name with the name of the > > > > > > previously requested resource. > > > > > > > > > > Thanks a lot for doing this work! > > > > > > > > > > Add "()" after function names in subject and commit log. > > > > > > > > > > > > > Thanks for your review. I will fix the issue right now. > > > > > > > > > Please include a couple lines of the oops message to help people > > > > > connect the problem with the fix. > > > > > > Maybe Prabhakar should be able to provide Oops log, as it is tested on real platform?? > > > > > It doesn't Oops out, it just prints a null string. Below are the logs from RZ/G2M: > > > > $ cat /proc/iomem > > 30000000-37ffffff : > > 38000000-3fffffff : Prabhakar's original email showed garbage here. Looks like your mailer removed it... > Before patch: > > fe000000-fe07ffff : fe000000.pcie-ep apb-base > fe100000-fe1fffff : > fe200000-fe3fffff : Same here. > After applying the patch: > fe000000-fe07ffff : fe000000.pcie-ep apb-base > fe100000-fe1fffff : memory0 > fe200000-fe3fffff : memory1 > > kingdix10@qq.com, maybe you need to update commit description referring oops. Depending on the data found in memory at the time of printing, the output will be different. I guess it might still crash in the (very unlikely) case that no NUL-terminator is found, and the string iterator will access unmapped memory above the stack. Gr{oetje,eeting}s, Geert
Hi Geert, > -----Original Message----- > From: Geert Uytterhoeven <geert@linux-m68k.org> > Sent: 08 January 2025 11:09 > Subject: Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling > devm_request_mem_region > > Hi Biju, > > On Wed, Jan 8, 2025 at 11:57 AM Biju Das <biju.das.jz@bp.renesas.com> wrote: > > > From: Lad, Prabhakar <prabhakar.csengg@gmail.com> On Wed, Jan 8, > > > 2025 at 10:45 AM Biju Das <biju.das.jz@bp.renesas.com> wrote: > > > > > From: kingdix10@qq.com <kingdix10@qq.com> > > > > > Sent: 08 January 2025 04:59 > > > > > Subject: Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the > > > > > name parameter when calling devm_request_mem_region > > > > > > > > > > On Tue, 2025-01-07 at 16:56 -0600, Bjorn Helgaas wrote: > > > > > > On Tue, Jan 07, 2025 at 09:51:23PM +0800, kingdix10@qq.com wrote: > > > > > > > From: King Dix <kingdix10@qq.com> > > > > > > > > > > > > > > When using devm_request_mem_region to request a resource, if > > > > > > > the passed variable is a stack string variable, it will lead > > > > > > > to an oops issue when executing the command cat /proc/iomem. > > > > > > > > > > > > > > Fix this by replacing outbound_name with the name of the > > > > > > > previously requested resource. > > > > > > > > > > > > Thanks a lot for doing this work! > > > > > > > > > > > > Add "()" after function names in subject and commit log. > > > > > > > > > > > > > > > > Thanks for your review. I will fix the issue right now. > > > > > > > > > > > Please include a couple lines of the oops message to help > > > > > > people connect the problem with the fix. > > > > > > > > Maybe Prabhakar should be able to provide Oops log, as it is tested on real platform?? > > > > > > > It doesn't Oops out, it just prints a null string. Below are the logs from RZ/G2M: > > > > > > $ cat /proc/iomem > > > 30000000-37ffffff : > > > 38000000-3fffffff : > > Prabhakar's original email showed garbage here. > Looks like your mailer removed it... Oops. My mailer removed junk chars. > > > Before patch: > > > > fe000000-fe07ffff : fe000000.pcie-ep apb-base fe100000-fe1fffff : > > fe200000-fe3fffff : > > Same here. > > > After applying the patch: > > fe000000-fe07ffff : fe000000.pcie-ep apb-base fe100000-fe1fffff : > > memory0 fe200000-fe3fffff : memory1 > > > > kingdix10@qq.com, maybe you need to update commit description referring oops. > > Depending on the data found in memory at the time of printing, the output will be different. I guess > it might still crash in the (very > unlikely) case that no NUL-terminator is found, and the string iterator will access unmapped memory > above the stack. I agree. Cheers, Biju
diff --git a/drivers/pci/controller/pcie-rcar-ep.c b/drivers/pci/controller/pcie-rcar-ep.c index 047e2cef5afc..c5e0d025bc43 100644 --- a/drivers/pci/controller/pcie-rcar-ep.c +++ b/drivers/pci/controller/pcie-rcar-ep.c @@ -107,7 +107,7 @@ static int rcar_pcie_parse_outbound_ranges(struct rcar_pcie_endpoint *ep, } if (!devm_request_mem_region(&pdev->dev, res->start, resource_size(res), - outbound_name)) { + res->name)) { dev_err(pcie->dev, "Cannot request memory region %s.\n", outbound_name); return -EIO;