Re: [PATCH 1/4] create cfg80211
On Sun, 2007-02-11 at 20:39 +0100, Johannes Berg wrote:
On Fri, 2007-02-09 at 17:27 +0100, [EMAIL PROTECTED] wrote:
[...]
needs to be changed. wiphy_free() should wait for
wiphy_class_dev_release (to make sure sysfs is gone) before freeing the
structure (if it has ever been added to sysfs).
On second thought, no, that's perfectly correct. There's a slight bug
however in the registration, it must not set wiphy_index when sysfs
registration fails.
The real bug I'm chasing (use-after-free leading to oops when rmmod'ing
bcm43xx-d80211 while device is up) is in bcm43xx-d80211 and I found it
too. Consider the following changes I made to debug:
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
index 9f4d51d..5205859 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -1479,6 +1479,8 @@ static irqreturn_t bcm43xx_interrupt_handler(int irq,
void *dev_id)
if (!dev)
return IRQ_NONE;
+ printk(KERN_INFO bcm43xx_interrupt_handler\n);
+
spin_lock(dev-wl-irq_lock);
assert(bcm43xx_status(dev) == BCM43xx_STAT_INITIALIZED);
@@ -3453,7 +3455,8 @@ static void bcm43xx_one_core_detach(struct ssb_device
*dev)
list_del(wldev-list);
wl-nr_devs--;
ssb_set_drvdata(dev, NULL);
- kfree(wldev);
+ printk(KERN_INFO kfree(wldev)\n);
+// kfree(wldev);
}
static int bcm43xx_one_core_attach(struct ssb_device *dev,
@@ -3535,8 +3538,10 @@ static void bcm43xx_wireless_exit(struct ssb_device *dev,
{
struct ieee80211_hw *hw = wl-hw;
+ printk(KERN_INFO bcm43xx_wireless_exit(): unregister_hw()\n);
ieee80211_unregister_hw(hw);
ssb_set_devtypedata(dev, NULL);
+ printk(KERN_INFO bcm43xx_wireless_exit(): free_hw()\n);
ieee80211_free_hw(hw);
}
Now remember the oops I got which was a use-after-free in the interrupt handler.
Now also consider this message log I got when inserting bcm43xx,
scanning (I removed some interrupt messages), and then removing the
module again:
[ 1443.269289] wlan0: starting scan
[ 1443.316409] bcm43xx_interrupt_handler
...
[ 1444.016378] bcm43xx_interrupt_handler
[ 1444.053623] wlan0: scan completed
[ 1445.317311] kfree(wldev)
[ 1445.317931] bcm43xx_wireless_exit(): unregister_hw()
[ 1445.385872] bcm43xx_d80211: Wireless interface stopped
[ 1445.386554] bcm43xx_d80211: Removing Interface type 2
[ 1445.387219] bcm43xx_d80211: DMA-32 0x0200 (RX) max used slots: 0/64
[ 1445.389551] bcm43xx_d80211: DMA-32 0x02A0 (TX) max used slots: 0/128
[ 1445.390609] bcm43xx_d80211: DMA-32 0x0280 (TX) max used slots: 0/128
[ 1445.391678] bcm43xx_d80211: DMA-32 0x0260 (TX) max used slots: 0/128
[ 1445.392756] bcm43xx_d80211: DMA-32 0x0240 (TX) max used slots: 0/128
[ 1445.393821] bcm43xx_d80211: DMA-32 0x0220 (TX) max used slots: 2/128
[ 1445.394869] bcm43xx_d80211: DMA-32 0x0200 (TX) max used slots: 0/128
[ 1445.395924] bcm43xx_d80211: Radio turned off
[ 1445.516479] bcm43xx_wireless_exit(): free_hw()
[ 1445.517144] wiphy_free()
[ 1445.518029] PM: Removing info for ssb:ssb04:04
[ 1445.518164] PM: Removing info for ssb:ssb04:03
[ 1445.518284] PM: Removing info for ssb:ssb04:02
[ 1445.518405] PM: Removing info for ssb:ssb04:01
[ 1445.518597] PM: Removing info for ssb:ssb04:00
Now let's also take a look at the code that prints Wireless interface
stopped. That function is bcm43xx_wireless_core_stop(), which is passed
a struct bcm43xx_wldev, precisely the one that two lines before was
passed to that kfree()...
So what happens is that sometimes a whole bunch of things in
bcm43xx_wireless_core_stop will not work properly due to the
use-after-free we have here. Unless you have slab debugging disabled
(like me) where of course it fails every time...
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFT: The real fix for BCM4311 and BCM4312
[Freitag, 9. Februar 2007 18:00] schrieb Larry Finger (wrote): Jochen Puchalla wrote: Hi Larry, I tried both versions with the combined patch on 2.6.20-rc7, still only 100kB/s. Could this be related to the fact that I have a b-type router and not a g-type? It shouldn't. I just ran tests here with different settings on my AP. With a B-only setting, I get a maximum of 5.5 Mbs. In Mixed B/G-mode, I get 5.9 Mbs and with G only, the rate is 6.3 Mbs. All of these were run with an iwconfig rate of 11 Mbs. Hi Larry, finally I switched to 2.6.20 and your second revision patch and it works! I get 2Mbps with iperf, that's great! Probably the maximum rate was also reduced by another network on the same channel, now I switched to an exclusive channel and the rate doesn't drop. Green light for upstream from me :-) Again, many thanks! Gruß, Jochen -- In a world without fences and walls, who needs gates and windows? Das bessere Office kostenlos: http://de.openoffice.org/ Einfach der bessere Browser: http://www.mozilla.com/firefox/all pgpbyFUpV46iU.pgp Description: PGP signature ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
Rafael J. Wysocki wrote: On Monday, 12 February 2007 02:18, Larry Finger wrote: Rafael J. Wysocki wrote: It doesn't help in my case. The behavior is similar to that without the patch, but also with the patch it loses the association entirely. Thanks for trying. Do you have this patch installed? If you do, please try increasing the 100 to 200. Hm, but it wouldn't help to get the microcode to respond after the resume ... Yes it would. That count is how long the system waits for the firmware to respond. I'm still thinking the problem is with the firmware. Where exactly is it stored? In the memory of the microprocessor on the card. Please do what I asked. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
On Monday, 12 February 2007 23:20, Larry Finger wrote: Rafael J. Wysocki wrote: On Monday, 12 February 2007 02:18, Larry Finger wrote: Rafael J. Wysocki wrote: It doesn't help in my case. The behavior is similar to that without the patch, but also with the patch it loses the association entirely. Thanks for trying. Do you have this patch installed? If you do, please try increasing the 100 to 200. Hm, but it wouldn't help to get the microcode to respond after the resume ... Yes it would. That count is how long the system waits for the firmware to respond. I'm still thinking the problem is with the firmware. Where exactly is it stored? In the memory of the microprocessor on the card. Please do what I asked. With or without the previous patch? Rafael ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix loss of association after resume
Rafael J. Wysocki wrote: On Monday, 12 February 2007 23:20, Larry Finger wrote: Rafael J. Wysocki wrote: On Monday, 12 February 2007 02:18, Larry Finger wrote: Rafael J. Wysocki wrote: It doesn't help in my case. The behavior is similar to that without the patch, but also with the patch it loses the association entirely. Thanks for trying. Do you have this patch installed? If you do, please try increasing the 100 to 200. Hm, but it wouldn't help to get the microcode to respond after the resume ... Yes it would. That count is how long the system waits for the firmware to respond. I'm still thinking the problem is with the firmware. Where exactly is it stored? In the memory of the microprocessor on the card. Please do what I asked. With or without the previous patch? With the change to BCM43xx_IRQWAIT_MAX_RETRIES, but not the one that tries to reload the firmware. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 1/4] create cfg80211
On Monday 12 February 2007 09:12, Johannes Berg wrote: The real bug I'm chasing (use-after-free leading to oops when rmmod'ing bcm43xx-d80211 while device is up) is in bcm43xx-d80211 and I found it too. Consider the following changes I made to debug: Should be fixed in my tree now. Thanks for the good bugreport. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
