linux-kernel - Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 7 Feb 2017 22:12:12 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        peterz@...radead.org
Cc:     hch@....de, mgorman@...e.de, viro@...IV.linux.org.uk,
        linux-mm@...ck.org, hannes@...xchg.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages
 per zone

On Mon 06-02-17 11:39:18, Michal Hocko wrote:
> On Sun 05-02-17 19:43:07, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > I got same warning with ext4. Maybe we need to check carefully.
> > 
> > [  511.215743] =====================================================
> > [  511.218003] WARNING: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected
> > [  511.220031] 4.10.0-rc6-next-20170202+ #500 Not tainted
> > [  511.221689] -----------------------------------------------------
> > [  511.223579] a.out/49302 [HC0[0]:SC0[0]:HE1:SE1] is trying to acquire:
> > [  511.225533]  (cpu_hotplug.dep_map){++++++}, at: [<ffffffff810a1477>] get_online_cpus+0x37/0x80
> > [  511.227795] 
> > [  511.227795] and this task is already holding:
> > [  511.230082]  (jbd2_handle){++++-.}, at: [<ffffffff813a8be7>] start_this_handle+0x1a7/0x590
> > [  511.232592] which would create a new lock dependency:
> > [  511.234192]  (jbd2_handle){++++-.} -> (cpu_hotplug.dep_map){++++++}
> > [  511.235966] 
> > [  511.235966] but this new dependency connects a RECLAIM_FS-irq-safe lock:
> > [  511.238563]  (jbd2_handle){++++-.}
> > [  511.238564] 
> > [  511.238564] ... which became RECLAIM_FS-irq-safe at:
> > [  511.242078]   
> > [  511.242084] [<ffffffff811089db>] __lock_acquire+0x34b/0x1640
> > [  511.244495] [<ffffffff8110a119>] lock_acquire+0xc9/0x250
> > [  511.246697] [<ffffffff813b3525>] jbd2_log_wait_commit+0x55/0x1d0
> [...]
> > [  511.276216] to a RECLAIM_FS-irq-unsafe lock:
> > [  511.278128]  (cpu_hotplug.dep_map){++++++}
> > [  511.278130] 
> > [  511.278130] ... which became RECLAIM_FS-irq-unsafe at:
> > [  511.281809] ...
> > [  511.281811]   
> > [  511.282598] [<ffffffff81108141>] mark_held_locks+0x71/0x90
> > [  511.284854] [<ffffffff8110ab6f>] lockdep_trace_alloc+0x6f/0xd0
> > [  511.287218] [<ffffffff812744c8>] kmem_cache_alloc_node_trace+0x48/0x3b0
> > [  511.289755] [<ffffffff810cfa65>] __smpboot_create_thread.part.2+0x35/0xf0
> > [  511.292329] [<ffffffff810d0026>] smpboot_create_threads+0x66/0x90
> [...]
> > [  511.317867] other info that might help us debug this:
> > [  511.317867] 
> > [  511.320920]  Possible interrupt unsafe locking scenario:
> > [  511.320920] 
> > [  511.323218]        CPU0                    CPU1
> > [  511.324622]        ----                    ----
> > [  511.325973]   lock(cpu_hotplug.dep_map);
> > [  511.327246]                                local_irq_disable();
> > [  511.328870]                                lock(jbd2_handle);
> > [  511.330483]                                lock(cpu_hotplug.dep_map);
> > [  511.332259]   <Interrupt>
> > [  511.333187]     lock(jbd2_handle);
> 
> Peter, is there any way how to tell the lockdep that this is in fact
> reclaim safe? The direct reclaim only does the trylock and backs off so
> we cannot deadlock here.
> 
> Or am I misinterpreting the trace?

This is moot - http://lkml.kernel.org/r/20170207201950.20482-1-mhocko@kernel.org

-- 
Michal Hocko
SUSE Labs