The pci-host-generic driver parses the linux,pci-probe-only property,
and assumes that it will have a boolean parameter.
Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
property, which leads to the driver dereferencing some unsuspecting
memory location. Nothing really bad happens (we end up reading some
other bit of DT, fortunately), but that not a reason to keep it this
way. Turns out that the Pseries code (where this code was lifted from)
may suffer from the same issue.
The first patch introduces a common (and fixed) version of that check
that can be used by drivers and architectures that require it. The two
following patches change the pci-host-generic driver and the powerpc
code to use it.
Finally, the bad property is removed from the Seatle DTS, because it
is simply not necessary (it actually prevents me from using SR-IOV,
which otherwise runs fine without the probe-only thing).
This has been tested on the offending Seattle board.
* From v1:
- Consolidate the parsing in of_pci.c (Bjorn)
Marc Zyngier (4):
of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
powerpc: PCI: Fix lookup of linux,pci-probe-only property
arm64: dts: Drop linux,pci-probe-only from the Seattle DTS
arch/arm64/boot/dts/amd/amd-overdrive.dts | 1 -
arch/powerpc/platforms/pseries/setup.c | 14 ++------------
drivers/of/of_pci.c | 30 ++++++++++++++++++++++++++++++
drivers/pci/host/pci-host-generic.c | 9 +--------
include/linux/of_pci.h | 3 +++
5 files changed, 36 insertions(+), 21 deletions(-)
--
2.1.4
Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
can be triggered if the property has no parameter.
Provide a generic implementation that can be used by both.
Signed-off-by: Marc Zyngier <[email protected]>
---
drivers/of/of_pci.c | 30 ++++++++++++++++++++++++++++++
include/linux/of_pci.h | 3 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..a4e29ff 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -118,6 +118,36 @@ int of_get_pci_domain_nr(struct device_node *node)
EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
/**
+ * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
+ * is present and valid
+ *
+ * @node: device tree node that may contain the property (usually "chosen")
+ *
+ */
+void of_pci_check_probe_only(struct device_node *node)
+{
+ const int *prop;
+ int len;
+
+ if (!node)
+ return;
+
+ prop = of_get_property(node, "linux,pci-probe-only", &len);
+ if (prop) {
+ if (!len) {
+ pr_warn("linux,pci-probe-only set without value, ignoring\n");
+ return;
+ }
+
+ if (be32_to_cpup(prop))
+ pci_add_flags(PCI_PROBE_ONLY);
+ else
+ pci_clear_flags(PCI_PROBE_ONLY);
+ }
+}
+EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
+
+/**
* of_pci_dma_configure - Setup DMA configuration
* @dev: ptr to pci_dev struct of the PCI device
*
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 29fd3fe..4c0a617 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,6 +17,7 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
int of_get_pci_domain_nr(struct device_node *node);
void of_pci_dma_configure(struct pci_dev *pci_dev);
+void of_pci_check_probe_only(struct device_node *node);
#else
static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
{
@@ -53,6 +54,8 @@ of_get_pci_domain_nr(struct device_node *node)
}
static inline void of_pci_dma_configure(struct pci_dev *pci_dev) { }
+
+static inline void of_pci_check_probe_only(struct device_node *node) { }
#endif
#if defined(CONFIG_OF_ADDRESS)
--
2.1.4
When pci-host-generic looks for the probe-only property, it seems
to trust the DT to be correctly written, and assumes that there
is a parameter to the property.
Unfortunately, this is not always the case, and some firmware expose
this property naked. The driver ends up making a decision based on
whatever the property pointer points to, which is likely to be junk.
Switch to the common of_pci.c implementation that doesn't suffer
from this problem.
Signed-off-by: Marc Zyngier <[email protected]>
---
drivers/pci/host/pci-host-generic.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index 265dd25..545ff4e 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
int err;
const char *type;
const struct of_device_id *of_id;
- const int *prop;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
@@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
return -EINVAL;
}
- prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
- if (prop) {
- if (*prop)
- pci_add_flags(PCI_PROBE_ONLY);
- else
- pci_clear_flags(PCI_PROBE_ONLY);
- }
+ of_pci_check_probe_only(of_chosen);
of_id = of_match_node(gen_pci_of_match, np);
pci->cfg.ops = of_id->data;
--
2.1.4
When find_and_init_phbs() looks for the probe-only property, it seems
to trust the firmware to be correctly written, and assumes that there
is a parameter to the property.
It is conceivable that the firmware could not be that perfect, and it
could expose this property naked (at least one arm64 platform seems to
exhibit this exact behaviour). The setup code the ends up making
a decision based on whatever the property pointer points to, which
is likely to be junk.
Instead, switch to the common of_pci.c implementation that doesn't
suffer from this problem and ignore the property if the firmware
couldn't make up its mind.
Signed-off-by: Marc Zyngier <[email protected]>
---
arch/powerpc/platforms/pseries/setup.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index df6a704..8434953 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -40,6 +40,7 @@
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/of.h>
+#include <linux/of_pci.h>
#include <linux/kexec.h>
#include <asm/mmu.h>
@@ -488,18 +489,7 @@ static void __init find_and_init_phbs(void)
* PCI_PROBE_ONLY and PCI_REASSIGN_ALL_BUS can be set via properties
* in chosen.
*/
- if (of_chosen) {
- const int *prop;
-
- prop = of_get_property(of_chosen,
- "linux,pci-probe-only", NULL);
- if (prop) {
- if (*prop)
- pci_add_flags(PCI_PROBE_ONLY);
- else
- pci_clear_flags(PCI_PROBE_ONLY);
- }
- }
+ of_pci_check_probe_only(of_chosen);
}
static void __init pSeries_setup_arch(void)
--
2.1.4
The linux,pci-probe-only property mandates an argument to indicate
whether or not to engage the "probe-only" mode, but the Seattle
DTS just provides a naked property, which is illegal.
Also, it turns out that the board is perfectly happy without
probe-only, so let's drop this altogether.
Signed-off-by: Marc Zyngier <[email protected]>
---
arch/arm64/boot/dts/amd/amd-overdrive.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amd/amd-overdrive.dts b/arch/arm64/boot/dts/amd/amd-overdrive.dts
index 564a3f7..128fa94 100644
--- a/arch/arm64/boot/dts/amd/amd-overdrive.dts
+++ b/arch/arm64/boot/dts/amd/amd-overdrive.dts
@@ -14,7 +14,6 @@
chosen {
stdout-path = &serial0;
- linux,pci-probe-only;
};
};
--
2.1.4
On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware expose
> this property naked. The driver ends up making a decision based on
> whatever the property pointer points to, which is likely to be junk.
>
> Switch to the common of_pci.c implementation that doesn't suffer
> from this problem.
>
> Signed-off-by: Marc Zyngier <[email protected]>
> ---
> drivers/pci/host/pci-host-generic.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
> index 265dd25..545ff4e 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
> int err;
> const char *type;
> const struct of_device_id *of_id;
> - const int *prop;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> @@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
> - if (prop) {
> - if (*prop)
> - pci_add_flags(PCI_PROBE_ONLY);
> - else
> - pci_clear_flags(PCI_PROBE_ONLY);
> - }
> + of_pci_check_probe_only(of_chosen);
Do we need support for pci-probe-only in pci-host-generic at all?
You're removing the use in amd-overdrive.dts, and there are no other
DTs in the kernel tree that mention it.
If we can live without it, that would be nice. It seems like a relic from
days when we couldn't reliably assign resources. (I'm not saying we can do
that reliably even today, but I'd rather make it reliable than turn it
off.)
> of_id = of_match_node(gen_pci_of_match, np);
> pci->cfg.ops = of_id->data;
> --
> 2.1.4
>
On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
> > When pci-host-generic looks for the probe-only property, it seems
> > to trust the DT to be correctly written, and assumes that there
> > is a parameter to the property.
> >
> > Unfortunately, this is not always the case, and some firmware expose
> > this property naked. The driver ends up making a decision based on
> > whatever the property pointer points to, which is likely to be junk.
> >
> > Switch to the common of_pci.c implementation that doesn't suffer
> > from this problem.
> >
> > Signed-off-by: Marc Zyngier <[email protected]>
> > ---
> > drivers/pci/host/pci-host-generic.c | 9 +--------
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
> > index 265dd25..545ff4e 100644
> > --- a/drivers/pci/host/pci-host-generic.c
> > +++ b/drivers/pci/host/pci-host-generic.c
> > @@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
> > int err;
> > const char *type;
> > const struct of_device_id *of_id;
> > - const int *prop;
> > struct device *dev = &pdev->dev;
> > struct device_node *np = dev->of_node;
> > struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> > @@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
> > return -EINVAL;
> > }
> >
> > - prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
> > - if (prop) {
> > - if (*prop)
> > - pci_add_flags(PCI_PROBE_ONLY);
> > - else
> > - pci_clear_flags(PCI_PROBE_ONLY);
> > - }
> > + of_pci_check_probe_only(of_chosen);
>
> Do we need support for pci-probe-only in pci-host-generic at all?
> You're removing the use in amd-overdrive.dts, and there are no other
> DTs in the kernel tree that mention it.
>
> If we can live without it, that would be nice. It seems like a relic from
> days when we couldn't reliably assign resources. (I'm not saying we can do
> that reliably even today, but I'd rather make it reliable than turn it
> off.)
Kvmtool certainly uses it (and generates its own DT, hence why you don't
see it in mainline). Not sure about qemu, though.
Will
On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware expose
> this property naked. The driver ends up making a decision based on
> whatever the property pointer points to, which is likely to be junk.
>
> Switch to the common of_pci.c implementation that doesn't suffer
> from this problem.
>
> Signed-off-by: Marc Zyngier <[email protected]>
> ---
> drivers/pci/host/pci-host-generic.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
> index 265dd25..545ff4e 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
> int err;
> const char *type;
> const struct of_device_id *of_id;
> - const int *prop;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> @@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
> - if (prop) {
> - if (*prop)
> - pci_add_flags(PCI_PROBE_ONLY);
> - else
> - pci_clear_flags(PCI_PROBE_ONLY);
> - }
> + of_pci_check_probe_only(of_chosen);
You could probably just make this take void, as the probe-only property
is always in the /chosen node.
Either way:
Acked-by: Will Deacon <[email protected]>
Will
> On 14.08.2015, at 09:43, Will Deacon <[email protected]> wrote:
>
> On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
>> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
>>> When pci-host-generic looks for the probe-only property, it seems
>>> to trust the DT to be correctly written, and assumes that there
>>> is a parameter to the property.
>>>
>>> Unfortunately, this is not always the case, and some firmware expose
>>> this property naked. The driver ends up making a decision based on
>>> whatever the property pointer points to, which is likely to be junk.
>>>
>>> Switch to the common of_pci.c implementation that doesn't suffer
>>> from this problem.
>>>
>>> Signed-off-by: Marc Zyngier <[email protected]>
>>> ---
>>> drivers/pci/host/pci-host-generic.c | 9 +--------
>>> 1 file changed, 1 insertion(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
>>> index 265dd25..545ff4e 100644
>>> --- a/drivers/pci/host/pci-host-generic.c
>>> +++ b/drivers/pci/host/pci-host-generic.c
>>> @@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
>>> int err;
>>> const char *type;
>>> const struct of_device_id *of_id;
>>> - const int *prop;
>>> struct device *dev = &pdev->dev;
>>> struct device_node *np = dev->of_node;
>>> struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
>>> @@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
>>> return -EINVAL;
>>> }
>>>
>>> - prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
>>> - if (prop) {
>>> - if (*prop)
>>> - pci_add_flags(PCI_PROBE_ONLY);
>>> - else
>>> - pci_clear_flags(PCI_PROBE_ONLY);
>>> - }
>>> + of_pci_check_probe_only(of_chosen);
>>
>> Do we need support for pci-probe-only in pci-host-generic at all?
>> You're removing the use in amd-overdrive.dts, and there are no other
>> DTs in the kernel tree that mention it.
>>
>> If we can live without it, that would be nice. It seems like a relic from
>> days when we couldn't reliably assign resources. (I'm not saying we can do
>> that reliably even today, but I'd rather make it reliable than turn it
>> off.)
>
> Kvmtool certainly uses it (and generates its own DT, hence why you don't
> see it in mainline). Not sure about qemu, though.
QEMU definitely doesn't do proble-only. Is this driver used on real PPC machines too? In that case you also won't see the dt, because it comes with the hardware ;).
Alex
On Fri, Aug 14, 2015 at 11:43 AM, Will Deacon <[email protected]> wrote:
> On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
>> On Fri, Aug 14, 2015 at 05:19:17PM +0100, Marc Zyngier wrote:
>> > When pci-host-generic looks for the probe-only property, it seems
>> > to trust the DT to be correctly written, and assumes that there
>> > is a parameter to the property.
>> >
>> > Unfortunately, this is not always the case, and some firmware expose
>> > this property naked. The driver ends up making a decision based on
>> > whatever the property pointer points to, which is likely to be junk.
>> >
>> > Switch to the common of_pci.c implementation that doesn't suffer
>> > from this problem.
>> >
>> > Signed-off-by: Marc Zyngier <[email protected]>
>> > ---
>> > drivers/pci/host/pci-host-generic.c | 9 +--------
>> > 1 file changed, 1 insertion(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
>> > index 265dd25..545ff4e 100644
>> > --- a/drivers/pci/host/pci-host-generic.c
>> > +++ b/drivers/pci/host/pci-host-generic.c
>> > @@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
>> > int err;
>> > const char *type;
>> > const struct of_device_id *of_id;
>> > - const int *prop;
>> > struct device *dev = &pdev->dev;
>> > struct device_node *np = dev->of_node;
>> > struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
>> > @@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
>> > return -EINVAL;
>> > }
>> >
>> > - prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
>> > - if (prop) {
>> > - if (*prop)
>> > - pci_add_flags(PCI_PROBE_ONLY);
>> > - else
>> > - pci_clear_flags(PCI_PROBE_ONLY);
>> > - }
>> > + of_pci_check_probe_only(of_chosen);
>>
>> Do we need support for pci-probe-only in pci-host-generic at all?
>> You're removing the use in amd-overdrive.dts, and there are no other
>> DTs in the kernel tree that mention it.
>>
>> If we can live without it, that would be nice. It seems like a relic from
>> days when we couldn't reliably assign resources. (I'm not saying we can do
>> that reliably even today, but I'd rather make it reliable than turn it
>> off.)
>
> Kvmtool certainly uses it (and generates its own DT, hence why you don't
> see it in mainline). Not sure about qemu, though.
Do you know why kvmtool wants probe-only? Would something break if we
didn't support probe-only? I guess we'd be looking for a case where
Linux assigns resources and that assignment doesn't work with kvmtool?
"pci-probe-only" doesn't appear in qemu
(git://git.qemu-project.org/qemu.git). (I guess Alexander confirmed
that later.)
Alexander wrote:
> QEMU definitely doesn't do proble-only.
> Is this driver used on real PPC machines too?
I think you're asking about pci-host-generic.c, and the answer is
"no," because pci-host-generic.c currently depends on CONFIG_ARM.
Bjorn
On Fri, Aug 14, 2015 at 11:19 AM, Marc Zyngier <[email protected]> wrote:
> Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
> to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
> can be triggered if the property has no parameter.
Humm, I bet we could break a lot of machines if we fixed the core code
to properly make pp->value NULL when there is no value.
> Provide a generic implementation that can be used by both.
>
> Signed-off-by: Marc Zyngier <[email protected]>
> ---
> drivers/of/of_pci.c | 30 ++++++++++++++++++++++++++++++
> include/linux/of_pci.h | 3 +++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..a4e29ff 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -118,6 +118,36 @@ int of_get_pci_domain_nr(struct device_node *node)
> EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
>
> /**
> + * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
> + * is present and valid
> + *
> + * @node: device tree node that may contain the property (usually "chosen")
> + *
> + */
> +void of_pci_check_probe_only(struct device_node *node)
> +{
> + const int *prop;
> + int len;
> +
> + if (!node)
> + return;
> +
> + prop = of_get_property(node, "linux,pci-probe-only", &len);
It is preferred to use of_property_read_u32 to avoid just these types
of problems.
Rob
On Fri, Aug 14, 2015 at 09:26:21PM +0100, Bjorn Helgaas wrote:
> On Fri, Aug 14, 2015 at 11:43 AM, Will Deacon <[email protected]> wrote:
> > On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
> >> Do we need support for pci-probe-only in pci-host-generic at all?
> >> You're removing the use in amd-overdrive.dts, and there are no other
> >> DTs in the kernel tree that mention it.
> >>
> >> If we can live without it, that would be nice. It seems like a relic from
> >> days when we couldn't reliably assign resources. (I'm not saying we can do
> >> that reliably even today, but I'd rather make it reliable than turn it
> >> off.)
> >
> > Kvmtool certainly uses it (and generates its own DT, hence why you don't
> > see it in mainline). Not sure about qemu, though.
>
> Do you know why kvmtool wants probe-only? Would something break if we
> didn't support probe-only? I guess we'd be looking for a case where
> Linux assigns resources and that assignment doesn't work with kvmtool?
It's basically because the BARs aren't writable other than to find the
region size. It could fixed with a bit of pain, but it doesn't help older
kvmtools that do work with mainline today.
Will