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;
MIME-Version: 1.0
References: <20181212022506.171936-1-dbasehore@chromium.org>
 <20181212022506.171936-2-dbasehore@chromium.org> <20181212090901.GV5289@hirez.programming.kicks-ass.net>
In-Reply-To: <20181212090901.GV5289@hirez.programming.kicks-ass.net>
From:   "dbasehore ." <dbasehore@chromium.org>
Date:   Wed, 12 Dec 2018 03:42:54 -0800
Message-ID: <CAGAzgsrj91jyp96XPiww=32NUhbcwH9q_t0OxzotRF-3Zga_=Q@mail.gmail.com>
Subject: Re: RFC [PATCH 1/1] locking/lockdep: Fix nest lock warning on unlock
To:     Peter Zijlstra <peterz@infradead.org>, sboyd@kernel.org
Cc:     Ingo Molnar <mingo@redhat.com>, will.deacon@arm.com,
        linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Dec 12, 2018 at 1:09 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Dec 11, 2018 at 06:25:06PM -0800, Derek Basehore wrote:
> > The function __lock_acquire checks that the nest lock is held passed
> > in as an argument. The issue with this is that __lock_acquire is used
> > for internal bookkeeping on lock_release. This produces a false
> > positive lockdep warning on unlock. Since you explicitly don't need to
> > hold the nest lock on unlock, this is an issue.
>
> Who is triggering this?

I'm writing code right now that triggers this. The goal is to reduce
lock contention in the Common Clk Framework by getting rid of its
global lock. One of the approaches I'm considering is adding a nest
lock with n "subtree" locks. After locking all of the needed subtree
locks, it's important to unlock the nest lock to reduce contention.