1. 06 Oct, 2014 32 commits
  2. 05 Oct, 2014 5 commits
    • John Fastabend's avatar
      net: sched: suspicious RCU usage in qdisc_watchdog · 1e203c1a
      John Fastabend authored
      Suspicious RCU usage in qdisc_watchdog call needs to be done inside
      rcu_read_lock/rcu_read_unlock. And then Qdisc destroy operations
      need to ensure timer is cancelled before removing qdisc structure.
      
      [ 3992.191339] ===============================
      [ 3992.191340] [ INFO: suspicious RCU usage. ]
      [ 3992.191343] 3.17.0-rc6net-next+ #72 Not tainted
      [ 3992.191345] -------------------------------
      [ 3992.191347] include/net/sch_generic.h:272 suspicious rcu_dereference_check() usage!
      [ 3992.191348]
      [ 3992.191348] other info that might help us debug this:
      [ 3992.191348]
      [ 3992.191351]
      [ 3992.191351] rcu_scheduler_active = 1, debug_locks = 1
      [ 3992.191353] no locks held by swapper/1/0.
      [ 3992.191355]
      [ 3992.191355] stack backtrace:
      [ 3992.191358] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.17.0-rc6net-next+ #72
      [ 3992.191360] Hardware name:                  /DZ77RE-75K, BIOS GAZ7711H.86A.0060.2012.1115.1750 11/15/2012
      [ 3992.191362]  0000000000000001 ffff880235803e48 ffffffff8178f92c 0000000000000000
      [ 3992.191366]  ffff8802322224a0 ffff880235803e78 ffffffff810c9966 ffff8800a5fe3000
      [ 3992.191370]  ffff880235803f30 ffff8802359cd768 ffff8802359cd6e0 ffff880235803e98
      [ 3992.191374] Call Trace:
      [ 3992.191376]  <IRQ>  [<ffffffff8178f92c>] dump_stack+0x4e/0x68
      [ 3992.191387]  [<ffffffff810c9966>] lockdep_rcu_suspicious+0xe6/0x130
      [ 3992.191392]  [<ffffffff8167213a>] qdisc_watchdog+0x8a/0xb0
      [ 3992.191396]  [<ffffffff810f93f2>] __run_hrtimer+0x72/0x420
      [ 3992.191399]  [<ffffffff810f9bcd>] ? hrtimer_interrupt+0x7d/0x240
      [ 3992.191403]  [<ffffffff816720b0>] ? tc_classify+0xc0/0xc0
      [ 3992.191406]  [<ffffffff810f9c4f>] hrtimer_interrupt+0xff/0x240
      [ 3992.191410]  [<ffffffff8109e4a5>] ? __atomic_notifier_call_chain+0x5/0x140
      [ 3992.191415]  [<ffffffff8103577b>] local_apic_timer_interrupt+0x3b/0x60
      [ 3992.191419]  [<ffffffff8179c2b5>] smp_apic_timer_interrupt+0x45/0x60
      [ 3992.191422]  [<ffffffff8179a6bf>] apic_timer_interrupt+0x6f/0x80
      [ 3992.191424]  <EOI>  [<ffffffff815ed233>] ? cpuidle_enter_state+0x73/0x2e0
      [ 3992.191432]  [<ffffffff815ed22e>] ? cpuidle_enter_state+0x6e/0x2e0
      [ 3992.191437]  [<ffffffff815ed567>] cpuidle_enter+0x17/0x20
      [ 3992.191441]  [<ffffffff810c0741>] cpu_startup_entry+0x3d1/0x4a0
      [ 3992.191445]  [<ffffffff81106fc6>] ? clockevents_config_and_register+0x26/0x30
      [ 3992.191448]  [<ffffffff81033c16>] start_secondary+0x1b6/0x260
      
      Fixes: b26b0d1e ("net: qdisc: use rcu prefix and silence sparse warnings")
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e203c1a
    • Florian Fainelli's avatar
      net: dsa: do not call phy_start_aneg · f7d6b96f
      Florian Fainelli authored
      Commit f7f1de51 ("net: dsa: start and stop the PHY state machine")
      add calls to phy_start() in dsa_slave_open() respectively phy_stop() in
      dsa_slave_close().
      
      We also call phy_start_aneg() in dsa_slave_create(), and this call is
      messing up with the PHY state machine, since we basically start the
      auto-negotiation, and later on restart it when calling phy_start().
      phy_start() does not currently handle the PHY_FORCING or PHY_AN states
      properly, but such a fix would be too invasive for this window.
      
      Fixes: f7f1de51 ("net: dsa: start and stop the PHY state machine")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7d6b96f
    • Sébastien Barré's avatar
      Removed unused inet6 address state · dd3619f2
      Sébastien Barré authored
      the inet6 state INET6_IFADDR_STATE_UP only appeared in its definition.
      
      Cc: Christoph Paasch <christoph.paasch@uclouvain.be>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSébastien Barré <sebastien.barre@uclouvain.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dd3619f2
    • Vijay Subramanian's avatar
      net: Cleanup skb cloning by adding SKB_FCLONE_FREE · c8753d55
      Vijay Subramanian authored
      SKB_FCLONE_UNAVAILABLE has overloaded meaning depending on type of skb.
      1: If skb is allocated from head_cache, it indicates fclone is not available.
      2: If skb is a companion fclone skb (allocated from fclone_cache), it indicates
      it is available to be used.
      
      To avoid confusion for case 2 above, this patch  replaces
      SKB_FCLONE_UNAVAILABLE with SKB_FCLONE_FREE where appropriate. For fclone
      companion skbs, this indicates it is free for use.
      
      SKB_FCLONE_UNAVAILABLE will now simply indicate skb is from head_cache and
      cannot / will not have a companion fclone.
      Signed-off-by: default avatarVijay Subramanian <subramanian.vijay@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c8753d55
    • Eric Dumazet's avatar
      mlx4: add a new xmit_more counter · 9fab426d
      Eric Dumazet authored
      ethtool -S reports a new counter, tracking number of time doorbell
      was not triggered, because skb->xmit_more was set.
      
      $ ethtool -S eth0 | egrep "tx_packet|xmit_more"
           tx_packets: 2413288400
           xmit_more: 666121277
      
      I merged the tso_packet false sharing avoidance in this patch as well.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9fab426d
  3. 03 Oct, 2014 3 commits
    • David S. Miller's avatar
      Merge branch 'gudp' · 6106253e
      David S. Miller authored
      Tom Herbert says:
      
      ====================
      net: Generic UDP Encapsulation
      
      Generic UDP Encapsulation (GUE) is UDP encapsulation protocol which
      encapsulates packets of various IP protocols. The GUE protocol is
      described in http://tools.ietf.org/html/draft-herbert-gue-01.
      
      The receive path of GUE is implemented in the FOU over UDP module (FOU).
      This includes a UDP encap receive function for GUE as well as GUE
      specific GRO functions. Management and configuration of GUE ports shares
      most of the same code with FOU.
      
      For the transmit path, the previous FOU support for IPIP, sit, and GRE
      was simply extended for GUE (when GUE is enabled insert the GUE
      header on transmit in addition to UDP header inserted for FOU).
      
      Semantically GUE is the same as FOU in that the encapsulation (UDP
      and GUE headers) that are inserted on transmission and removed on
      reception so that IP packet is processed with the inner header.
      
      This patch set includes:
       - Some fixes to FOU, removal of IPv4,v6 specific GRO functions
       - Support to configure a GUE receive port
       - Implementation of GUE receive path (normal and GRO)
       - Additions to ip_tunnel netlink to configure GUE
       - GUE header inserion in ip_tunnel transmit path
      
      v2:
       - Include net/gue.h in patch set
      
      Testing:
      
      I ran performance numbers using netperf TCP_RR with 200 streams,
      comparing encapsulation without GUE, encapsulation with GUE, and
      encapsulation with FOU.
      
       GRE
          TCP_STREAM
            IPv4, FOU, UDP checksum enabled
              14.04% TX CPU utilization
              13.17% RX CPU utilization
              9211 Mbps
            IPv4, GUE, UDP checksum enabled
              14.99% TX CPU utilization
              13.79% RX CPU utilization
              9185 Mbps
            IPv4, FOU, UDP checksum disabled
              13.14% TX CPU utilization
              23.18% RX CPU utilization
              9277 Mbps
            IPv4, GUE, UDP checksum disabled
              13.66% TX CPU utilization
              23.57% RX CPU utilization
              9184 Mbps
          TCP_RR
            IPv4, FOU, UDP checksum enabled
              94.2% CPU utilization
              155/249/460 90/95/99% latencies
              1.17018e+06 tps
            IPv4, GUE, UDP checksum enabled
              93.9% CPU utilization
              158/253/472 90/95/99% latencies
              1.15045e+06 tps
      
        IPIP
          TCP_STREAM
            FOU, UDP checksum enabled
              15.28% TX CPU utilization
              13.92% RX CPU utilization
              9342 Mbps
            GUE, UDP checksum enabled
              13.99% TX CPU utilization
              13.34% RX CPU utilization
              9210 Mbps
            FOU, UDP checksum disabled
              15.08% TX CPU utilization
              24.64% RX CPU utilization
              9226 Mbps
            GUE, UDP checksum disabled
              15.90% TX CPU utilization
              24.77% RX CPU utilization
              9197 Mbps
          TCP_RR
            FOU, UDP checksum enabled
              94.23% CPU utilization
              149/237/429 90/95/99% latencies
              1.19553e+06 tps
            GUE, UDP checksum enabled
              93.75% CPU utilization
              152/243/442 90/95/99% latencies
              1.17027e+06 tps
      
        SIT
          TCP_STREAM
            FOU, UDP checksum enabled
              14.47% TX CPU utilization
              14.58% RX CPU utilization
              9106 Mbps
            GUE, UDP checksum enabled
              15.09% TX CPU utilization
              14.84% RX CPU utilization
              9080 Mbps
            FOU, UDP checksum disabled
              15.70% TX CPU utilization
              27.93% RX CPU utilization
              9097 Mbps
            GUE, UDP checksum disabled
              15.04% TX CPU utilization
              27.54% RX CPU utilization
              9073 Mbps
          TCP_RR
            FOU, UDP checksum enabled
              96.9% CPU utilization
              170/281/581 90/95/99% latencies
              1.03372e+06 tps
            GUE, UDP checksum enabled
              97.16% CPU utilization
              172/286/576 90/95/99% latencies
              1.00469e+06 tps
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6106253e
    • Tom Herbert's avatar
      ip_tunnel: Add GUE support · bc1fc390
      Tom Herbert authored
      This patch allows configuring IPIP, sit, and GRE tunnels to use GUE.
      This is very similar to fou excpet that we need to insert the GUE header
      in addition to the UDP header on transmit.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc1fc390
    • Tom Herbert's avatar
      gue: Receive side for Generic UDP Encapsulation · 37dd0247
      Tom Herbert authored
      This patch adds support receiving for GUE packets in the fou module. The
      fou module now supports direct foo-over-udp (no encapsulation header)
      and GUE. To support this a type parameter is added to the fou netlink
      parameters.
      
      For a GUE socket we define gue_udp_recv, gue_gro_receive, and
      gue_gro_complete to handle the specifics of the GUE protocol. Most
      of the code to manage and configure sockets is common with the fou.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37dd0247