1. 02 12月, 2011 2 次提交
  2. 01 12月, 2011 7 次提交
  3. 30 11月, 2011 4 次提交
  4. 29 11月, 2011 10 次提交
    • D
      Merge branch 'nf' of git://1984.lsi.us.es/net · c1baa884
      David S. Miller 提交于
      c1baa884
    • X
      sctp: integer overflow in sctp_auth_create_key() · a5e5c374
      Xi Wang 提交于
      The previous commit 30c2235c is incomplete and cannot prevent integer
      overflows. For example, when key_len is 0x80000000 (INT_MAX + 1), the
      left-hand side of the check, (INT_MAX - key_len), which is unsigned,
      becomes 0xffffffff (UINT_MAX) and bypasses the check.
      Signed-off-by: NXi Wang <xi.wang@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5e5c374
    • L
      ipv6: Set mcast_hops to IPV6_DEFAULT_MCASTHOPS when -1 was given. · 2a38e6d5
      Li Wei 提交于
      We need to set np->mcast_hops to it's default value at this moment
      otherwise when we use it and found it's value is -1, the logic to
      get default hop limit doesn't take multicast into account and will
      return wrong hop limit(IPV6_DEFAULT_HOPLIMIT) which is for unicast.
      Signed-off-by: NLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a38e6d5
    • A
      net: Fix corruption in /proc/*/net/dev_mcast · 5cac98dd
      Anton Blanchard 提交于
      I just hit this during my testing. Isn't there another bug lurking?
      
      BUG kmalloc-8: Redzone overwritten
      
      INFO: 0xc0000000de9dec48-0xc0000000de9dec4b. First byte 0x0 instead of 0xcc
      INFO: Allocated in .__seq_open_private+0x30/0xa0 age=0 cpu=5 pid=3896
      	.__kmalloc+0x1e0/0x2d0
      	.__seq_open_private+0x30/0xa0
      	.seq_open_net+0x60/0xe0
      	.dev_mc_seq_open+0x4c/0x70
      	.proc_reg_open+0xd8/0x260
      	.__dentry_open.clone.11+0x2b8/0x400
      	.do_last+0xf4/0x950
      	.path_openat+0xf8/0x480
      	.do_filp_open+0x48/0xc0
      	.do_sys_open+0x140/0x250
      	syscall_exit+0x0/0x40
      
      dev_mc_seq_ops uses dev_seq_start/next/stop but only allocates
      sizeof(struct seq_net_private) of private data, whereas it expects
      sizeof(struct dev_iter_state):
      
      struct dev_iter_state {
      	struct seq_net_private p;
      	unsigned int pos; /* bucket << BUCKET_SPACE + offset */
      };
      
      Create dev_seq_open_ops and use it so we don't have to expose
      struct dev_iter_state.
      
      [ Problem added by commit f04565dd (dev: use name hash for
        dev_seq_ops) -Eric ]
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5cac98dd
    • E
      mac80211: fix race between the AGG SM and the Tx data path · 2a1e0fd1
      Emmanuel Grumbach 提交于
      When a packet is supposed to sent be as an a-MPDU, mac80211 sets
      IEEE80211_TX_CTL_AMPDU to let the driver know. On the other
      hand, mac80211 configures the driver for aggregration with the
      ampdu_action callback.
      There is race between these two mechanisms since the following
      scenario can occur when the BA agreement is torn down:
      
      Tx softIRQ	 			drv configuration
      ==========				=================
      
      check OPERATIONAL bit
      Set the TX_CTL_AMPDU bit in the packet
      
      					clear OPERATIONAL bit
      					stop Tx AGG
      Pass Tx packet to the driver.
      
      In that case the driver would get a packet with TX_CTL_AMPDU set
      although it has already been notified that the BA session has been
      torn down.
      
      To fix this, we need to synchronize all the Qdisc activity after we
      cleared the OPERATIONAL bit. After that step, all the following
      packets will be buffered until the driver reports it is ready to get
      new packets for this RA / TID. This buffering allows not to run into
      another race that would send packets with TX_CTL_AMPDU unset while
      the driver hasn't been requested to tear down the BA session yet.
      
      This race occurs in practice and iwlwifi complains with a WARN_ON
      when it happens.
      
      Cc: stable@kernel.org
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a1e0fd1
    • N
      mac80211: fix race condition caused by late addBA response · d305a655
      Nikolay Martynov 提交于
      If addBA responses comes in just after addba_resp_timer has
      expired mac80211 will still accept it and try to open the
      aggregation session. This causes drivers to be confused and
      in some cases even crash.
      
      This patch fixes the race condition and makes sure that if
      addba_resp_timer has expired addBA response is not longer
      accepted and we do not try to open half-closed session.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNikolay Martynov <mar.kolya@gmail.com>
      [some adjustments]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d305a655
    • R
      ath9k: Revert change that broke AR928X on Acer Ferrari One · a7322812
      Rafael J. Wysocki 提交于
      Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by
      commit 2577c6e8 (ath9k_hw: Add
      support for AR946/8x chipsets) that caused a nasty regression to
      appear on my Acer Ferrari One (the box locks up entirely at random
      times after the wireless has been started without any way to get
      debug information out of it).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7322812
    • S
      rtlwifi: fix lps_lock deadlock · e55b32c1
      Stanislaw Gruszka 提交于
      rtl_lps_leave can be called from interrupt context, so we have to
      disable interrupts when taking lps_lock.
      
      Below is full lockdep info about deadlock:
      
      [   93.815269] =================================
      [   93.815390] [ INFO: inconsistent lock state ]
      [   93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815556] ---------------------------------
      [   93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [   93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [   93.815832]  (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.815947] {SOFTIRQ-ON-W} state was registered at:
      [   93.815947]   [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c
      [   93.815947]   [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.815947]   [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.815947]   [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi]
      [   93.815947]   [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi]
      [   93.815947]   [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211]
      [   93.815947]   [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211]
      [   93.815947]   [<ffffffff81075aa5>] process_one_work+0x205/0x3e7
      [   93.815947]   [<ffffffff81076753>] worker_thread+0xda/0x15d
      [   93.815947]   [<ffffffff8107a119>] kthread+0xa8/0xb0
      [   93.815947]   [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10
      [   93.815947] irq event stamp: 547822
      [   93.815947] hardirqs last  enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61
      [   93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e
      [   93.815947] softirqs last  enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15
      [   93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.815947]
      [   93.815947] other info that might help us debug this:
      [   93.815947]  Possible unsafe locking scenario:
      [   93.815947]
      [   93.815947]        CPU0
      [   93.815947]        ----
      [   93.815947]   lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]   <Interrupt>
      [   93.815947]     lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]
      [   93.815947]  *** DEADLOCK ***
      [   93.815947]
      [   93.815947] no locks held by swapper/0.
      [   93.815947]
      [   93.815947] stack backtrace:
      [   93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815947] Call Trace:
      [   93.815947]  <IRQ>  [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8
      [   93.815947]  [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49
      [   93.815947]  [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0
      [   93.815947]  [<ffffffff8108dc8a>] mark_lock+0x106/0x220
      [   93.815947]  [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c
      [   93.815947]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
      [   93.830125]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
      [   93.830125]  [<ffffffff81080181>] ? sched_clock_local+0x12/0x75
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d
      [   93.830125]  [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi]
      [   93.830125]  [<ffffffff8106281f>] tasklet_action+0x8d/0xee
      [   93.830125]  [<ffffffff810629ce>] __do_softirq+0x112/0x25a
      [   93.830125]  [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.830125]  [<ffffffff81010bf6>] do_softirq+0x4b/0xa1
      [   93.830125]  [<ffffffff81062d7d>] irq_exit+0x5d/0xcf
      [   93.830125]  [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5
      [   93.830125]  [<ffffffff814ea533>] common_interrupt+0x73/0x73
      [   93.830125]  <EOI>  [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf
      [   93.830125]  [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c
      [   93.830125]  [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c
      [   93.830125]  [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe
      [   93.830125]  [<ffffffff8100e2ef>] cpu_idle+0xab/0x101
      [   93.830125]  [<ffffffff814c6373>] rest_init+0xd7/0xde
      [   93.830125]  [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c
      [   93.830125]  [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea
      [   93.830125]  [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3
      [   93.830125]  [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140
      [   93.830125]  [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111
      
      Resolves:
      https://bugzilla.redhat.com/show_bug.cgi?id=755154
      
      Reported-by: vjain02@students.poly.edu
      Reported-and-tested-by: NOliver Paukstadt <pstadt@sourcentral.org>
      Cc: stable@vger.kernel.org
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e55b32c1
    • J
      mac80211: don't stop a single aggregation session twice · 24f50a9d
      Johannes Berg 提交于
      Nikolay noticed (by code review) that mac80211 can
      attempt to stop an aggregation session while it is
      already being stopped. So to fix it, check whether
      stop is already being done and bail out if so.
      
      Also move setting the STOPPING state into the lock
      so things are properly atomic.
      
      Cc: stable@vger.kernel.org
      Reported-by: NNikolay Martynov <mar.kolya@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      24f50a9d
    • E
      nl80211: fix MAC address validation · e007b857
      Eliad Peller 提交于
      MAC addresses have a fixed length. The current
      policy allows passing < ETH_ALEN bytes, which
      might result in reading beyond the buffer.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e007b857
  5. 28 11月, 2011 1 次提交
  6. 27 11月, 2011 11 次提交
  7. 26 11月, 2011 1 次提交
  8. 25 11月, 2011 1 次提交
  9. 24 11月, 2011 3 次提交