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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ