1. 01 Dec, 2011 2 commits
  2. 30 Nov, 2011 4 commits
  3. 29 Nov, 2011 6 commits
  4. 28 Nov, 2011 9 commits
    • Li Wei's avatar
      ipv6: Set mcast_hops to IPV6_DEFAULT_MCASTHOPS when -1 was given. · 2a38e6d5
      Li Wei authored
      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: default avatarLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a38e6d5
    • Anton Blanchard's avatar
      net: Fix corruption in /proc/*/net/dev_mcast · 5cac98dd
      Anton Blanchard authored
      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: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cac98dd
    • Emmanuel Grumbach's avatar
      mac80211: fix race between the AGG SM and the Tx data path · 2a1e0fd1
      Emmanuel Grumbach authored
      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: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2a1e0fd1
    • Nikolay Martynov's avatar
      mac80211: fix race condition caused by late addBA response · d305a655
      Nikolay Martynov authored
      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: default avatarNikolay Martynov <mar.kolya@gmail.com>
      [some adjustments]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d305a655
    • Rafael J. Wysocki's avatar
      ath9k: Revert change that broke AR928X on Acer Ferrari One · a7322812
      Rafael J. Wysocki authored
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a7322812
    • Stanislaw Gruszka's avatar
      rtlwifi: fix lps_lock deadlock · e55b32c1
      Stanislaw Gruszka authored
      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: default avatarOliver Paukstadt <pstadt@sourcentral.org>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e55b32c1
    • Johannes Berg's avatar
      mac80211: don't stop a single aggregation session twice · 24f50a9d
      Johannes Berg authored
      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: default avatarNikolay Martynov <mar.kolya@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      24f50a9d
    • Eliad Peller's avatar
      nl80211: fix MAC address validation · e007b857
      Eliad Peller authored
      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: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e007b857
    • Aries Lee's avatar
      jme: PHY configuration for compatible issue · c4860ba2
      Aries Lee authored
      To perform PHY calibration and set a different EA value by chip ID,
      Whenever the NIC chip power on, ie booting or resuming, we need to
      force HW to calibrate PHY parameter again, and also set a proper EA
      value which gather from experiment.
      
      Those procedures help to reduce compatible issues(NIC is unable to link
      up in some special case) in giga speed.
      Signed-off-by: default avatarAriesLee <AriesLee@jmicron.com>
      Signed-off-by: default avatarGuo-Fu Tseng <cooldavid@cooldavid.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4860ba2
  5. 27 Nov, 2011 1 commit
  6. 26 Nov, 2011 10 commits
  7. 25 Nov, 2011 2 commits
  8. 24 Nov, 2011 5 commits
  9. 23 Nov, 2011 1 commit