linux-kernel - Re: lockdep: incorrect deadlock warning with two GPIO expanders

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]

Date:   Mon, 12 Sep 2016 14:09:38 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc:     Ingo Molnar <mingo@...hat.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: lockdep: incorrect deadlock warning with two GPIO expanders

On Mon, Sep 12, 2016 at 01:51:55PM +0200, Bartosz Golaszewski wrote:
> I'm trying to figure out a way of getting rid of an incorrect lockdep
> deadlock warning, but the issue is not trivial.
> 
> In our hardware an I2C multiplexer is controlled by a GPIO provided by
> an expander. There's a second expander using the same device driver
> (pca953x) on one of the I2C bus segments. The diagram below presents
> the setup:
> 
>                                                - - - - -
>  -------             ---------  Bus segment 1 |         |
> |       |           |         |---------------  Devices
> |       | SCL/SDA   |         |               |         |
> | Linux |-----------| I2C MUX |                - - - - -
> |       |    |      |         | Bus segment 2
> |       |    |      |         |-------------------
>  -------     |       ---------                    |
>              |           |                    - - - - -
>         ------------     | MUX GPIO          |         |
>        |            |    |                     Devices
>        |    GPIO    |    |                   |         |
>        | Expander 1 |----                     - - - - -
>        |            |                             |
>         ------------                              | SCL/SDA
>                                                   |
>                                              ------------
>                                             |            |
>                                             |    GPIO    |
>                                             | Expander 2 |
>                                             |            |
>                                              ------------

> Using mutex_lock_nested(&chip->i2c_lock, SINGLE_DEPTH_NESTING) in
> pca953x_gpio_get_value() and pca953x_gpio_direction_input/output()
> helps for reading the values or setting the direction, but doesn't do
> anything if used in pca953x_gpio_set_value() since we still end up
> taking the lock of the same subclass again.
> 
> It would require some nasty hacks to figure out that a GPIO is being
> used by an I2C mux if we wanted to explicitly provide a different
> sublass in this case, but that would not fix the culprit, since the
> same problem would occur in other gpio drivers under similar
> circumstances.
> 
> It seems the problem is with the way lockdep works, but I lack the
> knowledge to propose any solution.
> 
> Any help & ideas are appreciated.

So I'm entirely clueless on how the device model works let alone i2c
and/or gpio. So I'm going to need some help as well. What's an SCL/SDA
for instance?

So the 'problem' is that pca953x_probe()'s mutex_init() will collapse
all mutexes it initializes into a single class. It assumes that the
locking rules for all instances will be the same.

This happens to not be true in this case.

The tricky part, and here I have absolutely no clue what so ever, is
being able to tell at pca953x_probe() time that this is so.

Once we can tell, at probe time, there are two different annotations we
could use, depending on need.

I suppose that theoretically you can keep nesting like that ad
infinitum, but I also expect that its uncommon enough, and maybe not
practical, to really nest like this -- seeing this is the first instance
of such issues.

In any case, can you tell at probe time? And how deep a nesting should
we worry about?

Seeing how this lock is specific to the driver, and there is no generic
infrastructure, I don't see how we could solve it other than on a
per-driver basis.