Don't abuse wl->current_dev in the LED work for checking whether we're
going down. Add an explicit variable.
This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
in various other places of the driver.
Signed-off-by: Michael Buesch <[email protected]>
---
Note to self: Don't try to safe a byte of memory :)
Index: wireless-testing/drivers/net/wireless/b43/leds.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/leds.c 2009-09-14 22:42:05.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/leds.c 2009-09-14 23:15:39.000000000 +0200
@@ -112,10 +112,7 @@ static void b43_led_brightness_set(struc
struct b43_led *led = container_of(led_dev, struct b43_led, led_dev);
struct b43_wl *wl = led->wl;
- /* The check for current_dev is only needed while unregistering,
- * so it is sequencial and does not race. But we must not dereference
- * current_dev here. */
- if (likely(wl->current_dev)) {
+ if (likely(!wl->leds.stop)) {
atomic_set(&led->state, brightness);
ieee80211_queue_work(wl->hw, &wl->leds.work);
}
@@ -314,6 +311,8 @@ void b43_leds_init(struct b43_wldev *dev
break;
}
}
+
+ dev->wl->leds.stop = 0;
}
void b43_leds_exit(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/leds.h
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/leds.h 2009-09-14 22:42:05.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/leds.h 2009-09-14 23:13:38.000000000 +0200
@@ -35,6 +35,7 @@ struct b43_leds {
struct b43_led led_radio;
struct b43_led led_assoc;
+ bool stop;
struct work_struct work;
};
Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-09-14 23:11:17.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-09-14 23:14:39.000000000 +0200
@@ -4987,7 +4987,7 @@ static void b43_remove(struct ssb_device
* might have modified it. Restoring is important, so the networking
* stack can properly free resources. */
wl->hw->queues = wl->mac80211_initially_registered_queues;
- wl->current_dev = NULL;
+ wl->leds.stop = 1;
cancel_work_sync(&wl->leds.work);
ieee80211_unregister_hw(wl->hw);
}
--
Greetings, Michael.
On Tuesday 15 September 2009 00:58:18 Larry Finger wrote:
> Michael Buesch wrote:
> > Don't abuse wl->current_dev in the LED work for checking whether we're
> > going down. Add an explicit variable.
> > This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
> > in various other places of the driver.
> >
> > Signed-off-by: Michael Buesch <[email protected]>
>
> This patch does not apply. What other patches should I have beyond the
> current state of wireless-testing?
All patches that are currently queued up.
--
Greetings, Michael.
Michael Buesch wrote:
> Don't abuse wl->current_dev in the LED work for checking whether we're
> going down. Add an explicit variable.
> This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
> in various other places of the driver.
>
> Signed-off-by: Michael Buesch <[email protected]>
This patch does not apply. What other patches should I have beyond the
current state of wireless-testing?
Larry
Michael Buesch wrote:
> On Tuesday 15 September 2009 00:58:18 Larry Finger wrote:
>> Michael Buesch wrote:
>>> Don't abuse wl->current_dev in the LED work for checking whether we're
>>> going down. Add an explicit variable.
>>> This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
>>> in various other places of the driver.
>>>
>>> Signed-off-by: Michael Buesch <[email protected]>
>> This patch does not apply. What other patches should I have beyond the
>> current state of wireless-testing?
>
> All patches that are currently queued up.
I found the ones I needed in my mailboxes.
The patch cured my problem. Thanks and ack.
Larry