1. 29 11月, 2013 6 次提交
  2. 24 11月, 2013 11 次提交
  3. 22 11月, 2013 8 次提交
  4. 21 11月, 2013 15 次提交
    • J
      Merge branch 'master' of... · 7acd7187
      John W. Linville 提交于
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      7acd7187
    • M
      net/phy: Add the autocross feature for forced links on VSC82x4 · 3fb69bca
      Madalin Bucur 提交于
      Add auto-MDI/MDI-X capability for forced (autonegotiation disabled)
      10/100 Mbps speeds on Vitesse VSC82x4 PHYs. Exported previously static
      function genphy_setup_forced() required by the new config_aneg handler
      in the Vitesse PHY module.
      Signed-off-by: NMadalin Bucur <madalin.bucur@freescale.com>
      Signed-off-by: NShruti Kanetkar <Shruti@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3fb69bca
    • S
      net/phy: Add VSC8662 support · 06ae4f84
      Sandeep Singh 提交于
      Vitesse VSC8662 is Dual Port 10/100/1000Base-T Phy
      Its register set and features are similar to other Vitesse Phys.
      Signed-off-by: NSandeep Singh <Sandeep@freescale.com>
      Signed-off-by: NAndy Fleming <afleming@gmail.com>
      Signed-off-by: NShruti Kanetkar <Shruti@Freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06ae4f84
    • S
      net/phy: Add VSC8574 support · c2efef74
      shaohui xie 提交于
      The VSC8574 is a quad-port Gigabit Ethernet transceiver with four SerDes
      interfaces for quad-port dual media capability.
      Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NAndy Fleming <afleming@gmail.com>
      Signed-off-by: NShruti Kanetkar <Shruti@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2efef74
    • A
      net/phy: Add VSC8234 support · 0508019c
      Andy Fleming 提交于
      Vitesse VSC8234 is quad port 10/100/1000BASE-T PHY
      with SGMII and SERDES MAC interfaces.
      Signed-off-by: NAndy Fleming <afleming@gmail.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NShruti Kanetkar <Shruti@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0508019c
    • H
      net: add BUG_ON if kernel advertises msg_namelen > sizeof(struct sockaddr_storage) · 68c6beb3
      Hannes Frederic Sowa 提交于
      In that case it is probable that kernel code overwrote part of the
      stack. So we should bail out loudly here.
      
      The BUG_ON may be removed in future if we are sure all protocols are
      conformant.
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68c6beb3
    • H
      net: rework recvmsg handler msg_name and msg_namelen logic · f3d33426
      Hannes Frederic Sowa 提交于
      This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
      set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
      to return msg_name to the user.
      
      This prevents numerous uninitialized memory leaks we had in the
      recvmsg handlers and makes it harder for new code to accidentally leak
      uninitialized memory.
      
      Optimize for the case recvfrom is called with NULL as address. We don't
      need to copy the address at all, so set it to NULL before invoking the
      recvmsg handler. We can do so, because all the recvmsg handlers must
      cope with the case a plain read() is called on them. read() also sets
      msg_name to NULL.
      
      Also document these changes in include/linux/net.h as suggested by David
      Miller.
      
      Changes since RFC:
      
      Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      affect sendto as it would bail out earlier while trying to copy-in the
      address. It also more naturally reflects the logic by the callers of
      verify_iovec.
      
      With this change in place I could remove "
      if (!uaddr || msg_sys->msg_namelen == 0)
      	msg->msg_name = NULL
      ".
      
      This change does not alter the user visible error logic as we ignore
      msg_namelen as long as msg_name is NULL.
      
      Also remove two unnecessary curly brackets in ___sys_recvmsg and change
      comments to netdev style.
      
      Cc: David Miller <davem@davemloft.net>
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3d33426
    • D
      bridge: flush br's address entry in fdb when remove the · f8730420
      Ding Tianhong 提交于
       bridge dev
      
      When the following commands are executed:
      
      brctl addbr br0
      ifconfig br0 hw ether <addr>
      rmmod bridge
      
      The calltrace will occur:
      
      [  563.312114] device eth1 left promiscuous mode
      [  563.312188] br0: port 1(eth1) entered disabled state
      [  563.468190] kmem_cache_destroy bridge_fdb_cache: Slab cache still has objects
      [  563.468197] CPU: 6 PID: 6982 Comm: rmmod Tainted: G           O 3.12.0-0.7-default+ #9
      [  563.468199] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  563.468200]  0000000000000880 ffff88010f111e98 ffffffff814d1c92 ffff88010f111eb8
      [  563.468204]  ffffffff81148efd ffff88010f111eb8 0000000000000000 ffff88010f111ec8
      [  563.468206]  ffffffffa062a270 ffff88010f111ed8 ffffffffa063ac76 ffff88010f111f78
      [  563.468209] Call Trace:
      [  563.468218]  [<ffffffff814d1c92>] dump_stack+0x6a/0x78
      [  563.468234]  [<ffffffff81148efd>] kmem_cache_destroy+0xfd/0x100
      [  563.468242]  [<ffffffffa062a270>] br_fdb_fini+0x10/0x20 [bridge]
      [  563.468247]  [<ffffffffa063ac76>] br_deinit+0x4e/0x50 [bridge]
      [  563.468254]  [<ffffffff810c7dc9>] SyS_delete_module+0x199/0x2b0
      [  563.468259]  [<ffffffff814e0922>] system_call_fastpath+0x16/0x1b
      [  570.377958] Bridge firewalling registered
      
      --------------------------- cut here -------------------------------
      
      The reason is that when the bridge dev's address is changed, the
      br_fdb_change_mac_address() will add new address in fdb, but when
      the bridge was removed, the address entry in the fdb did not free,
      the bridge_fdb_cache still has objects when destroy the cache, Fix
      this by flushing the bridge address entry when removing the bridge.
      
      v2: according to the Toshiaki Makita and Vlad's suggestion, I only
          delete the vlan0 entry, it still have a leak here if the vlan id
          is other number, so I need to call fdb_delete_by_port(br, NULL, 1)
          to flush all entries whose dst is NULL for the bridge.
      Suggested-by: NToshiaki Makita <toshiaki.makita1@gmail.com>
      Suggested-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8730420
    • V
      net: core: Always propagate flag changes to interfaces · d2615bf4
      Vlad Yasevich 提交于
      The following commit:
          b6c40d68
          net: only invoke dev->change_rx_flags when device is UP
      
      tried to fix a problem with VLAN devices and promiscuouse flag setting.
      The issue was that VLAN device was setting a flag on an interface that
      was down, thus resulting in bad promiscuity count.
      This commit blocked flag propagation to any device that is currently
      down.
      
      A later commit:
          deede2fa
          vlan: Don't propagate flag changes on down interfaces
      
      fixed VLAN code to only propagate flags when the VLAN interface is up,
      thus fixing the same issue as above, only localized to VLAN.
      
      The problem we have now is that if we have create a complex stack
      involving multiple software devices like bridges, bonds, and vlans,
      then it is possible that the flags would not propagate properly to
      the physical devices.  A simple examle of the scenario is the
      following:
      
        eth0----> bond0 ----> bridge0 ---> vlan50
      
      If bond0 or eth0 happen to be down at the time bond0 is added to
      the bridge, then eth0 will never have promisc mode set which is
      currently required for operation as part of the bridge.  As a
      result, packets with vlan50 will be dropped by the interface.
      
      The only 2 devices that implement the special flag handling are
      VLAN and DSA and they both have required code to prevent incorrect
      flag propagation.  As a result we can remove the generic solution
      introduced in b6c40d68 and leave
      it to the individual devices to decide whether they will block
      flag propagation or not.
      Reported-by: NStefan Priebe <s.priebe@profihost.ag>
      Suggested-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2615bf4
    • A
      ipv4: fix race in concurrent ip_route_input_slow() · dcdfdf56
      Alexei Starovoitov 提交于
      CPUs can ask for local route via ip_route_input_noref() concurrently.
      if nh_rth_input is not cached yet, CPUs will proceed to allocate
      equivalent DSTs on 'lo' and then will try to cache them in nh_rth_input
      via rt_cache_route()
      Most of the time they succeed, but on occasion the following two lines:
      	orig = *p;
      	prev = cmpxchg(p, orig, rt);
      in rt_cache_route() do race and one of the cpus fails to complete cmpxchg.
      But ip_route_input_slow() doesn't check the return code of rt_cache_route(),
      so dst is leaking. dst_destroy() is never called and 'lo' device
      refcnt doesn't go to zero, which can be seen in the logs as:
      	unregister_netdevice: waiting for lo to become free. Usage count = 1
      Adding mdelay() between above two lines makes it easily reproducible.
      Fix it similar to nh_pcpu_rth_output case.
      
      Fixes: d2d68ba9 ("ipv4: Cache input routes in fib_info nexthops.")
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dcdfdf56
    • D
      Merge branch 'r8152' · 4f837c3b
      David S. Miller 提交于
      Hayes Wang says:
      
      ====================
      r8152 bug fixes
      
      For the patch #3, I add netif_tx_lock() before checking the
      netif_queue_stopped(). Besides, I add checking the skb queue
      length before waking the tx queue.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f837c3b
    • H
      r8152: fix incorrect type in assignment · 500b6d7e
      hayeswang 提交于
      The data from the hardware should be little endian. Correct the
      declaration.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      500b6d7e
    • H
      r8152: support stopping/waking tx queue · dd1b119c
      hayeswang 提交于
      The maximum packet number which a tx aggregation buffer could contain
      is the tx_qlen.
      
      	tx_qlen = buffer size / (packet size + descriptor size).
      
      If the tx buffer is empty and the queued packets are more than the
      maximum value which is defined above, stop the tx queue. Wake the
      tx queue if tx queue is stopped and the queued packets are less than
      tx_qlen.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd1b119c
    • H
      r8152: modify the tx flow · 61598788
      hayeswang 提交于
      Remove the code for sending the packet in the rtl8152_start_xmit().
      Let rtl8152_start_xmit() to queue the packet only, and schedule a
      tasklet to send the queued packets. This simplify the code and make
      sure all the packet would be sent by the original order.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61598788
    • H
      r8152: fix tx/rx memory overflow · 7937f9e5
      hayeswang 提交于
      The tx/rx would access the memory which is out of the desired range.
      Modify the method of checking the end of the memory to avoid it.
      
      For r8152_tx_agg_fill(), the variable remain may become negative.
      However, the declaration is unsigned, so the while loop wouldn't
      break when reaching the end of the desied memory. Although to change
      the declaration from unsigned to signed is enough to fix it, I also
      modify the checking method for safe. Replace
      
      		remain = rx_buf_sz - sizeof(*tx_desc) -
      			 (u32)((void *)tx_data - agg->head);
      
      with
      
      		remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
      
      to make sure the variable remain is always positive. Then, the
      overflow wouldn't happen.
      
      For rx_bottom(), the rx_desc should not be used to calculate the
      packet length before making sure the rx_desc is in the desired range.
      Change the checking to two parts. First, check the descriptor is in
      the memory. The other, using the descriptor to find out the packet
      length and check if the packet is in the memory.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7937f9e5