p54: fix memory management

RFC PATCH [email protected] 1 participant 2 messages Oct 3, 2008

lore

Share & tools

lore

[email protected]

author

2008-10-03 14:16 UTC #0 lore raw

Quoted 138 lines

Quoted 11 lines · Christian Lamparter

Well, since a lot of people have worked with the memory management of p54 driver (or similar projects ;-) ), it's probably the best to give this _urgent_ thing a RFC round.
The problem is that if multiple "control frames" are passed in a very short intervals to the device's firmware (e.g: QoS and frequency are the best candidates)
the data might get corrupted. As p54_assign_address always put them into same memory location and the device's firmware is too slow to pick the frames up, before they're overwritten again.
P.S: the code inside the #if 0 - #endif will go away in the final version, but for now its very useful for debugging. So don't complain about it ;-).

When the patch works, it seems to be OK; however, I got two oops and one system lockup (caps lock blinking at a 1 Hz rate). The first one is as follows:

Oct  2 17:22:52 larrylap kernel: BUG: unable to handle kernel NULL
pointer dereference at 0000000000000000
Oct  2 17:22:52 larrylap kernel: IP: [<ffffffffa024916e>]
p54_assign_address+0xff/0x162 [p54common]
Oct  2 17:22:52 larrylap kernel: PGD 0
Oct  2 17:22:52 larrylap kernel: Oops: 0000 [1] SMP
Oct  2 17:22:52 larrylap kernel: CPU 0
Oct  2 17:22:52 larrylap kernel: Modules linked in: snd_pcm_oss

snd_mixer_oss snd_seq snd_seq_device af_packet sunrpc rfkill_input cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8 fuse loop dm_mod ide_cd_mod cdrom arc4 ecb crypto_blkcipher p54usb b43 snd_hda_intel rfkill amd74xx p54common snd_pcm led_class ide_pci_generic mac80211 snd_timer k8temp input_polldev snd battery ac button hwmon joydev ide_core forcedeth soundcore cfg80211 ssb snd_page_alloc serio_raw sg sd_mod ehci_hcd ohci_hcd usbcore edd fan thermal processor ext3 mbcache jbd ahci libata scsi_mod dock

Oct  2 17:22:52 larrylap kernel: Pid: 2021, comm: p54usb Tainted: G
M      2.6.27-rc8-wl #51
Oct  2 17:22:52 larrylap kernel: RIP: 0010:[<ffffffffa024916e>]
[<ffffffffa024916e>] p54_assign_address+0xff/0x162 [p54common]
Oct  2 17:22:52 larrylap kernel: RSP: 0018:ffff8800ba0ebd20  EFLAGS:
00010006
Oct  2 17:22:52 larrylap kernel: RAX: ffff8800ba0b04a0 RBX:
ffff8800ba0b1d00 RCX: 000000000000009c
Oct  2 17:22:52 larrylap kernel: RDX: ffff8800b9260f40 RSI:
0000000000000000 RDI: ffff8800b9260840
Oct  2 17:22:52 larrylap kernel: RBP: ffff8800ba0ebd70 R08:
0000000000000002 R09: ffffffffa02490d0
Oct  2 17:22:52 larrylap kernel: R10: ffff8800b9260f00 R11:
ffff8800a7de2480 R12: 00000000000000c0
Oct  2 17:22:52 larrylap kernel: R13: ffff8800b9260f00 R14:
0000000000024178 R15: ffff8800ba0b1d08
Oct  2 17:22:52 larrylap kernel: FS:  00007f9a5f2fe6f0(0000)
GS:ffffffff8069d680(0000) knlGS:00000000f7caf6c0
Oct  2 17:22:52 larrylap kernel: CS:  0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Oct  2 17:22:52 larrylap kernel: CR2: 0000000000000000 CR3:
00000000b9cdc000 CR4: 00000000000006e0
Oct  2 17:22:52 larrylap kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Oct  2 17:22:52 larrylap kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Oct  2 17:22:52 larrylap kernel: Process p54usb (pid: 2021, threadinfo
ffff8800ba0ea000, task ffff8800b8a4c790)
Oct  2 17:22:52 larrylap kernel: Stack:  ffff8800a7e69e10
ffff8800ba0b04a0 ffff8800ba0b1d20 0002020000000000
Oct  2 17:22:52 larrylap kernel:  0000000000000286 ffff8800b9260f00
ffff8800a7e69e10 ffff8800ba0b1d00
Oct  2 17:22:52 larrylap kernel:  ffff8800ba0b04a0 ffff8800ba0b04a0
ffff8800ba0ebdb0 ffffffffa02499fb
Oct  2 17:22:52 larrylap kernel: Call Trace:
Oct  2 17:22:52 larrylap kernel:  [<ffffffffa02499fb>]
p54_set_vdcf+0xe1/0x104 [p54common]
Oct  2 17:22:52 larrylap kernel:  [<ffffffffa024a0fb>]
p54_config+0x2b0/0x2ca [p54common]
Oct  2 17:22:52 larrylap kernel:  [<ffffffff802339a2>] ?
finish_task_switch+0x0/0xb9
Oct  2 17:22:52 larrylap kernel:  [<ffffffffa01f1055>]
ieee80211_hw_config+0x55/0x57 [mac80211]
Oct  2 17:22:52 larrylap kernel:  [<ffffffffa01f6de7>]
ieee80211_scan_work+0xd1/0x196 [mac80211]
Oct  2 17:22:52 larrylap kernel:  [<ffffffff802478ef>]
run_workqueue+0x103/0x20a
Oct  2 17:22:52 larrylap kernel:  [<ffffffff8024789d>] ?
run_workqueue+0xb1/0x20a
Oct  2 17:22:52 larrylap kernel:  [<ffffffffa01f6d16>] ?
ieee80211_scan_work+0x0/0x196 [mac80211]
Oct  2 17:22:52 larrylap kernel:  [<ffffffff80247ad6>]
worker_thread+0xe0/0xf1
Oct  2 17:22:52 larrylap kernel:  [<ffffffff8024b5e0>] ?
autoremove_wake_function+0x0/0x38
Oct  2 17:22:53 larrylap kernel:  [<ffffffff802479f6>] ?
worker_thread+0x0/0xf1
Oct  2 17:22:53 larrylap kernel:  [<ffffffff8024b284>] kthread+0x49/0x76
Oct  2 17:22:53 larrylap kernel:  [<ffffffff8020d099>] child_rip+0xa/0x11
Oct  2 17:22:53 larrylap kernel:  [<ffffffff80427834>] ?
_spin_unlock_irq+0x2b/0x30
Oct  2 17:22:53 larrylap kernel:  [<ffffffff8020c6cf>] ?
restore_args+0x0/0x30
Oct  2 17:22:53 larrylap kernel:  [<ffffffff8024b23b>] ? kthread+0x0/0x76
Oct  2 17:22:53 larrylap kernel:  [<ffffffff8020d08f>] ?
child_rip+0x0/0x11
Oct  2 17:22:53 larrylap kernel:
Oct  2 17:22:53 larrylap kernel:
Oct  2 17:22:53 larrylap kernel: Code: 8b 4b 04 44 29 f1 39 d1 0f 42
ca 4d 85 ed 74 54 8b 45 cc 49 8d 55 40 89 c9 41 89 45 40 44 01 e0 89
42 04 48 8b 45 b8 48 89 42 08 <48> 8b 06 49 89 75 08 49 89 45 00 4c 89
68 08 4c 89 2e 0f b7 53
Oct  2 17:22:53 larrylap kernel: RIP  [<ffffffffa024916e>]
p54_assign_address+0xff/0x162 [p54common]
Oct  2 17:22:53 larrylap kernel:  RSP <ffff8800ba0ebd20>
Oct  2 17:22:53 larrylap kernel: CR2: 0000000000000000
Oct  2 17:22:53 larrylap kernel: ---[ end trace 4bd18aa5f2aeb5d8 ]---

Note, the "tainted" flag is false. No closed-source drivers have been loaded.

The oops occurs in the following inline routine:

static inline void __skb_queue_after(struct sk_buff_head *list,
struct sk_buff *prev, struct sk_buff *newsk)

{
        __skb_insert(newsk, prev, prev->next, list);
}

and is called from p54_assign_addresses() in the following region:

       if (skb) {
                struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
                struct memrecord *range = (void *)info->driver_data;
                range->start_addr = target_addr;
                range->end_addr = target_addr + len;
                range->dev = dev;
                __skb_queue_after(&priv->tx_queue, target_skb, skb);
                if (largest_hole < priv->rx_mtu + priv->headroom +
                                   priv->tailroom +
                                   sizeof(struct p54_control_hdr))
                        ieee80211_stop_queues(dev);
        }

Quoted 1 line

Larry

Hmm, just a guess:

according to skbuff.h
the callback buffer in every skb is about;
char cb[48];

now, when we look at what mac80211 puts inside it
struct ieee80211_tx_info {
u32 flags;
u8 band;
s8 tx_rate_idx;
u8 antenna_sel_tx;

/* 1 byte hole => 8 bytes so far */

union {
struct {
struct ieee80211_vif *vif; // another 8 byte on 64bit cpus => 16 struct ieee80211_key_conf *hw_key; // + 8 bytes => 24 struct ieee80211_sta *sta; // + 8 bytes => 32
unsigned long jiffies; // + 8 bytes => 40
s8 rts_cts_rate_idx, alt_retry_rate_idx; // + 2
u8 retry_limit; // + 1
u8 icv_len; // + 1
u8 iv_len; // + 1
} control;
[...]

= 45 Bytes (without alignment, with it it's probably 48) out of 48...
If this is true, we have a serious problem on x64 since the memrecord
struct is about 8 bytes in the old code, but with this patch it's 16... well I am not sure, can I put the extra ieee80211_hw* thing into skb->dev. It would be nice, but of course net_device isn't exactly ieee80211_hw, as far as I can see.

But this won't solve the problem where the rest of the 8 bytes in memrecord should go. I think we should mark p54 as broken for now, since it corrupts a rather huge chunk of the skb's data structure.

Regards,
Chr

_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114

Christian Lamparter

author

2008-10-03 19:21 UTC #1 lore raw

Quoted 59 lines · On Friday 03 October 2008 16:16:32 [email protected] wrote:

Quoted 28 lines
Note, the "tainted" flag is false. No closed-source drivers have been loaded.
The oops occurs in the following inline routine:
static inline void __skb_queue_after(struct sk_buff_head *list,
struct sk_buff *prev, struct sk_buff *newsk)
{
        __skb_insert(newsk, prev, prev->next, list);
}
and is called from p54_assign_addresses() in the following region:
       if (skb) {
                struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
                struct memrecord *range = (void *)info->driver_data;
                range->start_addr = target_addr;
                range->end_addr = target_addr + len;
                range->dev = dev;
                __skb_queue_after(&priv->tx_queue, target_skb, skb);
                if (largest_hole < priv->rx_mtu + priv->headroom +
                                   priv->tailroom +
                                   sizeof(struct p54_control_hdr))
                        ieee80211_stop_queues(dev);
        }
Quoted 1 line
Larry
Hmm, just a guess:
according to skbuff.h
the callback buffer in every skb is about;
char cb[48];
now, when we look at what mac80211 puts inside it
struct ieee80211_tx_info {
u32 flags;
u8 band;
s8 tx_rate_idx;
u8 antenna_sel_tx;
/* 1 byte hole => 8 bytes so far */
union {
struct {
struct ieee80211_vif *vif; // another 8 byte on 64bit cpus => 16 struct ieee80211_key_conf *hw_key; // + 8 bytes => 24 struct ieee80211_sta *sta; // + 8 bytes => 32
unsigned long jiffies; // + 8 bytes => 40
s8 rts_cts_rate_idx, alt_retry_rate_idx; // + 2
u8 retry_limit; // + 1
u8 icv_len; // + 1
u8 iv_len; // + 1
} control;
[...]

Quoted 6 lines

= 45 Bytes (without alignment, with it it's probably 48) out of 48... If this is true, we have a serious problem on x64 since the memrecord struct is about 8 bytes in the old code, but with this patch it's 16... well I am not sure, can I put the extra ieee80211_hw* thing into skb->dev. It would be nice, but of course net_device isn't exactly ieee80211_hw, as far as I can see.

Ahh, that's garbage. driver_data is a member of the union, so it has about 40 bytes which is plenty. sorry for the noise.

Regards,
Chr.