[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181115184917.6goqg67hpojfhk42@linux-r8p5>
Date: Thu, 15 Nov 2018 10:49:17 -0800
From: Davidlohr Bueso <dave@...olabs.net>
To: "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
fweisbec@...il.com, oleg@...hat.com, joel@...lfernandes.org,
Lance Roy <ldr709@...il.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Yang Shi <yang.shi@...ux.alibaba.com>,
Matthew Wilcox <mawilcox@...rosoft.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Jan Kara <jack@...e.cz>, Shakeel Butt <shakeelb@...gle.com>,
linux-mm@...ck.org
Subject: Re: [PATCH tip/core/rcu 6/7] mm: Replace spin_is_locked() with
lockdep
On Sun, 11 Nov 2018, Paul E. McKenney wrote:
>From: Lance Roy <ldr709@...il.com>
>
>lockdep_assert_held() is better suited to checking locking requirements,
>since it only checks if the current thread holds the lock regardless of
>whether someone else does. This is also a step towards possibly removing
>spin_is_locked().
So fyi I'm not crazy about these kind of patches simply because lockdep
is a lot less used out of anything that's not a lab, and we can be missing
potential offenders. There's obviously nothing wrong about what you describe
above perse, just my two cents.
Thansk,
Davidlohr
Powered by blists - more mailing lists