From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Alexander Aring <aahringo@redhat.com>
Cc: jacob.e.keller@intel.com, akpm@linux-foundation.org,
thunder.leizhen@huawei.com, linux-sparse@vger.kernel.org,
cluster-devel <cluster-devel@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: sparse warnings related to kref_put_lock() and refcount_dec_and_lock()
Date: Tue, 28 Jun 2022 10:58:21 +0200 [thread overview]
Message-ID: <20220628085821.kn3jjrviyprgai4w@mail> (raw)
In-Reply-To: <CAK-6q+g795MwPvUGxWXTE+s-TfJnbh2wf=Udb1k7r6ru-4FTMQ@mail.gmail.com>
On Mon, Jun 27, 2022 at 09:06:43PM -0400, Alexander Aring wrote:
> >
> > If we change the refcount code to _never_ calling unlock() for the
> > specific lock, then all those foo_and_lock_bar() functions can be
> > annotated with "__acquires()". This should also end in the same code?
>
> sorry, this will not work because of the first condition of "if
> (refcount_dec_not_one(r))" which will never hold the lock if true...
> that's what the optimization is all about. However, maybe somebody has
> another idea...
I would certainly not recommend this but ...
if it's OK to cheat and lie then you can do:
+ bool refcount_dec_and_lock(refcount_t *r, spinlock_t *lock) __acquires(lock);
+
bool refcount_dec_and_lock(refcount_t *r, spinlock_t *lock)
{
- if (refcount_dec_not_one(r))
- return false;
+ if (refcount_dec_not_one(r)) {
+ __acquire(lock);
+ return false;
+ }
spin_lock(lock);
if (!refcount_dec_and_test(r)) {
spin_unlock(lock);
+ __acquire(lock);
return false;
}
return true;
}
In other word, pretend that the lock is always taken but ...
1) it's ugly
2) it's lying and can be confusing
3) now all the users of this function will have an imbalance problem
(but they probably already have one since refcount_dec_and_lock()
is not annotated).
What is needed is some kind of annotation for conditional locks.
I've tried a few time and in itself it was working but in most
cases the usage pattern was so that there was a imbalance anyway.
-- Luc
WARNING: multiple messages have this Message-ID (diff)
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] sparse warnings related to kref_put_lock() and refcount_dec_and_lock()
Date: Tue, 28 Jun 2022 10:58:21 +0200 [thread overview]
Message-ID: <20220628085821.kn3jjrviyprgai4w@mail> (raw)
In-Reply-To: <CAK-6q+g795MwPvUGxWXTE+s-TfJnbh2wf=Udb1k7r6ru-4FTMQ@mail.gmail.com>
On Mon, Jun 27, 2022 at 09:06:43PM -0400, Alexander Aring wrote:
> >
> > If we change the refcount code to _never_ calling unlock() for the
> > specific lock, then all those foo_and_lock_bar() functions can be
> > annotated with "__acquires()". This should also end in the same code?
>
> sorry, this will not work because of the first condition of "if
> (refcount_dec_not_one(r))" which will never hold the lock if true...
> that's what the optimization is all about. However, maybe somebody has
> another idea...
I would certainly not recommend this but ...
if it's OK to cheat and lie then you can do:
+ bool refcount_dec_and_lock(refcount_t *r, spinlock_t *lock) __acquires(lock);
+
bool refcount_dec_and_lock(refcount_t *r, spinlock_t *lock)
{
- if (refcount_dec_not_one(r))
- return false;
+ if (refcount_dec_not_one(r)) {
+ __acquire(lock);
+ return false;
+ }
spin_lock(lock);
if (!refcount_dec_and_test(r)) {
spin_unlock(lock);
+ __acquire(lock);
return false;
}
return true;
}
In other word, pretend that the lock is always taken but ...
1) it's ugly
2) it's lying and can be confusing
3) now all the users of this function will have an imbalance problem
(but they probably already have one since refcount_dec_and_lock()
is not annotated).
What is needed is some kind of annotation for conditional locks.
I've tried a few time and in itself it was working but in most
cases the usage pattern was so that there was a imbalance anyway.
-- Luc
next prev parent reply other threads:[~2022-06-28 8:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 15:15 sparse warnings related to kref_put_lock() and refcount_dec_and_lock() Alexander Aring
2022-06-27 15:15 ` [Cluster-devel] " Alexander Aring
2022-06-27 18:42 ` Luc Van Oostenryck
2022-06-27 18:42 ` [Cluster-devel] " Luc Van Oostenryck
2022-06-28 0:56 ` Alexander Aring
2022-06-28 0:56 ` [Cluster-devel] " Alexander Aring
2022-06-28 1:06 ` Alexander Aring
2022-06-28 1:06 ` [Cluster-devel] " Alexander Aring
2022-06-28 8:58 ` Luc Van Oostenryck [this message]
2022-06-28 8:58 ` Luc Van Oostenryck
2022-06-28 13:26 ` Alexander Aring
2022-06-28 13:26 ` [Cluster-devel] " Alexander Aring
2022-06-28 17:27 ` Linus Torvalds
2022-06-28 17:27 ` [Cluster-devel] " Linus Torvalds
2022-06-29 14:42 ` Alexander Aring
2022-06-29 14:42 ` [Cluster-devel] " Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220628085821.kn3jjrviyprgai4w@mail \
--to=luc.vanoostenryck@gmail.com \
--cc=aahringo@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cluster-devel@redhat.com \
--cc=jacob.e.keller@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=thunder.leizhen@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.