1. 06 10月, 2014 30 次提交
  2. 05 10月, 2014 5 次提交
    • J
      net: sched: suspicious RCU usage in qdisc_watchdog · 1e203c1a
      John Fastabend 提交于
      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: NJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: NCong Wang <cwang@twopensource.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e203c1a
    • F
      net: dsa: do not call phy_start_aneg · f7d6b96f
      Florian Fainelli 提交于
      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: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7d6b96f
    • S
      Removed unused inet6 address state · dd3619f2
      Sébastien Barré 提交于
      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: NSébastien Barré <sebastien.barre@uclouvain.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd3619f2
    • V
      net: Cleanup skb cloning by adding SKB_FCLONE_FREE · c8753d55
      Vijay Subramanian 提交于
      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: NVijay Subramanian <subramanian.vijay@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8753d55
    • E
      mlx4: add a new xmit_more counter · 9fab426d
      Eric Dumazet 提交于
      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: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fab426d
  3. 04 10月, 2014 5 次提交
    • D
      Merge branch 'gudp' · 6106253e
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      6106253e
    • T
      ip_tunnel: Add GUE support · bc1fc390
      Tom Herbert 提交于
      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: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc1fc390
    • T
      gue: Receive side for Generic UDP Encapsulation · 37dd0247
      Tom Herbert 提交于
      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: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37dd0247
    • T
      fou: eliminate IPv4,v6 specific GRO functions · efc98d08
      Tom Herbert 提交于
      This patch removes fou[46]_gro_receive and fou[46]_gro_complete
      functions. The v4 or v6 variants were chosen for the UDP offloads
      based on the address family of the socket this is not necessary
      or correct. Alternatively, this patch adds is_ipv6 to napi_gro_skb.
      This is set in udp6_gro_receive and unset in udp4_gro_receive. In
      fou_gro_receive the value is used to select the correct inet_offloads
      for the protocol of the outer IP header.
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efc98d08
    • T
      ip_tunnel: Account for secondary encapsulation header in max_headroom · 7371e022
      Tom Herbert 提交于
      When adjusting max_header for the tunnel interface based on egress
      device we need to account for any extra bytes in secondary encapsulation
      (e.g. FOU).
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7371e022