Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1980514imm; Sun, 27 May 2018 22:20:18 -0700 (PDT) X-Google-Smtp-Source: ADUXVKINDMSJ8uLCVsSGfN7x0kIyNf1GhBM7d/TOaaaqBXXLSGgt/r4m8wqrT54hv10nDctCVBU7 X-Received: by 2002:a17:902:be0c:: with SMTP id r12-v6mr977171pls.350.1527484818037; Sun, 27 May 2018 22:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527484818; cv=none; d=google.com; s=arc-20160816; b=Q3O+fG+SZQlYb8fte0VLdo9Fi1CpiEhuofq9X6qsp649TcVySVpfcPIcqQpuzYSTaD fNlrdqMi13FzvVpi99R6NS40DxcmJ2qDuU/Gzv+7wHtUxHKEPZHtqo0CpheiqKkR0Uto wnl+1RcuXKnBrtDnOyksPKLMzrhctfuYy15llBxlTYhSNhWLEf2InP6LKo4GcEuMLOcc ubgmx92NrDGi1TLq/NvaL/bPpSoG83bfTjX/tyeqlXk5vkndB6ZcAK9gyA1YEgjD7hnJ uioh1bypzvQJwG2V623Hvz21j//0F9clMocYPzXDGSGp9GKHsCTRj07hn1Ddff+3a1ME Y9Pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=G9NXX9j5fk6fB4tCGdNI1lL1cFAJ3xsDOle3HLmmuaY=; b=pImwTXnmjEv4zK58CIYEOtFeMdC+uPk80v+z43wBPdeGI3T6hpxv2NcQt+Ln5t7eBd o9oqCf7FhcYUbvFBgKIFtPAJKh7gx3K/RpeyXPs+F97U5H3a/C0aBUEEEDnIbPOlIaOA az0QAlw9nITkfP4uEgjPlOczPEG6JaSfoNDs0Gc5ABfhULRIwQ6+uwr2cPQQCoTbMQGE lRVSTi9NaDHYg2NWC4ibrtJRQdhKqGXufGcRAVphxpRUSMzNCCUPSA8fOGpBE8Od2b6z jfDrE3XNIzQJONq0QTtxUhjYDtBvQITekwlt8MeVzeh4NmHD/sh38Z9F2+ctaZa0487U wm0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=fPowo6i9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q23-v6si3443161pls.101.2018.05.27.22.19.48; Sun, 27 May 2018 22:20:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=fPowo6i9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753142AbeE1FTj (ORCPT + 99 others); Mon, 28 May 2018 01:19:39 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:33208 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765AbeE1FTh (ORCPT ); Mon, 28 May 2018 01:19:37 -0400 Received: by mail-pg0-f68.google.com with SMTP id e21-v6so4783319pgv.0 for ; Sun, 27 May 2018 22:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=G9NXX9j5fk6fB4tCGdNI1lL1cFAJ3xsDOle3HLmmuaY=; b=fPowo6i9TDMBsbNomJvJCNR46n6HhwOdpybJcvtpTrMw1Y7TUtiB6uO0gl24NBm3Ho v83RYBFceddyf0sLBsEyvkdDFKNbn0pwEehxxJf3Td6fysXoQzrrFyWnX2k65V/0BfXO GzRgCeBdfNXVO57DAawgA8W74cdlexZll0+EI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=G9NXX9j5fk6fB4tCGdNI1lL1cFAJ3xsDOle3HLmmuaY=; b=gAwmNwsKKB9hKhVzm2G4HBsKdAL6frghKbDb/JQSSJ332sz+iyWngjRaBfMyGIO7eW mqVUy8aeOIhKfcBC8K6xnchkqL+H6QE8xAtKmC1EG/Umm+TIAEujMkfZr0Zorqqw6DaR evc55tt96gPmz6liLKwxqos9aQhn9a3O5jZNot0v3/u73LrCZtdy9H98ljvjb2R6UvAg AWc7kynGAmqwufgu/jhv0XifHJowv1nJ2Ii8gi5Rac4dv98xJfjxJm06NVpNyCTnUxNo doZrGgJHQQ1XK1YRYym5Uini2J4v6qA+2FLQ6eRTFQcKeTy3R/OymPARWB1hRQnEaX6R gyVw== X-Gm-Message-State: ALKqPwea354HH0mLNCaRVC3iLn54grHaQvVFM9g9tYuDF8BHsLmWhHt/ w9YsT3qp04deqUY5yQEUre7Egg== X-Received: by 2002:a62:1013:: with SMTP id y19-v6mr791628pfi.166.1527484777166; Sun, 27 May 2018 22:19:37 -0700 (PDT) Received: from localhost ([2620:0:1000:1600:3122:ea9c:d178:eb]) by smtp.gmail.com with ESMTPSA id n18-v6sm67135741pfg.36.2018.05.27.22.19.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 27 May 2018 22:19:36 -0700 (PDT) Date: Sun, 27 May 2018 22:19:36 -0700 From: Joel Fernandes To: Peter Rosin Cc: linux-kernel@vger.kernel.org, Wolfram Sang , Peter Zijlstra , Ingo Molnar , Will Deacon , Davidlohr Bueso , Philippe Ombredanne , Thomas Gleixner , Greg Kroah-Hartman , linux-i2c@vger.kernel.org, Peter Chang , Deepa Dinamani , John Sperbeck Subject: Re: [PATCH v3 1/2] rtmutex: allow specifying a subclass for nested locking Message-ID: <20180528051936.GA205298@joelaf.mtv.corp.google.com> References: <20180524135240.10881-1-peda@axentia.se> <20180524135240.10881-2-peda@axentia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180524135240.10881-2-peda@axentia.se> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 24, 2018 at 03:52:39PM +0200, Peter Rosin wrote: > Needed for annotating rt_mutex locks. > > Signed-off-by: Peter Rosin > --- > include/linux/rtmutex.h | 7 +++++++ > kernel/locking/rtmutex.c | 29 +++++++++++++++++++++++++---- > 2 files changed, 32 insertions(+), 4 deletions(-) > > diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h > index 1b92a28dd672..6fd615a0eea9 100644 > --- a/include/linux/rtmutex.h > +++ b/include/linux/rtmutex.h > @@ -106,7 +106,14 @@ static inline int rt_mutex_is_locked(struct rt_mutex *lock) > extern void __rt_mutex_init(struct rt_mutex *lock, const char *name, struct lock_class_key *key); > extern void rt_mutex_destroy(struct rt_mutex *lock); > > +#ifdef CONFIG_DEBUG_LOCK_ALLOC > +extern void rt_mutex_lock_nested(struct rt_mutex *lock, unsigned int subclass); > +#define rt_mutex_lock(lock) rt_mutex_lock_nested(lock, 0) > +#else > extern void rt_mutex_lock(struct rt_mutex *lock); > +#define rt_mutex_lock_nested(lock, subclass) rt_mutex_lock(lock) > +#endif > + > extern int rt_mutex_lock_interruptible(struct rt_mutex *lock); > extern int rt_mutex_timed_lock(struct rt_mutex *lock, > struct hrtimer_sleeper *timeout); > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c : > } > > +static inline void __rt_mutex_lock(struct rt_mutex *lock, unsigned int subclass) > +{ > + might_sleep(); > + > + mutex_acquire(&lock->dep_map, subclass, 0, _RET_IP_); > + rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock); > +} > + > +#ifdef CONFIG_DEBUG_LOCK_ALLOC > +/** > + * rt_mutex_lock_nested - lock a rt_mutex This ifdef seems consistent with other nested locking primitives, but its kind of confusing. The Kconfig.debug for DEBUG_LOCK_ALLOC says: config DEBUG_LOCK_ALLOC bool "Lock debugging: detect incorrect freeing of live locks" [...] help This feature will check whether any held lock (spinlock, rwlock, mutex or rwsem) is incorrectly freed by the kernel, via any of the memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), vfree(), etc.), whether a live lock is incorrectly reinitialized via spin_lock_init()/mutex_init()/etc., or whether there is any lock held during task exit. Shouldn't this ideally be ifdef'd under PROVE_LOCKING for this and other locking primitives? Any idea what's the reason? I know PROVE_LOCKING selects DEBUG_LOCK_ALLOC but still.. thanks! - Joel