1. 20 Jun, 2013 35 commits
  2. 19 Jun, 2013 5 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · d98cae64
      David S. Miller authored
      Conflicts:
      	drivers/net/wireless/ath/ath9k/Kconfig
      	drivers/net/xen-netback/netback.c
      	net/batman-adv/bat_iv_ogm.c
      	net/wireless/nl80211.c
      
      The ath9k Kconfig conflict was a change of a Kconfig option name right
      next to the deletion of another option.
      
      The xen-netback conflict was overlapping changes involving the
      handling of the notify list in xen_netbk_rx_action().
      
      Batman conflict resolution provided by Antonio Quartulli, basically
      keep everything in both conflict hunks.
      
      The nl80211 conflict is a little more involved.  In 'net' we added a
      dynamic memory allocation to nl80211_dump_wiphy() to fix a race that
      Linus reported.  Meanwhile in 'net-next' the handlers were converted
      to use pre and post doit handlers which use a flag to determine
      whether to hold the RTNL mutex around the operation.
      
      However, the dump handlers to not use this logic.  Instead they have
      to explicitly do the locking.  There were apparent bugs in the
      conversion of nl80211_dump_wiphy() in that we were not dropping the
      RTNL mutex in all the return paths, and it seems we very much should
      be doing so.  So I fixed that whilst handling the overlapping changes.
      
      To simplify the initial returns, I take the RTNL mutex after we try
      to allocate 'tb'.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d98cae64
    • John W. Linville's avatar
      Merge branch 'master' of... · 4067c666
      John W. Linville authored
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      4067c666
    • John W. Linville's avatar
    • Johannes Berg's avatar
      nl80211: fix attrbuf access race by allocating a separate one · 3a5a423b
      Johannes Berg authored
      Since my commit 3713b4e3 ("nl80211: allow splitting wiphy
      information in dumps"), nl80211_dump_wiphy() uses the global
      nl80211_fam.attrbuf for parsing the incoming data. This wouldn't
      be a problem if it only did so on the first dump iteration which
      is locked against other commands in generic netlink, but due to
      space constraints in cb->args (the needed state doesn't fit) I
      decided to always parse the original message. That's racy though
      since nl80211_fam.attrbuf could be used by some other parsing in
      generic netlink concurrently.
      
      For now, fix this by allocating a separate parse buffer (it's a
      bit too big for the stack, currently 1448 bytes on 64-bit). For
      -next, I'll change the code to parse into the global buffer in
      the first round only and then allocate a smaller buffer to keep
      the data in cb->args.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3a5a423b
    • stephen hemminger's avatar
      vxlan: fix check for migration of static entry · eb064c3b
      stephen hemminger authored
      The check introduced by:
      	commit 26a41ae6
      	Author: stephen hemminger <stephen@networkplumber.org>
      	Date:   Mon Jun 17 12:09:58 2013 -0700
      
      	    vxlan: only migrate dynamic FDB entries
      
      was not correct because it is checking flag about type of FDB
      entry, rather than the state (dynamic versus static). The confusion
      arises because vxlan is reusing values from bridge, and bridge is
      reusing values from neighbour table, and easy to get lost in translation.
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb064c3b