On Wed, Jan 28, 2026 at 04:20:02PM +0100, Bartosz Golaszewski wrote:
> On Wed, Jan 28, 2026 at 4:05 PM Jason Gunthorpe <[email protected]> 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.
Oh, I didn't know you could safely use SRCU within atomic
sections. That's a pretty good reason to use it in some places.
> struct subsys_data {
> struct driver_data __rcu *priv;
> struct device dev;
> }
IMHO this is not a good pattern.
The thing to RCU protect is the *driver ops* pointer, not the driver
data. It is what I was saying before, the goal is to not call ops if
the driver is revoked so that the ops can assume they are in a
Device<Bound> context.
It should not be normal for the core code to be touching priv at all,
it has no natural reason to ever load it. It does have to fetch ops!
Jason
