vid Miller wrote:
> >>> Where is the patch? :-)
> >>>
> >>> Second time you've done this in two days Herbert, tsk tsk :)))
> >> The patch was so easy that it was left as an exercise to the reader :)
> >>
> >> [SC92031]: Fix priv->lock context
> &g
left as an exercise to the reader :)
[SC92031]: Fix priv->lock context
The spin_lock calls made in dev->open and dev->close must disable
BH since open/close are made in process context. Conversely, the
call in dev->hard_start_xmit does not need to disable BH since it
is already exe
The patch was so easy that it was left as an exercise to the reader :)
>
> [SC92031]: Fix priv->lock context
>
> The spin_lock calls made in dev->open and dev->close must disable
> BH since open/close are made in process context. Conversely, the
> call in dev->hard_star
was too much for me :-)
>
> [SC92031]: Fix priv->lock context
>
> The spin_lock calls made in dev->open and dev->close must disable
> BH since open/close are made in process context. Conversely, the
> call in dev->hard_start_xmit does not need to disable BH since it
On Thu, Apr 05, 2007 at 09:59:29AM -0700, David Miller wrote:
>
> Where is the patch? :-)
>
> Second time you've done this in two days Herbert, tsk tsk :)))
The patch was so easy that it was left as an exercise to the reader :)
[SC92031]: Fix priv->lock context
The spin_lo
drivers/net/sc92031.c in rc5-mm4.
>
> Actually, this looks like a latent bug in sc92031. It's calling
> spin_lock in the dev->open function on a lock that's held in BH
> context.
>
> [SC92031]: Fix priv->lock context
Where is the patch? :-)
Second time you've
pin_lock in the dev->open function on a lock that's held in BH
context.
[SC92031]: Fix priv->lock context
The spin_lock calls made in dev->open and dev->close must disable
BH since open/close are made in process context. Conversely, the
call in dev->hard_start_xmit does not
