From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id 530D46B0033 for ; Wed, 1 Nov 2017 04:59:32 -0400 (EDT) Received: by mail-pg0-f70.google.com with SMTP id l23so1955041pgc.10 for ; Wed, 01 Nov 2017 01:59:32 -0700 (PDT) Received: from lgeamrelo13.lge.com (LGEAMRELO13.lge.com. [156.147.23.53]) by mx.google.com with ESMTP id q124si144222pga.510.2017.11.01.01.59.30 for ; Wed, 01 Nov 2017 01:59:31 -0700 (PDT) Date: Wed, 1 Nov 2017 17:59:27 +0900 From: Byungchul Park Subject: Re: possible deadlock in lru_add_drain_all Message-ID: <20171101085927.GB3172@X58A-UD3R> References: <20171027134234.7dyx4oshjwd44vqx@dhcp22.suse.cz> <20171030082203.4xvq2af25shfci2z@dhcp22.suse.cz> <20171030100921.GA18085@X58A-UD3R> <20171030151009.ip4k7nwan7muouca@hirez.programming.kicks-ass.net> <20171031131333.pr2ophwd2bsvxc3l@dhcp22.suse.cz> <20171031135104.rnlytzawi2xzuih3@hirez.programming.kicks-ass.net> <20171031145247.5kjbanjqged34lbp@hirez.programming.kicks-ass.net> <20171031145804.ulrpk245ih6t7q7h@dhcp22.suse.cz> <20171031151024.uhbaynabzq6k7fbc@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171031151024.uhbaynabzq6k7fbc@hirez.programming.kicks-ass.net> Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: Michal Hocko , Dmitry Vyukov , syzbot , Andrew Morton , Dan Williams , Johannes Weiner , Jan Kara , jglisse@redhat.com, LKML , linux-mm@kvack.org, shli@fb.com, syzkaller-bugs@googlegroups.com, Thomas Gleixner , Vlastimil Babka , ying.huang@intel.com, kernel-team@lge.com On Tue, Oct 31, 2017 at 04:10:24PM +0100, Peter Zijlstra wrote: > On Tue, Oct 31, 2017 at 03:58:04PM +0100, Michal Hocko wrote: > > On Tue 31-10-17 15:52:47, Peter Zijlstra wrote: > > [...] > > > If we want to save those stacks; we have to save a stacktrace on _every_ > > > lock acquire, simply because we never know ahead of time if there will > > > be a new link. Doing this is _expensive_. > > > > > > Furthermore, the space into which we store stacktraces is limited; > > > since memory allocators use locks we can't very well use dynamic memory > > > for lockdep -- that would give recursive and robustness issues. I agree with all you said. But, I have a better idea, that is, to save only the caller's ip of each acquisition as an additional information? Of course, it's not enough in some cases, but it's cheep and better than doing nothing. For example, when building A->B, let's save not only full stack of B, but also caller's ip of A together, then use them on warning like: -> #3 aa_mutex: a() b() c() d() --- while holding bb_mutex at $IP <- additional information I said -> #2 bb_mutex: e() f() g() h() --- while holding cc_mutex at $IP <- additional information I said -> #1 cc_mutex: i() j() k() l() --- while holding xxx at $IP <- additional information I said and so on. Don't you think this is worth working it? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org