1. 04 May, 2009 9 commits
    • Jiri Slaby's avatar
      mac80211: pid, fix memory corruption · 6909268d
      Jiri Slaby authored
      pid doesn't count with some band having more bitrates than the one
      associated the first time.
      Fix that by counting the maximal available bitrate count and allocate
      big enough space.
      
      Secondly, fix touching uninitialized memory which causes panics.
      Index sucked from this random memory points to the hell.
      The fix is to sort the rates on each band change.
      Signed-off-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6909268d
    • Jiri Slaby's avatar
      mac80211: minstrel, fix memory corruption · 8e532175
      Jiri Slaby authored
      minstrel doesn't count max rate count in fact, since it doesn't use
      a loop variable `i' and hence allocs space only for bitrates found in
      the first band.
      
      Fix it by involving the `i' as an index so that it traverses all the
      bands now and finds the real max bitrate count.
      Signed-off-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8e532175
    • Luis R. Rodriguez's avatar
    • Luis R. Rodriguez's avatar
      cfg80211: fix bug while trying to process beacon hints on init · b1ed8ddd
      Luis R. Rodriguez authored
      During initialization we would not have received any beacons
      so skip processing reg beacon hints, also adds a check to
      reg_is_world_roaming() for last_request before accessing its
      fields.
      
      This should fix this:
      
      BUG: unable to handle kernel NULL pointer dereference at
      
      IP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295
      
      *pdpt = 0000000008bf1001 *pde = 0000000000000000
      Oops: 0000 [#1]
      last sysfs file: /sys/class/backlight/eeepc/brightness
      Modules linked in: ath5k(+) mac80211 led_class cfg80211
      go_bit cfbcopyarea cfbimgblt cfbfillrect ipv6
      ydev usual_tables(P) snd_hda_codec_realtek snd_hda_intel
      nd_hwdep uhci_hcd snd_pcm_oss snd_mixer_oss i2c_i801
      e serio_raw i2c_core pcspkr atl2 snd_pcm intel_agp
      re agpgart eeepc_laptop snd_page_alloc ac video backlight
      rfkill button processor evdev thermal fan ata_generic
      
      Pid: 2909, comm: modprobe Tainted: Pc #112) 701
      EIP: 0060:[<e0171332>] EFLAGS: 00010246 CPU: 0
      EIP is at wiphy_update_regulatory+0x20f/0x295 [cfg80211]
      EAX: 00000000 EBX: c5da0000 ECX: 00000000 EDX: c5da0060
      ESI: 0000001a EDI: c5da0060 EBP: df3bdd70 ESP: df3bdd40
       DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      Process modprobe (pid: 2909, ti=df3bc000 task=c5d030000)
      Stack:
       df3bdd90 c5da0060 c04277e0 00000001 00000044 c04277e402
       00000002 c5da0000 0000001a c5da0060 df3bdda8 e01706a2 02
       00000282 000080d0 00000068 c5d53500 00000080 0000028240
      Call Trace:
       [<e01706a2>] ? wiphy_register+0x122/0x1b7 [cfg80211]
       [<e0328e02>] ? ieee80211_register_hw+0xd8/0x346
       [<e06a7c9f>] ? ath5k_hw_set_bssid_mask+0x71/0x78 [ath5k]
       [<e06b0c52>] ? ath5k_pci_probe+0xa5c/0xd0a [ath5k]
       [<c01a6037>] ? sysfs_find_dirent+0x16/0x27
       [<c01fec95>] ? local_pci_probe+0xe/0x10
       [<c01ff526>] ? pci_device_probe+0x48/0x66
       [<c024c9fd>] ? driver_probe_device+0x7f/0xf2
       [<c024cab3>] ? __driver_attach+0x43/0x5f
       [<c024c0af>] ? bus_for_each_dev+0x39/0x5a
       [<c024c8d0>] ? driver_attach+0x14/0x16
       [<c024ca70>] ? __driver_attach+0x0/0x5f
       [<c024c5b3>] ? bus_add_driver+0xd7/0x1e7
       [<c024ccb9>] ? driver_register+0x7b/0xd7
       [<c01ff827>] ? __pci_register_driver+0x32/0x85
       [<e00a8018>] ? init_ath5k_pci+0x18/0x30 [ath5k]
       [<c0101131>] ? _stext+0x49/0x10b
       [<e00a8000>] ? init_ath5k_pci+0x0/0x30 [ath5k]
       [<c012f452>] ? __blocking_notifier_call_chain+0x40/0x4c
       [<c013a714>] ? sys_init_module+0x87/0x18b
       [<c0102804>] ? sysenter_do_call+0x12/0x22
      Code: b8 da 17 e0 83 c0 04 e8 92 f9 ff ff 84 c0 75 2a 8b
      85 c0 74 0c 83 c0 04 e8 7c f9 ff ff 84 c0 75 14 a1 bc da
      4 03 74 66 8b 4d d4 80 79 08 00 74 5d a1 e0 d2 17 e0 48
      EIP: [<e0171332>] wiphy_update_regulatory+0x20f/0x295
      SP 0068:df3bdd40
      CR2: 0000000000000004
      ---[ end trace 830f2dd2a95fd1a8 ]---
      
      This issue is hard to reproduce, but it was noticed and discussed on
      this thread:
      
      http://marc.info/?t=123938022700005&r=1&w=2
      
      Cc: stable@kernel.org
      Reported-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b1ed8ddd
    • Luis R. Rodriguez's avatar
      cfg80211: fix race condition with wiphy_apply_custom_regulatory() · ac46d48e
      Luis R. Rodriguez authored
      We forgot to lock using the cfg80211_mutex in
      wiphy_apply_custom_regulatory(). Without the lock
      there is possible race between processing a reply from CRDA
      and a driver calling wiphy_apply_custom_regulatory(). During
      the processing of the reply from CRDA we free last_request and
      wiphy_apply_custom_regulatory() eventually accesses an
      element from last_request in the through freq_reg_info_regd().
      
      This is very difficult to reproduce (I haven't), it takes us
      3 hours and you need to be banging hard, but the race is obvious
      by looking at the code.
      
      This should only affect those who use this caller, which currently
      is ath5k, ath9k, and ar9170.
      
      EIP: 0060:[<f8ebec50>] EFLAGS: 00210282 CPU: 1
      EIP is at freq_reg_info_regd+0x24/0x121 [cfg80211]
      EAX: 00000000 EBX: f7ca0060 ECX: f5183d94 EDX: 0024cde0
      ESI: f8f56edc EDI: 00000000 EBP: 00000000 ESP: f5183d44
      DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process modprobe (pid: 14617, ti=f5182000 task=f3934d10 task.ti=f5182000)
      Stack: c0505300 f7ca0ab4 f5183d94 0024cde0 f8f403a6 f8f63160 f7ca0060 00000000
      00000000 f8ebedf8 f5183d90 f8f56edc 00000000 00000004 00000f40 f8f56edc
      f7ca0060 f7ca1234 00000000 00000000 00000000 f7ca14f0 f7ca0ab4 f7ca1289
      Call Trace:
      [<f8ebedf8>] wiphy_apply_custom_regulatory+0x8f/0x122 [cfg80211]
      [<f8f3f798>] ath_attach+0x707/0x9e6 [ath9k]
      [<f8f45e46>] ath_pci_probe+0x18d/0x29a [ath9k]
      [<c023c7ba>] pci_device_probe+0xa3/0xe4
      [<c02a860b>] really_probe+0xd7/0x1de
      [<c02a87e7>] __driver_attach+0x37/0x55
      [<c02a7eed>] bus_for_each_dev+0x31/0x57
      [<c02a83bd>] driver_attach+0x16/0x18
      [<c02a78e6>] bus_add_driver+0xec/0x21b
      [<c02a8959>] driver_register+0x85/0xe2
      [<c023c9bb>] __pci_register_driver+0x3c/0x69
      [<f8e93043>] ath9k_init+0x43/0x68 [ath9k]
      [<c010112b>] _stext+0x3b/0x116
      [<c014a872>] sys_init_module+0x8a/0x19e
      [<c01049ad>] sysenter_do_call+0x12/0x21
      [<ffffe430>] 0xffffe430
      =======================
      Code: 0f 94 c0 c3 31 c0 c3 55 57 56 53 89 c3 83 ec 14 8b 74 24 2c 89 54 24 0c 89 4c 24 08 85 f6 75
      06 8b 35 c8 bb ec f8 a1 cc bb ec f8 <8b> 40 04 83 f8 03 74 3a 48 74 37 8b 43 28 85 c0 74 30 89 c6
      8b
      EIP: [<f8ebec50>] freq_reg_info_regd+0x24/0x121 [cfg80211] SS:ESP 0068:f5183d44
      
      Cc: stable@kernel.org
      Reported-by: default avatarNataraj Sadasivam <Nataraj.Sadasivam@Atheros.com>
      Reported-by: default avatarVivek Natarajan <Vivek.Natarajan@Atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ac46d48e
    • Reinette Chatre's avatar
      iwlwifi: update key flags at time key is set · 299f5462
      Reinette Chatre authored
      We need to be symmetrical in what is done when key is set and cleared.
      This is important wrt the key flags as they are used during key
      clearing and if they are not set when the key is set the key cannot be
      cleared completely.
      
      This addresses the many occurences of the WARN found in
      iwl_set_tkip_dynamic_key_info() and tracked in
      http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key
      
      If calling iwl_set_tkip_dynamic_key_info()/iwl_remove_dynamic_key()
      pair a few times in a row will cause that we run out of key space.
      This is because the index stored in the key flags is used by
      iwl_remove_dynamic_key() to decide if it should remove the key.
      Unfortunately the key flags, and hence the key index is currently only
      set at the time the key is written to the device (in
      iwl_update_tkip_key()) and _not_ in iwl_set_tkip_dynamic_key_info().
      Fix this by setting flags in iwl_set_tkip_dynamic_key_info().
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      299f5462
    • Johannes Berg's avatar
      cfg80211: fix truncated IEs · c0f0aac0
      Johannes Berg authored
      Another bug in the "cfg80211: do not replace BSS structs" patch,
      a forgotten length update leads to bogus data being stored and
      passed to userspace, often truncated.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c0f0aac0
    • Johannes Berg's avatar
      mac80211: correct fragmentation threshold check · 8ccd8f21
      Johannes Berg authored
      The fragmentation threshold is defined to be including the
      FCS, and the code that sets the TX_FRAGMENTED flag correctly
      accounts for those four bytes. The code that verifies this
      doesn't though, which could lead to spurious warnings and
      frames being dropped although everything is ok. Correct the
      code by accounting for the FCS.
      
      (JWL -- The problem is described here:
       http://article.gmane.org/gmane.linux.kernel.wireless.general/32205 )
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8ccd8f21
    • Andreas Schwab's avatar
      iwlwifi: remove EXPORT_SYMBOL for static symbol · 3ee59f8d
      Andreas Schwab authored
      It does not make sense to apply EXPORT_SYMBOL to a static symbol.  Fixes
      this build error:
      
      drivers/net/wireless/iwlwifi/iwl3945-base.c:1697: error: __ksymtab_iwl3945_rx_queue_reset causes a section type conflict
      Signed-off-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3ee59f8d
  2. 02 May, 2009 5 commits
  3. 01 May, 2009 10 commits
  4. 30 Apr, 2009 3 commits
    • Jarek Poplawski's avatar
      net: Fix oops when splicing skbs from a frag_list. · 7a67e56f
      Jarek Poplawski authored
      Lennert Buytenhek wrote:
      > Since 4fb66994 ("net: Optimize memory
      > usage when splicing from sockets.") I'm seeing this oops (e.g. in
      > 2.6.30-rc3) when splicing from a TCP socket to /dev/null on a driver
      > (mv643xx_eth) that uses LRO in the skb mode (lro_receive_skb) rather
      > than the frag mode:
      
      My patch incorrectly assumed skb->sk was always valid, but for
      "frag_listed" skbs we can only use skb->sk of their parent.
      Reported-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Debugged-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Tested-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a67e56f
    • Lennert Buytenhek's avatar
      mv643xx_eth: 64bit mib counter read fix · 93af7aca
      Lennert Buytenhek authored
      On several mv643xx_eth hardware versions, the two 64bit mib counters
      for 'good octets received' and 'good octets sent' are actually 32bit
      counters, and reading from the upper half of the register has the same
      effect as reading from the lower half of the register: an atomic
      read-and-clear of the entire 32bit counter value.  This can under heavy
      traffic occasionally lead to small numbers being added to the upper
      half of the 64bit mib counter even though no 32bit wrap has occured.
      
      Since we poll the mib counters at least every 30 seconds anyway, we
      might as well just skip the reads of the upper halves of the hardware
      counters without breaking the stats, which this patch does.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93af7aca
    • Lennert Buytenhek's avatar
      mv643xx_eth: OOM handling fixes · 1319ebad
      Lennert Buytenhek authored
      Currently, when OOM occurs during rx ring refill, mv643xx_eth will get
      into an infinite loop, due to the refill function setting the OOM bit
      but not clearing the 'rx refill needed' bit for this queue, while the
      calling function (the NAPI poll handler) will call the refill function
      in a loop until the 'rx refill needed' bit goes off, without checking
      the OOM bit.
      
      This patch fixes this by checking the OOM bit in the NAPI poll handler
      before attempting to do rx refill.  This means that once OOM occurs,
      we won't try to do any memory allocations again until the next invocation
      of the poll handler.
      
      While we're at it, change the OOM flag to be a single bit instead of
      one bit per receive queue since OOM is a system state rather than a
      per-queue state, and cancel the OOM timer on entry to the NAPI poll
      handler if it's running to prevent it from firing when we've already
      come out of OOM.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1319ebad
  5. 29 Apr, 2009 6 commits
  6. 28 Apr, 2009 7 commits
    • Bob Copeland's avatar
      ath5k: fix buffer overrun in rate debug code · b7fcb5c4
      Bob Copeland authored
      char bname[5] is too small for the string "X GHz" when the null
      terminator is taken into account.  Thus, turning on rate debugging
      can crash unless we have lucky stack alignment.
      
      Cc: stable@kernel.org
      Reported-by: default avatarParide Legovini <legovini@spiro.fisica.unipd.it>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b7fcb5c4
    • Johannes Berg's avatar
      iwlwifi: notify on scan completion even when shutting down · 74aa9be0
      Johannes Berg authored
      Under certain circumstances iwlwifi can get stuck and will no
      longer accept scan requests, because the core code (cfg80211)
      thinks that it's still processing one. This fixes one of the
      points where it can happen, but I've still seen it (although
      only with my radio-off-when-idle patch).
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      74aa9be0
    • Jussi Kivilinna's avatar
      rndis_wlan: fix initialization order for workqueue&workers · e805e4d0
      Jussi Kivilinna authored
      rndis_wext_link_change() might be called from rndis_command() at
      initialization stage and priv->workqueue/priv->work have not been
      initialized yet. This causes invalid opcode at rndis_wext_bind on
      some brands of bcm4320.
      
      Fix by initializing workqueue/workers in rndis_wext_bind() before
      rndis_command is used.
      
      This bug has existed since 2.6.25, reported at:
      	http://bugzilla.kernel.org/show_bug.cgi?id=12794Signed-off-by: default avatarJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e805e4d0
    • Stephen Rothwell's avatar
      wireless: remove unneeded EXPORT_SYMBOL the tickles a powerpc compiler bug · 6269b731
      Stephen Rothwell authored
      drivers/net/wireless/iwlwifi/iwl3945-base.c:1415: error: __ksymtab_iwl3945_rx_queue_reset causes a section type conflict
      
      I am pretty sure that this is a compiler bug, so not to worry.  However,
      as far as I can see, iwl-3945.o (the only user) and iwl3945-base.o are
      always linked into the same module, so the EXPORT_SYMBOL (which causes
      the problem) should not be needed.  Correct?
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6269b731
    • Marcel Holtmann's avatar
      Bluetooth: Fix connection establishment with low security requirement · 3fdca1e1
      Marcel Holtmann authored
      The Bluetooth 2.1 specification introduced four different security modes
      that can be mapped using Legacy Pairing and Simple Pairing. With the
      usage of Simple Pairing it is required that all connections (except
      the ones for SDP) are encrypted. So even the low security requirement
      mandates an encrypted connection when using Simple Pairing. When using
      Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
      since it causes interoperability issues.
      
      To support this properly the low security requirement translates into
      different host controller transactions depending if Simple Pairing is
      supported or not. However in case of Simple Pairing the command to
      switch on encryption after a successful authentication is not triggered
      for the low security mode. This patch fixes this and actually makes
      the logic to differentiate between Simple Pairing and Legacy Pairing
      a lot simpler.
      
      Based on a report by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3fdca1e1
    • Marcel Holtmann's avatar
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann authored
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      triggered.
      
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      052b30b0
    • Roger Quadros's avatar
      Bluetooth: Ensure that HCI sysfs add/del is preempt safe · f3784d83
      Roger Quadros authored
      Use a different work_struct variables for add_conn() and del_conn() and
      use single work queue instead of two for adding and deleting connections.
      
      It eliminates the following error on a preemptible kernel:
      
      [  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      [  204.370697] pgd = c0004000
      [  204.373443] [0000000c] *pgd=00000000
      [  204.378601] Internal error: Oops: 17 [#1] PREEMPT
      [  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
      [  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
      [  204.443664] PC is at klist_put+0x2c/0xb4
      [  204.447601] LR is at klist_put+0x18/0xb4
      [  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
      [  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
      [  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
      [  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
      [  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
      [  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      [  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
      [  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)
      Signed-off-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f3784d83