All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Bart Van Assche <bvanassche@acm.org>,
	Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Kees Cook <kees@kernel.org>, Jann Horn <jannh@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 00/33] Compile-time thread-safety checking
Date: Fri, 7 Feb 2025 10:05:47 +0100	[thread overview]
Message-ID: <Z6XM6zjK3mtqYfan@elver.google.com> (raw)
In-Reply-To: <20250207084223.GX7145@noisy.programming.kicks-ass.net>

On Fri, Feb 07, 2025 at 09:42AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 06, 2025 at 10:34:09AM -0800, Bart Van Assche wrote:
> 
> > I'm looking forward to the feedback from others about what their opinion
> > is about how to enable thread-safety checking in the Linux kernel.
> 
> So Bart's patches are rather SHOUTING A LOT:-(, which I find really
> jarring to look at.
> 
> Also, however much I despise the sparse thing, that is something we
> already have some of, so we might as well adapt that.
> 
> But I should probably go read up on the whole clang feature first. 
> 
> I've seen both have a __guarded_by() variant for structure members, can
> you stack those?
> 
> Eg. perf has locking where a structure has both a raw_spinlock_t and a
> mutex and modification requires holding both, but holding either is
> sufficient for reading.

Yes, you can add multiple guarded_by. But it's just going to enforce
that you need to hold both locks before you access the member. If you
want the rules to be more complex, the best way to express that is with
some helpers. E.g. something like this (tested on top my series)

--- a/lib/test_capability-analysis.c
+++ b/lib/test_capability-analysis.c
@@ -479,3 +479,53 @@ static void __used test_local_lock_guard(void)
 	{ guard(local_lock_irqsave)(&test_local_lock_data.lock); this_cpu_add(test_local_lock_data.counter, 1); }
 	{ guard(local_lock_nested_bh)(&test_local_lock_data.lock); this_cpu_add(test_local_lock_data.counter, 1); }
 }
+
+struct some_data {
+	spinlock_t lock;
+	struct mutex mtx;
+	int counter __var_guarded_by(&lock) __var_guarded_by(&mtx);
+};
+
+static void some_data_read_lock_via_lock(struct some_data *d)
+	__acquires(&d->lock) __acquires_shared(&d->mtx)
+{
+	spin_lock(&d->lock);
+	__acquire_shared(&d->mtx);
+}
+
+static void some_data_read_unlock_via_lock(struct some_data *d)
+	__releases(&d->lock) __releases_shared(&d->mtx)
+{
+	__release_shared(&d->mtx);
+	spin_unlock(&d->lock);
+}
+
+static void some_data_read_lock_via_mtx(struct some_data *d)
+	__acquires(&d->mtx) __acquires_shared(&d->lock)
+{
+	mutex_lock(&d->mtx);
+	__acquire_shared(&d->lock);
+}
+
+static void some_data_read_unlock_via_mtx(struct some_data *d)
+	__releases(&d->mtx) __releases_shared(&d->lock)
+{
+	__release_shared(&d->lock);
+	mutex_unlock(&d->mtx);
+}
+
+static void __used foo_1(struct some_data *d)
+{
+	some_data_read_lock_via_lock(d);
+	(void)d->counter;
+	// d->counter++;  // error, because mtx only held shared
+	some_data_read_unlock_via_lock(d);
+}
+
+static void __used foo_2(struct some_data *d)
+{
+	some_data_read_lock_via_mtx(d);
+	(void)d->counter;
+	// d->counter++;  // error, because lock only held shared
+	some_data_read_unlock_via_mtx(d);
+}

  reply	other threads:[~2025-02-07  9:05 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06 17:50 [PATCH RFC 00/33] Compile-time thread-safety checking Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 01/33] scsi, usb: Rename the RESERVE and RELEASE constants Bart Van Assche
2025-02-07  3:44   ` Christoph Hellwig
2025-02-06 17:50 ` [PATCH RFC 02/33] s390: Comment out the RELEASE constant Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 03/33] locking: Introduce <linux/thread_safety.h> Bart Van Assche
2025-02-07  3:53   ` Christoph Hellwig
2025-02-07  8:29     ` Marco Elver
2025-02-07 22:34     ` Bart Van Assche
2025-02-07 23:19       ` Marco Elver
2025-02-07 23:50         ` Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 04/33] include/linux/cleanup.h: Support thread-safety analysis Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 05/33] locking/mutex: Change the atomic_dec_and_mutex_lock() return type Bart Van Assche
2025-02-07  3:47   ` Christoph Hellwig
2025-02-06 17:50 ` [PATCH RFC 06/33] locking/mutex: Annotate struct mutex and mutex functions Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 07/33] driver core: Annotate locking functions in <linux/device.h> Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 08/33] kref: Add thread-safety annotations in <linux/kref.h> Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 09/33] refcount: Add thread-safety annotations in <linux/refcount.h> Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 10/33] treewide: Modify mutex_lock_interruptible() return value checks Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 11/33] PNP: isapnp: Check the isapnp_cfg_begin() return value Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 12/33] scsi: mpi3mr: Fix locking in an error path Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 13/33] scsi: mpt3sas: Fix a locking bug " Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 14/33] ice: Split ice_dcb_rebuild() Bart Van Assche
2025-02-06 22:01   ` Przemek Kitszel
2025-02-06 17:50 ` [PATCH RFC 15/33] ice: Fix a locking bug in an error path Bart Van Assche
2025-02-06 21:35   ` Tony Nguyen
2025-02-06 21:44     ` Bart Van Assche
2025-02-06 21:48       ` Tony Nguyen
2025-02-06 17:50 ` [PATCH RFC 16/33] net/mlx5e: Make the code easier to analyze Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 17/33] Input: synaptics-rmi4 - fix a locking bug in an error path Bart Van Assche
2025-02-06 17:50 ` [PATCH RFC 18/33] misc: nsm: Fix " Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 19/33] drm/amdgpu: Unlock a mutex before destroying it Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 20/33] drm/amdgpu: Fix a locking bug in an error path Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 21/33] drm/amdgpu: Fix locking bugs in error paths Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 22/33] drm: bridge: cdns-mhdp8546: Fix a locking bug in an error path Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 23/33] " Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 24/33] drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set() Bart Van Assche
2025-02-06 19:22   ` Sean Anderson
2025-02-06 20:24     ` Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 25/33] wifi: ath12k: Fix locking in error paths Bart Van Assche
2025-02-06 18:25   ` Jeff Johnson
2025-02-06 22:13     ` Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 26/33] mctp i3c: " Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 27/33] iavf: Fix a locking bug in an error path Bart Van Assche
2025-02-12  2:03   ` Jakub Kicinski
2025-02-06 17:51 ` [PATCH RFC 28/33] wifi: mt76: mt7925: " Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 29/33] hwmon: (it87) Check the it87_lock() return value Bart Van Assche
2025-02-06 22:51   ` Guenter Roeck
2025-02-06 23:34     ` Bart Van Assche
2025-02-06 23:41       ` Guenter Roeck
2025-02-09  5:04         ` Frank Crawford
2025-02-07  3:45     ` Christoph Hellwig
2025-02-06 17:51 ` [PATCH RFC 30/33] drivers/net/ethernet/marvell/octeontx2/nic: Fix locking in an error path Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 31/33] md/raid*: Fix raid*_set_queue_limits() Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 32/33] treewide: Annotate all struct mutex users Bart Van Assche
2025-02-06 17:51 ` [PATCH RFC 33/33] kbuild: clang: Unconditionally enable thread-safety checking Bart Van Assche
2025-02-06 18:20 ` [PATCH RFC 00/33] Compile-time " Marco Elver
2025-02-06 18:34   ` Bart Van Assche
2025-02-07  8:42     ` Peter Zijlstra
2025-02-07  9:05       ` Marco Elver [this message]
2025-02-07  9:08         ` Peter Zijlstra
2025-02-07  9:41           ` Marco Elver
2025-02-07 17:46           ` Bart Van Assche
2025-02-07 18:24             ` Marco Elver
2025-02-07 18:35               ` Bart Van Assche
2025-02-07 18:54                 ` Marco Elver
2025-02-07  3:44   ` Christoph Hellwig

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=Z6XM6zjK3mtqYfan@elver.google.com \
    --to=elver@google.com \
    --cc=bvanassche@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jannh@google.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=will@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.