1. 15 Nov, 2017 9 commits
    • Stephen Hemminger's avatar
      netem: remove unnecessary 64 bit modulus · 9b0ed891
      Stephen Hemminger authored
      Fix compilation on 32 bit platforms (where doing modulus operation
      with 64 bit requires extra glibc functions) by truncation.
      The jitter for table distribution is limited to a 32 bit value
      because random numbers are scaled as 32 bit value.
      
      Also fix some whitespace.
      
      Fixes: 99803171 ("netem: add uapi to express delay and jitter in nanoseconds")
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b0ed891
    • Stephen Hemminger's avatar
      netem: use 64 bit divide by rate · bce552fd
      Stephen Hemminger authored
      Since times are now expressed in nanosecond, need to now do
      true 64 bit divide. Old code would truncate rate at 32 bits.
      Rename function to better express current usage.
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bce552fd
    • Stephen Hemminger's avatar
      tcp: Namespace-ify sysctl_tcp_default_congestion_control · 6670e152
      Stephen Hemminger authored
      Make default TCP default congestion control to a per namespace
      value. This changes default congestion control to a pointer to congestion ops
      (rather than implicit as first element of available lsit).
      
      The congestion control setting of new namespaces is inherited
      from the current setting of the root namespace.
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6670e152
    • Kirill Tkhai's avatar
      net: Protect iterations over net::fib_notifier_ops in fib_seq_sum() · 11bf284f
      Kirill Tkhai authored
      There is at least unlocked deletion of net->ipv4.fib_notifier_ops
      from net::fib_notifier_ops:
      
      ip_fib_net_exit()
        rtnl_unlock()
        fib4_notifier_exit()
          fib_notifier_ops_unregister(net->ipv4.notifier_ops)
            list_del_rcu(&ops->list)
      
      So fib_seq_sum() can't use rtnl_lock() only for protection.
      
      The possible solution could be to use rtnl_lock()
      in fib_notifier_ops_unregister(), but this adds
      a possible delay during net namespace creation,
      so we better use rcu_read_lock() till someone
      really needs the mutex (if that happens).
      Signed-off-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11bf284f
    • Nicolas Dichtel's avatar
      ipv6: set all.accept_dad to 0 by default · 09400953
      Nicolas Dichtel authored
      With commits 35e015e1 and a2d3f3e3, the global 'accept_dad' flag
      is also taken into account (default value is 1). If either global or
      per-interface flag is non-zero, DAD will be enabled on a given interface.
      
      This is not backward compatible: before those patches, the user could
      disable DAD just by setting the per-interface flag to 0. Now, the
      user instead needs to set both flags to 0 to actually disable DAD.
      
      Restore the previous behaviour by setting the default for the global
      'accept_dad' flag to 0. This way, DAD is still enabled by default,
      as per-interface flags are set to 1 on device creation, but setting
      them to 0 is enough to disable DAD on a given interface.
      
      - Before 35e015e1f57a7 and a2d3f3e3:
                global    per-interface    DAD enabled
      [default]   1             1              yes
                  X             0              no
                  X             1              yes
      
      - After 35e015e1 and a2d3f3e3:
                global    per-interface    DAD enabled
      [default]   1             1              yes
                  0             0              no
                  0             1              yes
                  1             0              yes
      
      - After this fix:
                global    per-interface    DAD enabled
                  1             1              yes
                  0             0              no
      [default]   0             1              yes
                  1             0              yes
      
      Fixes: 35e015e1 ("ipv6: fix net.ipv6.conf.all interface DAD handlers")
      Fixes: a2d3f3e3 ("ipv6: fix net.ipv6.conf.all.accept_dad behaviour for real")
      CC: Stefano Brivio <sbrivio@redhat.com>
      CC: Matteo Croce <mcroce@redhat.com>
      CC: Erik Kline <ek@google.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09400953
    • Dmitry V. Levin's avatar
      uapi: fix linux/tls.h userspace compilation error · b9f3eb49
      Dmitry V. Levin authored
      Move inclusion of a private kernel header <net/tcp.h>
      from uapi/linux/tls.h to its only user - net/tls.h,
      to fix the following linux/tls.h userspace compilation error:
      
      /usr/include/linux/tls.h:41:21: fatal error: net/tcp.h: No such file or directory
      
      As to this point uapi/linux/tls.h was totaly unusuable for userspace,
      cleanup this header file further by moving other redundant includes
      to net/tls.h.
      
      Fixes: 3c4d7559 ("tls: kernel TLS support")
      Cc: <stable@vger.kernel.org> # v4.13+
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9f3eb49
    • Alexander Kappner's avatar
      usbnet: ipheth: prevent TX queue timeouts when device not ready · bb1b40c7
      Alexander Kappner authored
      iOS devices require the host to be "trusted" before servicing network
      packets. Establishing trust requires the user to confirm a dialog on the
      iOS device.Until trust is established, the iOS device will silently discard
      network packets from the host. Currently, the ipheth driver does not detect
      whether an iOS device has established trust with the host, and immediately
      sets up the transmit queues.
      
      This causes the following problems:
      
      - Kernel taint due to WARN() in netdev watchdog.
      - Dmesg spam ("TX timeout").
      - Disruption of user space networking activity (dhcpd, etc...) when new
      interface comes up but cannot be used.
      - Unnecessary host and device wakeups and USB traffic
      
      Example dmesg output:
      
      [ 1101.319778] NETDEV WATCHDOG: eth1 (ipheth): transmit queue 0 timed out
      [ 1101.319817] ------------[ cut here ]------------
      [ 1101.319828] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x20f/0x220
      [ 1101.319831] Modules linked in: ipheth usbmon nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) iwlmvm mac80211 iwlwifi btusb btrtl btbcm btintel qmi_wwan bluetooth cfg80211 ecdh_generic thinkpad_acpi rfkill [last unloaded: ipheth]
      [ 1101.319861] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P           O    4.13.12.1 #1
      [ 1101.319864] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W (1.35 ) 11/10/2016
      [ 1101.319867] task: ffffffff81e11500 task.stack: ffffffff81e00000
      [ 1101.319873] RIP: 0010:dev_watchdog+0x20f/0x220
      [ 1101.319876] RSP: 0018:ffff8810a3c03e98 EFLAGS: 00010292
      [ 1101.319880] RAX: 000000000000003a RBX: 0000000000000000 RCX: 0000000000000000
      [ 1101.319883] RDX: ffff8810a3c15c48 RSI: ffffffff81ccbfc2 RDI: 00000000ffffffff
      [ 1101.319886] RBP: ffff880c04ebc41c R08: 0000000000000000 R09: 0000000000000379
      [ 1101.319889] R10: 00000100696589d0 R11: 0000000000000378 R12: ffff880c04ebc000
      [ 1101.319892] R13: 0000000000000000 R14: 0000000000000001 R15: ffff880c2865fc80
      [ 1101.319896] FS:  0000000000000000(0000) GS:ffff8810a3c00000(0000) knlGS:0000000000000000
      [ 1101.319899] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1101.319902] CR2: 00007f3ff24ac000 CR3: 0000000001e0a000 CR4: 00000000003406f0
      [ 1101.319905] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1101.319908] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 1101.319910] Call Trace:
      [ 1101.319914]  <IRQ>
      [ 1101.319921]  ? dev_graft_qdisc+0x70/0x70
      [ 1101.319928]  ? dev_graft_qdisc+0x70/0x70
      [ 1101.319934]  ? call_timer_fn+0x2e/0x170
      [ 1101.319939]  ? dev_graft_qdisc+0x70/0x70
      [ 1101.319944]  ? run_timer_softirq+0x1ea/0x440
      [ 1101.319951]  ? timerqueue_add+0x54/0x80
      [ 1101.319956]  ? enqueue_hrtimer+0x38/0xa0
      [ 1101.319963]  ? __do_softirq+0xed/0x2e7
      [ 1101.319970]  ? irq_exit+0xb4/0xc0
      [ 1101.319976]  ? smp_apic_timer_interrupt+0x39/0x50
      [ 1101.319981]  ? apic_timer_interrupt+0x8c/0xa0
      [ 1101.319983]  </IRQ>
      [ 1101.319992]  ? cpuidle_enter_state+0xfa/0x2a0
      [ 1101.319999]  ? do_idle+0x1a3/0x1f0
      [ 1101.320004]  ? cpu_startup_entry+0x5f/0x70
      [ 1101.320011]  ? start_kernel+0x444/0x44c
      [ 1101.320017]  ? early_idt_handler_array+0x120/0x120
      [ 1101.320023]  ? x86_64_start_kernel+0x145/0x154
      [ 1101.320028]  ? secondary_startup_64+0x9f/0x9f
      [ 1101.320033] Code: 20 04 00 00 eb 9f 4c 89 e7 c6 05 59 44 71 00 01 e8 a7 df fd ff 89 d9 4c 89 e6 48 c7 c7 70 b7 cd 81 48 89 c2 31 c0 e8 97 64 90 ff <0f> ff eb bf 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
      [ 1101.320103] ---[ end trace 0cc4d251e2b57080 ]---
      [ 1101.320110] ipheth 1-5:4.2: ipheth_tx_timeout: TX timeout
      
      The last message "TX timeout" is repeated every 5 seconds until trust is
      established or the device is disconnected, filling up dmesg.
      
      The proposed patch eliminates the problem by, upon connection, keeping the
      TX queue and carrier disabled until a packet is first received from the iOS
      device. This is reflected by the confirmed_pairing variable in the device
      structure. Only after at least one packet has been received from the iOS
      device, the transmit queue and carrier are brought up during the periodic
      device poll in ipheth_carrier_set. Because the iOS device will always send
      a packet immediately upon trust being established, this should not delay
      the interface becoming useable. To prevent failed UBRs in
      ipheth_rcvbulk_callback from perpetually re-enabling the queue if it was
      disabled, a new check is added so only successful transfers re-enable the
      queue, whereas failed transfers only trigger an immediate poll.
      
      This has the added benefit of removing the periodic control requests to the
      iOS device until trust has been established and thus should reduce wakeup
      events on both the host and the iOS device.
      Signed-off-by: default avatarAlexander Kappner <agk@godking.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb1b40c7
    • Jason Wang's avatar
      vhost_net: conditionally enable tx polling · feb8892c
      Jason Wang authored
      We always poll tx for socket, this is sub optimal since this will
      slightly increase the waitqueue traversing time and more important,
      vhost could not benefit from commit 9e641bdc ("net-tun:
      restructure tun_do_read for better sleep/wakeup efficiency") even if
      we've stopped rx polling during handle_rx(), tx poll were still left
      in the waitqueue.
      
      Pktgen from a remote host to VM over mlx4 on two 2.00GHz Xeon E5-2650
      shows 11.7% improvements on rx PPS. (from 1.28Mpps to 1.44Mpps)
      
      Cc: Wei Xu <wexu@redhat.com>
      Cc: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      feb8892c
    • Dmitry V. Levin's avatar
      uapi: fix linux/rxrpc.h userspace compilation errors · 0eef304b
      Dmitry V. Levin authored
      Consistently use types provided by <linux/types.h> to fix the following
      linux/rxrpc.h userspace compilation errors:
      
      /usr/include/linux/rxrpc.h:24:2: error: unknown type name 'u16'
        u16  srx_service; /* service desired */
      /usr/include/linux/rxrpc.h:25:2: error: unknown type name 'u16'
        u16  transport_type; /* type of transport socket (SOCK_DGRAM) */
      /usr/include/linux/rxrpc.h:26:2: error: unknown type name 'u16'
        u16  transport_len; /* length of transport address */
      
      Use __kernel_sa_family_t instead of sa_family_t the same way
      as uapi/linux/in.h does, to fix the following
      linux/rxrpc.h userspace compilation errors:
      
      /usr/include/linux/rxrpc.h:23:2: error: unknown type name 'sa_family_t'
        sa_family_t srx_family; /* address family */
      /usr/include/linux/rxrpc.h:28:3: error: unknown type name 'sa_family_t'
        sa_family_t family;  /* transport address family */
      
      Fixes: 727f8914 ("rxrpc: Expose UAPI definitions to userspace")
      Cc: <stable@vger.kernel.org> # v4.14
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0eef304b
  2. 14 Nov, 2017 31 commits