Re: Using a waiting MDIO does not go well with a spinlocked bridge

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Mar 20, 2015 at 01:22:46PM +0100, Jonas Johansson wrote:
> The bridge code will sometimes hold a spinlock and the code
> following must therefore be atomic. If using a MDIO call which uses
> a wait/sleep in this contex, the kernel will not be very happy.
> 
> I'm using a switch device and wants to flush its FDB when the linux
> bridge FDB is flushed. I've implemented some hooks for this task.
> In short:
>      bridge    - br_fdb_flush() & br_fdb_delete_by_port
>   -> switchdev - switch_flush()
>   -> dsa       - slave_flush()
>   -> mv88e6xxx - mv88_flush()

Hi Jonas

Have you seen the patches from Guenter Roeck implementing hardware
bridging? There should be a new version coming out soon.

> So, when a bridge port is flushed via e.g. sysfs, the mv88_flush()
> function will at the end be called. The mv88_flush() will use MDIO
> calls to set the proper registers and flush the device. But, due to
> that the MDIO on my platform uses wait_for_completion() and a
> spinlock is held (in this case in brport_store()) the process will
> not go very well.

Ah, not good. We have a number of mutex in the mv88x6xxx code, one of
which is used with fdb operations..
 
> The only possible solutions that came into my mind is:
>  1) Let mv88_flush() schedule a work queue to take care of the flush
>     later on.
>  2) Change the MDIO implementation to use polling.

I don't think these is feasible. The MDIO bus could be a gpio
bit-banging interface. It is hard to guarantee that the GPIO code will
not sleep.

>  3) Dont use spinlock in bridge code.

This would be my preference, but i've no idea how much work it is.  We
should audit the bridge code and document in what context operations
on the switch are called.

   Andrew