linux-kernel - Re: lockdep warning while booting POWER9 PowerNV

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: <1567693804.5576.93.camel@lca.pw>
Date:   Thu, 05 Sep 2019 10:30:04 -0400
From:   Qian Cai <cai@....pw>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Bart Van Assche <bvanassche@....org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org
Subject: Re: lockdep warning while booting POWER9 PowerNV

On Thu, 2019-09-05 at 13:55 +1000, Michael Ellerman wrote:
> Bart Van Assche <bvanassche@....org> writes:
> > On 8/30/19 2:13 PM, Qian Cai wrote:
> > > https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
> > > 
> > > Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would
> > > generate
> > > a warning in lockdep_register_key() at,
> > > 
> > > if (WARN_ON_ONCE(static_obj(key)))
> > > 
> > > because
> > > 
> > > key = 0xc0000000019ad118
> > > &_stext = 0xc000000000000000
> > > &_end = 0xc0000000049d0000
> > > 
> > > i.e., it will cause static_obj() returns 1.
> > 
> > (back from a trip)
> > 
> > Hi Qian,
> > 
> > Does this mean that on POWER9 it can happen that a dynamically allocated 
> > object has an address that falls between &_stext and &_end?
> 
> I thought that was true on all arches due to initmem, but seems not.
> 
> I guess we have the same problem as s390 and we need to define
> arch_is_kernel_initmem_freed().

Actually, it is in the .bss section. The commit 2d4f567103ff ("KVM: PPC:
Introduce kvm_tmp framework") adds kvm_tmp[] into the .bss section and then free
the rest of unused spaces back to the page allocator.

kernel_init
  kvm_guest_init
    kvm_free_tmp
      free_reserved_area
        free_unref_page
          free_unref_page_prepare

Later, alloc_workqueue() happens to allocate some pages from there, and triggers
the warning. Not sure what the best way to solve this.