linux-kernel - Re: lockdep warning: console vs. mem hotplug

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: <20170329073146.GA27994@dhcp22.suse.cz>
Date:   Wed, 29 Mar 2017 09:31:47 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Sebastian Ott <sebott@...ux.vnet.ibm.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: lockdep warning: console vs. mem hotplug

On Tue 28-03-17 18:00:16, Petr Mladek wrote:
> On Tue 2017-03-28 16:22:27, Michal Hocko wrote:
> > On Sat 25-03-17 09:04:42, Sergey Senozhatsky wrote:
> > > On (03/21/17 13:44), Sergey Senozhatsky wrote:
> > > [..]
> > > > so we probably can
> > > > 
> > > > 
> > > > 1) move pr_info() out of zone->lock in __offline_isolated_pages().
> > > >    meh...
> > > > 
> > > > 
> > > > 2) switch to printk_deferred() in __offline_isolated_pages().
> > > >    meh.. there might a bunch of other printks done from under zone->lock.
> > > > 
> > > > 
> > > > 3) move add_timer() out of sclp_con_lock console in sclp_console_write().
> > > >    well, there can be other consoles that do something similar.
> > > > 
> > > > 
> > > > 4) ... something smart.
> > > 
> > > 
> > > Sebastian, does this change make lockdep happy?
> > > 
> > > it removes console drivers from the __offline_isolated_pages(). not the
> > > best solution I can think of, but the simplest one.
> > > 
> > > ---
> > > 
> > >  mm/page_alloc.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index f749b7ff7c50..eb61e6ab5f4f 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -7705,7 +7705,7 @@ __offline_isolated_pages(unsigned long start_pfn, unsigned long end_pfn)
> > >  		BUG_ON(!PageBuddy(page));
> > >  		order = page_order(page);
> > >  #ifdef CONFIG_DEBUG_VM
> > > -		pr_info("remove from free list %lx %d %lx\n",
> > > +		printk_deferred(KERN_INFO "remove from free list %lx %d %lx\n",
> > >  			pfn, 1 << order, end_pfn);
> > >  #endif
> > >  		list_del(&page->lru);
> > 
> > I believe this is not a proper fix. Although this code is ugly and maybe
> > it doesn't really need zone->lock because that should be the page
> > allocator internal thing the problem is that printk shouldn't impose
> > such a subtle dependency on locks. Why does the timer needs to allocate
> > at all?
> 
> printk/console use timers to postpone flushing of buffers. There are
> often more consequent printks. The code wants to wait a bit and flush
> them together eventually. At the same time, it wants to set a deadline
> for the flushing. It makes sure that they will get flushed in a
> reasonable time even when the buffer is not full. It is questionable
> but it makes some sense.
> 
> In each case, the timer code is used also by scheduler and we probably
> need to use scheduler from printk.
> 
> Regarding the timer code. The problem seems to be with static
> timers. They call debug_object_init() when the timer is used
> for the first time. See the special handling of not-found
> objects in debug_object_activate().

Thanks for the clarification!

> Now, __debug_object_init() calls fill_pool() that allocates
> the memory. A solution would be to either use static
> struct kmem_cache

I am not sure what do you mean by that.

> for statically defined timers and avoid the allocation. Or we should
> call fill_pool() asynchronously from a safe context.

I think we should avoid the allocation completely. It is GFP_ATOMIC and
so likely to fail under heavy memory pressure. Async fill will make it
slightly more complicated but still unreliable.
 
> What do you think?

Why cannot we simply embed this debugging data into the timer itself?
It will make the structure larger (I didn't check how much) but this is
an opt in feature so it should be acceptable.

A subtle dependecny on the allocator is really bad and we should get rid
of it.
-- 
Michal Hocko
SUSE Labs