Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 8月, 2009 1 次提交
  3. 15 8月, 2009 1 次提交
  5. 14 8月, 2009 1 次提交
    • L
      mac80211: fix panic when splicing unprepared TIDs · 416fbdff
      由 Luis R. Rodriguez 提交于 
      We splice skbs from the pending queue for a TID
onto the local pending queue when tearing down a
block ack request. This is not necessary unless we
actually have received a request to start a block ack
request (rate control, for example). If we never received
that request we should not be splicing the tid pending
queue as it would be null, causing a panic.

Not sure yet how exactly we allowed through a call when the
tid state does not have at least HT_ADDBA_REQUESTED_MSK set,
that will require some further review as it is not quite
obvious.

For more information see the bug report:

http://bugzilla.kernel.org/show_bug.cgi?id=13922

This fixes this oops:

BUG: unable to handle kernel NULL pointer dereference at 00000030
IP: [<f8806c70>] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211]
*pdpt = 0000000002d1e001 *pde = 0000000000000000
Thread overran stack, or stack corrupted
Oops: 0000 [#1] SMP
last sysfs file: /sys/module/aes_generic/initstate
Modules linked in: <bleh>

Pid: 0, comm: swapper Not tainted (2.6.31-rc5-wl #2) Dell DV051
EIP: 0060:[<f8806c70>] EFLAGS: 00010292 CPU: 0
EIP is at ieee80211_agg_splice_packets+0x40/0xc0 [mac80211]
EAX: 00000030 EBX: 0000004c ECX: 00000003 EDX: 00000000
ESI: c1c98000 EDI: f745a1c0 EBP: c076be58 ESP: c076be38
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c076a000 task=c0709160 task.ti=c076a000)
Stack: <bleh2>
Call Trace:
 [<f8806edb>] ? ieee80211_stop_tx_ba_cb+0xab/0x150 [mac80211]
 [<f8802f1e>] ? ieee80211_tasklet_handler+0xce/0x110 [mac80211]
 [<c04862ff>] ? net_rx_action+0xef/0x1d0
 [<c0149378>] ? tasklet_action+0x58/0xc0
 [<c014a0f2>] ? __do_softirq+0xc2/0x190
 [<c018eb48>] ? handle_IRQ_event+0x58/0x140
 [<c01205fe>] ? ack_apic_level+0x7e/0x270
 [<c014a1fd>] ? do_softirq+0x3d/0x40
 [<c014a345>] ? irq_exit+0x65/0x90
 [<c010a6af>] ? do_IRQ+0x4f/0xc0
 [<c014a35d>] ? irq_exit+0x7d/0x90
 [<c011d547>] ? smp_apic_timer_interrupt+0x57/0x90
 [<c01094a9>] ? common_interrupt+0x29/0x30
 [<c010fd9e>] ? mwait_idle+0xbe/0x100
 [<c0107e42>] ? cpu_idle+0x52/0x90
 [<c054b1a5>] ? rest_init+0x55/0x60
 [<c077492d>] ? start_kernel+0x315/0x37d
 [<c07743ce>] ? unknown_bootoption+0x0/0x1f9
 [<c0774099>] ? i386_start_kernel+0x79/0x81
Code: <bleh3>
EIP: [<f8806c70>] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211] SS:ESP 0068:c076be38
CR2: 0000000000000030

Cc: stable@kernel.org
Testedy-by: NJack Lau <jackelectronics@hotmail.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      416fbdff
  7. 10 8月, 2009 3 次提交
    • R
      sctp: fix missing destroy of percpu counter variable in sctp_proc_exit() · 418372b0
      由 Rafael Laufer 提交于 
      Commit 1748376b,
	net: Use a percpu_counter for sockets_allocated

added percpu_counter function calls to sctp_proc_init code path, but
forgot to add them to sctp_proc_exit().  This resulted in a following
Ooops when performing this test
	# modprobe sctp
	# rmmod -f sctp
	# modprobe sctp

[  573.862512] BUG: unable to handle kernel paging request at f8214a24
[  573.862518] IP: [<c0308b8f>] __percpu_counter_init+0x3f/0x70
[  573.862530] *pde = 37010067 *pte = 00000000
[  573.862534] Oops: 0002 [#1] SMP
[  573.862537] last sysfs file: /sys/module/libcrc32c/initstate
[  573.862540] Modules linked in: sctp(+) crc32c libcrc32c binfmt_misc bridge
stp bnep lp snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm_oss snd_mixer_oss arc4 joydev snd_pcm ecb pcmcia snd_seq_dummy
snd_seq_oss iwlagn iwlcore snd_seq_midi snd_rawmidi snd_seq_midi_event
yenta_socket rsrc_nonstatic thinkpad_acpi snd_seq snd_timer snd_seq_device
mac80211 psmouse sdhci_pci sdhci nvidia(P) ppdev video snd soundcore serio_raw
pcspkr iTCO_wdt iTCO_vendor_support led_class ricoh_mmc pcmcia_core intel_agp
nvram agpgart usbhid parport_pc parport output snd_page_alloc cfg80211 btusb
ohci1394 ieee1394 e1000e [last unloaded: sctp]
[  573.862589]
[  573.862593] Pid: 5373, comm: modprobe Tainted: P  R        (2.6.31-rc3 #6)
7663B15
[  573.862596] EIP: 0060:[<c0308b8f>] EFLAGS: 00010286 CPU: 1
[  573.862599] EIP is at __percpu_counter_init+0x3f/0x70
[  573.862602] EAX: f8214a20 EBX: f80faa14 ECX: c48c0000 EDX: f80faa20
[  573.862604] ESI: f80a7000 EDI: 00000000 EBP: f69d5ef0 ESP: f69d5eec
[  573.862606]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  573.862610] Process modprobe (pid: 5373, ti=f69d4000 task=c2130c70
task.ti=f69d4000)
[  573.862612] Stack:
[  573.862613]  00000000 f69d5f18 f80a70a8 f80fa9fc 00000000 fffffffc f69d5f30
c018e2d4
[  573.862619] <0> 00000000 f80a7000 00000000 f69d5f88 c010112b 00000000
c07029c0 fffffffb
[  573.862626] <0> 00000000 f69d5f38 c018f83f f69d5f54 c0557cad f80fa860
00000001 c07010c0
[  573.862634] Call Trace:
[  573.862644]  [<f80a70a8>] ? sctp_init+0xa8/0x7d4 [sctp]
[  573.862650]  [<c018e2d4>] ? marker_update_probe_range+0x184/0x260
[  573.862659]  [<f80a7000>] ? sctp_init+0x0/0x7d4 [sctp]
[  573.862662]  [<c010112b>] ? do_one_initcall+0x2b/0x160
[  573.862666]  [<c018f83f>] ? tracepoint_module_notify+0x2f/0x40
[  573.862671]  [<c0557cad>] ? notifier_call_chain+0x2d/0x70
[  573.862678]  [<c01588fd>] ? __blocking_notifier_call_chain+0x4d/0x60
[  573.862682]  [<c016b2f1>] ? sys_init_module+0xb1/0x1f0
[  573.862686]  [<c0102ffc>] ? sysenter_do_call+0x12/0x28
[  573.862688] Code: 89 48 08 b8 04 00 00 00 e8 df aa ec ff ba f4 ff ff ff 85
c0 89 43 14 74 31 b8 b0 18 71 c0 e8 19 b9 24 00 a1 c4 18 71 c0 8d 53 0c <89> 50
04 89 43 0c b8 b0 18 71 c0 c7 43 10 c4 18 71 c0 89 15 c4
[  573.862725] EIP: [<c0308b8f>] __percpu_counter_init+0x3f/0x70 SS:ESP
0068:f69d5eec
[  573.862730] CR2: 00000000f8214a24
[  573.862734] ---[ end trace 39c4e0b55e7cf54d ]---
Signed-off-by: NRafael Laufer <rlaufer@cisco.com>
Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      418372b0
    • E
      can: Fix raw_getname() leak · e84b90ae
      由 Eric Dumazet 提交于 
      raw_getname() can leak 10 bytes of kernel memory to user

(two bytes hole between can_family and can_ifindex,
8 bytes at the end of sockaddr_can structure)
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NOliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e84b90ae
    • J
      Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition · b79a7947
      由 Jussi Mäki 提交于 
      This patch fixes hash collisions in cases where number
of entries have incrementing IP source and destination addresses
from single respective subnets (i.e. 192.168.0.1-172.16.0.1,
192.168.0.2-172.16.0.2, and so on.).
Signed-off-by: NJussi Maki <joamaki@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b79a7947
  9. 07 8月, 2009 5 次提交
  11. 06 8月, 2009 4 次提交
  13. 05 8月, 2009 1 次提交
    • I
      net: Fix spinlock use in alloc_netdev_mq() · 0bf52b98
      由 Ingo Molnar 提交于 
      -tip testing found this lockdep warning:

[    2.272010] calling  net_dev_init+0x0/0x164 @ 1
[    2.276033] device class 'net': registering
[    2.280191] INFO: trying to register non-static key.
[    2.284005] the code is fine but needs lockdep annotation.
[    2.284005] turning off the locking correctness validator.
[    2.284005] Pid: 1, comm: swapper Not tainted 2.6.31-rc5-tip #1145
[    2.284005] Call Trace:
[    2.284005]  [<7958eb4e>] ? printk+0xf/0x11
[    2.284005]  [<7904f83c>] __lock_acquire+0x11b/0x622
[    2.284005]  [<7908c9b7>] ? alloc_debug_processing+0xf9/0x144
[    2.284005]  [<7904e2be>] ? mark_held_locks+0x3a/0x52
[    2.284005]  [<7908dbc4>] ? kmem_cache_alloc+0xa8/0x13f
[    2.284005]  [<7904e475>] ? trace_hardirqs_on_caller+0xa2/0xc3
[    2.284005]  [<7904fdf6>] lock_acquire+0xb3/0xd0
[    2.284005]  [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
[    2.284005]  [<79591514>] _spin_lock_bh+0x2d/0x5d
[    2.284005]  [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
[    2.284005]  [<79489678>] alloc_netdev_mq+0xf5/0x1ad
[    2.284005]  [<793a38f2>] ? loopback_setup+0x0/0x74
[    2.284005]  [<798eecd0>] loopback_net_init+0x20/0x5d
[    2.284005]  [<79483efb>] register_pernet_device+0x23/0x4b
[    2.284005]  [<798f5c9f>] net_dev_init+0x115/0x164
[    2.284005]  [<7900104f>] do_one_initcall+0x4a/0x11a
[    2.284005]  [<798f5b8a>] ? net_dev_init+0x0/0x164
[    2.284005]  [<79066f6d>] ? register_irq_proc+0x8c/0xa8
[    2.284005]  [<798cc29a>] do_basic_setup+0x42/0x52
[    2.284005]  [<798cc30a>] kernel_init+0x60/0xa1
[    2.284005]  [<798cc2aa>] ? kernel_init+0x0/0xa1
[    2.284005]  [<79003e03>] kernel_thread_helper+0x7/0x10
[    2.284078] device: 'lo': device_add
[    2.288248] initcall net_dev_init+0x0/0x164 returned 0 after 11718 usecs
[    2.292010] calling  neigh_init+0x0/0x66 @ 1
[    2.296010] initcall neigh_init+0x0/0x66 returned 0 after 0 usecs

it's using an zero-initialized spinlock. This is a side-effect of:

        dev_unicast_init(dev);

in alloc_netdev_mq() making use of dev->addr_list_lock.

The device has just been allocated freshly, it's not accessible
anywhere yet so no locking is needed at all - in fact it's wrong
to lock it here (the lock isnt initialized yet).

This bug was introduced via:

| commit a6ac65db
| Date:   Thu Jul 30 01:06:12 2009 +0000
|
|     net: restore the original spinlock to protect unicast list
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NJiri Pirko <jpirko@redhat.com>
Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bf52b98
  15. 04 8月, 2009 3 次提交
    • L
      cfg80211: fix regression on beacon world roaming feature · 37184244
      由 Luis R. Rodriguez 提交于 
      A regression was added through patch a4ed90d6:

"cfg80211: respect API on orig_flags on channel for beacon hint"

We did indeed respect _orig flags but the intention was not clearly
stated in the commit log. This patch fixes firmware issues picked
up by iwlwifi when we lift passive scan of beaconing restrictions
on channels its EEPROM has been configured to always enable.

By doing so though we also disallowed beacon hints on devices
registering their wiphy with custom world regulatory domains
enabled, this happens to be currently ath5k, ath9k and ar9170.
The passive scan and beacon restrictions on those devices would
never be lifted even if we did find a beacon and the hardware did
support such enhancements when world roaming.

Since Johannes indicates iwlwifi firmware cannot be changed to
allow beacon hinting we set up a flag now to specifically allow
drivers to disable beacon hints for devices which cannot use them.

We enable the flag on iwlwifi to disable beacon hints and by default
enable it for all other drivers. It should be noted beacon hints lift
passive scan flags and beacon restrictions when we receive a beacon from
an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
band. We don't bother with channels 1-11 as those channels are allowed
world wide.

This should fix world roaming for ath5k, ath9k and ar9170, thereby
improving scan time when we receive the first beacon from any AP,
and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
would otherwise not be allowed to do so. Drivers not using custom
regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
by this as the orig_flags for the channels would have been cleared
upon wiphy registration.

I tested this with a world roaming ath5k card.

Cc: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37184244
    • J
      cfg80211: add two missing NULL pointer checks · cd3468ba
      由 Johannes Berg 提交于 
      These pointers can be NULL, the is_mesh() case isn't
ever hit in the current kernel, but cmp_ies() can be
hit under certain conditions.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org [2.6.29, 2.6.30]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cd3468ba
    • D
      bluetooth: rfcomm_init bug fix · af0d3b10
      由 Dave Young 提交于 
      rfcomm tty may be used before rfcomm_tty_driver initilized,
The problem is that now socket layer init before tty layer, if userspace
program do socket callback right here then oops will happen.

reporting in:
http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2

make 3 changes:
1. remove #ifdef in rfcomm/core.c,
make it blank function when rfcomm tty not selected in rfcomm.h

2. tune the rfcomm_init error patch to ensure
tty driver initilized before rfcomm socket usage.

3. remove __exit for rfcomm_cleanup_sockets
because above change need call it in a __init function.
Reported-by: NOliver Hartkopp <oliver@hartkopp.net>
Tested-by: NOliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      af0d3b10
  17. 03 8月, 2009 2 次提交
  19. 31 7月, 2009 2 次提交
  21. 30 7月, 2009 2 次提交
  23. 28 7月, 2009 2 次提交
  25. 27 7月, 2009 2 次提交
  27. 22 7月, 2009 7 次提交
  29. 20 7月, 2009 3 次提交
  31. 17 7月, 2009 1 次提交
    • E
      net: sock_copy() fixes · 4dc6dc71
      由 Eric Dumazet 提交于 
      Commit e912b114
(net: sk_prot_alloc() should not blindly overwrite memory)
took care of not zeroing whole new socket at allocation time.

sock_copy() is another spot where we should be very careful.
We should not set refcnt to a non null value, until
we are sure other fields are correctly setup, or
a lockless reader could catch this socket by mistake,
while not fully (re)initialized.

This patch puts sk_node & sk_refcnt to the very beginning
of struct sock to ease sock_copy() & sk_prot_alloc() job.

We add appropriate smp_wmb() before sk_refcnt initializations
to match our RCU requirements (changes to sock keys should
be committed to memory before sk_refcnt setting)
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4dc6dc71