[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260130091049.GH3374091@killaraus>
Date: Fri, 30 Jan 2026 11:10:49 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Jason Gunthorpe <jgg@...dia.com>,
Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>,
Johan Hovold <johan@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Tzung-Bi Shih <tzungbi@...nel.org>,
Linus Walleij <linusw@...nel.org>, Jonathan Corbet <corbet@....net>,
Shuah Khan <shuah@...nel.org>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Simona Vetter <simona.vetter@...ll.ch>,
Dan Williams <dan.j.williams@...el.com>, linux-doc@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
Bartosz Golaszewski <brgl@...nel.org>,
maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
tzimmermann@...e.de
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"
On Thu, Jan 29, 2026 at 11:29:03PM +0100, Danilo Krummrich wrote:
> (Cc: Maxime, Thomas, Maarten)
>
> On Thu Jan 29, 2026 at 2:08 AM CET, Laurent Pinchart wrote:
> > That's what I've been advocating for. The best way to ensure that driver
> > code will not accessed data freed at .remove() time is to prevent the
> > code to run at all.
>
> With this we are in full agreement, I think that'd be best too. But, I also
> think that sometimes this isn't possible. For instance, DRM has such a case with
> atomic mode setting.
I don't see why it would be impossible there.
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists