1. 01 12月, 2012 7 次提交
    • A
      6lowpan: consider checksum bytes in fragmentation threshold · b333b7e6
      Alan Ott 提交于
      Change the threshold for framentation of a lowpan packet from
      using the MTU size to now use the MTU size minus the checksum length,
      which is added by the hardware. For IEEE 802.15.4, this effectively
      changes it from 127 bytes to 125 bytes.
      Signed-off-by: NAlan Ott <alan@signal11.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b333b7e6
    • D
      Merge branch 'for-davem' of git://gitorious.org/linux-can/linux-can-next · fed2c6fd
      David S. Miller 提交于
      Marc Kleine-Budde says:
      
      ====================
      this pull request is for net-next/master. There is a patch by Alexander
      Stein fixing a reference counter problem which can make driver
      unloading impossible (stable Cc'ed). And several patches by me which
      remove an obsolete mechanism from several drivers, which is already
      handled at the infrastructure level.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fed2c6fd
    • A
      mISDN: improve bitops usage · 481af03b
      Akinobu Mita 提交于
      This improves bitops usages in several points:
      
      - Convert u64 to a proper bitmap declaration.  This enables to remove
        superfluous typecasting from 'u64' to 'unsigned long *'.
      
      - Convert superfluous atomic bitops to non atomic bitops.  The bitmap
        is allocated on the stack and it is not accessed by any other threads,
        so using atomic bitops is not necessary.
      
      - Use find_next_zero_bit and find_next_zero_bit instead of calling
        test_bit() for each bit.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      481af03b
    • Y
      8021q: fix vlan device to inherit the unicast filtering capability flag · 6e22ce2c
      Yi Zou 提交于
      This bug is observed on running FCoE over a VLAN device associated w/
      a real device that has IFF_UNICAST_FLT set since FCoE would add unicast
      address such as FLOGI MAC to the VLAN interface that FCoE is on. Since
      currently, VLAN device is not inheriting the IFF_UNICAST_FLT flag from the
      parent real device even though the real device is capable of doing unicast
      filtering. This forces the VLAN device and its real device go to promiscuous
      mode unnecessarily even the added address is actually being added to the
      available unicast filter table in real device.
      Signed-off-by: NYi Zou <yi.zou@intel.com>
      Cc: devel@open-fcoe.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e22ce2c
    • J
      bonding: delete migrated IP addresses from the rlb hash table · e53665c6
      Jiri Bohac 提交于
      Bonding in balance-alb mode records information from ARP packets
      passing through the bond in a hash table (rx_hashtbl).
      
      At certain situations (e.g. link change of a slave),
      rlb_update_rx_clients() will send out ARP packets to update ARP
      caches of other hosts on the network to achieve RX load
      balancing.
      
      The problem is that once an IP address is recorded in the hash
      table, it stays there indefinitely. If this IP address is
      migrated to a different host in the network, bonding still sends
      out ARP packets that poison other systems' ARP caches with
      invalid information.
      
      This patch solves this by looking at all incoming ARP packets,
      and checking if the source IP address is one of the source
      addresses stored in the rx_hashtbl. If it is, but the MAC
      addresses differ, the corresponding hash table entries are
      removed. Thus, when an IP address is migrated, the first ARP
      broadcast by its new owner will purge the offending entries of
      rx_hashtbl.
      
      The hash table is hashed by ip_dst. To be able to do the above
      check efficiently (not walking the whole hash table), we need a
      reverse mapping (by ip_src).
      
      I added three new members in struct rlb_client_info:
         rx_hashtbl[x].src_first will point to the start of a list of
            entries for which hash(ip_src) == x.
         The list is linked with src_next and src_prev.
      
      When an incoming ARP packet arrives at rlb_arp_recv()
      rlb_purge_src_ip() can quickly walk only the entries on the
      corresponding lists, i.e. the entries that are likely to contain
      the offending IP address.
      
      To avoid confusion, I renamed these existing fields of struct
      rlb_client_info:
      	next -> used_next
      	prev -> used_prev
      	rx_hashtbl_head -> rx_hashtbl_used_head
      
      (The current linked list is _not_ a list of hash table
      entries with colliding ip_dst. It's a list of entries that are
      being used; its purpose is to avoid walking the whole hash table
      when looking for used entries.)
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e53665c6
    • Z
      bonding: rlb mode of bond should not alter ARP originating via bridge · 567b871e
      zheng.li 提交于
      Do not modify or load balance ARP packets passing through balance-alb
      mode (wherein the ARP did not originate locally, and arrived via a bridge).
      
      Modifying pass-through ARP replies causes an incorrect MAC address
      to be placed into the ARP packet, rendering peers unable to communicate
      with the actual destination from which the ARP reply originated.
      
      Load balancing pass-through ARP requests causes an entry to be
      created for the peer in the rlb table, and bond_alb_monitor will
      occasionally issue ARP updates to all peers in the table instrucing them
      as to which MAC address they should communicate with; this occurs when
      some event sets rx_ntt.  In the bridged case, however, the MAC address
      used for the update would be the MAC of the slave, not the actual source
      MAC of the originating destination.  This would render peers unable to
      communicate with the destinations beyond the bridge.
      Signed-off-by: NZheng Li <zheng.x.li@oracle.com>
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      567b871e
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch · e7165030
      David S. Miller 提交于
      Conflicts:
      	net/ipv6/exthdrs_core.c
      
      Jesse Gross says:
      
      ====================
      This series of improvements for 3.8/net-next contains four components:
       * Support for modifying IPv6 headers
       * Support for matching and setting skb->mark for better integration with
         things like iptables
       * Ability to recognize the EtherType for RARP packets
       * Two small performance enhancements
      
      The movement of ipv6_find_hdr() into exthdrs_core.c causes two small merge
      conflicts.  I left it as is but can do the merge if you want.  The conflicts
      are:
       * ipv6_find_hdr() and ipv6_find_tlv() were both moved to the bottom of
         exthdrs_core.c.  Both should stay.
       * A new use of ipv6_find_hdr() was added to net/netfilter/ipvs/ip_vs_core.c
         after this patch.  The IPVS user has two instances of the old constant
         name IP6T_FH_F_FRAG which has been renamed to IP6_FH_F_FRAG.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e7165030
  2. 30 11月, 2012 3 次提交
  3. 29 11月, 2012 30 次提交