From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751722AbdB1ToX (ORCPT ); Tue, 28 Feb 2017 14:44:23 -0500 Received: from merlin.infradead.org ([205.233.59.134]:35310 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751468AbdB1ToR (ORCPT ); Tue, 28 Feb 2017 14:44:17 -0500 Date: Tue, 28 Feb 2017 19:15:47 +0100 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, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, npiggin@gmail.com Subject: Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature Message-ID: <20170228181547.GM5680@worktop> References: <1484745459-2055-1-git-send-email-byungchul.park@lge.com> <1484745459-2055-7-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484745459-2055-7-git-send-email-byungchul.park@lge.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote: > + /* > + * Each work of workqueue might run in a different context, > + * thanks to concurrency support of workqueue. So we have to > + * distinguish each work to avoid false positive. > + * > + * TODO: We can also add dependencies between two acquisitions > + * of different work_id, if they don't cause a sleep so make > + * the worker stalled. > + */ > + unsigned int work_id; > +/* > + * Crossrelease needs to distinguish each work of workqueues. > + * Caller is supposed to be a worker. > + */ > +void crossrelease_work_start(void) > +{ > + if (current->xhlocks) > + current->work_id++; > +} So what you're trying to do with that 'work_id' thing is basically wipe the entire history when we're at the bottom of a context. Which is a useful operation, but should arguably also be done on the return to userspace path. Any historical lock from before the current syscall is irrelevant. (And we should not be returning to userspace with locks held anyway -- lockdep already has a check for that).