From: Johan Hovold <johan@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Tzung-Bi Shih <tzungbi@kernel.org>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Linus Walleij <linusw@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Simona Vetter <simona.vetter@ffwll.ch>,
Dan Williams <dan.j.williams@intel.com>,
Jason Gunthorpe <jgg@nvidia.com>,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, Johan Hovold <johan@kernel.org>
Subject: [PATCH v2 0/3] Revert "revocable: Revocable resource management"
Date: Wed, 4 Feb 2026 15:28:46 +0100 [thread overview]
Message-ID: <20260204142849.22055-1-johan@kernel.org> (raw)
I was surprised to learn that the revocable functionality was merged the other
week given the community feedback on list and at LPC, but not least since there
are no users of it, which we are supposed to require to be able to evaluate it
properly.
The chromeos ec driver issue which motivated this work turned out not to need
it as was found during review. And the example gpiolib conversion was posted
the very same morning that this was merged which hardly provides enough time
for evaluation (even if Bartosz quickly reported a performance regression).
Turns out there are correctness issues with both the gpiolib conversion and
the revocable design itself that can lead to use-after-free and hung tasks (see
[1] and [2]).
And as was pointed out repeatedly during review, and again at the day of the
merge, this does not look like the right interface for the chardev unplug
issue.
Despite the last-minute attempt at addressing the issues mentioned above
incrementally, the revocable design is still fundamentally flawed (see patch
3/3).
We have processes like requiring a user before merging a new interface so that
issues like these can be identified and the soundness of an API be evaluated.
They also give a sense of when things are expected to happen, which allows our
scarce reviewers to manage their time (e.g. to not be forced to drop everything
else they are doing when things are merged prematurely).
There really is no reason to exempt any new interface from this regardless of
whether one likes the underlying concept or not.
Revert the revocable implementation until a redesign has been proposed and
evaluated properly.
Johan
[1] https://lore.kernel.org/all/aXT45B6vLf9R3Pbf@hovoldconsulting.com/
[2] https://lore.kernel.org/all/20260124170535.11756-4-johan@kernel.org/
Changes in v2:
- revert also the incremental changes in driver-core-next
- explain why the latest revocable design is still fundamentally broken
Johan Hovold (3):
Revert "selftests: revocable: Add kselftest cases"
Revert "revocable: Add Kunit test cases"
Revert "revocable: Revocable resource management"
.../driver-api/driver-model/index.rst | 1 -
.../driver-api/driver-model/revocable.rst | 149 ---------
MAINTAINERS | 9 -
drivers/base/Kconfig | 8 -
drivers/base/Makefile | 3 -
drivers/base/revocable.c | 225 --------------
drivers/base/revocable_test.c | 284 ------------------
include/linux/revocable.h | 89 ------
.../selftests/drivers/base/revocable/Makefile | 7 -
.../drivers/base/revocable/revocable_test.c | 136 ---------
.../drivers/base/revocable/test-revocable.sh | 39 ---
.../base/revocable/test_modules/Makefile | 10 -
.../revocable/test_modules/revocable_test.c | 187 ------------
13 files changed, 1147 deletions(-)
delete mode 100644 Documentation/driver-api/driver-model/revocable.rst
delete mode 100644 drivers/base/revocable.c
delete mode 100644 drivers/base/revocable_test.c
delete mode 100644 include/linux/revocable.h
delete mode 100644 tools/testing/selftests/drivers/base/revocable/Makefile
delete mode 100644 tools/testing/selftests/drivers/base/revocable/revocable_test.c
delete mode 100755 tools/testing/selftests/drivers/base/revocable/test-revocable.sh
delete mode 100644 tools/testing/selftests/drivers/base/revocable/test_modules/Makefile
delete mode 100644 tools/testing/selftests/drivers/base/revocable/test_modules/revocable_test.c
--
2.52.0
next reply other threads:[~2026-02-04 14:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 14:28 Johan Hovold [this message]
2026-02-04 14:28 ` [PATCH v2 1/3] Revert "selftests: revocable: Add kselftest cases" Johan Hovold
2026-02-04 14:28 ` [PATCH v2 2/3] Revert "revocable: Add Kunit test cases" Johan Hovold
2026-02-04 14:28 ` [PATCH v2 3/3] Revert "revocable: Revocable resource management" Johan Hovold
2026-02-05 8:51 ` Tzung-Bi Shih
2026-02-05 11:56 ` Danilo Krummrich
2026-02-06 9:14 ` Tzung-Bi Shih
2026-02-05 14:03 ` Johan Hovold
2026-02-06 9:14 ` Tzung-Bi Shih
2026-02-06 15:07 ` Johan Hovold
2026-02-06 15:13 ` [PATCH v2 0/3] " Greg Kroah-Hartman
2026-02-07 14:00 ` Tzung-Bi Shih
2026-02-13 8:32 ` Bartosz Golaszewski
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=20260204142849.22055-1-johan@kernel.org \
--to=johan@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linusw@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=shuah@kernel.org \
--cc=simona.vetter@ffwll.ch \
--cc=tzungbi@kernel.org \
--cc=wsa+renesas@sang-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox