[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yr3EmEcO1AMFRlLA@hirez.programming.kicks-ass.net>
Date: Thu, 30 Jun 2022 17:43:20 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Alexander Aring <aahringo@...hat.com>
Cc: will@...nel.org, boqun.feng@...il.com, mark.rutland@....com,
thunder.leizhen@...wei.com, jacob.e.keller@...el.com,
akpm@...ux-foundation.org, linux-sparse@...r.kernel.org,
cluster-devel@...hat.com, luc.vanoostenryck@...il.com,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/2] refcount: add __cond_lock() for conditional lock
refcount API
On Thu, Jun 30, 2022 at 09:59:33AM -0400, Alexander Aring wrote:
> This patch adds the __cond_lock() macro to refcounts conditional lock
> API. Currently sparse cannot detect the conditional lock handling of
> refcount_dec_and_lock() functionality and prints a context imbalance
> warning like:
>
> warning: context imbalance in 'put_rsb' - unexpected unlock
>
> with this patch and having the refcount_dec_and_lock() functionality
> inside the if condition to decide whenever doing unlock or not the
> warning disappears.
>
> The patch follows a similar naming scheme like raw_spin_trylock() by
> adding a "raw_" prefix to refcount_dec_and_lock() functionality and
> introduce a macro for the replaced functions that uses __cond_lock()
> to signal that an acquire depends on the return value of the passed
> function.
>
> A cast to bool seems to be necessary because __cond_lock() does return a
> non-boolean scalar type.
I hate the __cond_lock() think with a passions. Please just fix sparse
to not suck.
Powered by blists - more mailing lists