Re: [PATCH v2 0/4] gpio: fix an incorrect lockdep warning
From: Peter Zijlstra
Date: Tue Sep 20 2016 - 06:29:00 EST
On Tue, Sep 20, 2016 at 12:07:39PM +0200, Bartosz Golaszewski wrote:
> 2016-09-20 10:48 GMT+02:00 Peter Rosin <peda@xxxxxxxxxx>:
> >
> > One pretty simple problematic case is:
> >
> > .---. .----.
> > | | | |-- i2c2
> > | |-- i2c0 --|mux0| .----.
> > | l | | |-- i2c3 --|gpio|
> > | i | '----' '----'
> > | n | .--------------'
> > | u | .----. .----.
> > | x | | |-- i2c4 --|dev0|
> > | |-- i2c1 --|mux1| '----'
> > | | | |-- i2c5
> > '---' '----'
Shees, and I suppose this is all external to SoC stuff, so people can
stick on whatever they pretty well please. I mean, its an i2c bus, just
order parts from ebay and stick on a board.
> > Accesses to dev0 will:
> >
> > 1. lock i2c1:mux_lock (depth 0)
> > 2. switch mux1 to i2c4 using gpio
> > a lock i2c0:mux_lock (depth 0)
> > b switch mux0 to i2c3 using whatever
> > c access gpio
> > d unlock i2c0:mux_lock
> > 3. access dev0
> > 4. unlock i2c1:mux_lock
> >
> > 2a will cause a lockdep splat if i2c0:mux_lock is in the same
> > lockdep class & subclass as i2c1:mux_lock. So, lockdep needs
> > separate lockdep classes depending on the i2c root adapter
> > (subclasses are needed to handle deeper trees, so they are off
> > limits). Great fun. How do I go about creating a new lockdep
> > class for every i2c root adapter instance?
> >
>
> I feel like it's just wrong to set an arbitrary limit on the number of
> i2c branches - and this is what the result of this approach would be.
>
> One solution that comes to mind is to have a separate, global set of
> lock classes solely for gpio expanders. I think you mentioned earlier
> that it's the only thing that can cause this kind of lockdep false
> positives. We could potentially have a limited set of lock classes and
> every expander that would need one would request it using some kind of
> API ensuring that every instance gets a separate class. But this
> sounds like a big hack too I'm afraid... And regmap would need to be
> aware of that as well.
>
> Anyways, we're past rc7 already and 4.9 will be the next LTS kernel.
> We have real hardware here that runs on mainline linux and is
> suffering from this issue. Are there any objections against merging
> this series now and continuing the work on improving the solution for
> 4.10?
Seems sensible, I'll also see if I can come up with a better annotation
that can help here.