1. 16 Aug, 2017 18 commits
    • Kai-Heng Feng's avatar
      usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter · dd3a2a08
      Kai-Heng Feng authored
      commit 7496cfe5 upstream.
      
      Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
      connect to Realtek r8153.
      
      The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
      can make it work.
      
      Since another r8153 dongle at my hand does not have the issue, so add
      the quirk to the Genesys Logic hub instead.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd3a2a08
    • Bin Liu's avatar
      usb: core: unlink urbs from the tail of the endpoint's urb_list · 921a1ed2
      Bin Liu authored
      commit 2eac1362 upstream.
      
      While unlink an urb, if the urb has been programmed in the controller,
      the controller driver might do some hw related actions to tear down the
      urb.
      
      Currently usb_hcd_flush_endpoint() passes each urb from the head of the
      endpoint's urb_list to the controller driver, which could make the
      controller driver think each urb has been programmed and take the
      unnecessary actions for each urb.
      
      This patch changes the behavior in usb_hcd_flush_endpoint() to pass the
      urbs from the tail of the list, to avoid any unnecessary actions in an
      controller driver.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      921a1ed2
    • Alan Stern's avatar
      USB: Check for dropped connection before switching to full speed · bc2f02f7
      Alan Stern authored
      commit 94c43b98 upstream.
      
      Some buggy USB disk adapters disconnect and reconnect multiple times
      during the enumeration procedure.  This may lead to a device
      connecting at full speed instead of high speed, because when the USB
      stack sees that a device isn't able to enumerate at high speed, it
      tries to hand the connection over to a full-speed companion
      controller.
      
      The logic for doing this is careful to check that the device is still
      connected.  But this check is inadequate if the device disconnects and
      reconnects before the check is done.  The symptom is that a device
      works, but much more slowly than it is capable of operating.
      
      The situation was made worse recently by commit 22547c4c ("usb:
      hub: Wait for connection to be reestablished after port reset"), which
      increases the delay following a reset before a disconnect is
      recognized, thus giving the device more time to reconnect.
      
      This patch makes the check more robust.  If the device was
      disconnected at any time during enumeration, we will now skip the
      full-speed handover.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarZdenek Kabelac <zkabelac@redhat.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc2f02f7
    • Alan Swanson's avatar
      uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069 · ed4f50ee
      Alan Swanson authored
      commit 89f23d51 upstream.
      
      Similar to commit d595259f ("usb-storage: Add ignore-residue quirk for
      Initio INIC-3619") for INIC-3169 in unusual_devs.h but INIC-3069 already
      present in unusual_uas.h. Both in same controller IC family.
      
      Issue is that MakeMKV fails during key exchange with installed bluray drive
      with following error:
      
      002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED'
      occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'
      Signed-off-by: default avatarAlan Swanson <reiver@improbability.net>
      Acked-by: default avatarOliver Neukum <oneukum@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed4f50ee
    • Akinobu Mita's avatar
      iio: light: tsl2563: use correct event code · dedeba47
      Akinobu Mita authored
      commit a3507e48 upstream.
      
      The TSL2563 driver provides three iio channels, two of which are raw ADC
      channels (channel 0 and channel 1) in the device and the remaining one
      is calculated by the two.  The ADC channel 0 only supports programmable
      interrupt with threshold settings and this driver supports the event but
      the generated event code does not contain the corresponding iio channel
      type.
      
      This is going to change userspace ABI.  Hopefully fixing this to be
      what it should always have been won't break any userspace code.
      
      Cc: Jonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dedeba47
    • Hans de Goede's avatar
      iio: accel: bmc150: Always restore device to normal mode after suspend-resume · dfb5cc91
      Hans de Goede authored
      commit e59e1898 upstream.
      
      After probe we would put the device in normal mode, after a runtime
      suspend-resume we would put it back in normal mode. But for a regular
      suspend-resume we would only put it back in normal mode if triggers
      or events have been requested.  This is not consistent and breaks
      reading raw values after a suspend-resume.
      
      This commit changes the regular resume path to also unconditionally put
      the device back in normal mode, fixing reading of raw values not working
      after a regular suspend-resume cycle.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfb5cc91
    • Arnd Bergmann's avatar
      staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read · c5f6f4fe
      Arnd Bergmann authored
      commit 105967ad upstream.
      
      gcc-7 points out an older regression:
      
      drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw':
      drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]
      
      The original code had 'unsigned short' here, but incorrectly got
      converted to 'bool'. This reverts the regression and uses a normal
      type instead.
      
      Fixes: 29148543 ("staging:iio:resolver:ad2s1210 minimal chan spec conversion.")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5f6f4fe
    • Rafael J. Wysocki's avatar
      USB: hcd: Mark secondary HCD as dead if the primary one died · dc978e9b
      Rafael J. Wysocki authored
      commit cd5a6a4f upstream.
      
      Make usb_hc_died() clear the HCD_FLAG_RH_RUNNING flag for the shared
      HCD and set HCD_FLAG_DEAD for it, in analogy with what is done for
      the primary one.
      
      Among other thigs, this prevents check_root_hub_suspended() from
      returning -EBUSY for dead HCDs which helps to work around system
      suspend issues in some situations.
      
      This actually fixes occasional suspend failures on one of my test
      machines.
      Suggested-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc978e9b
    • Bin Liu's avatar
      usb: musb: fix tx fifo flush handling again · 8b278516
      Bin Liu authored
      commit 45d73860 upstream.
      
      commit 68fe05e2 ("usb: musb: fix tx fifo flush handling") drops the
      1ms delay trying to solve the long disconnect time issue when
      application queued many tx urbs. However, the 1ms delay is needed for
      some use cases, for example, without the delay, reconnecting AR9271 WIFI
      dongle no longer works if the connection is dropped from the AP.
      
      So let's add back the 1ms delay in musb_h_tx_flush_fifo(), and solve the
      long disconnect time problem with a separate patch for
      usb_hcd_flush_endpoint().
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b278516
    • Greg Kroah-Hartman's avatar
      USB: serial: pl2303: add new ATEN device id · 8a0c2256
      Greg Kroah-Hartman authored
      commit 3b6bcd3d upstream.
      
      This adds a new ATEN device id for a new pl2303-based device.
      Reported-by: default avatarPeter Kuo <PeterKuo@aten.com.tw>
      Cc: Johan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a0c2256
    • Stefan Triller's avatar
      USB: serial: cp210x: add support for Qivicon USB ZigBee dongle · 31c9287b
      Stefan Triller authored
      commit 9585e340 upstream.
      
      The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
      for their SmartHome Home Base in its 1. Generation. The productId is not
      known by the according kernel module, this patch adds support for it.
      Signed-off-by: default avatarStefan Triller <github@stefantriller.de>
      Reviewed-by: default avatarFrans Klaver <fransklaver@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31c9287b
    • Hector Martin's avatar
      USB: serial: option: add D-Link DWM-222 device ID · 9cb43dec
      Hector Martin authored
      commit fd1b8668 upstream.
      
      Add device id for D-Link DWM-222.
      Signed-off-by: default avatarHector Martin <marcan@marcan.st>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cb43dec
    • Weston Andros Adamson's avatar
      nfs/flexfiles: fix leak of nfs4_ff_ds_version arrays · a89843a8
      Weston Andros Adamson authored
      commit 1feb2616 upstream.
      
      The client was freeing the nfs4_ff_layout_ds, but not the contained
      nfs4_ff_ds_version array.
      Signed-off-by: default avatarWeston Andros Adamson <dros@primarydata.com>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a89843a8
    • Mateusz Jurczyk's avatar
      fuse: initialize the flock flag in fuse_file on allocation · 7271d130
      Mateusz Jurczyk authored
      commit 68227c03 upstream.
      
      Before the patch, the flock flag could remain uninitialized for the
      lifespan of the fuse_file allocation. Unless set to true in
      fuse_file_flock(), it would remain in an indeterminate state until read in
      an if statement in fuse_release_common(). This could consequently lead to
      taking an unexpected branch in the code.
      
      The bug was discovered by a runtime instrumentation designed to detect use
      of uninitialized memory in the kernel.
      Signed-off-by: default avatarMateusz Jurczyk <mjurczyk@google.com>
      Fixes: 37fb3a30 ("fuse: fix flock")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7271d130
    • Nicholas Bellinger's avatar
      iscsi-target: Fix iscsi_np reset hung task during parallel delete · b89e781d
      Nicholas Bellinger authored
      commit 978d13d6 upstream.
      
      This patch fixes a bug associated with iscsit_reset_np_thread()
      that can occur during parallel configfs rmdir of a single iscsi_np
      used across multiple iscsi-target instances, that would result in
      hung task(s) similar to below where configfs rmdir process context
      was blocked indefinately waiting for iscsi_np->np_restart_comp
      to finish:
      
      [ 6726.112076] INFO: task dcp_proxy_node_:15550 blocked for more than 120 seconds.
      [ 6726.119440]       Tainted: G        W  O     4.1.26-3321 #2
      [ 6726.125045] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 6726.132927] dcp_proxy_node_ D ffff8803f202bc88     0 15550      1 0x00000000
      [ 6726.140058]  ffff8803f202bc88 ffff88085c64d960 ffff88083b3b1ad0 ffff88087fffeb08
      [ 6726.147593]  ffff8803f202c000 7fffffffffffffff ffff88083f459c28 ffff88083b3b1ad0
      [ 6726.155132]  ffff88035373c100 ffff8803f202bca8 ffffffff8168ced2 ffff8803f202bcb8
      [ 6726.162667] Call Trace:
      [ 6726.165150]  [<ffffffff8168ced2>] schedule+0x32/0x80
      [ 6726.170156]  [<ffffffff8168f5b4>] schedule_timeout+0x214/0x290
      [ 6726.176030]  [<ffffffff810caef2>] ? __send_signal+0x52/0x4a0
      [ 6726.181728]  [<ffffffff8168d7d6>] wait_for_completion+0x96/0x100
      [ 6726.187774]  [<ffffffff810e7c80>] ? wake_up_state+0x10/0x10
      [ 6726.193395]  [<ffffffffa035d6e2>] iscsit_reset_np_thread+0x62/0xe0 [iscsi_target_mod]
      [ 6726.201278]  [<ffffffffa0355d86>] iscsit_tpg_disable_portal_group+0x96/0x190 [iscsi_target_mod]
      [ 6726.210033]  [<ffffffffa0363f7f>] lio_target_tpg_store_enable+0x4f/0xc0 [iscsi_target_mod]
      [ 6726.218351]  [<ffffffff81260c5a>] configfs_write_file+0xaa/0x110
      [ 6726.224392]  [<ffffffff811ea364>] vfs_write+0xa4/0x1b0
      [ 6726.229576]  [<ffffffff811eb111>] SyS_write+0x41/0xb0
      [ 6726.234659]  [<ffffffff8169042e>] system_call_fastpath+0x12/0x71
      
      It would happen because each iscsit_reset_np_thread() sets state
      to ISCSI_NP_THREAD_RESET, sends SIGINT, and then blocks waiting
      for completion on iscsi_np->np_restart_comp.
      
      However, if iscsi_np was active processing a login request and
      more than a single iscsit_reset_np_thread() caller to the same
      iscsi_np was blocked on iscsi_np->np_restart_comp, iscsi_np
      kthread process context in __iscsi_target_login_thread() would
      flush pending signals and only perform a single completion of
      np->np_restart_comp before going back to sleep within transport
      specific iscsit_transport->iscsi_accept_np code.
      
      To address this bug, add a iscsi_np->np_reset_count and update
      __iscsi_target_login_thread() to keep completing np->np_restart_comp
      until ->np_reset_count has reached zero.
      Reported-by: default avatarGary Guo <ghg@datera.io>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b89e781d
    • Varun Prakash's avatar
      iscsi-target: fix memory leak in iscsit_setup_text_cmd() · 3afc4e92
      Varun Prakash authored
      commit ea8dc5b4 upstream.
      
      On receiving text request iscsi-target allocates buffer for
      payload in iscsit_handle_text_cmd() and assigns buffer pointer
      to cmd->text_in_ptr, this buffer is currently freed in
      iscsit_release_cmd(), if iscsi-target sets 'C' bit in text
      response then it will receive another text request from the
      initiator with ttt != 0xffffffff in this case iscsi-target
      will find cmd using itt and call iscsit_setup_text_cmd()
      which will set cmd->text_in_ptr to NULL without freeing
      previously allocated buffer.
      
      This patch fixes this issue by calling kfree(cmd->text_in_ptr)
      in iscsit_setup_text_cmd() before assigning NULL to it.
      
      For the first text request cmd->text_in_ptr is NULL as
      cmd is memset to 0 in iscsit_allocate_cmd().
      Signed-off-by: default avatarVarun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3afc4e92
    • Jonathan Toppins's avatar
      mm: ratelimit PFNs busy info message · 9ea732eb
      Jonathan Toppins authored
      commit 75dddef3 upstream.
      
      The RDMA subsystem can generate several thousand of these messages per
      second eventually leading to a kernel crash.  Ratelimit these messages
      to prevent this crash.
      
      Doug said:
       "I've been carrying a version of this for several kernel versions. I
        don't remember when they started, but we have one (and only one) class
        of machines: Dell PE R730xd, that generate these errors. When it
        happens, without a rate limit, we get rcu timeouts and kernel oopses.
        With the rate limit, we just get a lot of annoying kernel messages but
        the machine continues on, recovers, and eventually the memory
        operations all succeed"
      
      And:
       "> Well... why are all these EBUSY's occurring? It sounds inefficient
        > (at least) but if it is expected, normal and unavoidable then
        > perhaps we should just remove that message altogether?
      
        I don't have an answer to that question. To be honest, I haven't
        looked real hard. We never had this at all, then it started out of the
        blue, but only on our Dell 730xd machines (and it hits all of them),
        but no other classes or brands of machines. And we have our 730xd
        machines loaded up with different brands and models of cards (for
        instance one dedicated to mlx4 hardware, one for qib, one for mlx5, an
        ocrdma/cxgb4 combo, etc), so the fact that it hit all of the machines
        meant it wasn't tied to any particular brand/model of RDMA hardware.
        To me, it always smelled of a hardware oddity specific to maybe the
        CPUs or mainboard chipsets in these machines, so given that I'm not an
        mm expert anyway, I never chased it down.
      
        A few other relevant details: it showed up somewhere around 4.8/4.9 or
        thereabouts. It never happened before, but the prinkt has been there
        since the 3.18 days, so possibly the test to trigger this message was
        changed, or something else in the allocator changed such that the
        situation started happening on these machines?
      
        And, like I said, it is specific to our 730xd machines (but they are
        all identical, so that could mean it's something like their specific
        ram configuration is causing the allocator to hit this on these
        machine but not on other machines in the cluster, I don't want to say
        it's necessarily the model of chipset or CPU, there are other bits of
        identicalness between these machines)"
      
      Link: http://lkml.kernel.org/r/499c0f6cc10d6eb829a67f2a4d75b4228a9b356e.1501695897.git.jtoppins@redhat.comSigned-off-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Reviewed-by: default avatarDoug Ledford <dledford@redhat.com>
      Tested-by: default avatarDoug Ledford <dledford@redhat.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ea732eb
    • Dima Zavin's avatar
      cpuset: fix a deadlock due to incomplete patching of cpusets_enabled() · 97e37140
      Dima Zavin authored
      commit 89affbf5 upstream.
      
      In codepaths that use the begin/retry interface for reading
      mems_allowed_seq with irqs disabled, there exists a race condition that
      stalls the patch process after only modifying a subset of the
      static_branch call sites.
      
      This problem manifested itself as a deadlock in the slub allocator,
      inside get_any_partial.  The loop reads mems_allowed_seq value (via
      read_mems_allowed_begin), performs the defrag operation, and then
      verifies the consistency of mem_allowed via the read_mems_allowed_retry
      and the cookie returned by xxx_begin.
      
      The issue here is that both begin and retry first check if cpusets are
      enabled via cpusets_enabled() static branch.  This branch can be
      rewritted dynamically (via cpuset_inc) if a new cpuset is created.  The
      x86 jump label code fully synchronizes across all CPUs for every entry
      it rewrites.  If it rewrites only one of the callsites (specifically the
      one in read_mems_allowed_retry) and then waits for the
      smp_call_function(do_sync_core) to complete while a CPU is inside the
      begin/retry section with IRQs off and the mems_allowed value is changed,
      we can hang.
      
      This is because begin() will always return 0 (since it wasn't patched
      yet) while retry() will test the 0 against the actual value of the seq
      counter.
      
      The fix is to use two different static keys: one for begin
      (pre_enable_key) and one for retry (enable_key).  In cpuset_inc(), we
      first bump the pre_enable key to ensure that cpuset_mems_allowed_begin()
      always return a valid seqcount if are enabling cpusets.  Similarly, when
      disabling cpusets via cpuset_dec(), we first ensure that callers of
      cpuset_mems_allowed_retry() will start ignoring the seqcount value
      before we let cpuset_mems_allowed_begin() return 0.
      
      The relevant stack traces of the two stuck threads:
      
        CPU: 1 PID: 1415 Comm: mkdir Tainted: G L  4.9.36-00104-g540c51286237 #4
        Hardware name: Default string Default string/Hardware, BIOS 4.29.1-20170526215256 05/26/2017
        task: ffff8817f9c28000 task.stack: ffffc9000ffa4000
        RIP: smp_call_function_many+0x1f9/0x260
        Call Trace:
          smp_call_function+0x3b/0x70
          on_each_cpu+0x2f/0x90
          text_poke_bp+0x87/0xd0
          arch_jump_label_transform+0x93/0x100
          __jump_label_update+0x77/0x90
          jump_label_update+0xaa/0xc0
          static_key_slow_inc+0x9e/0xb0
          cpuset_css_online+0x70/0x2e0
          online_css+0x2c/0xa0
          cgroup_apply_control_enable+0x27f/0x3d0
          cgroup_mkdir+0x2b7/0x420
          kernfs_iop_mkdir+0x5a/0x80
          vfs_mkdir+0xf6/0x1a0
          SyS_mkdir+0xb7/0xe0
          entry_SYSCALL_64_fastpath+0x18/0xad
      
        ...
      
        CPU: 2 PID: 1 Comm: init Tainted: G L  4.9.36-00104-g540c51286237 #4
        Hardware name: Default string Default string/Hardware, BIOS 4.29.1-20170526215256 05/26/2017
        task: ffff8818087c0000 task.stack: ffffc90000030000
        RIP: int3+0x39/0x70
        Call Trace:
          <#DB> ? ___slab_alloc+0x28b/0x5a0
          <EOE> ? copy_process.part.40+0xf7/0x1de0
          __slab_alloc.isra.80+0x54/0x90
          copy_process.part.40+0xf7/0x1de0
          copy_process.part.40+0xf7/0x1de0
          kmem_cache_alloc_node+0x8a/0x280
          copy_process.part.40+0xf7/0x1de0
          _do_fork+0xe7/0x6c0
          _raw_spin_unlock_irq+0x2d/0x60
          trace_hardirqs_on_caller+0x136/0x1d0
          entry_SYSCALL_64_fastpath+0x5/0xad
          do_syscall_64+0x27/0x350
          SyS_clone+0x19/0x20
          do_syscall_64+0x60/0x350
          entry_SYSCALL64_slow_path+0x25/0x25
      
      Link: http://lkml.kernel.org/r/20170731040113.14197-1-dmitriyz@waymo.com
      Fixes: 46e700ab ("mm, page_alloc: remove unnecessary taking of a seqlock when cpusets are disabled")
      Signed-off-by: default avatarDima Zavin <dmitriyz@waymo.com>
      Reported-by: default avatarCliff Spradlin <cspradlin@waymo.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christopher Lameter <cl@linux.com>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      97e37140
  2. 13 Aug, 2017 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.82 · 4e2e415f
      Greg Kroah-Hartman authored
      4e2e415f
    • Michal Kubeček's avatar
      net: account for current skb length when deciding about UFO · fab61468
      Michal Kubeček authored
      commit a5cb659b upstream.
      
      Our customer encountered stuck NFS writes for blocks starting at specific
      offsets w.r.t. page boundary caused by networking stack sending packets via
      UFO enabled device with wrong checksum. The problem can be reproduced by
      composing a long UDP datagram from multiple parts using MSG_MORE flag:
      
        sendto(sd, buff, 1000, MSG_MORE, ...);
        sendto(sd, buff, 1000, MSG_MORE, ...);
        sendto(sd, buff, 3000, 0, ...);
      
      Assume this packet is to be routed via a device with MTU 1500 and
      NETIF_F_UFO enabled. When second sendto() gets into __ip_append_data(),
      this condition is tested (among others) to decide whether to call
      ip_ufo_append_data():
      
        ((length + fragheaderlen) > mtu) || (skb && skb_is_gso(skb))
      
      At the moment, we already have skb with 1028 bytes of data which is not
      marked for GSO so that the test is false (fragheaderlen is usually 20).
      Thus we append second 1000 bytes to this skb without invoking UFO. Third
      sendto(), however, has sufficient length to trigger the UFO path so that we
      end up with non-UFO skb followed by a UFO one. Later on, udp_send_skb()
      uses udp_csum() to calculate the checksum but that assumes all fragments
      have correct checksum in skb->csum which is not true for UFO fragments.
      
      When checking against MTU, we need to add skb->len to length of new segment
      if we already have a partially filled skb and fragheaderlen only if there
      isn't one.
      
      In the IPv6 case, skb can only be null if this is the first segment so that
      we have to use headersize (length of the first IPv6 header) rather than
      fragheaderlen (length of IPv6 header of further fragments) for skb == NULL.
      
      Fixes: e89e9cf5 ("[IPv4/IPv6]: UFO Scatter-gather approach")
      Fixes: e4c5e13a ("ipv6: Should use consistent conditional judgement for
      	ip6 fragment between __ip6_append_data and ip6_finish_output")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Acked-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fab61468
    • zheng li's avatar
      ipv4: Should use consistent conditional judgement for ip fragment in... · 96cdeaa3
      zheng li authored
      ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output
      
      commit 0a28cfd5 upstream.
      
      There is an inconsistent conditional judgement in __ip_append_data and
      ip_finish_output functions, the variable length in __ip_append_data just
      include the length of application's payload and udp header, don't include
      the length of ip header, but in ip_finish_output use
      (skb->len > ip_skb_dst_mtu(skb)) as judgement, and skb->len include the
      length of ip header.
      
      That causes some particular application's udp payload whose length is
      between (MTU - IP Header) and MTU were fragmented by ip_fragment even
      though the rst->dev support UFO feature.
      
      Add the length of ip header to length in __ip_append_data to keep
      consistent conditional judgement as ip_finish_output for ip fragment.
      Signed-off-by: default avatarZheng Li <james.z.li@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      96cdeaa3
    • Matthew Dawson's avatar
      mm/mempool: avoid KASAN marking mempool poison checks as use-after-free · d45aabad
      Matthew Dawson authored
      commit 76401310 upstream.
      
      When removing an element from the mempool, mark it as unpoisoned in KASAN
      before verifying its contents for SLUB/SLAB debugging.  Otherwise KASAN
      will flag the reads checking the element use-after-free writes as
      use-after-free reads.
      Signed-off-by: default avatarMatthew Dawson <matthew@mjdsystems.ca>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrii Bordunov <aborduno@cisco.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d45aabad
    • Suzuki K Poulose's avatar
      KVM: arm/arm64: Handle hva aging while destroying the vm · 7e86f2d5
      Suzuki K Poulose authored
      commit 7e5a6722 upstream.
      
      The mmu_notifier_release() callback of KVM triggers cleaning up
      the stage2 page table on kvm-arm. However there could be other
      notifier callbacks in parallel with the mmu_notifier_release(),
      which could cause the call backs ending up in an empty stage2
      page table. Make sure we check it for all the notifier callbacks.
      
      Fixes: commit 293f2936 ("kvm-arm: Unmap shadow pagetables properly")
      Reported-by: default avatarAlex Graf <agraf@suse.de>
      Reviewed-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      7e86f2d5
    • Rob Gardner's avatar
      sparc64: Prevent perf from running during super critical sections · 6fe71ca3
      Rob Gardner authored
      commit fc290a11 upstream.
      
      This fixes another cause of random segfaults and bus errors that may
      occur while running perf with the callgraph option.
      
      Critical sections beginning with spin_lock_irqsave() raise the interrupt
      level to PIL_NORMAL_MAX (14) and intentionally do not block performance
      counter interrupts, which arrive at PIL_NMI (15).
      
      But some sections of code are "super critical" with respect to perf
      because the perf_callchain_user() path accesses user space and may cause
      TLB activity as well as faults as it unwinds the user stack.
      
      One particular critical section occurs in switch_mm:
      
              spin_lock_irqsave(&mm->context.lock, flags);
              ...
              load_secondary_context(mm);
              tsb_context_switch(mm);
              ...
              spin_unlock_irqrestore(&mm->context.lock, flags);
      
      If a perf interrupt arrives in between load_secondary_context() and
      tsb_context_switch(), then perf_callchain_user() could execute with
      the context ID of one process, but with an active TSB for a different
      process. When the user stack is accessed, it is very likely to
      incur a TLB miss, since the h/w context ID has been changed. The TLB
      will then be reloaded with a translation from the TSB for one process,
      but using a context ID for another process. This exposes memory from
      one process to another, and since it is a mapping for stack memory,
      this usually causes the new process to crash quickly.
      
      This super critical section needs more protection than is provided
      by spin_lock_irqsave() since perf interrupts must not be allowed in.
      
      Since __tsb_context_switch already goes through the trouble of
      disabling interrupts completely, we fix this by moving the secondary
      context load down into this better protected region.
      
      Orabug: 25577560
      Signed-off-by: default avatarDave Aldridge <david.j.aldridge@oracle.com>
      Signed-off-by: default avatarRob Gardner <rob.gardner@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fe71ca3
    • Willem de Bruijn's avatar
      udp: consistently apply ufo or fragmentation · 938990d2
      Willem de Bruijn authored
      
      [ Upstream commit 85f1bd9a ]
      
      When iteratively building a UDP datagram with MSG_MORE and that
      datagram exceeds MTU, consistently choose UFO or fragmentation.
      
      Once skb_is_gso, always apply ufo. Conversely, once a datagram is
      split across multiple skbs, do not consider ufo.
      
      Sendpage already maintains the first invariant, only add the second.
      IPv6 does not have a sendpage implementation to modify.
      
      A gso skb must have a partial checksum, do not follow sk_no_check_tx
      in udp_send_skb.
      
      Found by syzkaller.
      
      Fixes: e89e9cf5 ("[IPv4/IPv6]: UFO Scatter-gather approach")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      938990d2
    • Greg Kroah-Hartman's avatar
      revert "ipv4: Should use consistent conditional judgement for ip fragment in... · 98c1ad1e
      Greg Kroah-Hartman authored
      revert "ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output"
      
      This reverts commit f102bb71 which is
      commit 0a28cfd5 upstream as there is
      another patch that needs to be applied instead of this one.
      
      Cc: Zheng Li <james.z.li@ericsson.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Sasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      98c1ad1e
    • Greg Kroah-Hartman's avatar
      revert "net: account for current skb length when deciding about UFO" · 54fc0c32
      Greg Kroah-Hartman authored
      This reverts commit ef09c9ff which is
      commit a5cb659b upstream as it causes
      merge issues with later patches that are much more important...
      
      Cc: Michal Kubecek <mkubecek@suse.cz>
      Cc: Vlad Yasevich <vyasevic@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Sasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54fc0c32
    • Willem de Bruijn's avatar
      packet: fix tp_reserve race in packet_set_ring · 63364a50
      Willem de Bruijn authored
      
      [ Upstream commit c27927e3 ]
      
      Updates to tp_reserve can race with reads of the field in
      packet_set_ring. Avoid this by holding the socket lock during
      updates in setsockopt PACKET_RESERVE.
      
      This bug was discovered by syzkaller.
      
      Fixes: 8913336a ("packet: add PACKET_RESERVE sockopt")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63364a50
    • Willem de Bruijn's avatar
      net: avoid skb_warn_bad_offload false positives on UFO · 37d5c6e8
      Willem de Bruijn authored
      
      [ Upstream commit 8d63bee6 ]
      
      skb_warn_bad_offload triggers a warning when an skb enters the GSO
      stack at __skb_gso_segment that does not have CHECKSUM_PARTIAL
      checksum offload set.
      
      Commit b2504a5d ("net: reduce skb_warn_bad_offload() noise")
      observed that SKB_GSO_DODGY producers can trigger the check and
      that passing those packets through the GSO handlers will fix it
      up. But, the software UFO handler will set ip_summed to
      CHECKSUM_NONE.
      
      When __skb_gso_segment is called from the receive path, this
      triggers the warning again.
      
      Make UFO set CHECKSUM_UNNECESSARY instead of CHECKSUM_NONE. On
      Tx these two are equivalent. On Rx, this better matches the
      skb state (checksum computed), as CHECKSUM_NONE here means no
      checksum computed.
      
      See also this thread for context:
      http://patchwork.ozlabs.org/patch/799015/
      
      Fixes: b2504a5d ("net: reduce skb_warn_bad_offload() noise")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37d5c6e8
    • Eric Dumazet's avatar
      tcp: fastopen: tcp_connect() must refresh the route · 8607d550
      Eric Dumazet authored
      
      [ Upstream commit 8ba60924 ]
      
      With new TCP_FASTOPEN_CONNECT socket option, there is a possibility
      to call tcp_connect() while socket sk_dst_cache is either NULL
      or invalid.
      
       +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
       +0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
       +0 setsockopt(4, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
       +0 connect(4, ..., ...) = 0
      
      << sk->sk_dst_cache becomes obsolete, or even set to NULL >>
      
       +1 sendto(4, ..., 1000, MSG_FASTOPEN, ..., ...) = 1000
      
      We need to refresh the route otherwise bad things can happen,
      especially when syzkaller is running on the host :/
      
      Fixes: 19f6d3f3 ("net/tcp-fastopen: Add new API support")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Wei Wang <weiwan@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: default avatarWei Wang <weiwan@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8607d550
    • Xin Long's avatar
      net: sched: set xt_tgchk_param par.nft_compat as 0 in ipt_init_target · 40fc2b44
      Xin Long authored
      
      [ Upstream commit 96d97030 ]
      
      Commit 55917a21 ("netfilter: x_tables: add context to know if
      extension runs from nft_compat") introduced a member nft_compat to
      xt_tgchk_param structure.
      
      But it didn't set it's value for ipt_init_target. With unexpected
      value in par.nft_compat, it may return unexpected result in some
      target's checkentry.
      
      This patch is to set all it's fields as 0 and only initialize the
      non-zero fields in ipt_init_target.
      
      v1->v2:
        As Wang Cong's suggestion, fix it by setting all it's fields as
        0 and only initializing the non-zero fields.
      
      Fixes: 55917a21 ("netfilter: x_tables: add context to know if extension runs from nft_compat")
      Suggested-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40fc2b44
    • Daniel Borkmann's avatar
      bpf, s390: fix jit branch offset related to ldimm64 · d0da2877
      Daniel Borkmann authored
      
      [ Upstream commit b0a0c256 ]
      
      While testing some other work that required JIT modifications, I
      run into test_bpf causing a hang when JIT enabled on s390. The
      problematic test case was the one from ddc665a4 (bpf, arm64:
      fix jit branch offset related to ldimm64), and turns out that we
      do have a similar issue on s390 as well. In bpf_jit_prog() we
      update next instruction address after returning from bpf_jit_insn()
      with an insn_count. bpf_jit_insn() returns either -1 in case of
      error (e.g. unsupported insn), 1 or 2. The latter is only the
      case for ldimm64 due to spanning 2 insns, however, next address
      is only set to i + 1 not taking actual insn_count into account,
      thus fix is to use insn_count instead of 1. bpf_jit_enable in
      mode 2 provides also disasm on s390:
      
      Before fix:
      
        000003ff800349b6: a7f40003   brc     15,3ff800349bc                 ; target
        000003ff800349ba: 0000               unknown
        000003ff800349bc: e3b0f0700024       stg     %r11,112(%r15)
        000003ff800349c2: e3e0f0880024       stg     %r14,136(%r15)
        000003ff800349c8: 0db0               basr    %r11,%r0
        000003ff800349ca: c0ef00000000       llilf   %r14,0
        000003ff800349d0: e320b0360004       lg      %r2,54(%r11)
        000003ff800349d6: e330b03e0004       lg      %r3,62(%r11)
        000003ff800349dc: ec23ffeda065       clgrj   %r2,%r3,10,3ff800349b6 ; jmp
        000003ff800349e2: e3e0b0460004       lg      %r14,70(%r11)
        000003ff800349e8: e3e0b04e0004       lg      %r14,78(%r11)
        000003ff800349ee: b904002e   lgr     %r2,%r14
        000003ff800349f2: e3b0f0700004       lg      %r11,112(%r15)
        000003ff800349f8: e3e0f0880004       lg      %r14,136(%r15)
        000003ff800349fe: 07fe               bcr     15,%r14
      
      After fix:
      
        000003ff80ef3db4: a7f40003   brc     15,3ff80ef3dba
        000003ff80ef3db8: 0000               unknown
        000003ff80ef3dba: e3b0f0700024       stg     %r11,112(%r15)
        000003ff80ef3dc0: e3e0f0880024       stg     %r14,136(%r15)
        000003ff80ef3dc6: 0db0               basr    %r11,%r0
        000003ff80ef3dc8: c0ef00000000       llilf   %r14,0
        000003ff80ef3dce: e320b0360004       lg      %r2,54(%r11)
        000003ff80ef3dd4: e330b03e0004       lg      %r3,62(%r11)
        000003ff80ef3dda: ec230006a065       clgrj   %r2,%r3,10,3ff80ef3de6 ; jmp
        000003ff80ef3de0: e3e0b0460004       lg      %r14,70(%r11)
        000003ff80ef3de6: e3e0b04e0004       lg      %r14,78(%r11)          ; target
        000003ff80ef3dec: b904002e   lgr     %r2,%r14
        000003ff80ef3df0: e3b0f0700004       lg      %r11,112(%r15)
        000003ff80ef3df6: e3e0f0880004       lg      %r14,136(%r15)
        000003ff80ef3dfc: 07fe               bcr     15,%r14
      
      test_bpf.ko suite runs fine after the fix.
      
      Fixes: 05462310 ("s390/bpf: Add s390x eBPF JIT compiler backend")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0da2877
    • Eric Dumazet's avatar
      net: fix keepalive code vs TCP_FASTOPEN_CONNECT · 4e0675f4
      Eric Dumazet authored
      
      [ Upstream commit 2dda6400 ]
      
      syzkaller was able to trigger a divide by 0 in TCP stack [1]
      
      Issue here is that keepalive timer needs to be updated to not attempt
      to send a probe if the connection setup was deferred using
      TCP_FASTOPEN_CONNECT socket option added in linux-4.11
      
      [1]
       divide error: 0000 [#1] SMP
       CPU: 18 PID: 0 Comm: swapper/18 Not tainted
       task: ffff986f62f4b040 ti: ffff986f62fa2000 task.ti: ffff986f62fa2000
       RIP: 0010:[<ffffffff8409cc0d>]  [<ffffffff8409cc0d>] __tcp_select_window+0x8d/0x160
       Call Trace:
        <IRQ>
        [<ffffffff8409d951>] tcp_transmit_skb+0x11/0x20
        [<ffffffff8409da21>] tcp_xmit_probe_skb+0xc1/0xe0
        [<ffffffff840a0ee8>] tcp_write_wakeup+0x68/0x160
        [<ffffffff840a151b>] tcp_keepalive_timer+0x17b/0x230
        [<ffffffff83b3f799>] call_timer_fn+0x39/0xf0
        [<ffffffff83b40797>] run_timer_softirq+0x1d7/0x280
        [<ffffffff83a04ddb>] __do_softirq+0xcb/0x257
        [<ffffffff83ae03ac>] irq_exit+0x9c/0xb0
        [<ffffffff83a04c1a>] smp_apic_timer_interrupt+0x6a/0x80
        [<ffffffff83a03eaf>] apic_timer_interrupt+0x7f/0x90
        <EOI>
        [<ffffffff83fed2ea>] ? cpuidle_enter_state+0x13a/0x3b0
        [<ffffffff83fed2cd>] ? cpuidle_enter_state+0x11d/0x3b0
      
      Tested:
      
      Following packetdrill no longer crashes the kernel
      
      `echo 0 >/proc/sys/net/ipv4/tcp_timestamps`
      
      // Cache warmup: send a Fast Open cookie request
          0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
         +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
         +0 setsockopt(3, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
         +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation is now in progress)
         +0 > S 0:0(0) <mss 1460,nop,nop,sackOK,nop,wscale 8,FO,nop,nop>
       +.01 < S. 123:123(0) ack 1 win 14600 <mss 1460,nop,nop,sackOK,nop,wscale 6,FO abcd1234,nop,nop>
         +0 > . 1:1(0) ack 1
         +0 close(3) = 0
         +0 > F. 1:1(0) ack 1
         +0 < F. 1:1(0) ack 2 win 92
         +0 > .  2:2(0) ack 2
      
         +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
         +0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
         +0 setsockopt(4, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
         +0 setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
       +.01 connect(4, ..., ...) = 0
         +0 setsockopt(4, SOL_TCP, TCP_KEEPIDLE, [5], 4) = 0
         +10 close(4) = 0
      
      `echo 1 >/proc/sys/net/ipv4/tcp_timestamps`
      
      Fixes: 19f6d3f3 ("net/tcp-fastopen: Add new API support")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Wei Wang <weiwan@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e0675f4
    • Yuchung Cheng's avatar
      tcp: avoid setting cwnd to invalid ssthresh after cwnd reduction states · 025bb7f7
      Yuchung Cheng authored
      
      [ Upstream commit ed254971 ]
      
      If the sender switches the congestion control during ECN-triggered
      cwnd-reduction state (CA_CWR), upon exiting recovery cwnd is set to
      the ssthresh value calculated by the previous congestion control. If
      the previous congestion control is BBR that always keep ssthresh
      to TCP_INIFINITE_SSTHRESH, cwnd ends up being infinite. The safe
      step is to avoid assigning invalid ssthresh value when recovery ends.
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      025bb7f7
  3. 11 Aug, 2017 6 commits