Messages in this thread | | | Date | Mon, 18 Jan 2010 22:10:43 +0100 (CET) | From | Julia Lawall <> | Subject | Re: mcs7830 usb net: "scheduling while atomic" danger? |
| |
On Mon, 18 Jan 2010, Andreas Mohr wrote:
> Hi, > > drivers/net/usb/mcs7830.c does several: > > mutex_lock(&dev->phy_mutex); > /* write the MII command */ > ret = mcs7830_set_reg(dev, HIF_REG_PHY_CMD1, 2, cmd); > if (ret < 0) > goto out; > > /* wait for the data to become valid, should be within < 1ms */ > for (i = 0; i < 10; i++) { > ret = mcs7830_get_reg(dev, HIF_REG_PHY_CMD1, 2, cmd); > if ((ret < 0) || (cmd[1] & > HIF_REG_PHY_CMD2_READY_FLAG_BIT)) > break; > ret = -EIO; > msleep(1); > } > > > Forgive me, but doesn't that mutex_lock()/msleep() (ab)use mean > risking a "scheduling while atomic"? > (such as discussed in e.g. > http://search.luky.org/linux-kernel.2004/msg92817.html ) > > > And, if that is the case, shouldn't all such cases simply be killed for > good via a capable semantic patch?
The semantic match shown below finds 55 matches. All but two involve mutex_lock. Those are in the file /var/linuxes/linux-next/drivers/usb/host/ehci-hub.c in the functions ehci_bus_suspend and ehci_hub_control.
julia
@@ @@
( *mutex_lock(...) | *spin_lock(...) | *spin_lock_irq(...) | *spin_lock_irqsave(...) ) ... when != mutex_unlock(...) when != spin_unlock(...) when != spin_unlock_irq(...) when != spin_unlock_irqrestore(...) *msleep(...)
| |