1. 18 Oct, 2016 13 commits
  2. 17 Oct, 2016 12 commits
    • David S. Miller's avatar
      Merge branch 'net-driver-autoload' · 3dfcb4f5
      David S. Miller authored
      Javier Martinez Canillas says:
      
      ====================
      net: Fix module autoload for several platform drivers
      
      I noticed that module autoload won't be working in a bunch of platform
      drivers in the net subsystem and this patch series contains the fixes.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3dfcb4f5
    • Javier Martinez Canillas's avatar
      net: dsa: bcm_sf2: Fix module autoload for OF registration · 0822b43e
      Javier Martinez Canillas authored
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ modinfo drivers/net/dsa/bcm_sf2.ko | grep alias
      alias:          platform:brcm-sf2
      
      After this patch:
      
      $ modinfo drivers/net/dsa/bcm_sf2.ko | grep alias
      alias:          platform:brcm-sf2
      alias:          of:N*T*Cbrcm,bcm7445-switch-v4.0C*
      alias:          of:N*T*Cbrcm,bcm7445-switch-v4.0
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0822b43e
    • Javier Martinez Canillas's avatar
      net: dsa: b53: Fix module autoload · 03eaae52
      Javier Martinez Canillas authored
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ modinfo drivers/net/dsa/b53/b53_mmap.ko  | grep alias
      $
      
      After this patch:
      
      $ modinfo drivers/net/dsa/b53/b53_mmap.ko  | grep alias
      alias:          of:N*T*Cbrcm,bcm63xx-switchC*
      alias:          of:N*T*Cbrcm,bcm63xx-switch
      alias:          of:N*T*Cbrcm,bcm6368-switchC*
      alias:          of:N*T*Cbrcm,bcm6368-switch
      alias:          of:N*T*Cbrcm,bcm6328-switchC*
      alias:          of:N*T*Cbrcm,bcm6328-switch
      alias:          of:N*T*Cbrcm,bcm3384-switchC*
      alias:          of:N*T*Cbrcm,bcm3384-switch
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03eaae52
    • Javier Martinez Canillas's avatar
      net: hisilicon: Fix hns_mdio module autoload for OF registration · af40097e
      Javier Martinez Canillas authored
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ modinfo drivers/net/ethernet/hisilicon//hns_mdio.ko | grep alias
      alias:          platform:Hi-HNS_MDIO
      alias:          acpi*:HISI0141:*
      
      After this patch:
      
      $ modinfo drivers/net/ethernet/hisilicon//hns_mdio.ko | grep alias
      alias:          platform:Hi-HNS_MDIO
      alias:          of:N*T*Chisilicon,hns-mdioC*
      alias:          of:N*T*Chisilicon,hns-mdio
      alias:          of:N*T*Chisilicon,mdioC*
      alias:          of:N*T*Chisilicon,mdio
      alias:          acpi*:HISI0141:*
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      af40097e
    • Javier Martinez Canillas's avatar
      net: qcom/emac: Fix module autoload for OF registration · 70972685
      Javier Martinez Canillas authored
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ modinfo drivers/net/ethernet/qualcomm/emac/qcom-emac.ko | grep alias
      alias:          platform:qcom-emac
      
      After this patch:
      
      $ modinfo drivers/net/ethernet/qualcomm/emac/qcom-emac.ko | grep alias
      alias:          platform:qcom-emac
      alias:          of:N*T*Cqcom,fsm9900-emacC*
      alias:          of:N*T*Cqcom,fsm9900-emac
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Acked-by: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70972685
    • Javier Martinez Canillas's avatar
      net: hns: Fix hns_dsaf module autoload for OF registration · a7deb924
      Javier Martinez Canillas authored
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ modinfo drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko | grep alias
      alias:          acpi*:HISI00B2:*
      alias:          acpi*:HISI00B1:*
      
      After this patch:
      
      $ modinfo drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko | grep alias
      alias:          acpi*:HISI00B2:*
      alias:          acpi*:HISI00B1:*
      alias:          of:N*T*Chisilicon,hns-dsaf-v2C*
      alias:          of:N*T*Chisilicon,hns-dsaf-v2
      alias:          of:N*T*Chisilicon,hns-dsaf-v1C*
      alias:          of:N*T*Chisilicon,hns-dsaf-v1
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7deb924
    • Javier Martinez Canillas's avatar
      net: ethernet: nb8800: Fix module autoload · 2fa3e317
      Javier Martinez Canillas authored
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ $ modinfo drivers/net/ethernet/aurora/nb8800.ko | grep alias
      $
      
      After this patch:
      
      $ modinfo drivers/net/ethernet/aurora/nb8800.ko | grep alias
      alias:          of:N*T*Csigma,smp8734-ethernetC*
      alias:          of:N*T*Csigma,smp8734-ethernet
      alias:          of:N*T*Csigma,smp8642-ethernetC*
      alias:          of:N*T*Csigma,smp8642-ethernet
      alias:          of:N*T*Caurora,nb8800C*
      alias:          of:N*T*Caurora,nb8800
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Acked-by: default avatarMans Rullgard <mans@mansr.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fa3e317
    • Javier Martinez Canillas's avatar
      net: nps_enet: Fix module autoload · fc971a2f
      Javier Martinez Canillas authored
      If the driver is built as a module, autoload won't work because the module
      alias information is not filled. So user-space can't match the registered
      device with the corresponding module.
      
      Export the module alias information using the MODULE_DEVICE_TABLE() macro.
      
      Before this patch:
      
      $ modinfo drivers/net/ethernet/ezchip/nps_enet.ko | grep alias
      $
      
      After this patch:
      
      $ modinfo drivers/net/ethernet/ezchip/nps_enet.ko | grep alias
      alias:          of:N*T*Cezchip,nps-mgt-enetC*
      alias:          of:N*T*Cezchip,nps-mgt-enet
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc971a2f
    • Colin Ian King's avatar
      cxgb4: fix memory leak of qe on error exit path · 67b11e2e
      Colin Ian King authored
      A memory leak of qe occurs when t4_sched_queue_unbind fails,
      so fix this by free'ing qe on the error exit path.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67b11e2e
    • Eric Dumazet's avatar
      net: pktgen: remove rcu locking in pktgen_change_name() · 9a0b1e8b
      Eric Dumazet authored
      After Jesper commit back in linux-3.18, we trigger a lockdep
      splat in proc_create_data() while allocating memory from
      pktgen_change_name().
      
      This patch converts t->if_lock to a mutex, since it is now only
      used from control path, and adds proper locking to pktgen_change_name()
      
      1) pktgen_thread_lock to protect the outer loop (iterating threads)
      2) t->if_lock to protect the inner loop (iterating devices)
      
      Note that before Jesper patch, pktgen_change_name() was lacking proper
      protection, but lockdep was not able to detect the problem.
      
      Fixes: 8788370a ("pktgen: RCU-ify "if_list" to remove lock in next_to_run()")
      Reported-by: default avatarJohn Sperbeck <jsperbeck@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a0b1e8b
    • David Ahern's avatar
      net: Require exact match for TCP socket lookups if dif is l3mdev · a04a480d
      David Ahern authored
      Currently, socket lookups for l3mdev (vrf) use cases can match a socket
      that is bound to a port but not a device (ie., a global socket). If the
      sysctl tcp_l3mdev_accept is not set this leads to ack packets going out
      based on the main table even though the packet came in from an L3 domain.
      The end result is that the connection does not establish creating
      confusion for users since the service is running and a socket shows in
      ss output. Fix by requiring an exact dif to sk_bound_dev_if match if the
      skb came through an interface enslaved to an l3mdev device and the
      tcp_l3mdev_accept is not set.
      
      skb's through an l3mdev interface are marked by setting a flag in
      inet{6}_skb_parm. The IPv6 variant is already set; this patch adds the
      flag for IPv4. Using an skb flag avoids a device lookup on the dif. The
      flag is set in the VRF driver using the IP{6}CB macros. For IPv4, the
      inet_skb_parm struct is moved in the cb per commit 971f10ec, so the
      match function in the TCP stack needs to use TCP_SKB_CB. For IPv6, the
      move is done after the socket lookup, so IP6CB is used.
      
      The flags field in inet_skb_parm struct needs to be increased to add
      another flag. There is currently a 1-byte hole following the flags,
      so it can be expanded to u16 without increasing the size of the struct.
      
      Fixes: 193125db ("net: Introduce VRF device driver")
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a04a480d
    • Ard Biesheuvel's avatar
      mac80211: move struct aead_req off the stack · f4a067f9
      Ard Biesheuvel authored
      Some crypto implementations (such as the generic CCM wrapper in crypto/)
      use scatterlists to map fields of private data in their struct aead_req.
      This means these data structures cannot live in the vmalloc area, which
      means that they cannot live on the stack (with CONFIG_VMAP_STACK.)
      
      This currently occurs only with the generic software implementation, but
      the private data and usage is implementation specific, so move the whole
      data structures off the stack into heap by allocating every time we need
      to use them.
      
      In addition, take care not to put any of our own stack allocations into
      scatterlists. This involves reserving some extra room when allocating the
      aead_request structures, and referring to those allocations in the scatter-
      lists (while copying the data from the stack before the crypto operation)
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f4a067f9
  3. 15 Oct, 2016 4 commits
  4. 14 Oct, 2016 11 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2016-10-14' of... · 9e55d0f9
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2016-10-14' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.9
      
      wlcore
      
      * fix a double free regression causing hard to track crashes
      
      rtl8xxxu
      
      * fix driver reload issues, a memory leak and an endian bug
      
      rtlwifi
      
      * fix a major regression introduced in 4.9 with firmware loading on
        certain hardware
      
      ath10k
      
      * fix regression about broken cal_data debugfs file (since 4.7)
      
      ath9k
      
      * revert temperature compensation for AR9003+ devices, it was causing
        too much problems
      
      ath6kl
      
      * add Dell OEM SDIO I/O for the Venue 8 Pro
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e55d0f9
    • Guenter Roeck's avatar
      net: asix: Avoid looping when the device does not respond · 610df1d2
      Guenter Roeck authored
      Check answers from USB stack and avoid re-sending the request
      multiple times if the device does not respond.
      
      This fixes the following problem, observed with a probably flaky adapter.
      
      [62108.732707] usb 1-3: new high-speed USB device number 5 using xhci_hcd
      [62108.914421] usb 1-3: New USB device found, idVendor=0b95, idProduct=7720
      [62108.914463] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      [62108.914476] usb 1-3: Product: AX88x72A
      [62108.914486] usb 1-3: Manufacturer: ASIX Elec. Corp.
      [62108.914495] usb 1-3: SerialNumber: 000001
      [62114.109109] asix 1-3:1.0 (unnamed net_device) (uninitialized):
      	Failed to write reg index 0x0000: -110
      [62114.109139] asix 1-3:1.0 (unnamed net_device) (uninitialized):
      	Failed to send software reset: ffffff92
      [62119.109048] asix 1-3:1.0 (unnamed net_device) (uninitialized):
      	Failed to write reg index 0x0000: -110
      ...
      
      Since the USB timeout is 5 seconds, and the operation is retried 30 times,
      this results in
      
      [62278.180353] INFO: task mtpd:1725 blocked for more than 120 seconds.
      [62278.180373]       Tainted: G        W      3.18.0-13298-g94ace9ed #1
      [62278.180383] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      ...
      [62278.180957] kworker/2:0     D 0000000000000000     0  5744      2 0x00000000
      [62278.180978] Workqueue: usb_hub_wq hub_event
      [62278.181029]  ffff880177f833b8 0000000000000046 ffff88017fd00000 ffff88017b126d80
      [62278.181048]  ffff880177f83fd8 ffff880065a71b60 0000000000013340 ffff880065a71b60
      [62278.181065]  0000000000000286 0000000103b1c199 0000000000001388 0000000000000002
      [62278.181081] Call Trace:
      [62278.181092]  [<ffffffff8e0971fd>] ? console_conditional_schedule+0x2c/0x2c
      [62278.181105]  [<ffffffff8e094f7b>] schedule+0x69/0x6b
      [62278.181117]  [<ffffffff8e0972e0>] schedule_timeout+0xe3/0x11d
      [62278.181133]  [<ffffffff8daadb1b>] ? trace_timer_start+0x51/0x51
      [62278.181146]  [<ffffffff8e095a05>] do_wait_for_common+0x12f/0x16c
      [62278.181162]  [<ffffffff8da856a7>] ? wake_up_process+0x39/0x39
      [62278.181174]  [<ffffffff8e095aee>] wait_for_common+0x52/0x6d
      [62278.181187]  [<ffffffff8e095b3b>] wait_for_completion_timeout+0x13/0x15
      [62278.181201]  [<ffffffff8de676ce>] usb_start_wait_urb+0x93/0xf1
      [62278.181214]  [<ffffffff8de6780d>] usb_control_msg+0xe1/0x11d
      [62278.181230]  [<ffffffffc037d629>] usbnet_write_cmd+0x9c/0xc6 [usbnet]
      [62278.181286]  [<ffffffffc03af793>] asix_write_cmd+0x4e/0x7e [asix]
      [62278.181300]  [<ffffffffc03afb41>] asix_set_sw_mii+0x25/0x4e [asix]
      [62278.181314]  [<ffffffffc03b001d>] asix_mdio_read+0x51/0x109 [asix]
      ...
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      610df1d2
    • Jesse Brandeburg's avatar
      ethtool: silence warning on bit loss · 85a62440
      Jesse Brandeburg authored
      Sparse was complaining when we went to prototype some code
      using ethtool_cmd_speed_set and SPEED_100000, which uses
      the upper 16 bits of __u32 speed for the first time.
      
      CHECK
      ...
      .../uapi/linux/ethtool.h:123:28: warning:
        cast truncates bits from constant value (186a0 becomes 86a0)
      
      The warning is actually bogus, as no bits are really lost, but
      we can get rid of the sparse warning with this one small change.
      Reported-by: default avatarPreethi Banala <preethi.banala@intel.com>
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85a62440
    • Brenden Blanco's avatar
      net/mlx4_en: fixup xdp tx irq to match rx · 958b3d39
      Brenden Blanco authored
      In cases where the number of tx rings is not a multiple of the number of
      rx rings, the tx completion event will be handled on a different core
      from the transmit and population of the ring. Races on the ring will
      lead to a double-free of the page, and possibly other corruption.
      
      The rings are initialized by default with a valid multiple of rings,
      based on the number of cpus, therefore an invalid configuration requires
      ethtool to change the ring layout. For instance 'ethtool -L eth0 rx 9 tx
      8' will cause packets received on rx0, and XDP_TX'd to tx48, to be
      completed on cpu3 (48 % 9 == 3).
      
      Resolve this discrepancy by shifting the irq for the xdp tx queues to
      start again from 0, modulo rx_ring_num.
      
      Fixes: 9ecc2d86 ("net/mlx4_en: add xdp forwarding and data write support")
      Reported-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarBrenden Blanco <bblanco@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      958b3d39
    • David S. Miller's avatar
      Merge branch 'qed-fixes' · fbbfa34c
      David S. Miller authored
      Yuval Mintz says:
      
      ====================
      qed: Fix dependencies and warnings series
      
      The first patch in this series follows Dan Carpenter's reports about
      Smatch warnings for recent qed additions and fixes those.
      
      The second patch is the most significant one [and the reason this is
      ntended for 'net'] - it's based on Arnd Bermann's suggestion for fixing
      compilation issues that were introduced with the roce addition as a result
      of certain combinations of qed, qede and qedr Kconfig options.
      
      The third follows the discussion with Arnd and clears a lot of the warnings
      that arise when compiling the drivers with "C=1".
      
      Please consider applying this series to 'net'.
      ====================
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbbfa34c
    • Yuval Mintz's avatar
      qed: Additional work toward cleaning C=1 · 8c93beaf
      Yuval Mintz authored
      This cleans many of the warnings that would arise in qed as a
      result of compilations with C=1; Most of those are the addition
      of missing 'static' to functions, although there are several other
      fixes as well.
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@caviumnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c93beaf
    • Yuval Mintz's avatar
      qed*: Fix Kconfig dependencies with INFINIBAND_QEDR · 0189efb8
      Yuval Mintz authored
      The qedr driver would require a tristate Kconfig option [to allow
      it to compile as a module], and toward that end we've added the
      INFINIBAND_QEDR option. But as we've made the compilation of the
      qed/qede infrastructure required for RoCE dependent on the option
      we'd be facing linking difficulties in case that QED=y or QEDE=y,
      and INFINIBAND_QEDR=m.
      
      To resolve this, we seperate between the INFINIBAND_QEDR option
      and the infrastructure support in qed/qede by introducing a new
      QED_RDMA option which would be selected by INFINIBAND_QEDR but would
      be a boolean instead of a tristate; Following that, the qed/qede is
      fixed based on this new option so that all config combinations would
      be supported.
      
      Fixes: cee9fbd8 ("qede: add qedr framework")
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@caviumnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0189efb8
    • Yuval Mintz's avatar
      qed: Fix static checker warning. · ce6b04ee
      Yuval Mintz authored
      Smatch compains about qed_roce_ll2_tx() dereference
      of the 'cdev' variable while testing its validity later.
      As the validation checking is an over-kill [variable would always
      be set], simply remove it.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: abd49676 ("qed: Add RoCE ll2 & GSI support")
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@caviumnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce6b04ee
    • Jiri Bohac's avatar
      IPv6: fix DESYNC_FACTOR · 76506a98
      Jiri Bohac authored
      The IPv6 temporary address generation uses a variable called DESYNC_FACTOR
      to prevent hosts updating the addresses at the same time. Quoting RFC 4941:
      
         ... The value DESYNC_FACTOR is a random value (different for each
         client) that ensures that clients don't synchronize with each other and
         generate new addresses at exactly the same time ...
      
      DESYNC_FACTOR is defined as:
      
         DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR.
         It is computed once at system start (rather than each time it is used)
         and must never be greater than (TEMP_VALID_LIFETIME - REGEN_ADVANCE).
      
      First, I believe the RFC has a typo in it and meant to say: "and must
      never be greater than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE)"
      
      The reason is that at various places in the RFC, DESYNC_FACTOR is used in
      a calculation like (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) or
      (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR). It needs to be
      smaller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE) for the result of
      these calculations to be larger than zero. It's never used in a
      calculation together with TEMP_VALID_LIFETIME.
      
      I already submitted an errata to the rfc-editor:
      https://www.rfc-editor.org/errata_search.php?rfc=4941
      
      The Linux implementation of DESYNC_FACTOR is very wrong:
      max_desync_factor is used in places DESYNC_FACTOR should be used.
      max_desync_factor is initialized to the RFC-recommended value for
      MAX_DESYNC_FACTOR (600) but the whole point is to get a _random_ value.
      
      And nothing ensures that the value used is not greater than
      (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE), which leads to underflows.  The
      effect can easily be observed when setting the temp_prefered_lft sysctl
      e.g. to 60. The preferred lifetime of the temporary addresses will be
      bogus.
      
      TEMP_PREFERRED_LIFETIME and REGEN_ADVANCE are not constants and can be
      influenced by these three sysctls: regen_max_retry, dad_transmits and
      temp_prefered_lft. Thus, the upper bound for desync_factor needs to be
      re-calculated each time a new address is generated and if desync_factor is
      larger than the new upper bound, a new random value needs to be
      re-generated.
      
      And since we already have max_desync_factor configurable per interface, we
      also need to calculate and store desync_factor per interface.
      Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76506a98
    • Jiri Bohac's avatar
      IPv6: Drop the temporary address regen_timer · 9d6280da
      Jiri Bohac authored
      The randomized interface identifier (rndid) was periodically updated from
      the regen_timer timer. Simplify the code by updating the rndid only when
      needed by ipv6_try_regen_rndid().
      
      This makes the follow-up DESYNC_FACTOR fix much simpler.  Also it fixes a
      reference counting error in this error path, where an in6_dev_put was
      missing:
      		err = addrconf_sysctl_register(ndev);
      		if (err) {
      			ipv6_mc_destroy_dev(ndev);
      	-               del_timer(&ndev->regen_timer);
      			snmp6_unregister_dev(ndev);
      			goto err_release;
      Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d6280da
    • Paolo Abeni's avatar
      IB/ipoib: move back IB LL address into the hard header · fc791b63
      Paolo Abeni authored
      After the commit 9207f9d4 ("net: preserve IP control block
      during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
      That destroy the IPoIB address information cached there,
      causing a severe performance regression, as better described here:
      
      http://marc.info/?l=linux-kernel&m=146787279825501&w=2
      
      This change moves the data cached by the IPoIB driver from the
      skb control lock into the IPoIB hard header, as done before
      the commit 936d7de3 ("IPoIB: Stop lying about hard_header_len
      and use skb->cb to stash LL addresses").
      In order to avoid GRO issue, on packet reception, the IPoIB driver
      stash into the skb a dummy pseudo header, so that the received
      packets have actually a hard header matching the declared length.
      To avoid changing the connected mode maximum mtu, the allocated
      head buffer size is increased by the pseudo header length.
      
      After this commit, IPoIB performances are back to pre-regression
      value.
      
      v2 -> v3: rebased
      v1 -> v2: avoid changing the max mtu, increasing the head buf size
      
      Fixes: 9207f9d4 ("net: preserve IP control block during GSO segmentation")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc791b63