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: <20170328160016.GK2846@pathway.suse.cz>
Date:   Tue, 28 Mar 2017 18:00:16 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Michal Hocko <mhocko@...nel.org>
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 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().

Now, __debug_object_init() calls fill_pool() that allocates
the memory. A solution would be to either use static
struct kmem_cache for statically defined timers and
avoid the allocation. Or we should call fill_pool()
asynchronously from a safe context.

What do you think?

Best Regards,
Petr