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] [day] [month] [year] [list]
Date:   Mon, 14 Feb 2022 09:50:06 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Peter Zijlstra <peterz@...radead.org>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Michael Ellerman <mpe@...erman.id.au>
CC:     "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jason Baron <jbaron@...mai.com>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Zhouyi Zhou <zhouzhouyi@...il.com>
Subject: Re: BUG: sleeping function called from invalid context at
 include/linux/sched/mm.h:256



Le 14/02/2022 à 10:35, Peter Zijlstra a écrit :
> On Sun, Feb 13, 2022 at 12:05:50AM +0100, Paul Menzel wrote:
> 
>> [    0.012154][    T1] BUG: sleeping function called from invalid context at
> 
>> [    0.022443][    T1] [c0000000084837d0] [c000000000961aac] > dump_stack_lvl+0xa0/0xec (unreliable)
>> [    0.023356][    T1] [c000000008483820] [c00000000019b314] > __might_resched+0x2f4/0x310
>> [    0.024174][    T1] [c0000000084838b0] [c0000000004c0c70] > kmem_cache_alloc+0x220/0x4b0
>> [    0.025000][    T1] [c000000008483920] [c000000000448af4] > __pud_alloc+0x74/0x1d0
>> [    0.025772][    T1] [c000000008483970] [c00000000008fe3c] > hash__map_kernel_page+0x2cc/0x390
>> [    0.026643][    T1] [c000000008483a20] [c0000000000a9944] > do_patch_instruction+0x134/0x4a0
> 
> do_patch_instruction() rightfully disables IRQs, but then it goes and
> tries a memory alloc, which seems a bit daft.
> 
> I'm thinking Christophe might know more... he's recently been poking at
> Power text poking..


I don't know all details about PPC64, but here it seems like 
hash__map_kernel_page() allocates intermediate page directories when 
there is not one yet. So if that's the first time 
hash__map_kernel_page() is called for the text_poke_addr() it allocated 
PUD and PMD if necessary.

As it is kernel memory, once PUD and PMD are allocated they will remain 
forever I think. So maybe the only thing to do it to perform a dummy 
mapping/unmapping in text_area_cpu_up() to ensure the page directory are 
created in advance.

Christophe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ