linux-kernel - Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=McE5yTQ2hcLiR6asQWEi=Y1rhHzqq7G6FR58LCFZi6BAA@mail.gmail.com>
Date: Wed, 28 Jan 2026 16:20:02 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>, Johan Hovold <johan@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Danilo Krummrich <dakr@...nel.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>, 
	Laurent Pinchart <laurent.pinchart@...asonboard.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 <bartosz.golaszewski@....qualcomm.com>
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

On Wed, Jan 28, 2026 at 4:05 PM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> On Wed, Jan 28, 2026 at 11:01:03AM +0100, Wolfram Sang wrote:
> >
> > > One exception is I2C where the logic is so broken we need to first
> > > rework a lot of drivers.
> >
> > Let's say "bitrotten" instead of broken. People used what was available
> > at that time and they prevented the kernel from crashing, at least. And
> > up to now, nobody had the bandwidth to improve that part in I2C.
> >
> > > Wolfram is on board with that though.
> >
> > Ack. I want to emphasize here that for I2C the SRCU part goes into the
> > subsystem, not into the drivers.
>
> I would just gently advise again that SRCU is not a pancea and should
> only be used if the read side sections are super performance
> critical. I'm not sure that describes I2C. rwsem is often a simpler
> and better choice.
>

Sure. We're not there yet so that's TBD. The reason for using SRCU in
GPIO was the fact that we have consumers that may call into GPIOLIB
from atomic context - so we must not sleep - but we also have sleeping
controllers - so we must not take a spinlock before entering driver
code. SRCU was about the only synchronization mechanism that worked in
all cases as the locking at the subsystem level needs to be
centralized.

Also SRCU protects pointers by design, which makes the split into
subsystem- and provider-owned data logical in this case:

struct subsys_data {
  struct driver_data __rcu *priv;
  struct device dev;
}

Bartosz