* [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
@ 2025-01-07 13:51 kingdix10
2025-01-07 22:56 ` Bjorn Helgaas
0 siblings, 1 reply; 9+ messages in thread
From: kingdix10 @ 2025-01-07 13:51 UTC (permalink / raw)
To: marek.vasut+renesas, yoshihiro.shimoda.uh, lpieralisi, kw,
manivannan.sadhasivam, robh, bhelgaas, prabhakar.csengg
Cc: linux-pci, linux-renesas-soc, linux-kernel, King Dix,
Lad Prabhakar
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.
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-07 13:51 [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region kingdix10
@ 2025-01-07 22:56 ` Bjorn Helgaas
2025-01-08 4:59 ` kingdix10
0 siblings, 1 reply; 9+ messages in thread
From: Bjorn Helgaas @ 2025-01-07 22:56 UTC (permalink / raw)
To: kingdix10
Cc: marek.vasut+renesas, yoshihiro.shimoda.uh, lpieralisi, kw,
manivannan.sadhasivam, robh, bhelgaas, prabhakar.csengg,
linux-pci, linux-renesas-soc, linux-kernel, Lad Prabhakar
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-07 22:56 ` Bjorn Helgaas
@ 2025-01-08 4:59 ` kingdix10
2025-01-08 10:45 ` Biju Das
0 siblings, 1 reply; 9+ messages in thread
From: kingdix10 @ 2025-01-08 4:59 UTC (permalink / raw)
To: helgaas
Cc: bhelgaas, kingdix10, kw, linux-kernel, linux-pci,
linux-renesas-soc, lpieralisi, manivannan.sadhasivam,
marek.vasut+renesas, prabhakar.csengg, prabhakar.mahadev-lad.rj,
robh, yoshihiro.shimoda.uh
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
> >
^ permalink raw reply [flat|nested] 9+ messages in thread* RE: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-08 4:59 ` kingdix10
@ 2025-01-08 10:45 ` Biju Das
2025-01-08 10:50 ` Lad, Prabhakar
0 siblings, 1 reply; 9+ messages in thread
From: Biju Das @ 2025-01-08 10:45 UTC (permalink / raw)
To: kingdix10@qq.com, helgaas@kernel.org
Cc: bhelgaas@google.com, kw@linux.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
lpieralisi@kernel.org, manivannan.sadhasivam@linaro.org,
marek.vasut+renesas@gmail.com, prabhakar.csengg@gmail.com,
Prabhakar Mahadev Lad, robh@kernel.org, Yoshihiro Shimoda
> -----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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-08 10:45 ` Biju Das
@ 2025-01-08 10:50 ` Lad, Prabhakar
2025-01-08 10:57 ` Biju Das
0 siblings, 1 reply; 9+ messages in thread
From: Lad, Prabhakar @ 2025-01-08 10:50 UTC (permalink / raw)
To: Biju Das
Cc: kingdix10@qq.com, helgaas@kernel.org, bhelgaas@google.com,
kw@linux.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
lpieralisi@kernel.org, manivannan.sadhasivam@linaro.org,
marek.vasut+renesas@gmail.com, Prabhakar Mahadev Lad,
robh@kernel.org, Yoshihiro Shimoda
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-08 10:50 ` Lad, Prabhakar
@ 2025-01-08 10:57 ` Biju Das
2025-01-08 11:09 ` Geert Uytterhoeven
0 siblings, 1 reply; 9+ messages in thread
From: Biju Das @ 2025-01-08 10:57 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: kingdix10@qq.com, helgaas@kernel.org, bhelgaas@google.com,
kw@linux.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
lpieralisi@kernel.org, manivannan.sadhasivam@linaro.org,
marek.vasut+renesas@gmail.com, Prabhakar Mahadev Lad,
robh@kernel.org, Yoshihiro Shimoda
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-08 10:57 ` Biju Das
@ 2025-01-08 11:09 ` Geert Uytterhoeven
2025-01-08 11:13 ` Biju Das
0 siblings, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2025-01-08 11:09 UTC (permalink / raw)
To: Biju Das
Cc: Lad, Prabhakar, kingdix10@qq.com, helgaas@kernel.org,
bhelgaas@google.com, kw@linux.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
lpieralisi@kernel.org, manivannan.sadhasivam@linaro.org,
marek.vasut+renesas@gmail.com, Prabhakar Mahadev Lad,
robh@kernel.org, Yoshihiro Shimoda
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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread* RE: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-08 11:09 ` Geert Uytterhoeven
@ 2025-01-08 11:13 ` Biju Das
2025-01-09 0:45 ` kingdix10
0 siblings, 1 reply; 9+ messages in thread
From: Biju Das @ 2025-01-08 11:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lad, Prabhakar, kingdix10@qq.com, helgaas@kernel.org,
bhelgaas@google.com, kw@linux.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
lpieralisi@kernel.org, manivannan.sadhasivam@linaro.org,
marek.vasut+renesas@gmail.com, Prabhakar Mahadev Lad,
robh@kernel.org, Yoshihiro Shimoda
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region
2025-01-08 11:13 ` Biju Das
@ 2025-01-09 0:45 ` kingdix10
0 siblings, 0 replies; 9+ messages in thread
From: kingdix10 @ 2025-01-09 0:45 UTC (permalink / raw)
To: biju.das.jz
Cc: bhelgaas, geert, helgaas, kingdix10, kw, linux-kernel, linux-pci,
linux-renesas-soc, lpieralisi, manivannan.sadhasivam,
marek.vasut+renesas, prabhakar.csengg, prabhakar.mahadev-lad.rj,
robh, yoshihiro.shimoda.uh
On Wed, 2025-01-08 at 11:13 +0000, Biju Das wrote:
> 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
Thank you all very much for the information and suggestions. I'll handle it right away.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-01-09 0:56 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-07 13:51 [PATCH v4] PCI: rcar-ep: Fix the issue of the name parameter when calling devm_request_mem_region kingdix10
2025-01-07 22:56 ` Bjorn Helgaas
2025-01-08 4:59 ` kingdix10
2025-01-08 10:45 ` Biju Das
2025-01-08 10:50 ` Lad, Prabhakar
2025-01-08 10:57 ` Biju Das
2025-01-08 11:09 ` Geert Uytterhoeven
2025-01-08 11:13 ` Biju Das
2025-01-09 0:45 ` kingdix10
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox