linux-kernel - Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading

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:   Tue, 2 Mar 2021 17:24:08 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     DENG Qingfang <dqfext@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        netdev <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading

On Tue, Mar 2, 2021 at 5:11 PM Vladimir Oltean <olteanv@...il.com> wrote:
> On Tue, Mar 02, 2021 at 05:05:00PM +0100, Linus Walleij wrote:
> > On Tue, Mar 2, 2021 at 4:58 AM DENG Qingfang <dqfext@...il.com> wrote:
> > > On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij <linus.walleij@...aro.org> wrote:
> > > > With my minor changes:
> > > > Tested-by: Linus Walleij <linus.walleij@...aro.org>
> > >
> > > How about using a mutex lock in port_bridge_{join,leave} ?
> > > In my opinion all functions that access multiple registers should be
> > > synchronized.
> >
> > That's one way, in some cases the framework (DSA) serialize
> > the accesses so I don't know if that already happens on a
> > higher level? Since it is accessed over a slow bus we should go
> > for mutex in that case indeed.
>
> DSA does not serialize this. The .port_bridge_join and
> .port_bridge_leave calls are initiated from the NETDEV_CHANGEUPPER net
> device event, which is called under rtnl_mutex (see call_netdevice_notifiers).
> This is pretty fundamental and I don't think it will ever change.
>
> However, if you still want to add an extra layer of locking (with code
> paths that for some reason are not under the rtnl_mutex), then go ahead,
> I suppose. It will be challenging to make sure they do something that
> isn't snake oil, though.

Nah, just didn't know if was already in place.

I suggest Qingfang go with a driver-local mutex (it may already be needed in
more places).

Yours,
Linus Walleij