From: William Breathitt Gray <william.gray@linaro.org>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Biju Das <biju.das.jz@bp.renesas.com>, Lee Jones <lee@kernel.org>,
linux-iio@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] counter: rz-mtu3-cnt: Unlock on error in rz_mtu3_count_write()
Date: Wed, 19 Apr 2023 11:30:30 -0400 [thread overview]
Message-ID: <ZEAJFnNiAE+L5ht4@fedora> (raw)
In-Reply-To: <0859b9d5-c504-4f46-83ad-dcd7ada6b81b@kili.mountain>
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
On Wed, Apr 19, 2023 at 06:37:05PM +0300, Dan Carpenter wrote:
> On Wed, Apr 19, 2023 at 10:36:49AM -0400, William Breathitt Gray wrote:
> > The lock is acquired by rz_mtu3_lock_if_counter_is_valid(), so that
> > function needs a sparse __acquires(&priv->lock) annotation too.
>
> I found this bug using Smatch. It's a competing static checker which
> uses Sparse as a parser. I am the author of Smatch so I am naturally
> biased.
>
> I don't think it's as simple as that. I don't think Sparse has
> annotations for mutexes, only for spinlocks? Also it's really
> complicated to annotate something as taking the lock on the success path
> but not on the failure path. You have to set up a wrapper and use
> __cond_lock().
>
> Every other feature in Sparse is awesome, but for locking, it's better
> to just use Smatch.
>
> regards,
> dan carpenter
Ah that's a fair point, I can see how involved that would be to set up a
wrapper and handle the various paths correctly. The marginal benefit
just doesn't seem worth the effort afterall.
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-04-19 15:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 14:23 [PATCH] counter: rz-mtu3-cnt: Unlock on error in rz_mtu3_count_write() Dan Carpenter
2023-04-19 14:36 ` William Breathitt Gray
2023-04-19 15:37 ` Dan Carpenter
2023-04-19 15:30 ` William Breathitt Gray [this message]
2023-04-20 6:04 ` Biju Das
2023-04-20 14:17 ` William Breathitt Gray
2023-04-20 14:58 ` Dan Carpenter
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=ZEAJFnNiAE+L5ht4@fedora \
--to=william.gray@linaro.org \
--cc=biju.das.jz@bp.renesas.com \
--cc=dan.carpenter@linaro.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=lee@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
/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.