1. Jan 04, 2018
  2. Jan 03, 2018
    • Felix Janda's avatar
      uapi libc compat: add fallback for unsupported libcs · c0bace79
      Felix Janda authored
      libc-compat.h aims to prevent symbol collisions between uapi and libc
      headers for each supported libc. This requires continuous coordination
      between them.
      
      The goal of this commit is to improve the situation for libcs (such as
      musl) which are not yet supported and/or do not wish to be explicitly
      supported, while not affecting supported libcs. More precisely, with
      this commit, unsupported libcs can request the suppression of any
      specific uapi definition by defining the correspondings _UAPI_DEF_*
      macro as 0. This can fix symbol collisions for them, as long as the
      libc headers are included before the uapi headers. Inclusion in the
      other order is outside the scope of this commit.
      
      All infrastructure in order to enable this fallback for unsupported
      libcs is already in place, except that libc-compat.h unconditionally
      defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
      any previous definitions are ignored. In order to fix this, this commit
      merely makes these definitions conditional.
      
      This commit together with the musl libc commit
      
      http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
      
      
      
      fixes for example the following compiler errors when <linux/in6.h> is
      included after musl's <netinet/in.h>:
      
      ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
      ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
      ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
      
      The comments referencing glibc are still correct, but this file is not
      only used for glibc any more.
      
      Signed-off-by: default avatarFelix Janda <felix.janda@posteo.de>
      Reviewed-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0bace79
    • Jon Maloy's avatar
      tipc: fix problems with multipoint-to-point flow control · f9c935db
      Jon Maloy authored
      In commit 04d7b574
      
       ("tipc: add multipoint-to-point flow control") we
      introduced a protocol for preventing buffer overflow when many group
      members try to simultaneously send messages to the same receiving member.
      
      Stress test of this mechanism has revealed a couple of related bugs:
      
      - When the receiving member receives an advertisement REMIT message from
        one of the senders, it will sometimes prematurely activate a pending
        member and send it the remitted advertisement, although the upper
        limit for active senders has been reached. This leads to accumulation
        of illegal advertisements, and eventually to messages being dropped
        because of receive buffer overflow.
      
      - When the receiving member leaves REMITTED state while a received
        message is being read, we miss to look at the pending queue, to
        activate the oldest pending peer. This leads to some pending senders
        being starved out, and never getting the opportunity to profit from
        the remitted advertisement.
      
      We fix the former in the function tipc_group_proto_rcv() by returning
      directly from the function once it becomes clear that the remitting
      peer cannot leave REMITTED state at that point.
      
      We fix the latter in the function tipc_group_update_rcv_win() by looking
      up and activate the longest pending peer when it becomes clear that the
      remitting peer now can leave REMITTED state.
      
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9c935db
    • Stephen Hemminger's avatar
      ethtool: do not print warning for applications using legacy API · 71891e2d
      Stephen Hemminger authored
      In kernel log ths message appears on every boot:
       "warning: `NetworkChangeNo' uses legacy ethtool link settings API,
        link modes are only partially reported"
      
      When ethtool link settings API changed, it started complaining about
      usages of old API. Ironically, the original patch was from google but
      the application using the legacy API is chrome.
      
      Linux ABI is fixed as much as possible. The kernel must not break it
      and should not complain about applications using legacy API's.
      This patch just removes the warning since using legacy API's
      in Linux is perfectly acceptable.
      
      Fixes: 3f1ac7a7
      
       ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid Decotigny <decot@googlers.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71891e2d
    • SZ Lin (林上智)'s avatar
      NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625 · bd30ffc4
      SZ Lin (林上智) authored
      
      
      This patch adds support for PID 0x9625 of YUGA CLM920-NC5.
      
      YUGA CLM920-NC5 needs to enable QMI_WWAN_QUIRK_DTR before QMI operation.
      
      qmicli -d /dev/cdc-wdm0 -p --dms-get-revision
      [/dev/cdc-wdm0] Device revision retrieved:
              Revision: 'CLM920_NC5-V1  1  [Oct 23 2016 19:00:00]'
      
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd30ffc4
    • Benjamin Poirier's avatar
      e1000e: Fix e1000_check_for_copper_link_ich8lan return value. · 4110e02e
      Benjamin Poirier authored
      e1000e_check_for_copper_link() and e1000_check_for_copper_link_ich8lan()
      are the two functions that may be assigned to mac.ops.check_for_link when
      phy.media_type == e1000_media_type_copper. Commit 19110cfb
      
       ("e1000e:
      Separate signaling for link check/link up") changed the meaning of the
      return value of check_for_link for copper media but only adjusted the first
      function. This patch adjusts the second function likewise.
      
      Reported-by: default avatarChristian Hesse <list@eworm.de>
      Reported-by: default avatarGabriel C <nix.or.die@gmail.com>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=198047
      Fixes: 19110cfb
      
       ("e1000e: Separate signaling for link check/link up")
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Tested-by: default avatarChristian Hesse <list@eworm.de>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4110e02e
    • Tushar Dave's avatar
      e1000: fix disabling already-disabled warning · 0b76aae7
      Tushar Dave authored
      This patch adds check so that driver does not disable already
      disabled device.
      
      [   44.637743] advantechwdt: Unexpected close, not stopping watchdog!
      [   44.997548] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input6
      [   45.013419] e1000 0000:00:03.0: disabling already-disabled device
      [   45.013447] ------------[ cut here ]------------
      [   45.014868] WARNING: CPU: 1 PID: 71 at drivers/pci/pci.c:1641 pci_disable_device+0xa1/0x105:
      						pci_disable_device at drivers/pci/pci.c:1640
      [   45.016171] CPU: 1 PID: 71 Comm: rcu_perf_shutdo Not tainted 4.14.0-01330-g3c073991
      
       #1
      [   45.017197] task: ffff88011bee9e40 task.stack: ffffc90000860000
      [   45.017987] RIP: 0010:pci_disable_device+0xa1/0x105:
      						pci_disable_device at drivers/pci/pci.c:1640
      [   45.018603] RSP: 0000:ffffc90000863e30 EFLAGS: 00010286
      [   45.019282] RAX: 0000000000000035 RBX: ffff88013a230008 RCX: 0000000000000000
      [   45.020182] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000203
      [   45.021084] RBP: ffff88013a3f31e8 R08: 0000000000000001 R09: 0000000000000000
      [   45.021986] R10: ffffffff827ec29c R11: 0000000000000002 R12: 0000000000000001
      [   45.022946] R13: ffff88013a230008 R14: ffff880117802b20 R15: ffffc90000863e8f
      [   45.023842] FS:  0000000000000000(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
      [   45.024863] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   45.025583] CR2: ffffc900006d4000 CR3: 000000000220f000 CR4: 00000000000006a0
      [   45.026478] Call Trace:
      [   45.026811]  __e1000_shutdown+0x1d4/0x1e2:
      						__e1000_shutdown at drivers/net/ethernet/intel/e1000/e1000_main.c:5162
      [   45.027344]  ? rcu_perf_cleanup+0x2a1/0x2a1:
      						rcu_perf_shutdown at kernel/rcu/rcuperf.c:627
      [   45.027883]  e1000_shutdown+0x14/0x3a:
      						e1000_shutdown at drivers/net/ethernet/intel/e1000/e1000_main.c:5235
      [   45.028351]  device_shutdown+0x110/0x1aa:
      						device_shutdown at drivers/base/core.c:2807
      [   45.028858]  kernel_power_off+0x31/0x64:
      						kernel_power_off at kernel/reboot.c:260
      [   45.029343]  rcu_perf_shutdown+0x9b/0xa7:
      						rcu_perf_shutdown at kernel/rcu/rcuperf.c:637
      [   45.029852]  ? __wake_up_common_lock+0xa2/0xa2:
      						autoremove_wake_function at kernel/sched/wait.c:376
      [   45.030414]  kthread+0x126/0x12e:
      						kthread at kernel/kthread.c:233
      [   45.030834]  ? __kthread_bind_mask+0x8e/0x8e:
      						kthread at kernel/kthread.c:190
      [   45.031399]  ? ret_from_fork+0x1f/0x30:
      						ret_from_fork at arch/x86/entry/entry_64.S:443
      [   45.031883]  ? kernel_init+0xa/0xf5:
      						kernel_init at init/main.c:997
      [   45.032325]  ret_from_fork+0x1f/0x30:
      						ret_from_fork at arch/x86/entry/entry_64.S:443
      [   45.032777] Code: 00 48 85 ed 75 07 48 8b ab a8 00 00 00 48 8d bb 98 00 00 00 e8 aa d1 11 00 48 89 ea 48 89 c6 48 c7 c7 d8 e4 0b 82 e8 55 7d da ff <0f> ff b9 01 00 00 00 31 d2 be 01 00 00 00 48 c7 c7 f0 b1 61 82
      [   45.035222] ---[ end trace c257137b1b1976ef ]---
      [   45.037838] ACPI: Preparing to enter system sleep state S5
      
      Signed-off-by: default avatarTushar Dave <tushar.n.dave@oracle.com>
      Tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0b76aae7
    • Russell King's avatar
      sfp: fix sfp-bus oops when removing socket/upstream · 0b2122e4
      Russell King authored
      When we remove a socket or upstream, and the other side isn't
      registered, we dereference a NULL pointer, causing a kernel oops.
      Fix this.
      
      Fixes: ce0aa27f
      
       ("sfp: add sfp-bus to bridge between network devices and sfp cages")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b2122e4
    • Russell King's avatar
      phylink: ensure we report link down when LOS asserted · ac817f5a
      Russell King authored
      Although we disable the netdev carrier, we fail to report in the kernel
      log that the link went down.  Fix this.
      
      Fixes: 9525ae83
      
       ("phylink: add phylink infrastructure")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac817f5a
    • Gao Feng's avatar
      macvlan: Fix one possible double free · d02fd6e7
      Gao Feng authored
      
      
      Because the macvlan_uninit would free the macvlan port, so there is one
      double free case in macvlan_common_newlink. When the macvlan port is just
      created, then register_netdevice or netdev_upper_dev_link failed and they
      would invoke macvlan_uninit. Then it would reach the macvlan_port_destroy
      which triggers the double free.
      
      Signed-off-by: default avatarGao Feng <gfree.wind@vip.163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d02fd6e7
    • Roi Dayan's avatar
      net/sched: Fix update of lastuse in act modules implementing stats_update · 3bb23421
      Roi Dayan authored
      We need to update lastuse to to the most updated value between what
      is already set and the new value.
      If HW matching fails, i.e. because of an issue, the stats are not updated
      but it could be that software did match and updated lastuse.
      
      Fixes: 5712bf9c ("net/sched: act_mirred: Use passed lastuse argument")
      Fixes: 9fea47d9
      
       ("net/sched: act_gact: Update statistics when offloaded to hardware")
      Signed-off-by: default avatarRoi Dayan <roid@mellanox.com>
      Reviewed-by: default avatarPaul Blakey <paulb@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bb23421
    • Ido Schimmel's avatar
      mlxsw: spectrum: Relax sanity checks during enslavement · 90045fc9
      Ido Schimmel authored
      Since commit 25cc72a3 ("mlxsw: spectrum: Forbid linking to devices that
      have uppers") the driver forbids enslavement to netdevs that already
      have uppers of their own, as this can result in various ordering
      problems.
      
      This requirement proved to be too strict for some users who need to be
      able to enslave ports to a bridge that already has uppers. In this case,
      we can allow the enslavement if the bridge is already known to us, as
      any configuration performed on top of the bridge was already reflected
      to the device.
      
      Fixes: 25cc72a3
      
       ("mlxsw: spectrum: Forbid linking to devices that have uppers")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarAlexander Petrovskiy <alexpe@mellanox.com>
      Tested-by: default avatarAlexander Petrovskiy <alexpe@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90045fc9
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Fix NULL pointer deref · 8764a826
      Ido Schimmel authored
      When we remove the neighbour associated with a nexthop we should always
      refuse to write the nexthop to the adjacency table. Regardless if it is
      already present in the table or not.
      
      Otherwise, we risk dereferencing the NULL pointer that was set instead
      of the neighbour.
      
      Fixes: a7ff87ac
      
       ("mlxsw: spectrum_router: Implement next-hop routing")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarAlexander Petrovskiy <alexpe@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8764a826
    • Xin Long's avatar
      ip6_tunnel: allow ip6gre dev mtu to be set below 1280 · 2fa771be
      Xin Long authored
      Commit 582442d6
      
       ("ipv6: Allow the MTU of ipip6 tunnel to be set
      below 1280") fixed a mtu setting issue. It works for ipip6 tunnel.
      
      But ip6gre dev updates the mtu also with ip6_tnl_change_mtu. Since
      the inner packet over ip6gre can be ipv4 and it's mtu should also
      be allowed to set below 1280, the same issue also exists on ip6gre.
      
      This patch is to fix it by simply changing to check if parms.proto
      is IPPROTO_IPV6 in ip6_tnl_change_mtu instead, to make ip6gre to
      go to 'else' branch.
      
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fa771be
    • Xin Long's avatar
      geneve: update skb dst pmtu on tx path · 52a589d5
      Xin Long authored
      Commit a93bf0ff
      
       ("vxlan: update skb dst pmtu on tx path") has fixed
      a performance issue caused by the change of lower dev's mtu for vxlan.
      
      The same thing needs to be done for geneve as well.
      
      Note that geneve cannot adjust it's mtu according to lower dev's mtu
      when creating it. The performance is very low later when netperfing
      over it without fixing the mtu manually. This patch could also avoid
      this issue.
      
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52a589d5
    • Eli Cooper's avatar
      ip6_tunnel: disable dst caching if tunnel is dual-stack · 23263ec8
      Eli Cooper authored
      
      
      When an ip6_tunnel is in mode 'any', where the transport layer
      protocol can be either 4 or 41, dst_cache must be disabled.
      
      This is because xfrm policies might apply to only one of the two
      protocols. Caching dst would cause xfrm policies for one protocol
      incorrectly used for the other.
      
      Signed-off-by: default avatarEli Cooper <elicooper@gmx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      23263ec8
    • David S. Miller's avatar
      Revert "net: core: dev_get_valid_name is now the same as dev_alloc_name_ns" · 55a5ec9b
      David S. Miller authored
      This reverts commit 87c320e5.
      
      Changing the error return code in some situations turns out to
      be harmful in practice.  In particular Michael Ellerman reports
      that DHCP fails on his powerpc machines, and this revert gets
      things working again.
      
      Johannes Berg agrees that this revert is the best course of
      action for now.
      
      Fixes: 029b6d14
      
       ("Revert "net: core: maybe return -EEXIST in __dev_alloc_name"")
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55a5ec9b
  3. Dec 29, 2017
  4. Dec 28, 2017