1. 28 Jan, 2010 14 commits
  2. 27 Jan, 2010 22 commits
  3. 26 Jan, 2010 3 commits
    • Zhu Yi's avatar
      mac80211: fix NULL pointer dereference when ftrace is enabled · 3092ad05
      Zhu Yi authored
      I got below kernel oops when I try to bring down the network interface if
      ftrace is enabled. The root cause is drv_ampdu_action() is passed with a
      NULL ssn pointer in the BA session tear down case. We need to check and
      avoid dereferencing it in trace entry assignment.
      
      BUG: unable to handle kernel NULL pointer dereference
      Modules linked in: at (null)
      IP: [<f98fe02a>] ftrace_raw_event_drv_ampdu_action+0x10a/0x160 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [...]
      Call Trace:
       [<f98fdf20>] ? ftrace_raw_event_drv_ampdu_action+0x0/0x160 [mac80211]
       [<f98dac4c>] ? __ieee80211_stop_rx_ba_session+0xfc/0x220 [mac80211]
       [<f98d97fb>] ? ieee80211_sta_tear_down_BA_sessions+0x3b/0x50 [mac80211]
       [<f98dc6f6>] ? ieee80211_set_disassoc+0xe6/0x230 [mac80211]
       [<f98dc6ac>] ? ieee80211_set_disassoc+0x9c/0x230 [mac80211]
       [<f98dcbb8>] ? ieee80211_mgd_deauth+0x158/0x170 [mac80211]
       [<f98e4bdb>] ? ieee80211_deauth+0x1b/0x20 [mac80211]
       [<f8987f49>] ? __cfg80211_mlme_deauth+0xe9/0x120 [cfg80211]
       [<f898b870>] ? __cfg80211_disconnect+0x170/0x1d0 [cfg80211]
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3092ad05
    • David S. Miller's avatar
      ariadne: Fix build. · b747caf3
      David S. Miller authored
      References removed HAVE_MULTICAST.
      Reporeted-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b747caf3
    • Shan Wei's avatar
      ipv6: conntrack: Add member of user to nf_ct_frag6_queue structure · c92b544b
      Shan Wei authored
      The commit 0b5ccb2e(title:ipv6: reassembly: use seperate reassembly queues for
      conntrack and local delivery) has broken the saddr&&daddr member of
      nf_ct_frag6_queue when creating new queue.  And then hash value
      generated by nf_hashfn() was not equal with that generated by fq_find().
      So, a new received fragment can't be inserted to right queue.
      
      The patch fixes the bug with adding member of user to nf_ct_frag6_queue structure.
      Signed-off-by: default avatarShan Wei <shanwei@cn.fujitsu.com>
      Acked-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c92b544b
  4. 25 Jan, 2010 1 commit
    • Herbert Xu's avatar
      virtio_net: Make delayed refill more reliable · 39d32157
      Herbert Xu authored
      I have seen RX stalls on a machine that experienced a suspected
      OOM.  After the stall, the RX buffer is empty on the guest side
      and there are exactly 16 entries available on the host side.  As
      the number of entries is less than that required by a maximal
      skb, the host cannot proceed.
      
      The guest did not have a refill job scheduled.
      
      My diagnosis is that an OOM had occured, with the delayed refill
      job scheduled.  The job was able to allocate at least one skb, but
      not enough to overcome the minimum required by the host to proceed.
      
      As the refill job would only reschedule itself if it failed completely
      to allocate any skbs, this would lead to an RX stall.
      
      The following patch removes this stall possibility by always
      rescheduling the refill job until the ring is totally refilled.
      
      Testing has shown that the RX stall no longer occurs whereas
      previously it would occur within a day.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      39d32157