netdev - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180611160528.be37vniefy4est6m@linutronix.de>
Date:   Mon, 11 Jun 2018 18:05:28 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Inaky Perez-Gonzalez <inaky.perez-gonzalez@...el.com>,
        linux-wimax@...el.com
Cc:     netdev@...r.kernel.org, tglx@...utronix.de
Subject: locking in wimax/i2400m

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

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

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

While here, I noticed that i2400m_fw_cache() does use GFP_ATOMIC which
should be GFP_KERNEL since the context can't be atomic at this point
(there is even request_firmware() later on).

I am also curious why there is NULL and ~0 because it does not seem to
make a difference in i2400m_fw_uncache() but I'm more interested in
the locking bits :)

Sebastian