1. 06 5月, 2009 2 次提交
  2. 05 5月, 2009 20 次提交
    • P
      netfilter: ctnetlink: fix wrong message type in user updates · fecc1133
      Pablo Neira Ayuso 提交于
      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: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      fecc1133
    • P
      netfilter: xt_cluster: fix use of cluster match with 32 nodes · 280f37af
      Pablo Neira Ayuso 提交于
      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: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      280f37af
    • C
      netfilter: ip6t_ipv6header: fix match on packets ending with NEXTHDR_NONE · b98b4947
      Christoph Paasch 提交于
      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: NChristoph Paasch <christoph.paasch@gmail.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      b98b4947
    • P
      netfilter: add missing linux/types.h include to xt_LED.h · a7ca7fcc
      Patrick McHardy 提交于
      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: NPatrick McHardy <kaber@trash.net>
      a7ca7fcc
    • D
    • J
      e1000: fix virtualization bug · e151a60a
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e151a60a
    • J
      bonding: fix alb mode locking regression · 815bcc27
      Jay Vosburgh 提交于
      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: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      815bcc27
    • M
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann 提交于
      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: NMarcel Holtmann <marcel@holtmann.org>
      Tested-by: NJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: NRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: NMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
    • J
      mac80211: pid, fix memory corruption · 6909268d
      Jiri Slaby 提交于
      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: NJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6909268d
    • J
      mac80211: minstrel, fix memory corruption · 8e532175
      Jiri Slaby 提交于
      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: NJiri Slaby <jirislaby@gmail.com>
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e532175
    • L
    • L
      cfg80211: fix bug while trying to process beacon hints on init · b1ed8ddd
      Luis R. Rodriguez 提交于
      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: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b1ed8ddd
    • L
      cfg80211: fix race condition with wiphy_apply_custom_regulatory() · ac46d48e
      Luis R. Rodriguez 提交于
      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: NNataraj Sadasivam <Nataraj.Sadasivam@Atheros.com>
      Reported-by: NVivek Natarajan <Vivek.Natarajan@Atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ac46d48e
    • R
      iwlwifi: update key flags at time key is set · 299f5462
      Reinette Chatre 提交于
      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: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      299f5462
    • J
      cfg80211: fix truncated IEs · c0f0aac0
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c0f0aac0
    • J
      mac80211: correct fragmentation threshold check · 8ccd8f21
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8ccd8f21
    • A
      iwlwifi: remove EXPORT_SYMBOL for static symbol · 3ee59f8d
      Andreas Schwab 提交于
      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: NAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ee59f8d
    • O
      usbnet: CDC EEM support (v5) · 9f722c09
      Omar Laazimani 提交于
      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: NOmar Laazimani <omar.oberthur@gmail.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9f722c09
    • S
      tcp: Fix tcp_prequeue() to get correct rto_min value · 0c266898
      Satoru SATOH 提交于
      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: NSatoru SATOH <satoru.satoh@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c266898
    • H
      ehea: fix invalid pointer access · 0b2febf3
      Hannes Hering 提交于
      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: NHannes Hering <hering2@de.ibm.com>
      Signed-off-by: NJan-Bernd Themann <themann@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b2febf3
  3. 03 5月, 2009 3 次提交
  4. 02 5月, 2009 12 次提交
  5. 30 4月, 2009 3 次提交
    • J
      net: Fix oops when splicing skbs from a frag_list. · 7a67e56f
      Jarek Poplawski 提交于
      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: NLennert Buytenhek <buytenh@wantstofly.org>
      Debugged-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Tested-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a67e56f
    • L
      mv643xx_eth: 64bit mib counter read fix · 93af7aca
      Lennert Buytenhek 提交于
      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: NLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93af7aca
    • L
      mv643xx_eth: OOM handling fixes · 1319ebad
      Lennert Buytenhek 提交于
      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: NLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1319ebad