1. 06 12月, 2013 3 次提交
    • K
      macvlan: Support creating macvtaps from macvlans · d70f2cf5
      Kevin Wallace 提交于
      When running in a network namespace whose only link to the outside
      world is a macvlan device, not being able to create a macvtap off of
      it is a real pain.
      
      So modify macvtap creation to automatically forward a creation of a
      macvtap on a macvlan to become a creation of a macvtap on the
      underlying network device, just like is currently done with
      macvlan-on-macvlan devices.
      
      v2: Use netif_is_macvlan and macvlan_dev_real_dev helpers to make it
          more clear what we're doing.
      Signed-off-by: NKevin Wallace <kevin@pentabarf.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d70f2cf5
    • D
      Merge branch 'siocghwtstamp' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next · 426e1fa3
      David S. Miller 提交于
      Ben Hutchings says:
      
      ====================
      SIOCGHWTSTAMP ioctl
      
      1. Add the SIOCGHWTSTAMP ioctl and update the timestamping
      documentation.
      2. Implement SIOCGHWTSTAMP in most drivers that support SIOCSHWTSTAMP.
      3. Add a test program to exercise SIOC{G,S}HWTSTAMP.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      426e1fa3
    • D
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · e1ca87bb
      David S. Miller 提交于
      John W. Linville says:
      
      ====================
      Please pull this batch of fixes intende for the 3.13 stream!
      
      For the mac80211 bits, Johannes says:
      
      "For now I have various fixes all over, mostly for issues introduced in
      relatively recent patches. There's no real pattern to it. Some of the
      issues like go back longer, but still seemed 3.13 material."
      
      And...
      
      "These are just two patches disabling the broken CSA code. Once this
      goes into your tree I'll merge it into mac80211-next and revert there
      (since we fixed the bugs there)."
      
      For the iwlwifi bits, Emmanuel says:
      
      "I have here a few fixes for BT Coex. One of them is a NULL pointer
      dereference. Another one avoids to enable a feature that can make the
      firmware unhappy since the firmware isn't ready for it yet. WE also
      avoid a WARNING that can be triggered upon association in not-so-bad
      cases even if the association succeeded. We add support for new NICs
      (not yet on the market) and bump the API so that 3.13 will be able to
      work with the new firmware that will be out soon hopefully.
      I also have a boundary check from Johannes."
      
      In addition to those...
      
      - Arend van Spriel fixes a brcmfmac problem that could use an
      uninitialized variable in an error path.
      
      - Borislav Petkov fixes a Kconfig-based build breakage problem for
      brcmsmac.
      
      - Michal Nazarewicz fixes a couple of NULL pointer dereference problems
      in ath9k and wcn36xx.
      
      - Sujith Manoharan fixes a couple of ath9k problems related to
      incorrect interpretation of EEPROM configuration data.
      
      - Ujjal Roy fixes a memory leak in mwifiex.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1ca87bb
  2. 05 12月, 2013 1 次提交
  3. 04 12月, 2013 7 次提交
    • D
      Merge branch 'cxgb4' · 988bf4f0
      David S. Miller 提交于
      Hariprasad Shenai says:
      
      ====================
      Fixes T5 adapter init, due to incorrect FW version check
      
      This patch series fixes, Chelsio T5 adapter initialization failure due to
      incorrect firmware version check. This patch series modifies the firmware
      flashing mechanism for T4/T5 adapter.
      
      The patch series moves chip type from struct adapter to struct adapter_params.
      It changes the references of chip type in cxgb4 and cxgb4vf drivers such that
      build failure is avoided.
      
      Patch 3/3 is dependent on patch 1/3
      Patch 2/3 is also dependent on patch 1/3
      
      We would like to request this patch series to get merged via David Miller's
      'net' tree.
      
      We have included all the maintainers of respective drivers. Kindly review the
      change and let us know in case of any review comments.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      988bf4f0
    • H
    • H
    • H
    • W
      net/mlx4_core: destroy workqueue when driver fails to register · 1b85ee09
      Wei Yang 提交于
      When driver registration fails, we need to clean up the resources allocated
      before. mlx4_core missed destroying the workqueue allocated.
      
      This patch destroys the workqueue when registration fails.
      Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b85ee09
    • V
      rds: prevent BUG_ON triggered on congestion update to loopback · 18fc25c9
      Venkat Venkatsubra 提交于
      After congestion update on a local connection, when rds_ib_xmit returns
      less bytes than that are there in the message, rds_send_xmit calls
      back rds_ib_xmit with an offset that causes BUG_ON(off & RDS_FRAG_SIZE)
      to trigger.
      
      For a 4Kb PAGE_SIZE rds_ib_xmit returns min(8240,4096)=4096 when actually
      the message contains 8240 bytes. rds_send_xmit thinks there is more to send
      and calls rds_ib_xmit again with a data offset "off" of 4096-48(rds header)
      =4048 bytes thus hitting the BUG_ON(off & RDS_FRAG_SIZE) [RDS_FRAG_SIZE=4k].
      
      The commit 6094628b
      "rds: prevent BUG_ON triggering on congestion map updates" introduced
      this regression. That change was addressing the triggering of a different
      BUG_ON in rds_send_xmit() on PowerPC architecture with 64Kbytes PAGE_SIZE:
       	BUG_ON(ret != 0 &&
          		 conn->c_xmit_sg == rm->data.op_nents);
      This was the sequence it was going through:
      (rds_ib_xmit)
      /* Do not send cong updates to IB loopback */
      if (conn->c_loopback
         && rm->m_inc.i_hdr.h_flags & RDS_FLAG_CONG_BITMAP) {
        	rds_cong_map_updated(conn->c_fcong, ~(u64) 0);
          	return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
      }
      rds_ib_xmit returns 8240
      rds_send_xmit:
        c_xmit_data_off = 0 + 8240 - 48 (rds header accounted only the first time)
         		 = 8192
        c_xmit_data_off < 65536 (sg->length), so calls rds_ib_xmit again
      rds_ib_xmit returns 8240
      rds_send_xmit:
        c_xmit_data_off = 8192 + 8240 = 16432, calls rds_ib_xmit again
        and so on (c_xmit_data_off 24672,32912,41152,49392,57632)
      rds_ib_xmit returns 8240
      On this iteration this sequence causes the BUG_ON in rds_send_xmit:
          while (ret) {
          	tmp = min_t(int, ret, sg->length - conn->c_xmit_data_off);
          	[tmp = 65536 - 57632 = 7904]
          	conn->c_xmit_data_off += tmp;
          	[c_xmit_data_off = 57632 + 7904 = 65536]
          	ret -= tmp;
          	[ret = 8240 - 7904 = 336]
          	if (conn->c_xmit_data_off == sg->length) {
          		conn->c_xmit_data_off = 0;
          		sg++;
          		conn->c_xmit_sg++;
          		BUG_ON(ret != 0 &&
          			conn->c_xmit_sg == rm->data.op_nents);
          		[c_xmit_sg = 1, rm->data.op_nents = 1]
      
      What the current fix does:
      Since the congestion update over loopback is not actually transmitted
      as a message, all that rds_ib_xmit needs to do is let the caller think
      the full message has been transmitted and not return partial bytes.
      It will return 8240 (RDS_CONG_MAP_BYTES+48) when PAGE_SIZE is 4Kb.
      And 64Kb+48 when page size is 64Kb.
      Reported-by: NJosh Hunt <joshhunt00@gmail.com>
      Tested-by: NHonggang Li <honli@redhat.com>
      Acked-by: NBang Nguyen <bang.nguyen@oracle.com>
      Signed-off-by: NVenkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18fc25c9
    • P
      xen-netback: clear vif->task on disconnect · 67fa3660
      Paul Durrant 提交于
      xenvif_start_xmit() relies on checking vif->task for NULL to determine
      whether the vif is ready to accept packets. The task thread is stopped in
      xenvif_disconnect() but task is not set to NULL. Thus, on a re-connect the
      check will give a false positive.
      
      Also since commit ea732dff (Handle backend
      state transitions in a more robust way) it should not be possible for
      xenvif_connect() to be called if the vif is already connected so change the
      check of vif->tx_irq to a BUG_ON() and also add a BUG_ON(vif->task).
      Signed-off-by: NPaul Durrant <paul.durrant@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67fa3660
  4. 03 12月, 2013 22 次提交
  5. 02 12月, 2013 7 次提交