1. 16 Aug, 2017 32 commits
    • Sandeep Singh's avatar
      usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume · 4cae4a23
      Sandeep Singh authored
      commit e788787e upstream.
      
      Certain HP keyboards would keep inputting a character automatically which
      is the wake-up key after S3 resume
      
      On some AMD platforms USB host fails to respond (by holding resume-K) to
      USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures
      that resume is signaled for at least 20 ms (TDRSMDN), which is defined in
      USB 2.0 spec. The result is that the keyboard is out of function.
      
      In SNPS USB design, the host responds to the resume request only after
      system gets back to S0 and the host gets to functional after the internal
      HW restore operation that is more than 1 second after the initial resume
      request from the USB device.
      
      As a workaround for specific keyboard ID(HP Keyboards), applying port reset
      after resume when the keyboard is plugged in.
      Signed-off-by: default avatarSandeep Singh <Sandeep.Singh@amd.com>
      Signed-off-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
      Reviewed-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cae4a23
    • Kai-Heng Feng's avatar
      usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter · f4bbed57
      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>
      f4bbed57
    • Bin Liu's avatar
      usb: core: unlink urbs from the tail of the endpoint's urb_list · 42d65cc8
      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>
      42d65cc8
    • Alan Stern's avatar
      USB: Check for dropped connection before switching to full speed · 7c2beb1c
      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>
      7c2beb1c
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: Fix UGCTRL2 value for R-Car Gen3 · 7f737f10
      Yoshihiro Shimoda authored
      commit 2acecd58 upstream.
      
      The latest HW manual (Rev.0.55) shows us this UGCTRL2.VBUSSEL bit.
      If the bit sets to 1, the VBUS drive is controlled by phy related
      registers (called "UCOM Registers" on the manual). Since R-Car Gen3
      environment will control VBUS by phy-rcar-gen3-usb2 driver,
      the UGCTRL2.VBUSSEL bit should be set to 1. So, this patch fixes
      the register's value. Otherwise, even if the ID pin indicates to
      peripheral, the R-Car will output USBn_PWEN to 1 when a host driver
      is running.
      
      Fixes: de18757e ("usb: renesas_usbhs: add R-Car Gen3 power control"
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f737f10
    • Yoshihiro Shimoda's avatar
      usb: gadget: udc: renesas_usb3: Fix usb_gadget_giveback_request() calling · 2db03a7f
      Yoshihiro Shimoda authored
      commit aca5b9eb upstream.
      
      According to the gadget.h, a "complete" function will always be called
      with interrupts disabled. However, sometimes usb3_request_done() function
      is called with interrupts enabled. So, this function should be held
      by spin_lock_irqsave() to disable interruption. Also, this driver has
      to call spin_unlock() to avoid spinlock recursion by this driver before
      calling usb_gadget_giveback_request().
      Reported-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      Tested-by: default avatarKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
      Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2db03a7f
    • Alan Swanson's avatar
      uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069 · a09ecc93
      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>
      a09ecc93
    • Ian Abbott's avatar
      staging: comedi: comedi_fops: do not call blocking ops when !TASK_RUNNING · b189f8eb
      Ian Abbott authored
      commit cef98864 upstream.
      
      Comedi's read and write file operation handlers (`comedi_read()` and
      `comedi_write()`) currently call `copy_to_user()` or `copy_from_user()`
      whilst in the `TASK_INTERRUPTIBLE` state, which falls foul of the
      `might_fault()` checks when enabled.  Fix it by setting the current task
      state back to `TASK_RUNNING` a bit earlier before calling these
      functions.
      Reported-by: default avatarPiotr Gregor <piotrgregor@rsyncme.org>
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b189f8eb
    • Akinobu Mita's avatar
      iio: light: tsl2563: use correct event code · bbae0821
      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>
      bbae0821
    • Hans de Goede's avatar
      iio: accel: bmc150: Always restore device to normal mode after suspend-resume · 1ca38692
      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>
      1ca38692
    • Arnd Bergmann's avatar
      staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read · c5347390
      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>
      c5347390
    • Rafael J. Wysocki's avatar
      USB: hcd: Mark secondary HCD as dead if the primary one died · 199a3f26
      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>
      199a3f26
    • Bin Liu's avatar
      usb: musb: fix tx fifo flush handling again · 821ccbe2
      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>
      821ccbe2
    • Greg Kroah-Hartman's avatar
      USB: serial: pl2303: add new ATEN device id · 4fd8c366
      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>
      4fd8c366
    • Stefan Triller's avatar
      USB: serial: cp210x: add support for Qivicon USB ZigBee dongle · 56651640
      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>
      56651640
    • Hector Martin's avatar
      USB: serial: option: add D-Link DWM-222 device ID · e27f58cd
      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>
      e27f58cd
    • Maarten Lankhorst's avatar
      drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut · 2b3bf207
      Maarten Lankhorst authored
      commit 5279fc77 upstream.
      
      bdw_load_gamma_lut is writing beyond the array to the maximum value.
      The intend of the function is to clamp values > 1 to 1, so write
      the intended color to the max register.
      
      This fixes the following KASAN warning:
      
      [  197.020857] [IGT] kms_pipe_color: executing
      [  197.063434] [IGT] kms_pipe_color: starting subtest ctm-0-25-pipe0
      [  197.078989] ==================================================================
      [  197.079127] BUG: KASAN: slab-out-of-bounds in bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
      [  197.079188] Read of size 2 at addr ffff8800d38db150 by task kms_pipe_color/1839
      [  197.079208] CPU: 2 PID: 1839 Comm: kms_pipe_color Tainted: G     U 4.13.0-rc1-patser+ #5211
      [  197.079215] Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
      [  197.079220] Call Trace:
      [  197.079230]  dump_stack+0x68/0x9e
      [  197.079239]  print_address_description+0x6f/0x250
      [  197.079251]  kasan_report+0x216/0x370
      [  197.079374]  ? bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
      [  197.079451]  ? gen8_write16+0x4e0/0x4e0 [i915]
      [  197.079460]  __asan_report_load2_noabort+0x14/0x20
      [  197.079535]  bdw_load_gamma_lut.isra.2+0x3b9/0x570 [i915]
      [  197.079612]  broadwell_load_luts+0x1df/0x550 [i915]
      [  197.079690]  intel_color_load_luts+0x7b/0x80 [i915]
      [  197.079764]  intel_begin_crtc_commit+0x138/0x760 [i915]
      [  197.079783]  drm_atomic_helper_commit_planes_on_crtc+0x1a3/0x820 [drm_kms_helper]
      [  197.079859]  ? intel_pre_plane_update+0x571/0x580 [i915]
      [  197.079937]  intel_update_crtc+0x238/0x330 [i915]
      [  197.080016]  intel_update_crtcs+0x10f/0x210 [i915]
      [  197.080092]  intel_atomic_commit_tail+0x1552/0x3340 [i915]
      [  197.080101]  ? _raw_spin_unlock+0x3c/0x40
      [  197.080110]  ? __queue_work+0xb40/0xbf0
      [  197.080188]  ? skl_update_crtcs+0xc00/0xc00 [i915]
      [  197.080195]  ? trace_hardirqs_on+0xd/0x10
      [  197.080269]  ? intel_atomic_commit_ready+0x128/0x13c [i915]
      [  197.080329]  ? __i915_sw_fence_complete+0x5b8/0x6d0 [i915]
      [  197.080336]  ? debug_object_activate+0x39e/0x580
      [  197.080397]  ? i915_sw_fence_await+0x30/0x30 [i915]
      [  197.080409]  ? __might_sleep+0x15b/0x180
      [  197.080483]  intel_atomic_commit+0x944/0xa70 [i915]
      [  197.080490]  ? refcount_dec_and_test+0x11/0x20
      [  197.080567]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
      [  197.080597]  ? drm_atomic_crtc_set_property+0x303/0x580 [drm]
      [  197.080674]  ? intel_atomic_commit_tail+0x3340/0x3340 [i915]
      [  197.080704]  drm_atomic_commit+0xd7/0xe0 [drm]
      [  197.080722]  drm_atomic_helper_crtc_set_property+0xec/0x130 [drm_kms_helper]
      [  197.080749]  drm_mode_crtc_set_obj_prop+0x7d/0xb0 [drm]
      [  197.080775]  drm_mode_obj_set_property_ioctl+0x50b/0x5d0 [drm]
      [  197.080783]  ? __might_fault+0x104/0x180
      [  197.080809]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
      [  197.080838]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
      [  197.080861]  drm_ioctl_kernel+0x154/0x1a0 [drm]
      [  197.080885]  drm_ioctl+0x624/0x8f0 [drm]
      [  197.080910]  ? drm_mode_obj_find_prop_id+0x160/0x160 [drm]
      [  197.080934]  ? drm_getunique+0x210/0x210 [drm]
      [  197.080943]  ? __handle_mm_fault+0x1bd0/0x1ce0
      [  197.080949]  ? lock_downgrade+0x610/0x610
      [  197.080957]  ? __lru_cache_add+0x15a/0x180
      [  197.080967]  do_vfs_ioctl+0xd92/0xe40
      [  197.080975]  ? ioctl_preallocate+0x1b0/0x1b0
      [  197.080982]  ? selinux_capable+0x20/0x20
      [  197.080991]  ? __do_page_fault+0x7b7/0x9a0
      [  197.080997]  ? lock_downgrade+0x5bb/0x610
      [  197.081007]  ? security_file_ioctl+0x57/0x90
      [  197.081016]  SyS_ioctl+0x4e/0x80
      [  197.081024]  entry_SYSCALL_64_fastpath+0x18/0xad
      [  197.081030] RIP: 0033:0x7f61f287a987
      [  197.081035] RSP: 002b:00007fff7d44d188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [  197.081043] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f61f287a987
      [  197.081048] RDX: 00007fff7d44d1c0 RSI: 00000000c01864ba RDI: 0000000000000003
      [  197.081053] RBP: 00007f61f2b3eb00 R08: 0000000000000059 R09: 0000000000000000
      [  197.081058] R10: 0000002ea5c4a290 R11: 0000000000000246 R12: 00007f61f2b3eb58
      [  197.081063] R13: 0000000000001010 R14: 00007f61f2b3eb58 R15: 0000000000002702
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101659Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: default avatarMartin Peres <martin.peres@linux.intel.com>
      Cc: Martin Peres <martin.peres@linux.intel.com>
      Fixes: 82cf435b ("drm/i915: Implement color management on bdw/skl/bxt/kbl")
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Kiran S Kumar <kiran.s.kumar@intel.com>
      Cc: Kausal Malladi <kausalmalladi@gmail.com>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Link: https://patchwork.freedesktop.org/patch/msgid/20170724091431.24251-1-maarten.lankhorst@linux.intel.comReviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      (cherry picked from commit 09a92bc8)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b3bf207
    • Wladimir J. van der Laan's avatar
      drm/etnaviv: Fix off-by-one error in reloc checking · 4381e2c3
      Wladimir J. van der Laan authored
      commit d6f756e0 upstream.
      
      A relocation pointing to the last four bytes of a buffer can
      legitimately happen in the case of small vertex buffers.
      Signed-off-by: default avatarWladimir J. van der Laan <laanwj@gmail.com>
      Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Reviewed-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4381e2c3
    • Weston Andros Adamson's avatar
      nfs/flexfiles: fix leak of nfs4_ff_ds_version arrays · 00f3c2a2
      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>
      00f3c2a2
    • Haibo Chen's avatar
      mmc: mmc: correct the logic for setting HS400ES signal voltage · 0a205d81
      Haibo Chen authored
      commit 92ddd959 upstream.
      
      Change the default err value to -EINVAL, make sure the card only
      has type EXT_CSD_CARD_TYPE_HS400_1_8V also do the signal voltage
      setting when select hs400es mode.
      
      Fixes: commit 1720d354 ("mmc: core: switch to 1V8 or 1V2 for hs400es mode")
      Signed-off-by: default avatarHaibo Chen <haibo.chen@nxp.com>
      Reviewed-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a205d81
    • Miquel Raynal's avatar
      nand: fix wrong default oob layout for small pages using soft ecc · 160c365b
      Miquel Raynal authored
      commit f7f8c175 upstream.
      
      When using soft ecc, if no ooblayout is given, the core automatically
      uses one of the nand_ooblayout_{sp,lp}*() functions to determine the
      layout inside the out of band data.
      
      Until kernel version 4.6, struct nand_ecclayout was used for that
      purpose. During the migration from 4.6 to 4.7, an error shown up in the
      small page layout, in the case oob section is only 8 bytes long.
      
      The layout was using three bytes (0, 1, 2) for ecc, two bytes (3, 4)
      as free bytes, one byte (5) for bad block marker and finally
      two bytes (6, 7) as free bytes, as shown there:
      
      [linux-4.6] drivers/mtd/nand/nand_base.c:52
      static struct nand_ecclayout nand_oob_8 = {
      	.eccbytes = 3,
      	.eccpos = {0, 1, 2},
      	.oobfree = {
      		{.offset = 3,
      		 .length = 2},
      		{.offset = 6,
      		 .length = 2} }
      };
      
      This fixes the current implementation which is incoherent. It
      references bit 3 at the same time as an ecc byte and a free byte.
      
      Furthermore, it is clear with the previous implementation that there
      is only one ecc section with 8 bytes oob sections. We shall return
      -ERANGE in the nand_ooblayout_ecc_sp() function when asked for the
      second section.
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@free-electrons.com>
      Fixes: 41b207a7 ("mtd: nand: implement the default mtd_ooblayout_ops")
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      160c365b
    • Mateusz Jurczyk's avatar
      fuse: initialize the flock flag in fuse_file on allocation · 227559e6
      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>
      227559e6
    • Nicholas Bellinger's avatar
      target: Fix node_acl demo-mode + uncached dynamic shutdown regression · 1da30c23
      Nicholas Bellinger authored
      commit 6f48655f upstream.
      
      This patch fixes a generate_node_acls = 1 + cache_dynamic_acls = 0
      regression, that was introduced by
      
        commit 01d4d673
        Author: Nicholas Bellinger <nab@linux-iscsi.org>
        Date:   Wed Dec 7 12:55:54 2016 -0800
      
      which originally had the proper list_del_init() usage, but was
      dropped during list review as it was thought unnecessary by HCH.
      
      However, list_del_init() usage is required during the special
      generate_node_acls = 1 + cache_dynamic_acls = 0 case when
      transport_free_session() does a list_del(&se_nacl->acl_list),
      followed by target_complete_nacl() doing the same thing.
      
      This was manifesting as a general protection fault as reported
      by Justin:
      
      kernel: general protection fault: 0000 [#1] SMP
      kernel: Modules linked in:
      kernel: CPU: 0 PID: 11047 Comm: iscsi_ttx Not tainted 4.13.0-rc2.x86_64.1+ #20
      kernel: Hardware name: Intel Corporation S5500BC/S5500BC, BIOS S5500.86B.01.00.0064.050520141428 05/05/2014
      kernel: task: ffff88026939e800 task.stack: ffffc90007884000
      kernel: RIP: 0010:target_put_nacl+0x49/0xb0
      kernel: RSP: 0018:ffffc90007887d70 EFLAGS: 00010246
      kernel: RAX: dead000000000200 RBX: ffff8802556ca000 RCX: 0000000000000000
      kernel: RDX: dead000000000100 RSI: 0000000000000246 RDI: ffff8802556ce028
      kernel: RBP: ffffc90007887d88 R08: 0000000000000001 R09: 0000000000000000
      kernel: R10: ffffc90007887df8 R11: ffffea0009986900 R12: ffff8802556ce020
      kernel: R13: ffff8802556ce028 R14: ffff8802556ce028 R15: ffffffff88d85540
      kernel: FS:  0000000000000000(0000) GS:ffff88027fc00000(0000) knlGS:0000000000000000
      kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      kernel: CR2: 00007fffe36f5f94 CR3: 0000000009209000 CR4: 00000000003406f0
      kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      kernel: Call Trace:
      kernel:  transport_free_session+0x67/0x140
      kernel:  transport_deregister_session+0x7a/0xc0
      kernel:  iscsit_close_session+0x92/0x210
      kernel:  iscsit_close_connection+0x5f9/0x840
      kernel:  iscsit_take_action_for_connection_exit+0xfe/0x110
      kernel:  iscsi_target_tx_thread+0x140/0x1e0
      kernel:  ? wait_woken+0x90/0x90
      kernel:  kthread+0x124/0x160
      kernel:  ? iscsit_thread_get_cpumask+0x90/0x90
      kernel:  ? kthread_create_on_node+0x40/0x40
      kernel:  ret_from_fork+0x22/0x30
      kernel: Code: 00 48 89 fb 4c 8b a7 48 01 00 00 74 68 4d 8d 6c 24 08 4c
      89 ef e8 e8 28 43 00 48 8b 93 20 04 00 00 48 8b 83 28 04 00 00 4c 89
      ef <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 20
      kernel: RIP: target_put_nacl+0x49/0xb0 RSP: ffffc90007887d70
      kernel: ---[ end trace f12821adbfd46fed ]---
      
      To address this, go ahead and use proper list_del_list() for all
      cases of se_nacl->acl_list deletion.
      Reported-by: default avatarJustin Maggard <jmaggard01@gmail.com>
      Tested-by: default avatarJustin Maggard <jmaggard01@gmail.com>
      Cc: Justin Maggard <jmaggard01@gmail.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1da30c23
    • Nicholas Bellinger's avatar
      iscsi-target: Fix iscsi_np reset hung task during parallel delete · b51a7163
      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>
      b51a7163
    • Varun Prakash's avatar
      iscsi-target: fix memory leak in iscsit_setup_text_cmd() · e6a0599b
      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>
      e6a0599b
    • Boris Brezillon's avatar
      mtd: nand: Fix timing setup for NANDs that do not support SET FEATURES · ced271b8
      Boris Brezillon authored
      commit a11bf5ed upstream.
      
      Some ONFI NANDs do not support the SET/GET FEATURES commands, which,
      according to the spec, is perfectly valid.
      
      On these NANDs we can't set a specific timing mode using the "timing
      mode" feature, and we should assume the NAND does not require any setup
      to enter a specific timing mode.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Fixes: d8e725dd ("mtd: nand: automate NAND timings selection")
      Reported-by: default avatarAlexander Dahl <ada@thorsis.com>
      Tested-by: default avatarAlexander Dahl <ada@thorsis.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ced271b8
    • Max Filippov's avatar
      xtensa: don't limit csum_partial export by CONFIG_NET · a3118109
      Max Filippov authored
      commit 7f81e55c upstream.
      
      csum_partial and csum_partial_copy_generic are defined unconditionally
      and are available even when CONFIG_NET is disabled. They are used not
      only by the network drivers, but also by scsi and media.
      Don't limit these functions export by CONFIG_NET.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3118109
    • Max Filippov's avatar
      xtensa: mm/cache: add missing EXPORT_SYMBOLs · a3ab0f06
      Max Filippov authored
      commit bc652eb6 upstream.
      
      Functions clear_user_highpage, copy_user_highpage, flush_dcache_page,
      local_flush_cache_range and local_flush_cache_page may be used from
      modules. Export them.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3ab0f06
    • Max Filippov's avatar
      xtensa: fix cache aliasing handling code for WT cache · 03973c57
      Max Filippov authored
      commit 6d0f581d upstream.
      
      Currently building kernel for xtensa core with aliasing WT cache fails
      with the following messages:
      
        mm/memory.c:2152: undefined reference to `flush_dcache_page'
        mm/memory.c:2332: undefined reference to `local_flush_cache_page'
        mm/memory.c:1919: undefined reference to `local_flush_cache_range'
        mm/memory.c:4179: undefined reference to `copy_to_user_page'
        mm/memory.c:4183: undefined reference to `copy_from_user_page'
      
      This happens because implementation of these functions is only compiled
      when data cache is WB, which looks wrong: even when data cache doesn't
      need flushing it still needs invalidation. The functions like
      __flush_[invalidate_]dcache_* are correctly defined for both WB and WT
      caches (and even if they weren't that'd still be ok, just slower).
      
      Fix this by providing the same implementation of the above functions for
      both WB and WT cache.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03973c57
    • Mel Gorman's avatar
      futex: Remove unnecessary warning from get_futex_key · 0041042d
      Mel Gorman authored
      commit 48fb6f4d upstream.
      
      Commit 65d8fc77 ("futex: Remove requirement for lock_page() in
      get_futex_key()") removed an unnecessary lock_page() with the
      side-effect that page->mapping needed to be treated very carefully.
      
      Two defensive warnings were added in case any assumption was missed and
      the first warning assumed a correct application would not alter a
      mapping backing a futex key.  Since merging, it has not triggered for
      any unexpected case but Mark Rutland reported the following bug
      triggering due to the first warning.
      
        kernel BUG at kernel/futex.c:679!
        Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 3695 Comm: syz-executor1 Not tainted 4.13.0-rc3-00020-g307fec773ba3 #3
        Hardware name: linux,dummy-virt (DT)
        task: ffff80001e271780 task.stack: ffff000010908000
        PC is at get_futex_key+0x6a4/0xcf0 kernel/futex.c:679
        LR is at get_futex_key+0x6a4/0xcf0 kernel/futex.c:679
        pc : [<ffff00000821ac14>] lr : [<ffff00000821ac14>] pstate: 80000145
      
      The fact that it's a bug instead of a warning was due to an unrelated
      arm64 problem, but the warning itself triggered because the underlying
      mapping changed.
      
      This is an application issue but from a kernel perspective it's a
      recoverable situation and the warning is unnecessary so this patch
      removes the warning.  The warning may potentially be triggered with the
      following test program from Mark although it may be necessary to adjust
      NR_FUTEX_THREADS to be a value smaller than the number of CPUs in the
      system.
      
          #include <linux/futex.h>
          #include <pthread.h>
          #include <stdio.h>
          #include <stdlib.h>
          #include <sys/mman.h>
          #include <sys/syscall.h>
          #include <sys/time.h>
          #include <unistd.h>
      
          #define NR_FUTEX_THREADS 16
          pthread_t threads[NR_FUTEX_THREADS];
      
          void *mem;
      
          #define MEM_PROT  (PROT_READ | PROT_WRITE)
          #define MEM_SIZE  65536
      
          static int futex_wrapper(int *uaddr, int op, int val,
                                   const struct timespec *timeout,
                                   int *uaddr2, int val3)
          {
              syscall(SYS_futex, uaddr, op, val, timeout, uaddr2, val3);
          }
      
          void *poll_futex(void *unused)
          {
              for (;;) {
                  futex_wrapper(mem, FUTEX_CMP_REQUEUE_PI, 1, NULL, mem + 4, 1);
              }
          }
      
          int main(int argc, char *argv[])
          {
              int i;
      
              mem = mmap(NULL, MEM_SIZE, MEM_PROT,
                     MAP_SHARED | MAP_ANONYMOUS, -1, 0);
      
              printf("Mapping @ %p\n", mem);
      
              printf("Creating futex threads...\n");
      
              for (i = 0; i < NR_FUTEX_THREADS; i++)
                  pthread_create(&threads[i], NULL, poll_futex, NULL);
      
              printf("Flipping mapping...\n");
              for (;;) {
                  mmap(mem, MEM_SIZE, MEM_PROT,
                       MAP_FIXED | MAP_SHARED | MAP_ANONYMOUS, -1, 0);
              }
      
              return 0;
          }
      Reported-and-tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0041042d
    • Cong Wang's avatar
      mm: fix list corruptions on shmem shrinklist · e2286916
      Cong Wang authored
      commit d041353d upstream.
      
      We saw many list corruption warnings on shmem shrinklist:
      
        WARNING: CPU: 18 PID: 177 at lib/list_debug.c:59 __list_del_entry+0x9e/0xc0
        list_del corruption. prev->next should be ffff9ae5694b82d8, but was ffff9ae5699ba960
        Modules linked in: intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp iTCO_wdt iTCO_vendor_support crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid0 dcdbas shpchp wmi hed i2c_i801 ioatdma lpc_ich i2c_smbus acpi_cpufreq tcp_diag inet_diag sch_fq_codel ipmi_si ipmi_devintf ipmi_msghandler igb ptp crc32c_intel pps_core i2c_algo_bit i2c_core dca ipv6 crc_ccitt
        CPU: 18 PID: 177 Comm: kswapd1 Not tainted 4.9.34-t3.el7.twitter.x86_64 #1
        Hardware name: Dell Inc. PowerEdge C6220/0W6W6G, BIOS 2.2.3 11/07/2013
        Call Trace:
          dump_stack+0x4d/0x66
          __warn+0xcb/0xf0
          warn_slowpath_fmt+0x4f/0x60
          __list_del_entry+0x9e/0xc0
          shmem_unused_huge_shrink+0xfa/0x2e0
          shmem_unused_huge_scan+0x20/0x30
          super_cache_scan+0x193/0x1a0
          shrink_slab.part.41+0x1e3/0x3f0
          shrink_slab+0x29/0x30
          shrink_node+0xf9/0x2f0
          kswapd+0x2d8/0x6c0
          kthread+0xd7/0xf0
          ret_from_fork+0x22/0x30
      
        WARNING: CPU: 23 PID: 639 at lib/list_debug.c:33 __list_add+0x89/0xb0
        list_add corruption. prev->next should be next (ffff9ae5699ba960), but was ffff9ae5694b82d8. (prev=ffff9ae5694b82d8).
        Modules linked in: intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp iTCO_wdt iTCO_vendor_support crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid0 dcdbas shpchp wmi hed i2c_i801 ioatdma lpc_ich i2c_smbus acpi_cpufreq tcp_diag inet_diag sch_fq_codel ipmi_si ipmi_devintf ipmi_msghandler igb ptp crc32c_intel pps_core i2c_algo_bit i2c_core dca ipv6 crc_ccitt
        CPU: 23 PID: 639 Comm: systemd-udevd Tainted: G        W       4.9.34-t3.el7.twitter.x86_64 #1
        Hardware name: Dell Inc. PowerEdge C6220/0W6W6G, BIOS 2.2.3 11/07/2013
        Call Trace:
          dump_stack+0x4d/0x66
          __warn+0xcb/0xf0
          warn_slowpath_fmt+0x4f/0x60
          __list_add+0x89/0xb0
          shmem_setattr+0x204/0x230
          notify_change+0x2ef/0x440
          do_truncate+0x5d/0x90
          path_openat+0x331/0x1190
          do_filp_open+0x7e/0xe0
          do_sys_open+0x123/0x200
          SyS_open+0x1e/0x20
          do_syscall_64+0x61/0x170
          entry_SYSCALL64_slow_path+0x25/0x25
      
      The problem is that shmem_unused_huge_shrink() moves entries from the
      global sbinfo->shrinklist to its local lists and then releases the
      spinlock.  However, a parallel shmem_setattr() could access one of these
      entries directly and add it back to the global shrinklist if it is
      removed, with the spinlock held.
      
      The logic itself looks solid since an entry could be either in a local
      list or the global list, otherwise it is removed from one of them by
      list_del_init().  So probably the race condition is that, one CPU is in
      the middle of INIT_LIST_HEAD() but the other CPU calls list_empty()
      which returns true too early then the following list_add_tail() sees a
      corrupted entry.
      
      list_empty_careful() is designed to fix this situation.
      
      [akpm@linux-foundation.org: add comments]
      Link: http://lkml.kernel.org/r/20170803054630.18775-1-xiyou.wangcong@gmail.com
      Fixes: 779750d2 ("shmem: split huge pages beyond i_size under memory pressure")
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.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>
      e2286916
    • Jonathan Toppins's avatar
      mm: ratelimit PFNs busy info message · b56cd77c
      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>
      b56cd77c
  2. 13 Aug, 2017 8 commits