1. 06 May, 2009 3 commits
  2. 05 May, 2009 10 commits
    • Marcel Holtmann's avatar
      Bluetooth: Move dev_set_name() to a context that can sleep · 457ca7bb
      Marcel Holtmann authored
      Setting the name of a sysfs device has to be done in a context that can
      actually sleep. It allocates its memory with GFP_KERNEL. Previously it
      was a static (size limited) string and that got changed to accommodate
      longer device names. So move the dev_set_name() just before calling
      device_add() which is executed in a work queue.
      
      This fixes the following error:
      
      [  110.012125] BUG: sleeping function called from invalid context at mm/slub.c:1595
      [  110.012135] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
      [  110.012141] 2 locks held by swapper/0:
      [  110.012145]  #0:  (hci_task_lock){++.-.+}, at: [<ffffffffa01f822f>] hci_rx_task+0x2f/0x2d0 [bluetooth]
      [  110.012173]  #1:  (&hdev->lock){+.-.+.}, at: [<ffffffffa01fb9e2>] hci_event_packet+0x72/0x25c0 [bluetooth]
      [  110.012198] Pid: 0, comm: swapper Tainted: G        W 2.6.30-rc4-g953cdaa #1
      [  110.012203] Call Trace:
      [  110.012207]  <IRQ>  [<ffffffff8023eabd>] __might_sleep+0x14d/0x170
      [  110.012228]  [<ffffffff802cfbe1>] __kmalloc+0x111/0x170
      [  110.012239]  [<ffffffff803c2094>] kvasprintf+0x64/0xb0
      [  110.012248]  [<ffffffff803b7a5b>] kobject_set_name_vargs+0x3b/0xa0
      [  110.012257]  [<ffffffff80465326>] dev_set_name+0x76/0xa0
      [  110.012273]  [<ffffffffa01fb9e2>] ? hci_event_packet+0x72/0x25c0 [bluetooth]
      [  110.012289]  [<ffffffffa01ffc1d>] hci_conn_add_sysfs+0x3d/0x70 [bluetooth]
      [  110.012303]  [<ffffffffa01fba2c>] hci_event_packet+0xbc/0x25c0 [bluetooth]
      [  110.012312]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
      [  110.012328]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
      [  110.012343]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
      [  110.012347]  [<ffffffff805e88c5>] ? _read_unlock+0x75/0x80
      [  110.012354]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
      [  110.012360]  [<ffffffffa01f8403>] hci_rx_task+0x203/0x2d0 [bluetooth]
      [  110.012365]  [<ffffffff80250ab5>] tasklet_action+0xb5/0x160
      [  110.012369]  [<ffffffff8025116c>] __do_softirq+0x9c/0x150
      [  110.012372]  [<ffffffff805e850f>] ? _spin_unlock+0x3f/0x80
      [  110.012376]  [<ffffffff8020cbbc>] call_softirq+0x1c/0x30
      [  110.012380]  [<ffffffff8020f01d>] do_softirq+0x8d/0xe0
      [  110.012383]  [<ffffffff80250df5>] irq_exit+0xc5/0xe0
      [  110.012386]  [<ffffffff8020e71d>] do_IRQ+0x9d/0x120
      [  110.012389]  [<ffffffff8020c3d3>] ret_from_intr+0x0/0xf
      [  110.012391]  <EOI>  [<ffffffff80431832>] ? acpi_idle_enter_bm+0x264/0x2a6
      [  110.012399]  [<ffffffff80431828>] ? acpi_idle_enter_bm+0x25a/0x2a6
      [  110.012403]  [<ffffffff804f50d5>] ? cpuidle_idle_call+0xc5/0x130
      [  110.012407]  [<ffffffff8020a4b4>] ? cpu_idle+0xc4/0x130
      [  110.012411]  [<ffffffff805d2268>] ? rest_init+0x88/0xb0
      [  110.012416]  [<ffffffff807e2fbd>] ? start_kernel+0x3b5/0x412
      [  110.012420]  [<ffffffff807e2281>] ? x86_64_start_reservations+0x91/0xb5
      [  110.012424]  [<ffffffff807e2394>] ? x86_64_start_kernel+0xef/0x11b
      
      Based on a report by Davide Pesavento <davidepesa@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarHugo Mildenberger <hugo.mildenberger@namir.de>
      Tested-by: default avatarBing Zhao <bzhao@marvell.com>
      457ca7bb
    • David S. Miller's avatar
    • David S. Miller's avatar
    • Pablo Neira Ayuso's avatar
      netfilter: ctnetlink: fix wrong message type in user updates · fecc1133
      Pablo Neira Ayuso authored
      This patch fixes the wrong message type that are triggered by
      user updates, the following commands:
      
      (term1)# conntrack -I -p tcp -s 1.1.1.1 -d 2.2.2.2 -t 10 --sport 10 --dport 20 --state LISTEN
      (term1)# conntrack -U -p tcp -s 1.1.1.1 -d 2.2.2.2 -t 10 --sport 10 --dport 20 --state SYN_SENT
      (term1)# conntrack -U -p tcp -s 1.1.1.1 -d 2.2.2.2 -t 10 --sport 10 --dport 20 --state SYN_RECV
      
      only trigger event message of type NEW, when only the first is NEW
      while others should be UPDATE.
      
      (term2)# conntrack -E
          [NEW] tcp      6 10 LISTEN src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0
          [NEW] tcp      6 10 SYN_SENT src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0
          [NEW] tcp      6 10 SYN_RECV src=1.1.1.1 dst=2.2.2.2 sport=10 dport=20 [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=20 dport=10 mark=0
      
      This patch also removes IPCT_REFRESH from the bitmask since it is
      not of any use.
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      fecc1133
    • Pablo Neira Ayuso's avatar
      netfilter: xt_cluster: fix use of cluster match with 32 nodes · 280f37af
      Pablo Neira Ayuso authored
      This patch fixes a problem when you use 32 nodes in the cluster
      match:
      
      % iptables -I PREROUTING -t mangle -i eth0 -m cluster \
        --cluster-total-nodes  32  --cluster-local-node  32 \
        --cluster-hash-seed 0xdeadbeef -j MARK --set-mark 0xffff
      iptables: Invalid argument. Run `dmesg' for more information.
      % dmesg | tail -1
      xt_cluster: this node mask cannot be higher than the total number of nodes
      
      The problem is related to this checking:
      
      if (info->node_mask >= (1 << info->total_nodes)) {
      	printk(KERN_ERR "xt_cluster: this node mask cannot be "
      			"higher than the total number of nodes\n");
      	return false;
      }
      
      (1 << 32) is 1. Thus, the checking fails.
      
      BTW, I said this before but I insist: I have only tested the cluster
      match with 2 nodes getting ~45% extra performance in an active-active setup.
      The maximum limit of 32 nodes is still completely arbitrary. I'd really
      appreciate if people that have more nodes in their setups let me know.
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      280f37af
    • Christoph Paasch's avatar
      netfilter: ip6t_ipv6header: fix match on packets ending with NEXTHDR_NONE · b98b4947
      Christoph Paasch authored
      As packets ending with NEXTHDR_NONE don't have a last extension header,
      the check for the length needs to be after the check for NEXTHDR_NONE.
      Signed-off-by: default avatarChristoph Paasch <christoph.paasch@gmail.com>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      b98b4947
    • Patrick McHardy's avatar
      netfilter: add missing linux/types.h include to xt_LED.h · a7ca7fcc
      Patrick McHardy authored
      Pointed out by Dave Miller:
      
        CHECK   include/linux/netfilter (57 files)
      /home/davem/src/GIT/net-2.6/usr/include/linux/netfilter/xt_LED.h:6: found __[us]{8,16,32,64} type without #include <linux/types.h>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      a7ca7fcc
    • David S. Miller's avatar
    • Jesse Brandeburg's avatar
      e1000: fix virtualization bug · e151a60a
      Jesse Brandeburg authored
      a recent fix to e1000 (commit 15b2bee2) caused KVM/QEMU/VMware based
      virtualized e1000 interfaces to begin failing when resetting.
      
      This is because the driver in a virtual environment doesn't
      get to run instructions *AT ALL* when an interrupt is asserted.
      The interrupt code runs immediately and this recent bug fix
      allows an interrupt to be possible when the interrupt handler
      will reject it (due to the new code), when being called from
      any path in the driver that holds the E1000_RESETTING flag.
      
      the driver should use the __E1000_DOWN flag instead of the
      __E1000_RESETTING flag to prevent interrupt execution
      while reconfiguring the hardware.
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e151a60a
    • Jay Vosburgh's avatar
      bonding: fix alb mode locking regression · 815bcc27
      Jay Vosburgh authored
      Fix locking issue in alb MAC address management; removed
      incorrect locking and replaced with correct locking.  This bug was
      introduced in commit 059fe7a5
      ("bonding: Convert locks to _bh, rework alb locking for new locking")
      
      	Bug reported by Paul Smith <paul@mad-scientist.net>, who also
      tested the fix.
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      815bcc27
  3. 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
  4. 02 May, 2009 5 commits
  5. 01 May, 2009 9 commits