[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r2sz8opx.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
Date: Wed, 15 Nov 2017 11:56:58 -0500
From: Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To: Andrew Lunn <andrew@...n.ch>,
Egil Hjelmeland <privat@...l-hjelmeland.no>
Cc: Florian Fainelli <f.fainelli@...il.com>,
netdev <netdev@...r.kernel.org>
Subject: Re: question lan9303: DSA concurrency and locking,
Hi,
>> Does DSA offer any protection against concurrent calls of
>> dsa_switch_ops?
This is something I thought about for a while. Since DSA offers an
abstraction of different net stack entry points to its drivers, like
netlink (bridge, etc.) or ioctl (ethtool), it would make sense to add a
mutex at the DSA layer.
It would naturally go in the dsa_switch structure, and be (un)locked by
DSA core. But a switch fabric might be composed of multiple devices, so
this locking must happen at the dsa_switch_tree level. The entry points
to the DSA core are the dsa_port structure, either accessed via a master
interface's dsa_ptr pointer, or via a slave interface's private data.
So ideally the locking of the control path must occur when notifying an
operation to every device of the tree, i.e. in dsa_port_notify:
mutex_lock(&dst->lock);
err = raw_notifier_call_chain(&dst->nh, e, v);
mutex_lock(&dst->lock);
Unfortunately the code is not ready for that yet, because not all calls
to ds->ops->foo are centralized yet. But we are slowly going that way.
In the meantime, DSA drivers handle locking themselves when necessary.
Thanks,
Vivien
Powered by blists - more mailing lists