All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Qian Cai <cai@lca.pw>, Oliver O'Halloran <oohall@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: ioremap() called early from pnv_pci_init_ioda_phb()
Date: Sat, 09 May 2020 18:43:30 +1000	[thread overview]
Message-ID: <1589013519.0fzm2px5cz.astroid@bobo.none> (raw)
In-Reply-To: <CAOSf1CFNp6+k_y_87r7p2e8cKfX0rK-9wBxeR+K0e0y8R0_TNg@mail.gmail.com>

Excerpts from Oliver O'Halloran's message of May 9, 2020 6:11 pm:
> On Sat, May 9, 2020 at 12:41 AM Qian Cai <cai@lca.pw> wrote:
>>
>>  Booting POWER9 PowerNV has this message,
>>
>> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use early_ioremap() instead”
>>
>> but use the patch below will result in leaks because it will never call early_iounmap() anywhere. However, it looks me it was by design that phb->regs mapping would be there forever where it would be used in pnv_ioda_get_inval_reg(), so is just that check_early_ioremap_leak() initcall too strong?
> 
> The warning there is junk. The PHBs are setup at boot and never torn
> down so we're not "leaking" the mapping. It's supposed to be there for
> the lifetime of the kernel.
> 
> That said, we could probably move the PCI setup to a point later in
> boot where the normal ioremap can be be used. We would have to check
> for initcalls which depend on the PHBs being setup and delay those too
> though.

I think it helps to unify code a bit more and take special cases out of 
ioremap to have all these early calls use early_ioremap.

We actually do want to move these later if possible too, on radix they 
use memblock for page tables, and on hash they don't even set up proper 
kernel page tables but just bolt PTEs into the hash table.

Thanks,
Nick

WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com>
To: Qian Cai <cai@lca.pw>, Oliver O'Halloran <oohall@gmail.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: ioremap() called early from pnv_pci_init_ioda_phb()
Date: Sat, 09 May 2020 18:43:30 +1000	[thread overview]
Message-ID: <1589013519.0fzm2px5cz.astroid@bobo.none> (raw)
In-Reply-To: <CAOSf1CFNp6+k_y_87r7p2e8cKfX0rK-9wBxeR+K0e0y8R0_TNg@mail.gmail.com>

Excerpts from Oliver O'Halloran's message of May 9, 2020 6:11 pm:
> On Sat, May 9, 2020 at 12:41 AM Qian Cai <cai@lca.pw> wrote:
>>
>>  Booting POWER9 PowerNV has this message,
>>
>> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use early_ioremap() instead”
>>
>> but use the patch below will result in leaks because it will never call early_iounmap() anywhere. However, it looks me it was by design that phb->regs mapping would be there forever where it would be used in pnv_ioda_get_inval_reg(), so is just that check_early_ioremap_leak() initcall too strong?
> 
> The warning there is junk. The PHBs are setup at boot and never torn
> down so we're not "leaking" the mapping. It's supposed to be there for
> the lifetime of the kernel.
> 
> That said, we could probably move the PCI setup to a point later in
> boot where the normal ioremap can be be used. We would have to check
> for initcalls which depend on the PHBs being setup and delay those too
> though.

I think it helps to unify code a bit more and take special cases out of 
ioremap to have all these early calls use early_ioremap.

We actually do want to move these later if possible too, on radix they 
use memblock for page tables, and on hash they don't even set up proper 
kernel page tables but just bolt PTEs into the hash table.

Thanks,
Nick

  reply	other threads:[~2020-05-09  8:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 14:39 ioremap() called early from pnv_pci_init_ioda_phb() Qian Cai
2020-05-08 17:41 ` Qian Cai
2020-05-09  8:38   ` Nicholas Piggin
2020-05-09  8:38     ` Nicholas Piggin
2020-05-09 15:37     ` Qian Cai
2020-05-09 15:37       ` Qian Cai
2020-05-09 15:49   ` Christophe Leroy
2020-05-09 22:59     ` Oliver O'Halloran
2020-05-09 22:59       ` Oliver O'Halloran
2020-05-09  8:11 ` Oliver O'Halloran
2020-05-09  8:11   ` Oliver O'Halloran
2020-05-09  8:43   ` Nicholas Piggin [this message]
2020-05-09  8:43     ` Nicholas Piggin

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=1589013519.0fzm2px5cz.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=cai@lca.pw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oohall@gmail.com \
    /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.