1. 05 May, 2009 9 commits
  2. 04 May, 2009 13 commits
    • Marcel Holtmann's avatar
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann authored
      Due to a semantic changes in flush_workqueue() the current approach of
      synchronizing the sysfs handling for connections doesn't work anymore. The
      whole approach is actually fully broken and based on assumptions that are
      no longer valid.
      
      With the introduction of Simple Pairing support, the creation of low-level
      ACL links got changed. This change invalidates the reason why in the past
      two independent work queues have been used for adding/removing sysfs
      devices. The adding of the actual sysfs device is now postponed until the
      host controller successfully assigns an unique handle to that link. So
      the real synchronization happens inside the controller and not the host.
      
      The only left-over problem is that some internals of the sysfs device
      handling are not initialized ahead of time. This leaves potential access
      to invalid data and can cause various NULL pointer dereferences. To fix
      this a new function makes sure that all sysfs details are initialized
      when an connection attempt is made. The actual sysfs device is only
      registered when the connection has been successfully established. To
      avoid a race condition with the registration, the check if a device is
      registered has been moved into the removal work.
      
      As an extra protection two flush_work() calls are left in place to
      make sure a previous add/del work has been completed first.
      
      Based on a report by Marc Pignat <marc.pignat@hevs.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: default avatarMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
    • 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
    • Omar Laazimani's avatar
      usbnet: CDC EEM support (v5) · 9f722c09
      Omar Laazimani authored
      This introduces a CDC Ethernet Emulation Model (EEM) host side
      driver to support USB EEM devices.
      
      EEM is different from the Ethernet Control Model (ECM) currently
      supported by the "CDC Ethernet" driver.  One key difference is
      that it doesn't require of USB interface alternate settings to
      manage interface state; some maldesigned hardware can't handle
      that part of USB.  It also avoids a separate USB interface for
      control and status updates.
      
      [ dbrownell@users.sourceforge.net: fix skb leaks, add rx packet
      checks, improve fault handling, EEM conformance updates, cleanup ]
      Signed-off-by: default avatarOmar Laazimani <omar.oberthur@gmail.com>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f722c09
    • Satoru SATOH's avatar
      tcp: Fix tcp_prequeue() to get correct rto_min value · 0c266898
      Satoru SATOH authored
      tcp_prequeue() refers to the constant value (TCP_RTO_MIN) regardless of
      the actual value might be tuned. The following patches fix this and make
      tcp_prequeue get the actual value returns from tcp_rto_min().
      Signed-off-by: default avatarSatoru SATOH <satoru.satoh@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c266898
    • Hannes Hering's avatar
      ehea: fix invalid pointer access · 0b2febf3
      Hannes Hering authored
      This patch fixes an invalid pointer access in case the receive queue
      holds no pointer to the next skb when the queue is empty.
      Signed-off-by: default avatarHannes Hering <hering2@de.ibm.com>
      Signed-off-by: default avatarJan-Bernd Themann <themann@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b2febf3
  3. 02 May, 2009 5 commits
  4. 01 May, 2009 10 commits
  5. 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