From: Christoph Hellwig <hch@lst.de>
To: Marco Elver <elver@google.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
Peter Zijlstra <peterz@infradead.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 04:44:10 +0100 [thread overview]
Message-ID: <20250207034410.GA4596@lst.de> (raw)
In-Reply-To: <CANpmjNOsf1RnYJuZ7pmWVYNqVYMYe+eTL0vhDKU5sLihR9fN-g@mail.gmail.com>
On Thu, Feb 06, 2025 at 07:20:33PM +0100, Marco Elver wrote:
> Combining approach #1 and #2 may somehow be possible, but it is
> currently eluding me. Clearly, based on the bugs that Bart found, some
> way to do tree-wide analysis is very useful!
> One idea was to have "capability-selective tree-wide analysis" (such
> as mutex only) be controllable via a Kconfig option - the
> implementation of that (without excessive ifdefs sprinkled
> everywhere), however, most likely requires compiler support.
>
> Depending on the feedback that results from these RFCs, I think we
> will be able to plan better which direction things should go.
Opt-in just means some code will never get it. So I think we'll
need to eventually force all the useful capabilities everywhere.
Doing that step by step by opt-in/opt-out for early adopters sounds
fine.
prev parent reply other threads:[~2025-02-07 3:44 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
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 [this message]
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=20250207034410.GA4596@lst.de \
--to=hch@lst.de \
--cc=bvanassche@acm.org \
--cc=elver@google.com \
--cc=gregkh@linuxfoundation.org \
--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.