Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756906AbdGLH43 (ORCPT ); Wed, 12 Jul 2017 03:56:29 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:48323 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751350AbdGLH41 (ORCPT ); Wed, 12 Jul 2017 03:56:27 -0400 Date: Wed, 12 Jul 2017 09:56:17 +0200 From: Peter Zijlstra To: Byungchul Park Cc: mingo@kernel.org, tglx@linutronix.de, walken@google.com, boqun.feng@gmail.com, kirill@shutemov.name, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, willy@infradead.org, npiggin@gmail.com, kernel-team@lge.com Subject: Re: [PATCH v7 06/16] lockdep: Detect and handle hist_lock ring buffer overwrite Message-ID: <20170712075617.o2jds2giuoqxjqic@hirez.programming.kicks-ass.net> References: <1495616389-29772-1-git-send-email-byungchul.park@lge.com> <1495616389-29772-7-git-send-email-byungchul.park@lge.com> <20170711161232.GB28975@worktop> <20170712020053.GB20323@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170712020053.GB20323@X58A-UD3R> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1666 Lines: 46 On Wed, Jul 12, 2017 at 11:00:53AM +0900, Byungchul Park wrote: > On Tue, Jul 11, 2017 at 06:12:32PM +0200, Peter Zijlstra wrote: > > Right, like I wrote in the comment; I don't think you need quite this > > much. > > > > The problem only happens if you rewind more than MAX_XHLOCKS_NR; > > although I realize it can be an accumulative rewind, which makes it > > slightly more tricky. > > > > We can either make the rewind more expensive and make xhlock_valid() > > false for each rewound entry; or we can keep the max_idx and account > > Does max_idx mean the 'original position - 1'? orig_idx = current->hist_idx; current->hist_idx++; if ((int)(current->hist_idx - orig_idx) > 0) current->hist_idx_max = current->hist_idx; I've forgotten if the idx points to the most recent entry or beyond it. Given the circular nature, and tail being one ahead of head, the max effectively tracks the tail (I suppose we can also do an explicit tail tracking, but that might end up more difficult). This allows rewinds of less than array_size() while still maintaining a correct tail. Only once we (cummulative or not) rewind past the tail -- iow, loose the _entire_ history, do we need to do something drastic. > > from there. If we rewind >= MAX_XHLOCKS_NR from the max_idx we need to > > invalidate the entire state, which we can do by invaliding > > Could you explain what the entire state is? All hist_lock[]. Did the above help? > > xhlock_valid() or by re-introduction of the hist_gen_id. When we > > What does the re-introduction of the hist_gen_id mean? What you used to call work_id or something like that. A generation count for the hist_lock[].