netdev - Re: [PATCH v2 net] net: mscc: ocelot: install MAC addresses in .ndo_set_rx

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 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 4 Dec 2020 16:41:01 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        "Allan W . Nielsen" <allan.nielsen@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Steen Hegelund <steen.hegelund@...rochip.com>
Subject: Re: [PATCH v2 net] net: mscc: ocelot: install MAC addresses in
 .ndo_set_rx_mode from process context

On Fri, 4 Dec 2020 19:23:11 +0000 Vladimir Oltean wrote:
> > > > What's the expected poll time? maybe it's not that bad to busy wait?
> > > > Clearly nobody noticed the issue in 2 years (you mention lockdep so
> > > > not a "real" deadlock) which makes me think the wait can't be that long?  
> > >
> > > Not too much, but the sleep is there.
> > > Also, all 3 of ocelot/felix/seville are memory-mapped devices. But I
> > > heard from Alex a while ago that he intends to add support for a switch
> > > managed over a slow bus like SPI, and to use the same regmap infrastructure.
> > > That would mean that this problem would need to be resolved anyway.  
> >
> > So it's MMIO but the other end is some firmware running on the device?  
> 
> No. It's always register-based access, just that in some cases the
> registers are directly memory-mapped for Linux, while in other cases
> they are beyond an SPI bus. But there isn't any firmware in any case.

I see, so ocelot_mact_wait_for_completion() waits for some hardware
engine to process the command? It looked like FW is hiding behind that
register at a glance. 100ms sounds very high for hardware processing.