Message ID | 156821713818.1985334.14123187368108582810.stgit@bahia.lan (mailing list archive) |
---|---|
State | Accepted |
Commit | 6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8 |
Headers | show |
Series | [v2] powerpc/xive: Fix bogus error code returned by OPAL | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/apply_patch | success | Successfully applied on branch next (c317052c95bef1f977b023158e5aa929215f443d) |
snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 33 lines checked |
On 11/09/2019 17:52, Greg Kurz wrote: > There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call > to return the 32-bit value 0xffffffff when OPAL has run out of IRQs. > Unfortunatelty, OPAL return values are signed 64-bit entities and > errors are supposed to be negative. If that happens, the linux code > confusingly treats 0xffffffff as a valid IRQ number and panics at some > point. > > A fix was recently merged in skiboot: > > e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()") > > but we need a workaround anyway to support older skiboots already > in the field. > > Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error > returned upon resource exhaustion. > > Cc: stable@vger.kernel.org # v4.12+ > Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Thanks, C. > --- > v2: - fix syntax error in changelog > - Cc stable > - rename original OPAL wrapper > - rewrite fixup wrapper (style, use s64 and u32) > --- > arch/powerpc/include/asm/opal.h | 2 +- > arch/powerpc/platforms/powernv/opal-call.c | 2 +- > arch/powerpc/sysdev/xive/native.c | 11 +++++++++++ > 3 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h > index 57bd029c715e..d5a0807d21db 100644 > --- a/arch/powerpc/include/asm/opal.h > +++ b/arch/powerpc/include/asm/opal.h > @@ -272,7 +272,7 @@ int64_t opal_xive_get_vp_info(uint64_t vp, > int64_t opal_xive_set_vp_info(uint64_t vp, > uint64_t flags, > uint64_t report_cl_pair); > -int64_t opal_xive_allocate_irq(uint32_t chip_id); > +int64_t opal_xive_allocate_irq_raw(uint32_t chip_id); > int64_t opal_xive_free_irq(uint32_t girq); > int64_t opal_xive_sync(uint32_t type, uint32_t id); > int64_t opal_xive_dump(uint32_t type, uint32_t id); > diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c > index 29ca523c1c79..dccdc9df5213 100644 > --- a/arch/powerpc/platforms/powernv/opal-call.c > +++ b/arch/powerpc/platforms/powernv/opal-call.c > @@ -257,7 +257,7 @@ OPAL_CALL(opal_xive_set_queue_info, OPAL_XIVE_SET_QUEUE_INFO); > OPAL_CALL(opal_xive_donate_page, OPAL_XIVE_DONATE_PAGE); > OPAL_CALL(opal_xive_alloc_vp_block, OPAL_XIVE_ALLOCATE_VP_BLOCK); > OPAL_CALL(opal_xive_free_vp_block, OPAL_XIVE_FREE_VP_BLOCK); > -OPAL_CALL(opal_xive_allocate_irq, OPAL_XIVE_ALLOCATE_IRQ); > +OPAL_CALL(opal_xive_allocate_irq_raw, OPAL_XIVE_ALLOCATE_IRQ); > OPAL_CALL(opal_xive_free_irq, OPAL_XIVE_FREE_IRQ); > OPAL_CALL(opal_xive_get_vp_info, OPAL_XIVE_GET_VP_INFO); > OPAL_CALL(opal_xive_set_vp_info, OPAL_XIVE_SET_VP_INFO); > diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c > index 37987c815913..ad8ee7dd7f57 100644 > --- a/arch/powerpc/sysdev/xive/native.c > +++ b/arch/powerpc/sysdev/xive/native.c > @@ -231,6 +231,17 @@ static bool xive_native_match(struct device_node *node) > return of_device_is_compatible(node, "ibm,opal-xive-vc"); > } > > +static s64 opal_xive_allocate_irq(u32 chip_id) > +{ > + s64 irq = opal_xive_allocate_irq_raw(chip_id); > + > + /* > + * Old versions of skiboot can incorrectly return 0xffffffff to > + * indicate no space, fix it up here. > + */ > + return irq == 0xffffffff ? OPAL_RESOURCE : irq; > +} > + > #ifdef CONFIG_SMP > static int xive_native_get_ipi(unsigned int cpu, struct xive_cpu *xc) > { >
On Wed, 2019-09-11 at 15:52:18 UTC, Greg Kurz wrote: > There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call > to return the 32-bit value 0xffffffff when OPAL has run out of IRQs. > Unfortunatelty, OPAL return values are signed 64-bit entities and > errors are supposed to be negative. If that happens, the linux code > confusingly treats 0xffffffff as a valid IRQ number and panics at some > point. > > A fix was recently merged in skiboot: > > e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()") > > but we need a workaround anyway to support older skiboots already > in the field. > > Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error > returned upon resource exhaustion. > > Cc: stable@vger.kernel.org # v4.12+ > Signed-off-by: Greg Kurz <groug@kaod.org> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8 cheers
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h index 57bd029c715e..d5a0807d21db 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc/include/asm/opal.h @@ -272,7 +272,7 @@ int64_t opal_xive_get_vp_info(uint64_t vp, int64_t opal_xive_set_vp_info(uint64_t vp, uint64_t flags, uint64_t report_cl_pair); -int64_t opal_xive_allocate_irq(uint32_t chip_id); +int64_t opal_xive_allocate_irq_raw(uint32_t chip_id); int64_t opal_xive_free_irq(uint32_t girq); int64_t opal_xive_sync(uint32_t type, uint32_t id); int64_t opal_xive_dump(uint32_t type, uint32_t id); diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c index 29ca523c1c79..dccdc9df5213 100644 --- a/arch/powerpc/platforms/powernv/opal-call.c +++ b/arch/powerpc/platforms/powernv/opal-call.c @@ -257,7 +257,7 @@ OPAL_CALL(opal_xive_set_queue_info, OPAL_XIVE_SET_QUEUE_INFO); OPAL_CALL(opal_xive_donate_page, OPAL_XIVE_DONATE_PAGE); OPAL_CALL(opal_xive_alloc_vp_block, OPAL_XIVE_ALLOCATE_VP_BLOCK); OPAL_CALL(opal_xive_free_vp_block, OPAL_XIVE_FREE_VP_BLOCK); -OPAL_CALL(opal_xive_allocate_irq, OPAL_XIVE_ALLOCATE_IRQ); +OPAL_CALL(opal_xive_allocate_irq_raw, OPAL_XIVE_ALLOCATE_IRQ); OPAL_CALL(opal_xive_free_irq, OPAL_XIVE_FREE_IRQ); OPAL_CALL(opal_xive_get_vp_info, OPAL_XIVE_GET_VP_INFO); OPAL_CALL(opal_xive_set_vp_info, OPAL_XIVE_SET_VP_INFO); diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c index 37987c815913..ad8ee7dd7f57 100644 --- a/arch/powerpc/sysdev/xive/native.c +++ b/arch/powerpc/sysdev/xive/native.c @@ -231,6 +231,17 @@ static bool xive_native_match(struct device_node *node) return of_device_is_compatible(node, "ibm,opal-xive-vc"); } +static s64 opal_xive_allocate_irq(u32 chip_id) +{ + s64 irq = opal_xive_allocate_irq_raw(chip_id); + + /* + * Old versions of skiboot can incorrectly return 0xffffffff to + * indicate no space, fix it up here. + */ + return irq == 0xffffffff ? OPAL_RESOURCE : irq; +} + #ifdef CONFIG_SMP static int xive_native_get_ipi(unsigned int cpu, struct xive_cpu *xc) {
There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call to return the 32-bit value 0xffffffff when OPAL has run out of IRQs. Unfortunatelty, OPAL return values are signed 64-bit entities and errors are supposed to be negative. If that happens, the linux code confusingly treats 0xffffffff as a valid IRQ number and panics at some point. A fix was recently merged in skiboot: e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()") but we need a workaround anyway to support older skiboots already in the field. Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error returned upon resource exhaustion. Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Greg Kurz <groug@kaod.org> --- v2: - fix syntax error in changelog - Cc stable - rename original OPAL wrapper - rewrite fixup wrapper (style, use s64 and u32) --- arch/powerpc/include/asm/opal.h | 2 +- arch/powerpc/platforms/powernv/opal-call.c | 2 +- arch/powerpc/sysdev/xive/native.c | 11 +++++++++++ 3 files changed, 13 insertions(+), 2 deletions(-)