[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MdnzSEDD8tiioY9h8QmWA5k=h=DHMbvKkROQ9OFMKDycQ@mail.gmail.com>
Date: Tue, 3 Feb 2026 17:53:29 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Tzung-Bi Shih <tzungbi@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>, 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>, Jason Gunthorpe <jgg@...dia.com>,
Johan Hovold <johan@...nel.org>, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, chrome-platform@...ts.linux.dev,
Dan Williams <dan.j.williams@...el.com>, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v2 00/11] gpio: Adopt revocable mechanism for UAF prevention
On Tue, Feb 3, 2026 at 7:11 AM Tzung-Bi Shih <tzungbi@...nel.org> wrote:
>
> This series transitions the UAF prevention logic within the GPIO core
> (gpiolib) to use the 'revocable' mechanism.
>
> The existing code aims to prevent UAF issues when the underlying GPIO
> chip is removed. This series replaces that custom logic with the
> generic 'revocable' API, which is designed to handle such lifecycle
> dependencies. There should be no changes in behavior.
>
> The series applies after:
> - https://lore.kernel.org/all/20260129143733.45618-1-tzungbi@kernel.org
> - https://lore.kernel.org/all/20260203060210.972243-1-tzungbi@kernel.org
>
> Bartosz: the series was planned to send after -rc1 comes. But I think
> it'd be great to send out for your early review and testing if possible.
> The series base on v6.19-rc8, driver-core-next, and gpio/for-next.
> Please use the temporary integration testing branch
> https://git.kernel.org/pub/scm/linux/kernel/git/tzungbi/chrome-platform.git/log/?h=gpio_rev
> if you'd like to.
>
One high-level note: for this to be accepted into GPIO, the revocable
API contract must state very clearly that revocable_try_access() works
from process AND atomic context while also allowing sleeping inside
revocable critical sections. I'm saying this because while we use
naked SRCU, we can rely on the SRCU contract. Once we switch to
revocable, if someone - for instance - comes up with an idea of
replacing the internal primitives with rwsem, GPIO will break.
Bartosz
Powered by blists - more mailing lists