All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Frederic Barrat <fbarrat@linux.ibm.com>
Cc: aik@ozlabs.ru, stable@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, Greg Kurz <groug@kaod.org>,
	andrew.donnellan@au1.ibm.com
Subject: Re: [PATCH] powerpc/powernv/npu: Fix oops in pnv_try_setup_npu_table_group()
Date: Wed, 9 Jan 2019 17:58:51 +0100	[thread overview]
Message-ID: <20190109165851.GA9424@kroah.com> (raw)
In-Reply-To: <41fc8267-7a40-a3e0-df39-773771b661d2@linux.ibm.com>

On Wed, Jan 09, 2019 at 05:45:53PM +0100, Frederic Barrat wrote:
> 
> 
> Le 09/01/2019 à 17:25, Greg Kurz a écrit :
> > On Wed,  9 Jan 2019 16:13:42 +0100
> > Frederic Barrat <fbarrat@linux.ibm.com> wrote:
> > 
> > > With a recent change around IOMMU group, a system with an opencapi
> > > adapter is no longer booting and we get a kernel oops:
> > > 
> > > BUG: Kernel NULL pointer dereference at 0x00000028
> > > Faulting instruction address: 0xc0000000000aa38c
> > > Oops: Kernel access of bad area, sig: 7 [#1]
> > > LE SMP NR_CPUS=2048 NUMA PowerNV
> > > Modules linked in:
> > > CPU: 5 PID: 1 Comm: swapper/4 Not tainted 5.0.0-rc1-fxb-00001-g3bd6e94bec12
> > > NIP:  c0000000000aa38c LR: c0000000000a6608 CTR: c000000000097480
> > > REGS: c000000005783700 TRAP: 0300   Not tainted  (5.0.0-rc1-fxb-00001-g3bd6
> > > MSR:  9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE>  CR: 28000228  XER: 20
> > > CFAR: c0000000000a6604 DAR: 0000000000000028 DSISR: 00080000 IRQMASK: 0
> > > GPR00: c0000000000a6608 c000000005783990 c000000001036100 c0000007bf761860
> > > GPR04: 0000000000000000 c000000005783834 0000000000000000 0000000000000000
> > > GPR08: 69626d2c6e707500 0000000000000000 0000000000000000 9000000002001003
> > > GPR12: 0000000000000000 c0000007bfff8300 c000000000010450 0000000000000000
> > > GPR16: c000000000ced938 0000000000000100 c000000000ced948 00000000000a0000
> > > GPR20: 00000000000bfffe c000000000ced9a8 0000000000000200 c000000000ced978
> > > GPR24: 00000000006080c0 c000000716d09828 c00000002e6fd000 0000000000000000
> > > GPR28: c0000007bf4aff68 c0000007bf8d0080 c000000000f23938 c0000007bf761860
> > > NIP [c0000000000aa38c] pnv_try_setup_npu_table_group+0x1c/0x1a0
> > > LR [c0000000000a6608] pnv_pci_ioda_fixup+0x1f8/0x660
> > > Call Trace:
> > > [c000000005783990] [c0000000000aa3d0] pnv_try_setup_npu_table_group+0x60/0x
> > > [c0000000057839d0] [c0000000000a661c] pnv_pci_ioda_fixup+0x20c/0x660
> > > [c000000005783ab0] [c000000000e1d4c0] pcibios_resource_survey+0x2c8/0x31c
> > > [c000000005783b90] [c000000000e1caf4] pcibios_init+0xb0/0xe4
> > > [c000000005783c10] [c000000000010054] do_one_initcall+0x64/0x264
> > > [c000000005783ce0] [c000000000e1132c] kernel_init_freeable+0x36c/0x468
> > > [c000000005783db0] [c000000000010474] kernel_init+0x2c/0x148
> > > [c000000005783e20] [c00000000000b794] ret_from_kernel_thread+0x5c/0x68
> > > 
> > > An opencapi device is using a device PE, so the current code breaks
> > > because pe->pbus is not defined.
> > > 
> > > More generally, there's no need to define an IOMMU group for opencapi,
> > > as the device sends real addresses directly (admittedly, the
> > > virtualization story is yet to be written). So let's fix it by
> > 
> > Current plan is to go for mediated VFIO. The real HW stays under the control
> > of the host ocxl driver, and we still don't need an IOMMU group.
> > 
> > > skipping the IOMMU group setup for opencapi PHBs.
> > > 
> > > Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups")
> > > Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
> > > ---
> > 
> > Reviewed-by: Greg Kurz <groug@kaod.org>
> > 
> > and
> > 
> > Cc: stable@vger.kernel.org      # v4.20
> 
> Thanks for the review! But why did you add stable? that problem is only seen
> on 5.0-rc1, isn't it?

No, this is fixing a patch that got backported to stable.

Well, attempted to be backported, I dropped it because of the problem :)

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Frederic Barrat <fbarrat@linux.ibm.com>
Cc: Greg Kurz <groug@kaod.org>,
	linuxppc-dev@lists.ozlabs.org, aik@ozlabs.ru,
	andrew.donnellan@au1.ibm.com, stable@vger.kernel.org
Subject: Re: [PATCH] powerpc/powernv/npu: Fix oops in pnv_try_setup_npu_table_group()
Date: Wed, 9 Jan 2019 17:58:51 +0100	[thread overview]
Message-ID: <20190109165851.GA9424@kroah.com> (raw)
In-Reply-To: <41fc8267-7a40-a3e0-df39-773771b661d2@linux.ibm.com>

On Wed, Jan 09, 2019 at 05:45:53PM +0100, Frederic Barrat wrote:
> 
> 
> Le 09/01/2019 à 17:25, Greg Kurz a écrit :
> > On Wed,  9 Jan 2019 16:13:42 +0100
> > Frederic Barrat <fbarrat@linux.ibm.com> wrote:
> > 
> > > With a recent change around IOMMU group, a system with an opencapi
> > > adapter is no longer booting and we get a kernel oops:
> > > 
> > > BUG: Kernel NULL pointer dereference at 0x00000028
> > > Faulting instruction address: 0xc0000000000aa38c
> > > Oops: Kernel access of bad area, sig: 7 [#1]
> > > LE SMP NR_CPUS=2048 NUMA PowerNV
> > > Modules linked in:
> > > CPU: 5 PID: 1 Comm: swapper/4 Not tainted 5.0.0-rc1-fxb-00001-g3bd6e94bec12
> > > NIP:  c0000000000aa38c LR: c0000000000a6608 CTR: c000000000097480
> > > REGS: c000000005783700 TRAP: 0300   Not tainted  (5.0.0-rc1-fxb-00001-g3bd6
> > > MSR:  9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE>  CR: 28000228  XER: 20
> > > CFAR: c0000000000a6604 DAR: 0000000000000028 DSISR: 00080000 IRQMASK: 0
> > > GPR00: c0000000000a6608 c000000005783990 c000000001036100 c0000007bf761860
> > > GPR04: 0000000000000000 c000000005783834 0000000000000000 0000000000000000
> > > GPR08: 69626d2c6e707500 0000000000000000 0000000000000000 9000000002001003
> > > GPR12: 0000000000000000 c0000007bfff8300 c000000000010450 0000000000000000
> > > GPR16: c000000000ced938 0000000000000100 c000000000ced948 00000000000a0000
> > > GPR20: 00000000000bfffe c000000000ced9a8 0000000000000200 c000000000ced978
> > > GPR24: 00000000006080c0 c000000716d09828 c00000002e6fd000 0000000000000000
> > > GPR28: c0000007bf4aff68 c0000007bf8d0080 c000000000f23938 c0000007bf761860
> > > NIP [c0000000000aa38c] pnv_try_setup_npu_table_group+0x1c/0x1a0
> > > LR [c0000000000a6608] pnv_pci_ioda_fixup+0x1f8/0x660
> > > Call Trace:
> > > [c000000005783990] [c0000000000aa3d0] pnv_try_setup_npu_table_group+0x60/0x
> > > [c0000000057839d0] [c0000000000a661c] pnv_pci_ioda_fixup+0x20c/0x660
> > > [c000000005783ab0] [c000000000e1d4c0] pcibios_resource_survey+0x2c8/0x31c
> > > [c000000005783b90] [c000000000e1caf4] pcibios_init+0xb0/0xe4
> > > [c000000005783c10] [c000000000010054] do_one_initcall+0x64/0x264
> > > [c000000005783ce0] [c000000000e1132c] kernel_init_freeable+0x36c/0x468
> > > [c000000005783db0] [c000000000010474] kernel_init+0x2c/0x148
> > > [c000000005783e20] [c00000000000b794] ret_from_kernel_thread+0x5c/0x68
> > > 
> > > An opencapi device is using a device PE, so the current code breaks
> > > because pe->pbus is not defined.
> > > 
> > > More generally, there's no need to define an IOMMU group for opencapi,
> > > as the device sends real addresses directly (admittedly, the
> > > virtualization story is yet to be written). So let's fix it by
> > 
> > Current plan is to go for mediated VFIO. The real HW stays under the control
> > of the host ocxl driver, and we still don't need an IOMMU group.
> > 
> > > skipping the IOMMU group setup for opencapi PHBs.
> > > 
> > > Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups")
> > > Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
> > > ---
> > 
> > Reviewed-by: Greg Kurz <groug@kaod.org>
> > 
> > and
> > 
> > Cc: stable@vger.kernel.org      # v4.20
> 
> Thanks for the review! But why did you add stable? that problem is only seen
> on 5.0-rc1, isn't it?

No, this is fixing a patch that got backported to stable.

Well, attempted to be backported, I dropped it because of the problem :)

thanks,

greg k-h

  parent reply	other threads:[~2019-01-09 17:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 15:13 [PATCH] powerpc/powernv/npu: Fix oops in pnv_try_setup_npu_table_group() Frederic Barrat
2019-01-09 16:25 ` Greg Kurz
2019-01-09 16:25   ` Greg Kurz
2019-01-09 16:45   ` Frederic Barrat
2019-01-09 16:45     ` Frederic Barrat
2019-01-09 16:56     ` Greg Kurz
2019-01-09 16:56       ` Greg Kurz
2019-01-10 12:25       ` Michael Ellerman
2019-01-10 12:25         ` Michael Ellerman
2019-01-10 12:31         ` Greg Kurz
2019-01-10 12:31           ` Greg Kurz
2019-01-10 12:58         ` Frederic Barrat
2019-01-10 12:58           ` Frederic Barrat
2019-01-10 13:31           ` Greg KH
2019-01-10 13:31             ` Greg KH
2019-01-09 16:58     ` Greg KH [this message]
2019-01-09 16:58       ` Greg KH
2019-01-10  0:40 ` Andrew Donnellan
2019-01-14 10:12 ` Michael Ellerman

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=20190109165851.GA9424@kroah.com \
    --to=greg@kroah.com \
    --cc=aik@ozlabs.ru \
    --cc=andrew.donnellan@au1.ibm.com \
    --cc=fbarrat@linux.ibm.com \
    --cc=groug@kaod.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=stable@vger.kernel.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.