1. 15 Jul, 2010 2 commits
    • Tom Herbert's avatar
      net: fix problem in reading sock TX queue · b0f77d0e
      Tom Herbert authored
      Fix problem in reading the tx_queue recorded in a socket.  In
      dev_pick_tx, the TX queue is read by doing a check with
      sk_tx_queue_recorded on the socket, followed by a sk_tx_queue_get.
      The problem is that there is not mutual exclusion across these
      calls in the socket so it it is possible that the queue in the
      sock can be invalidated after sk_tx_queue_recorded is called so
      that sk_tx_queue get returns -1, which sets 65535 in queue_index
      and thus dev_pick_tx returns 65536 which is a bogus queue and
      can cause crash in dev_queue_xmit.
      
      We fix this by only calling sk_tx_queue_get which does the proper
      checks.  The interface is that sk_tx_queue_get returns the TX queue
      if the sock argument is non-NULL and TX queue is recorded, else it
      returns -1.  sk_tx_queue_recorded is no longer used so it can be
      completely removed.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0f77d0e
    • Doug Kehn's avatar
      net/core: neighbour update Oops · 91a72a70
      Doug Kehn authored
      When configuring DMVPN (GRE + openNHRP) and a GRE remote
      address is configured a kernel Oops is observed.  The
      obserseved Oops is caused by a NULL header_ops pointer
      (neigh->dev->header_ops) in neigh_update_hhs() when
      
      void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *)
      = neigh->dev->header_ops->cache_update;
      
      is executed.  The dev associated with the NULL header_ops is
      the GRE interface.  This patch guards against the
      possibility that header_ops is NULL.
      
      This Oops was first observed in kernel version 2.6.26.8.
      Signed-off-by: default avatarDoug Kehn <rdkehn@yahoo.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91a72a70
  2. 14 Jul, 2010 3 commits
  3. 13 Jul, 2010 3 commits
  4. 12 Jul, 2010 2 commits
  5. 09 Jul, 2010 1 commit
  6. 08 Jul, 2010 3 commits
  7. 07 Jul, 2010 5 commits
  8. 06 Jul, 2010 3 commits
  9. 04 Jul, 2010 1 commit
  10. 03 Jul, 2010 12 commits
  11. 02 Jul, 2010 3 commits
  12. 01 Jul, 2010 1 commit
  13. 30 Jun, 2010 1 commit
    • Flavio Leitner's avatar
      bonding: check if clients MAC addr has changed · 42d782ac
      Flavio Leitner authored
      When two systems using bonding devices in adaptive load
      balancing (ALB) communicates with each other, an endless
      ping-pong of ARP replies starts between these two systems.
      
      What happens? In the ALB mode, bonding driver keeps track
      of each client connected in a hash table, so it can do the
      receive load balancing (RLB). This hash table is updated
      when an ARP reply is received, then it scans for the client
      entry, updates its MAC address and flag it to be announced
      later. Therefore, two seconds later, the alb monitor runs
      and send for each updated client entry two ARP replies
      updating this specific client. The same process happens on
      the receiving system, causing the endless ping-pong of arp
      replies.
      
      See more information including the relevant functions below:
      
         System 1                          System 2
          bond0                             bond0
      
         ping <system2>
          ARP request  --------->
                                 <--------- ARP reply
      
      +->rlb_arp_recv  <---------------------+   <--- loop begins
      |  rlb_update_entry_from_arp           |
      |  client_info->ntt = 1;               |
      |  bond_info->rx_ntt = 1;              |
      |                                      |
      |         <communication succeed>      |
      |                                      |
      |  bond_alb_monitor                    |
      |  rlb_update_rx_clients               |
      |  rlb_update_client                   |
      |  arp_create(ARPOP_REPLY)             |
      |   send ARP reply -------------->     V
      |   send ARP reply -------------->
      |                               rlb_arp_recv
      |                               rlb_update_entry_from_arp
      |                               client_info->ntt = 1;
      |                               bond_info->rx_ntt = 1;
      |                           < snipped, same as in system 1>
      +-------           <-------------- send ARP reply
                         <-------------- send ARP reply
      
      Besides the unneeded networking traffic, this loop breaks
      a cluster because a backup system can't take over the IP
      address. There is always one system sending an ARP reply
      poisoning the network.
      
      This patch fixes the problem adding a check for the MAC
      address before updating it. Thus, if the MAC address didn't
      change, there is no need to update neither to announce it later.
      Signed-off-by: default avatarFlavio Leitner <fleitner@redhat.com>
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42d782ac