[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DFX20SA67PF2.VONCFNDOZOZT@kernel.org>
Date: Sat, 24 Jan 2026 20:08:28 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Johan Hovold" <johan@...nel.org>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Rafael J . Wysocki"
<rafael@...nel.org>, "Tzung-Bi Shih" <tzungbi@...nel.org>, "Bartosz
Golaszewski" <bartosz.golaszewski@....qualcomm.com>, "Linus Walleij"
<linusw@...nel.org>, "Jonathan Corbet" <corbet@....net>, "Shuah Khan"
<shuah@...nel.org>, "Laurent Pinchart" <laurent.pinchart@...asonboard.com>,
"Wolfram Sang" <wsa+renesas@...g-engineering.com>, "Simona Vetter"
<simona.vetter@...ll.ch>, "Dan Williams" <dan.j.williams@...el.com>, "Jason
Gunthorpe" <jgg@...dia.com>, <linux-doc@...r.kernel.org>,
<linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"
On Sat Jan 24, 2026 at 6:05 PM CET, Johan Hovold wrote:
> this does not look like the right interface for the chardev unplug issue.
I think it depends, we should do everything to prevent having the issue in the
first place, e.g. ensure that we synchronize the unplug properly on device
driver unbind.
Sometimes, however, this isn't possible; this is where a revocable mechanism can
come in handy to prevent UAF of device resources -- DRM is a good example for
this.
But to be fair, I also want to point out that there is a quite significant
difference regarding the usefulness of the revocable concept in C compared to in
Rust due to language capabilities.
Powered by blists - more mailing lists