netdev - RE: locking in wimax/i2400m

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] [day] [month] [year] [list]

Date:   Mon, 11 Jun 2018 19:56:41 +0000
From:   "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@...el.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        linux-wimax <linux-wimax@...el.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>
Subject: RE: locking in wimax/i2400m

Hello Sebastian

Thanks for checking this out,

    SA> I tried to figure out if the URB-completion handler uses any
    SA> locking and stumbled here.

    SA> i2400m_pm_notifier() is called from process context. This
    SA> function invokes i2400m_fw_cache() + i2400m_fw_uncache(). Both
    SA> functions do spin_lock(&i2400m->rx_lock); while in other
    SA> places (say i2400mu_rxd()) it does
    SA> spin_lock_irqsave(&i2400m->rx_lock, flags);

    SA> So what do I miss? Is this lock never used in interrupt
    SA> context and lockdep didn't complain or did nobody try suspend
    SA> with this driver before?  From what I can tell
    SA> i2400m_dev_bootstrap() has the same locking problem.

I don't remember ever getting to try suspend in the driver, so that
might be the case. That said, I haven't touched this code in years, or
the current locking best practices, so I'll let others chime in,
Thomas being prolly one of the key ones.