Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210113162948.45b0fbfd@canb.auug.org.au> <20210119162619.6782c5d2@canb.auug.org.au>
In-Reply-To: <20210119162619.6782c5d2@canb.auug.org.au>
From:   Daniel Vetter <daniel@ffwll.ch>
Date:   Tue, 19 Jan 2021 08:40:08 +0100
Message-ID: <CAKMK7uGiVnEaD029hCLhuHLXuTeMSuEQoe25oLXDm_GuOhzDrw@mail.gmail.com>
Subject: Re: linux-next: boot failure after merge of the iomem-mmap-vs-gup tree
To:     Stephen Rothwell <sfr@canb.auug.org.au>
Cc:     Daniel Vetter <daniel.vetter@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jan 19, 2021 at 6:26 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Wed, 13 Jan 2021 16:29:48 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the iomem-mmap-vs-gup tree, today's linux-next boot test
> > (powerpc pseries_le_defconfig) failed like this:
> >
> >     EEH: pSeries platform initialized
> >     PCI: Probing PCI hardware
> >     BUG: Kernel NULL pointer dereference on write at 0x00000030
> >     Faulting instruction address: 0xc00000000013bf4c
> >     Oops: Kernel access of bad area, sig: 11 [#1]
> >     LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> >     Modules linked in:
> >     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc3 #2
> >     NIP:  c00000000013bf4c LR: c0000000007a9ee8 CTR: 0000000000000000
> >     REGS: c0000000063a3610 TRAP: 0380   Not tainted  (5.11.0-rc3)
> >     MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 84002440  XER: 00000000
> >     CFAR: c0000000007a9ee4 IRQMASK: 0
> >     GPR00: c0000000007a9ee8 c0000000063a38b0 c0000000013d8100 c000000006061300
> >     GPR04: 0000000000000000 0000000000000b20 c000000000f11738 000000000000ffff
> >     GPR08: c0000000007a7ab0 0000000000000000 c0000000007a7a40 2d6770696f730000
> >     GPR12: 0000000000000000 c0000000015b0000 c000000000013120 0000000000000000
> >     GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >     GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >     GPR24: c000000006210de8 c000000006167120 c000000006620b20 0000000000000000
> >     GPR28: c000000006167120 0000000000000180 c000000006061300 c000000006167000
> >     NIP [c00000000013bf4c] iomem_get_mapping+0x1c/0x30
> >     LR [c0000000007a9ee8] pci_create_legacy_files+0xa8/0x1c0
> >     Call Trace:
> >     [c0000000063a38b0] [c0000000007a9e84] pci_create_legacy_files+0x44/0x1c0 (unreliable)
> >     [c0000000063a3930] [c000000000795198] pci_register_host_bridge+0x288/0x510
> >     [c0000000063a3a60] [c000000000795514] pci_create_root_bus+0xf4/0x150
> >     [c0000000063a3ac0] [c00000000006d424] pcibios_scan_phb+0xe4/0x270
> >     [c0000000063a3b70] [c000000001010b40] pcibios_init+0x8c/0x128
> >     [c0000000063a3bf0] [c000000000012b70] do_one_initcall+0x60/0x2c0
> >     [c0000000063a3cc0] [c0000000010046b4] kernel_init_freeable+0x2e8/0x380
> >     [c0000000063a3da0] [c000000000013144] kernel_init+0x2c/0x168
> >     [c0000000063a3e10] [c00000000000dff0] ret_from_kernel_thread+0x5c/0x6c
> >     Instruction dump:
> >     7c634850 4e800020 60000000 60000000 60420000 3c4c012a 3842c1d0 7c0802a6
> >     60000000 3d22000d e929caf8 7c2004ac <e8690030> 4e800020 60000000 60000000
> >     ---[ end trace 77f55ece72f02708 ]---
> >
> >     Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> >
> > Caused by commit
> >
> >   85482fbab59e ("PCI: Revoke mappings like devmem")
> >
> > Reverting that commit fixes the boot, so I have done that for today.
>
> I am still reverting this commit.

Thanks for the reminder, I missed your earlier report. I don't have a
machine here with HAVE_PCI_LEGACY, but I think I understand what's
going on here. I'll drop the last two patches from the branch for now
(since both need to be changed to address this somehow).
-Daniel


--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch