All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: cns3xxx: pci: avoid potential stack overflow
Date: Wed, 7 Oct 2015 22:01:49 +0200	[thread overview]
Message-ID: <201510072201.51697.arnd@arndb.de> (raw)
In-Reply-To: <m3fv6i8qnh.fsf@t19.piap.pl>

On Wednesday 27 May 2015, Krzysztof Ha?asa wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > The cns3xxx_pcie_hw_init function uses excessive kernel
> > stack space because of a hack that puts a fake struct
> > pci_sys_data and struct pci_bus on the stack in order to
> > call the generic pci_bus_read_config accessors, which causes
> > a warning in ARM allmodconfig builds:
> >
> > arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes
> >
> > This rewrites the code in question to use a private
> > implementation of the config space access for the same
> > purpose, getting rid of the local variables and the
> > warning in the process. As part of this, we have to
> > use an open-coded version of pci_bus_find_capability(),
> > which unfortunately complicates the implementation.
> 
> Wouldn't it be better to simply use static structs for this purpose?
> The hack isn't pretty, though.

Hi Krzysztof,

sorry for the late reply. I sent the patch shortly before my
parental leave and have only now picked up this work again.

I've looked at the driver once more and have come up with
a modified approach that should hopefully address all the
concerns.

> > +	regs = cnspci->cfg0_regs + (PCI_DEVFN(1, 0) << 12);
> > +
> 
> Some comment about would be helpful. Such as this:
> 
> 
> > -	bus.number = 1; /* directly connected PCIe device */
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Agreed. I think I've managed to get rid of this part completely though.

> > +	pos = cns3xxx_pci_raw_read_config(regs, PCI_CAPABILITY_LIST, 1);
> > +	while (cns3xxx_pci_raw_read_config(regs, pos, 1) != PCI_CAP_ID_EXP)
> > +		pos = cns3xxx_pci_raw_read_config(regs, pos + PCI_CAP_LIST_NEXT, 1);
> > +
> 
> I wonder if this can fail (i.e., no PCI_CAP_ID_EXP capability).

This is now gone too, so we no longer have to worry about it. I
was mistakingly assuming that these were registers inside of the SoC
rather than in the device that gets attached.

> > +	dc = cns3xxx_pci_raw_read_config(regs, pos + PCI_EXP_DEVCTL, 2);
> > +	dc &= ~(0x3 << 12);	/* Clear Device Control Register [14:12] */
> > +	cns3xxx_pci_raw_write_config(regs, pos + PCI_EXP_DEVCTL, 2, dc);
> > +	dc = cns3xxx_pci_raw_read_config(regs, pos + PCI_EXP_DEVCTL, 2);
> > +	if (!(dc & (0x3 << 12)))
> > +		pr_info("PCIe: Set Device Max_Read_Request_Size to 128 byte\n");
> > +
> 
> This seems to revert 367dc4b75f4349d5363bc3ebdc030939db944786. Why do
> you want to do it?

My mistake. Gone too now.

Thanks for your careful review back then!

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Krzysztof Hałasa" <khalasa@piap.pl>
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: cns3xxx: pci: avoid potential stack overflow
Date: Wed, 7 Oct 2015 22:01:49 +0200	[thread overview]
Message-ID: <201510072201.51697.arnd@arndb.de> (raw)
In-Reply-To: <m3fv6i8qnh.fsf@t19.piap.pl>

On Wednesday 27 May 2015, Krzysztof Hałasa wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > The cns3xxx_pcie_hw_init function uses excessive kernel
> > stack space because of a hack that puts a fake struct
> > pci_sys_data and struct pci_bus on the stack in order to
> > call the generic pci_bus_read_config accessors, which causes
> > a warning in ARM allmodconfig builds:
> >
> > arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes
> >
> > This rewrites the code in question to use a private
> > implementation of the config space access for the same
> > purpose, getting rid of the local variables and the
> > warning in the process. As part of this, we have to
> > use an open-coded version of pci_bus_find_capability(),
> > which unfortunately complicates the implementation.
> 
> Wouldn't it be better to simply use static structs for this purpose?
> The hack isn't pretty, though.

Hi Krzysztof,

sorry for the late reply. I sent the patch shortly before my
parental leave and have only now picked up this work again.

I've looked at the driver once more and have come up with
a modified approach that should hopefully address all the
concerns.

> > +	regs = cnspci->cfg0_regs + (PCI_DEVFN(1, 0) << 12);
> > +
> 
> Some comment about would be helpful. Such as this:
> 
> 
> > -	bus.number = 1; /* directly connected PCIe device */
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Agreed. I think I've managed to get rid of this part completely though.

> > +	pos = cns3xxx_pci_raw_read_config(regs, PCI_CAPABILITY_LIST, 1);
> > +	while (cns3xxx_pci_raw_read_config(regs, pos, 1) != PCI_CAP_ID_EXP)
> > +		pos = cns3xxx_pci_raw_read_config(regs, pos + PCI_CAP_LIST_NEXT, 1);
> > +
> 
> I wonder if this can fail (i.e., no PCI_CAP_ID_EXP capability).

This is now gone too, so we no longer have to worry about it. I
was mistakingly assuming that these were registers inside of the SoC
rather than in the device that gets attached.

> > +	dc = cns3xxx_pci_raw_read_config(regs, pos + PCI_EXP_DEVCTL, 2);
> > +	dc &= ~(0x3 << 12);	/* Clear Device Control Register [14:12] */
> > +	cns3xxx_pci_raw_write_config(regs, pos + PCI_EXP_DEVCTL, 2, dc);
> > +	dc = cns3xxx_pci_raw_read_config(regs, pos + PCI_EXP_DEVCTL, 2);
> > +	if (!(dc & (0x3 << 12)))
> > +		pr_info("PCIe: Set Device Max_Read_Request_Size to 128 byte\n");
> > +
> 
> This seems to revert 367dc4b75f4349d5363bc3ebdc030939db944786. Why do
> you want to do it?

My mistake. Gone too now.

Thanks for your careful review back then!

	Arnd

  reply	other threads:[~2015-10-07 20:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 15:14 [PATCH] ARM: cns3xxx: pci: avoid potential stack overflow Arnd Bergmann
2015-05-19 15:14 ` Arnd Bergmann
2015-05-27  6:45 ` Krzysztof Hałasa
2015-05-27  6:45   ` Krzysztof Hałasa
2015-10-07 20:01   ` Arnd Bergmann [this message]
2015-10-07 20:01     ` Arnd Bergmann
2015-10-07 20:05     ` [PATCH v2] " Arnd Bergmann
2015-10-07 20:05       ` Arnd Bergmann
2015-10-08 10:03       ` Krzysztof Hałasa
2015-10-08 10:03         ` Krzysztof Hałasa
2015-10-08 14:38         ` Arnd Bergmann
2015-10-08 14:38           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201510072201.51697.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.