linux-kernel - Re: [PATCH] net: usb: lan78xx: Use phy_mac

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: <20191022183411.0e9a7bdc@why>
Date:   Tue, 22 Oct 2019 18:34:11 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Daniel Wagner <dwagner@...e.de>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        UNGLinuxDriver@...rochip.com, netdev@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-rt-users@...r.kernel.org,
        Woojung Huh <woojung.huh@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>, Stefan Wahren <wahrenst@....net>,
        Jisheng Zhang <Jisheng.Zhang@...aptics.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] net: usb: lan78xx: Use phy_mac_interrupt() for
 interrupt handling

On Tue, 22 Oct 2019 10:17:47 -0700
Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:

> On Fri, 18 Oct 2019 15:15:32 +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-10-18 10:28:17 [+0200], Daniel Wagner wrote:  
> > > handle_simple_irq() expect interrupts to be disabled. The USB
> > > framework is using threaded interrupts, which implies that interrupts
> > > are re-enabled as soon as it has run.    
> > 
> > Without threading interrupts, this is invoked in pure softirq context
> > since commit ed194d1367698 ("usb: core: remove local_irq_save() around  
> > ->complete() handler") where the local_irq_disable() has been removed.    
> > 
> > This is probably not a problem because the lock is never observed with
> > in IRQ context.
> > 
> > Wouldn't handle_nested_irq() work here instead of the simple thingy?  
> 
> Daniel could you try this suggestion? Would it work?
> 
> I'm not sure we are at the stage yet where "doesn't work on -rt" is
> sufficient reason to revert a working upstream patch. Please correct 
> me if I'm wrong.

But that's the thing: it doesn't work at all, RT or not (it spits an
awful warning). See the various reports Daniel linked to. Maintainers
have been completely unresponsive, and the RPI folks have their own out
of tree hack, I believe (which probably reverts to the previous,
working situation where the driver uses polling for some of its PHY
handling business).

Sebastian's suggestion is definitely worth trying if you have the HW
though.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...