linux-kernel - Re: 2f47e7e19f ("x86/mm/kaiser: Use PCID feature to make user and .."): WARNING: CPU: 0 PID: 1 at mm/early_ioremap.c:114 __early

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0i5E679oaKwKbqNK2mVv81kJFN5P_L2xz_oAa1pKRtY_w@mail.gmail.com>
Date:   Mon, 27 Nov 2017 23:33:50 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        kernel test robot <fengguang.wu@...el.com>, LKP <lkp@...org>,
        kvm@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>, wfg@...ux.intel.com,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        "Brown, Len" <len.brown@...el.com>,
        Jesse Barnes <jbarnes@...tuousgeek.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: 2f47e7e19f ("x86/mm/kaiser: Use PCID feature to make user and
 .."): WARNING: CPU: 0 PID: 1 at mm/early_ioremap.c:114 __early_ioremap

On Mon, Nov 27, 2017 at 11:13 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Mon, Nov 27, 2017 at 5:14 PM, Dave Hansen
> <dave.hansen@...ux.intel.com> wrote:
>> On 11/27/2017 02:18 AM, Ingo Molnar wrote:
>>> [    0.031000] Call Trace:
>>> [    0.031000]  ? kernfs_add_one+0x1d9/0x1f0
>>> [    0.031000]  early_memremap+0x33/0x3d
>>> [    0.031000]  ? cnb20le_res+0x2f2/0x2f2
>>> [    0.031000]  __acpi_map_table+0x1d/0x28
>>> [    0.031000]  acpi_os_map_iomem+0x1cf/0x2a0
>>> [    0.031000]  ? cnb20le_res+0x2f2/0x2f2
>>> [    0.031000]  acpi_os_map_memory+0xd/0x20
>>> [    0.031000]  acpi_find_root_pointer+0x1f/0x1ec
>>> [    0.031000]  ? cnb20le_res+0x2f2/0x2f2
>>> [    0.031000]  acpi_os_get_root_pointer+0x18/0x25
>>> [    0.031000]  broadcom_postcore_init+0xc/0x6c
>>> [    0.031000]  do_one_initcall+0xc4/0x1f7
>>> [    0.031000]  kernel_init_freeable+0x1c2/0x2b2
>>> [    0.031000]  ? rest_init+0x1a0/0x1a0
>>> [    0.031000]  kernel_init+0xd/0x1bc
>>> [    0.031000]  ret_from_fork+0x1f/0x30
>>
>> I've been able to reproduce this.  The bug here (at least on my system)
>> is that we're calling into the ACPI code while 'acpi_disabled=1'.  The
>> ACPI code then notices that it hasn't been initialized (because it
>> should be off) and calls into the early_ioremap() code thinking that
>> it's in early boot.
>>
>> I don't know why the bisect pinned this on the kaiser patches, or why
>> it's only showing up now.  It's possible that some botched TLB flush
>> _caused_ ACPI to get disabled at a weird time which then caused this
>> warning.
>>
>> There are some recent changes around broadcom_postcore_init().
>>
>> ACPI folks, any suggestions on what to do here?  Should we be bailing
>> out of acpi_os_get_root_pointer() like the attached patch?
>
> No, the bug is in broadcom_postcore_init(), everything else should be fine.
>
> I'm not even sure why acpi_os_get_root_pointer() is called from there
> in the first place.  It should only be called from the ACPICA code.

This seems to be serving as a rough check whether or not ACPI is going
to be used on this platform (if we get the location of the tables, it
probably will be used) and it is missing the acpi_disabled check.

Thanks,
Rafael