1. 14 Jun, 2017 40 commits
    • Matt Ranostay's avatar
      iio: proximity: as3935: fix iio_trigger_poll issue · 698aa720
      Matt Ranostay authored
      commit 9122b54f upstream.
      
      Using iio_trigger_poll() can oops when multiple interrupts
      happen before the first is handled.
      
      Use iio_trigger_poll_chained() instead and use the timestamp
      when processed, since it will be in theory be 2 ms max latency.
      
      Fixes: 24ddb0e4 ("iio: Add AS3935 lightning sensor support")
      Signed-off-by: default avatarMatt Ranostay <matt.ranostay@konsulko.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      698aa720
    • Matt Ranostay's avatar
      iio: proximity: as3935: fix AS3935_INT mask · 71c0950c
      Matt Ranostay authored
      commit 275292d3 upstream.
      
      AS3935 interrupt mask has been incorrect so valid lightning events
      would never trigger an buffer event. Also noise interrupt should be
      BIT(0).
      
      Fixes: 24ddb0e4 ("iio: Add AS3935 lightning sensor support")
      Signed-off-by: default avatarMatt Ranostay <matt.ranostay@konsulko.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71c0950c
    • Marcin Niestroj's avatar
      iio: trigger: fix NULL pointer dereference in iio_trigger_write_current() · 7b5d3c1a
      Marcin Niestroj authored
      commit 4eecbe81 upstream.
      
      In case oldtrig == trig == NULL (which happens when we set none
      trigger, when there is already none set) there is a NULL pointer
      dereference during iio_trigger_put(trig). Below is kernel output when
      this occurs:
      
      [   26.741790] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [   26.750179] pgd = cacc0000
      [   26.752936] [00000000] *pgd=8adc6835, *pte=00000000, *ppte=00000000
      [   26.759531] Internal error: Oops: 17 [#1] SMP ARM
      [   26.764261] Modules linked in: usb_f_ncm u_ether usb_f_acm u_serial usb_f_fs libcomposite configfs evbug
      [   26.773844] CPU: 0 PID: 152 Comm: synchro Not tainted 4.12.0-rc1 #2
      [   26.780128] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
      [   26.786329] task: cb1de200 task.stack: cac92000
      [   26.790892] PC is at iio_trigger_write_current+0x188/0x1f4
      [   26.796403] LR is at lock_release+0xf8/0x20c
      [   26.800696] pc : [<c0736f34>]    lr : [<c016efb0>]    psr: 600d0013
      [   26.800696] sp : cac93e30  ip : cac93db0  fp : cac93e5c
      [   26.812193] r10: c0e64fe8  r9 : 00000000  r8 : 00000001
      [   26.817436] r7 : cb190810  r6 : 00000010  r5 : 00000001  r4 : 00000000
      [   26.823982] r3 : 00000000  r2 : 00000000  r1 : cb1de200  r0 : 00000000
      [   26.830528] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [   26.837683] Control: 10c5387d  Table: 8acc006a  DAC: 00000051
      [   26.843448] Process synchro (pid: 152, stack limit = 0xcac92210)
      [   26.849475] Stack: (0xcac93e30 to 0xcac94000)
      [   26.853857] 3e20:                                     00000001 c0736dac c054033c cae6b680
      [   26.862060] 3e40: cae6b680 00000000 00000001 cb3f8610 cac93e74 cac93e60 c054035c c0736db8
      [   26.870264] 3e60: 00000001 c054033c cac93e94 cac93e78 c029bf34 c0540348 00000000 00000000
      [   26.878469] 3e80: cb3f8600 cae6b680 cac93ed4 cac93e98 c029b320 c029bef0 00000000 00000000
      [   26.886672] 3ea0: 00000000 cac93f78 cb2d41fc caed3280 c029b214 cac93f78 00000001 000e20f8
      [   26.894874] 3ec0: 00000001 00000000 cac93f44 cac93ed8 c0221dcc c029b220 c0e1ca39 cb2d41fc
      [   26.903079] 3ee0: cac93f04 cac93ef0 c0183ef0 c0183ab0 cb2d41fc 00000000 cac93f44 cac93f08
      [   26.911282] 3f00: c0225eec c0183ebc 00000001 00000000 c0223728 00000000 c0245454 00000001
      [   26.919485] 3f20: 00000001 caed3280 000e20f8 cac93f78 000e20f8 00000001 cac93f74 cac93f48
      [   26.927690] 3f40: c0223680 c0221da4 c0246520 c0245460 caed3283 caed3280 00000000 00000000
      [   26.935893] 3f60: 000e20f8 00000001 cac93fa4 cac93f78 c0224520 c02235e4 00000000 00000000
      [   26.944096] 3f80: 00000001 000e20f8 00000001 00000004 c0107f84 cac92000 00000000 cac93fa8
      [   26.952299] 3fa0: c0107de0 c02244e8 00000001 000e20f8 0000000e 000e20f8 00000001 fbad2484
      [   26.960502] 3fc0: 00000001 000e20f8 00000001 00000004 beb6b698 00064260 0006421c beb6b4b4
      [   26.968705] 3fe0: 00000000 beb6b450 b6f219a0 b6e2f268 800d0010 0000000e cac93ff4 cac93ffc
      [   26.976896] Backtrace:
      [   26.979388] [<c0736dac>] (iio_trigger_write_current) from [<c054035c>] (dev_attr_store+0x20/0x2c)
      [   26.988289]  r10:cb3f8610 r9:00000001 r8:00000000 r7:cae6b680 r6:cae6b680 r5:c054033c
      [   26.996138]  r4:c0736dac r3:00000001
      [   26.999747] [<c054033c>] (dev_attr_store) from [<c029bf34>] (sysfs_kf_write+0x50/0x54)
      [   27.007686]  r5:c054033c r4:00000001
      [   27.011290] [<c029bee4>] (sysfs_kf_write) from [<c029b320>] (kernfs_fop_write+0x10c/0x224)
      [   27.019579]  r7:cae6b680 r6:cb3f8600 r5:00000000 r4:00000000
      [   27.025271] [<c029b214>] (kernfs_fop_write) from [<c0221dcc>] (__vfs_write+0x34/0x120)
      [   27.033214]  r10:00000000 r9:00000001 r8:000e20f8 r7:00000001 r6:cac93f78 r5:c029b214
      [   27.041059]  r4:caed3280
      [   27.043622] [<c0221d98>] (__vfs_write) from [<c0223680>] (vfs_write+0xa8/0x170)
      [   27.050959]  r9:00000001 r8:000e20f8 r7:cac93f78 r6:000e20f8 r5:caed3280 r4:00000001
      [   27.058731] [<c02235d8>] (vfs_write) from [<c0224520>] (SyS_write+0x44/0x98)
      [   27.065806]  r9:00000001 r8:000e20f8 r7:00000000 r6:00000000 r5:caed3280 r4:caed3283
      [   27.073582] [<c02244dc>] (SyS_write) from [<c0107de0>] (ret_fast_syscall+0x0/0x1c)
      [   27.081179]  r9:cac92000 r8:c0107f84 r7:00000004 r6:00000001 r5:000e20f8 r4:00000001
      [   27.088947] Code: 1a000009 e1a04009 e3a06010 e1a05008 (e5943000)
      [   27.095244] ---[ end trace 06d1dab86d6e6bab ]---
      
      To fix that problem call iio_trigger_put(trig) only when trig is not
      NULL.
      
      Fixes: d5d24bcc ("iio: trigger: close race condition in acquiring trigger reference")
      Signed-off-by: default avatarMarcin Niestroj <m.niestroj@grinn-global.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b5d3c1a
    • Franziska Naepelt's avatar
      iio: light: ltr501 Fix interchanged als/ps register field · 80c8ac6b
      Franziska Naepelt authored
      commit 7cc3bff4 upstream.
      
      The register mapping for the IIO driver for the Liteon Light and Proximity
      sensor LTR501 interrupt mode is interchanged (ALS/PS).
      There is a register called INTERRUPT register (address 0x8F)
      Bit 0 represents PS measurement trigger.
      Bit 1 represents ALS measurement trigger.
      This two bit fields are interchanged within the driver.
      see datasheet page 24:
      http://optoelectronics.liteon.com/upload/download/DS86-2012-0006/S_110_LTR-501ALS-01_PrelimDS_ver1%5B1%5D.pdfSigned-off-by: default avatarFranziska Naepelt <franziska.naepelt@idt.com>
      Fixes: 7ac702b3 ("iio: ltr501: Add interrupt support")
      Acked-by: default avatarPeter Meerwald-Stadler <pmeerw@pmeerw.net>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c8ac6b
    • Raveendra Padasalagi's avatar
      iio: adc: bcm_iproc_adc: swap primary and secondary isr handler's · 1cb7bbe7
      Raveendra Padasalagi authored
      commit f7d86ecf upstream.
      
      The third argument of devm_request_threaded_irq() is the primary
      handler. It is called in hardirq context and checks whether the
      interrupt is relevant to the device. If the primary handler returns
      IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is
      scheduled to run in process context.
      
      bcm_iproc_adc.c uses the secondary handler as the primary one
      and the other way around. So this patch fixes the same, along with
      re-naming the secondary handler and primary handler names properly.
      
      Tested on the BCM9583XX iProc SoC based boards.
      
      Fixes: 4324c97e ("iio: Add driver for Broadcom iproc-static-adc")
      Reported-by: default avatarPavel Roskin <plroskin@gmail.com>
      Signed-off-by: default avatarRaveendra Padasalagi <raveendra.padasalagi@broadcom.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cb7bbe7
    • Oleg Drokin's avatar
      staging/lustre/lov: remove set_fs() call from lov_getstripe() · d9b0c955
      Oleg Drokin authored
      commit 0a33252e upstream.
      
      lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
      lov_user_md pointer from user- or kernel-space.  This changes the
      behavior of copy_from_user() on SPARC and may result in a misaligned
      access exception which in turn oopses the kernel.  In fact the
      relevant argument to lov_getstripe() is never called with a
      kernel-space pointer and so changing the address limits is unnecessary
      and so we remove the calls to save, set, and restore the address
      limits.
      Signed-off-by: default avatarJohn L. Hammond <john.hammond@intel.com>
      Reviewed-on: http://review.whamcloud.com/6150
      Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221Reviewed-by: default avatarAndreas Dilger <andreas.dilger@intel.com>
      Reviewed-by: default avatarLi Wei <wei.g.li@intel.com>
      Signed-off-by: default avatarOleg Drokin <green@linuxhacker.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9b0c955
    • Michael Thalmeier's avatar
      usb: chipidea: debug: check before accessing ci_role · dd8980bb
      Michael Thalmeier authored
      commit 0340ff83 upstream.
      
      ci_role BUGs when the role is >= CI_ROLE_END.
      Signed-off-by: default avatarMichael Thalmeier <michael.thalmeier@hale.at>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd8980bb
    • Jisheng Zhang's avatar
      usb: chipidea: udc: fix NULL pointer dereference if udc_start failed · f2967b72
      Jisheng Zhang authored
      commit aa1f058d upstream.
      
      Fix below NULL pointer dereference. we set ci->roles[CI_ROLE_GADGET]
      too early in ci_hdrc_gadget_init(), if udc_start() fails due to some
      reason, the ci->roles[CI_ROLE_GADGET] check in  ci_hdrc_gadget_destroy
      can't protect us.
      
      We fix this issue by only setting ci->roles[CI_ROLE_GADGET] if
      udc_start() succeed.
      
      [    1.398550] Unable to handle kernel NULL pointer dereference at
      virtual address 00000000
      ...
      [    1.448600] PC is at dma_pool_free+0xb8/0xf0
      [    1.453012] LR is at dma_pool_free+0x28/0xf0
      [    2.113369] [<ffffff80081817d8>] dma_pool_free+0xb8/0xf0
      [    2.118857] [<ffffff800841209c>] destroy_eps+0x4c/0x68
      [    2.124165] [<ffffff8008413770>] ci_hdrc_gadget_destroy+0x28/0x50
      [    2.130461] [<ffffff800840fa30>] ci_hdrc_probe+0x588/0x7e8
      [    2.136129] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
      [    2.142066] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
      [    2.148270] [<ffffff800837f68c>] __device_attach_driver+0x9c/0xf8
      [    2.154563] [<ffffff800837d570>] bus_for_each_drv+0x58/0x98
      [    2.160317] [<ffffff800837f174>] __device_attach+0xc4/0x138
      [    2.166072] [<ffffff800837f738>] device_initial_probe+0x10/0x18
      [    2.172185] [<ffffff800837e58c>] bus_probe_device+0x94/0xa0
      [    2.177940] [<ffffff800837c560>] device_add+0x3f0/0x560
      [    2.183337] [<ffffff8008380d20>] platform_device_add+0x180/0x240
      [    2.189541] [<ffffff800840f0e8>] ci_hdrc_add_device+0x440/0x4f8
      [    2.195654] [<ffffff8008414194>] ci_hdrc_usb2_probe+0x13c/0x2d8
      [    2.201769] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
      [    2.207705] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
      [    2.213910] [<ffffff800837f5ec>] __driver_attach+0xac/0xb0
      [    2.219575] [<ffffff800837d4b0>] bus_for_each_dev+0x60/0xa0
      [    2.225329] [<ffffff800837ec80>] driver_attach+0x20/0x28
      [    2.230816] [<ffffff800837e880>] bus_add_driver+0x1d0/0x238
      [    2.236571] [<ffffff800837fdb0>] driver_register+0x60/0xf8
      [    2.242237] [<ffffff8008380ef4>] __platform_driver_register+0x44/0x50
      [    2.248891] [<ffffff80086fd440>] ci_hdrc_usb2_driver_init+0x18/0x20
      [    2.255365] [<ffffff8008082950>] do_one_initcall+0x38/0x128
      [    2.261121] [<ffffff80086e0d00>] kernel_init_freeable+0x1ac/0x250
      [    2.267414] [<ffffff800852f0b8>] kernel_init+0x10/0x100
      [    2.272810] [<ffffff8008082680>] ret_from_fork+0x10/0x50
      
      Fixes: 3f124d23 ("usb: chipidea: add role init and destroy APIs")
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2967b72
    • Andrey Smirnov's avatar
      usb: chipidea: imx: Do not access CLKONOFF on i.MX51 · f26ac1fc
      Andrey Smirnov authored
      commit 62b97d50 upstream.
      
      Unlike i.MX53, i.MX51's USBOH3 register file does not implemenent
      registers past offset 0x018, which includes
      MX53_USB_CLKONOFF_CTRL_OFFSET and trying to access that register on
      said platform results in external abort.
      
      Fix it by enabling CLKONOFF accessing codepath only for i.MX53.
      
      Fixes 3be3251d ("usb: chipidea: imx: Disable internal 60Mhz clock with ULPI PHY")
      Cc: cphealy@gmail.com
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-usb@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f26ac1fc
    • Bin Liu's avatar
      usb: musb: dsps: keep VBUS on for host-only mode · b89de040
      Bin Liu authored
      commit b3addcf0 upstream.
      
      Currently VBUS is turned off while a usb device is detached, and turned
      on again by the polling routine. This short period VBUS loss prevents
      usb modem to switch mode.
      
      VBUS should be constantly on for host-only mode, so this changes the
      driver to not turn off VBUS for host-only mode.
      
      Fixes: 2f3fd2c5 ("usb: musb: Prepare dsps glue layer for PM runtime support")
      Reported-by: default avatarMoreno Bartalucci <moreno.bartalucci@tecnorama.it>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b89de040
    • Thinh Nguyen's avatar
      usb: gadget: f_mass_storage: Serialize wake and sleep execution · c33b087c
      Thinh Nguyen authored
      commit dc9217b6 upstream.
      
      f_mass_storage has a memorry barrier issue with the sleep and wake
      functions that can cause a deadlock. This results in intermittent hangs
      during MSC file transfer. The host will reset the device after receiving
      no response to resume the transfer. This issue is seen when dwc3 is
      processing 2 transfer-in-progress events at the same time, invoking
      completion handlers for CSW and CBW. Also this issue occurs depending on
      the system timing and latency.
      
      To increase the chance to hit this issue, you can force dwc3 driver to
      wait and process those 2 events at once by adding a small delay (~100us)
      in dwc3_check_event_buf() whenever the request is for CSW and read the
      event count again. Avoid debugging with printk and ftrace as extra
      delays and memory barrier will mask this issue.
      
      Scenario which can lead to failure:
      -----------------------------------
      1) The main thread sleeps and waits for the next command in
         get_next_command().
      2) bulk_in_complete() wakes up main thread for CSW.
      3) bulk_out_complete() tries to wake up the running main thread for CBW.
      4) thread_wakeup_needed is not loaded with correct value in
         sleep_thread().
      5) Main thread goes to sleep again.
      
      The pattern is shown below. Note the 2 critical variables.
       * common->thread_wakeup_needed
       * bh->state
      
      	CPU 0 (sleep_thread)		CPU 1 (wakeup_thread)
      	==============================  ===============================
      
      					bh->state = BH_STATE_FULL;
      					smp_wmb();
      	thread_wakeup_needed = 0;	thread_wakeup_needed = 1;
      	smp_rmb();
      	if (bh->state != BH_STATE_FULL)
      		sleep again ...
      
      As pointed out by Alan Stern, this is an R-pattern issue. The issue can
      be seen when there are two wakeups in quick succession. The
      thread_wakeup_needed can be overwritten in sleep_thread, and the read of
      the bh->state maybe reordered before the write to thread_wakeup_needed.
      
      This patch applies full memory barrier smp_mb() in both sleep_thread()
      and wakeup_thread() to ensure the order which the thread_wakeup_needed
      and bh->state are written and loaded.
      
      However, a better solution in the future would be to use wait_queue
      method that takes care of managing memory barrier between waker and
      waiter.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c33b087c
    • Hans de Goede's avatar
      drm: Fix oops + Xserver hang when unplugging USB drm devices · 3d7ba52b
      Hans de Goede authored
      commit 75fb6363 upstream.
      
      commit a39be606 ("drm: Do a full device unregister when unplugging")
      causes backtraces like this one when unplugging an usb drm device while
      it is in use:
      
      usb 2-3: USB disconnect, device number 25
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:424
         drm_mode_config_cleanup+0x220/0x280 [drm]
      ...
      RIP: 0010:drm_mode_config_cleanup+0x220/0x280 [drm]
      ...
      Call Trace:
       gm12u320_modeset_cleanup+0xe/0x10 [gm12u320]
       gm12u320_driver_unload+0x35/0x70 [gm12u320]
       drm_dev_unregister+0x3c/0xe0 [drm]
       drm_unplug_dev+0x12/0x60 [drm]
       gm12u320_usb_disconnect+0x36/0x40 [gm12u320]
       usb_unbind_interface+0x72/0x280
       device_release_driver_internal+0x158/0x210
       device_release_driver+0x12/0x20
       bus_remove_device+0x104/0x180
       device_del+0x1d2/0x350
       usb_disable_device+0x9f/0x270
       usb_disconnect+0xc6/0x260
      ...
      [drm:drm_mode_config_cleanup [drm]] *ERROR* connector Unknown-1 leaked!
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:458
         drm_mode_config_cleanup+0x268/0x280 [drm]
      ...
      <same Call Trace>
      ---[ end trace 80df975dae439ed6 ]---
      general protection fault: 0000 [#1] SMP
      ...
      Call Trace:
       ? __switch_to+0x225/0x450
       drm_mode_rmfb_work_fn+0x55/0x70 [drm]
       process_one_work+0x193/0x3c0
       worker_thread+0x4a/0x3a0
      ...
      RIP: drm_framebuffer_remove+0x62/0x3f0 [drm] RSP: ffffb776c39dfd98
      ---[ end trace 80df975dae439ed7 ]---
      
      After which the system is unusable this is caused by drm_dev_unregister
      getting called immediately on unplug, which calls the drivers unload
      function which calls drm_mode_config_cleanup which removes the framebuffer
      object while userspace is still holding a reference to it.
      
      Reverting commit a39be606 ("drm: Do a full device unregister
      when unplugging") leads to the following oops on unplug instead,
      when userspace closes the last fd referencing the drm_dev:
      
      sysfs group 'power' not found for kobject 'card1-Unknown-1'
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 2459 at fs/sysfs/group.c:237
         sysfs_remove_group+0x80/0x90
      ...
      RIP: 0010:sysfs_remove_group+0x80/0x90
      ...
      Call Trace:
       dpm_sysfs_remove+0x57/0x60
       device_del+0xfd/0x350
       device_unregister+0x1a/0x60
       drm_sysfs_connector_remove+0x39/0x50 [drm]
       drm_connector_unregister+0x5a/0x70 [drm]
       drm_connector_unregister_all+0x45/0xa0 [drm]
       drm_modeset_unregister_all+0x12/0x30 [drm]
       drm_dev_unregister+0xca/0xe0 [drm]
       drm_put_dev+0x32/0x60 [drm]
       drm_release+0x2f3/0x380 [drm]
       __fput+0xdf/0x1e0
      ...
      ---[ end trace ecfb91ac85688bbe ]---
      BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
      IP: down_write+0x1f/0x40
      ...
      Call Trace:
       debugfs_remove_recursive+0x55/0x1b0
       drm_debugfs_connector_remove+0x21/0x40 [drm]
       drm_connector_unregister+0x62/0x70 [drm]
       drm_connector_unregister_all+0x45/0xa0 [drm]
       drm_modeset_unregister_all+0x12/0x30 [drm]
       drm_dev_unregister+0xca/0xe0 [drm]
       drm_put_dev+0x32/0x60 [drm]
       drm_release+0x2f3/0x380 [drm]
       __fput+0xdf/0x1e0
      ...
      ---[ end trace ecfb91ac85688bbf ]---
      
      This is caused by the revert moving back to drm_unplug_dev calling
      drm_minor_unregister which does:
      
              device_del(minor->kdev);
              dev_set_drvdata(minor->kdev, NULL); /* safety belt */
              drm_debugfs_cleanup(minor);
      
      Causing the sysfs entries to already be removed even though we still
      have references to them in e.g. drm_connector.
      
      Note we must call drm_minor_unregister to notify userspace of the unplug
      of the device, so calling drm_dev_unregister is not completely wrong the
      problem is that drm_dev_unregister does too much.
      
      This commit fixes drm_unplug_dev by not only reverting
      commit a39be606 ("drm: Do a full device unregister when unplugging")
      but by also adding a call to drm_modeset_unregister_all before the
      drm_minor_unregister calls to make sure all sysfs entries are removed
      before calling device_del(minor->kdev) thereby also fixing the second
      set of oopses caused by just reverting the commit.
      
      Fixes: a39be606 ("drm: Do a full device unregister when unplugging")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jeffy <jeffy.chen@rock-chips.com>
      Cc: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
      Reported-by: default avatarMarco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170601115430.4113-1-hdegoede@redhat.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d7ba52b
    • Jan Kara's avatar
      ext4: fix fdatasync(2) after extent manipulation operations · de8f4aea
      Jan Kara authored
      commit 67a7d5f5 upstream.
      
      Currently, extent manipulation operations such as hole punch, range
      zeroing, or extent shifting do not record the fact that file data has
      changed and thus fdatasync(2) has a work to do. As a result if we crash
      e.g. after a punch hole and fdatasync, user can still possibly see the
      punched out data after journal replay. Test generic/392 fails due to
      these problems.
      
      Fix the problem by properly marking that file data has changed in these
      operations.
      
      Fixes: a4bb6b64Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de8f4aea
    • Jan Kara's avatar
      ext4: fix data corruption with EXT4_GET_BLOCKS_ZERO · 875d084e
      Jan Kara authored
      commit 4f8caa60 upstream.
      
      When ext4_map_blocks() is called with EXT4_GET_BLOCKS_ZERO to zero-out
      allocated blocks and these blocks are actually converted from unwritten
      extent the following race can happen:
      
      CPU0					CPU1
      
      page fault				page fault
      ...					...
      ext4_map_blocks()
        ext4_ext_map_blocks()
          ext4_ext_handle_unwritten_extents()
            ext4_ext_convert_to_initialized()
      	- zero out converted extent
      	ext4_zeroout_es()
      	  - inserts extent as initialized in status tree
      
      					ext4_map_blocks()
      					  ext4_es_lookup_extent()
      					    - finds initialized extent
      					write data
        ext4_issue_zeroout()
          - zeroes out new extent overwriting data
      
      This problem can be reproduced by generic/340 for the fallocated case
      for the last block in the file.
      
      Fix the problem by avoiding zeroing out the area we are mapping with
      ext4_map_blocks() in ext4_ext_convert_to_initialized(). It is pointless
      to zero out this area in the first place as the caller asked us to
      convert the area to initialized because he is just going to write data
      there before the transaction finishes. To achieve this we delete the
      special case of zeroing out full extent as that will be handled by the
      cases below zeroing only the part of the extent that needs it. We also
      instruct ext4_split_extent() that the middle of extent being split
      contains data so that ext4_split_extent_at() cannot zero out full extent
      in case of ENOSPC.
      
      Fixes: 12735f88Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      875d084e
    • Konstantin Khlebnikov's avatar
      ext4: keep existing extra fields when inode expands · 22fb074c
      Konstantin Khlebnikov authored
      commit 887a9730 upstream.
      
      ext4_expand_extra_isize() should clear only space between old and new
      size.
      
      Fixes: 6dd4ee7c # v2.6.23
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22fb074c
    • Jan Kara's avatar
      ext4: fix SEEK_HOLE · 699dc108
      Jan Kara authored
      commit 7d95eddf upstream.
      
      Currently, SEEK_HOLE implementation in ext4 may both return that there's
      a hole at some offset although that offset already has data and skip
      some holes during a search for the next hole. The first problem is
      demostrated by:
      
      xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "seek -h 0" file
      wrote 57344/57344 bytes at offset 0
      56 KiB, 14 ops; 0.0000 sec (2.054 GiB/sec and 538461.5385 ops/sec)
      Whence	Result
      HOLE	0
      
      Where we can see that SEEK_HOLE wrongly returned offset 0 as containing
      a hole although we have written data there. The second problem can be
      demonstrated by:
      
      xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
             -c "seek -h 0" file
      
      wrote 57344/57344 bytes at offset 0
      56 KiB, 14 ops; 0.0000 sec (1.978 GiB/sec and 518518.5185 ops/sec)
      wrote 8192/8192 bytes at offset 131072
      8 KiB, 2 ops; 0.0000 sec (2 GiB/sec and 500000.0000 ops/sec)
      Whence	Result
      HOLE	139264
      
      Where we can see that hole at offsets 56k..128k has been ignored by the
      SEEK_HOLE call.
      
      The underlying problem is in the ext4_find_unwritten_pgoff() which is
      just buggy. In some cases it fails to update returned offset when it
      finds a hole (when no pages are found or when the first found page has
      higher index than expected), in some cases conditions for detecting hole
      are just missing (we fail to detect a situation where indices of
      returned pages are not contiguous).
      
      Fix ext4_find_unwritten_pgoff() to properly detect non-contiguous page
      indices and also handle all cases where we got less pages then expected
      in one place and handle it properly there.
      
      Fixes: c8c0df24
      CC: Zheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      699dc108
    • Julien Grall's avatar
      xen/privcmd: Support correctly 64KB page granularity when mapping memory · 628ee504
      Julien Grall authored
      commit 753c09b5 upstream.
      
      Commit 5995a68a "xen/privcmd: Add support for Linux 64KB page granularity" did
      not go far enough to support 64KB in mmap_batch_fn.
      
      The variable 'nr' is the number of 4KB chunk to map. However, when Linux
      is using 64KB page granularity the array of pages (vma->vm_private_data)
      contain one page per 64KB. Fix it by incrementing st->index correctly.
      
      Furthermore, st->va is not correctly incremented as PAGE_SIZE !=
      XEN_PAGE_SIZE.
      
      Fixes: 5995a68a ("xen/privcmd: Add support for Linux 64KB page granularity")
      Reported-by: default avatarFeng Kan <fkan@apm.com>
      Signed-off-by: default avatarJulien Grall <julien.grall@arm.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      628ee504
    • Marc Gonzalez's avatar
      mtd: nand: tango: Update ecc_stats.corrected · b9d013c0
      Marc Gonzalez authored
      commit 60cf0ce1 upstream.
      
      According to Boris, some user-space tools expect MTD drivers to
      update ecc_stats.corrected, and it's better to provide a lower
      bound than to provide no information at all.
      
      Fixes: 6956e238 ("mtd: nand: add tango NAND flash controller support")
      Reported-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9d013c0
    • Andres Galacho's avatar
      mtd: nand: tango: Export OF device ID table as module aliases · 6d916021
      Andres Galacho authored
      commit 2761b4f1 upstream.
      
      The device table is required to load modules based on
      modaliases. After adding MODULE_DEVICE_TABLE, below entries
      for example will be added to module.alias:
      alias:          of:N*T*Csigma,smp8758-nandC*
      alias:          of:N*T*Csigma,smp8758-nand
      
      Fixes: 6956e238 ("mtd: nand: add tango NAND flash controller support")
      Signed-off-by: default avatarAndres Galacho <andresgalacho@gmail.com>
      Acked-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d916021
    • Jan Kara's avatar
      reiserfs: Make flush bios explicitely sync · f0aa7a04
      Jan Kara authored
      commit d8747d64 upstream.
      
      Commit b685d3d6 "block: treat REQ_FUA and REQ_PREFLUSH as
      synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...}
      definitions.  generic_make_request_checks() however strips REQ_FUA and
      REQ_PREFLUSH flags from a bio when the storage doesn't report volatile
      write cache and thus write effectively becomes asynchronous which can
      lead to performance regressions
      
      Fix the problem by making sure all bios which are synchronous are
      properly marked with REQ_SYNC.
      
      Fixes: b685d3d6
      CC: reiserfs-devel@vger.kernel.org
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0aa7a04
    • Hou Tao's avatar
      cfq-iosched: fix the delay of cfq_group's vdisktime under iops mode · f2fee0c4
      Hou Tao authored
      commit 5be6b756 upstream.
      
      When adding a cfq_group into the cfq service tree, we use CFQ_IDLE_DELAY
      as the delay of cfq_group's vdisktime if there have been other cfq_groups
      already.
      
      When cfq is under iops mode, commit 9a7f38c4 ("cfq-iosched: Convert
      from jiffies to nanoseconds") could result in a large iops delay and
      lead to an abnormal io schedule delay for the added cfq_group. To fix
      it, we just need to revert to the old CFQ_IDLE_DELAY value: HZ / 5
      when iops mode is enabled.
      
      Despite having the same value, the delay of a cfq_queue in idle class
      and the delay of cfq_group are different things, so I define two new
      macros for the delay of a cfq_group under time-slice mode and iops mode.
      
      Fixes: 9a7f38c4 ("cfq-iosched: Convert from jiffies to nanoseconds")
      Signed-off-by: default avatarHou Tao <houtao1@huawei.com>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2fee0c4
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: set DMA mask to 40 bits · 067b131e
      Thomas Petazzoni authored
      commit b2d3c270 upstream.
      
      The XORv2 engine on Armada 7K/8K can only access the first 40 bits of
      the physical address space, so the DMA mask must be set accordingly.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      067b131e
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: remove interrupt coalescing · 6d41a85b
      Thomas Petazzoni authored
      commit 9dd4f319 upstream.
      
      The current implementation of interrupt coalescing doesn't work, because
      it doesn't configure the coalescing timer, which is needed to make sure
      we get an interrupt at some point.
      
      As a fix for stable, we simply remove the interrupt coalescing
      functionality. It will be re-introduced properly in a future commit.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d41a85b
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: fix tx_submit() implementation · 6f4c739d
      Thomas Petazzoni authored
      commit 44d5887a upstream.
      
      The mv_xor_v2_tx_submit() gets the next available HW descriptor by
      calling mv_xor_v2_get_desq_write_ptr(), which reads a HW register
      telling the next available HW descriptor. This was working fine when HW
      descriptors were issued for processing directly in tx_submit().
      
      However, as part of the review process of the driver, a change was
      requested to move the actual kick-off of HW descriptors processing to
      ->issue_pending(). Due to this, reading the HW register to know the next
      available HW descriptor no longer works.
      
      So instead of using this HW register, we implemented a software index
      pointing to the next available HW descriptor.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f4c739d
    • Hanna Hawa's avatar
      dmaengine: mv_xor_v2: enable XOR engine after its configuration · a4634dfb
      Hanna Hawa authored
      commit ab2c5f0a upstream.
      
      The engine was enabled prior to its configuration, which isn't
      correct. This patch relocates the activation of the XOR engine, to be
      after the configuration of the XOR engine.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarHanna Hawa <hannah@marvell.com>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4634dfb
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: do not use descriptors not acked by async_tx · cba2cd6d
      Thomas Petazzoni authored
      commit bc473da1 upstream.
      
      Descriptors that have not been acknowledged by the async_tx layer
      should not be re-used, so this commit adjusts the implementation of
      mv_xor_v2_prep_sw_desc() to skip descriptors for which
      async_tx_test_ack() is false.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cba2cd6d
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: properly handle wrapping in the array of HW descriptors · 2384df2b
      Thomas Petazzoni authored
      commit 2aab4e18 upstream.
      
      mv_xor_v2_tasklet() is looping over completed HW descriptors. Before the
      loop, it initializes 'next_pending_hw_desc' to the first HW descriptor
      to handle, and then the loop simply increments this point, without
      taking care of wrapping when we reach the last HW descriptor. The
      'pending_ptr' index was being wrapped back to 0 at the end, but it
      wasn't used in each iteration of the loop to calculate
      next_pending_hw_desc.
      
      This commit fixes that, and makes next_pending_hw_desc a variable local
      to the loop itself.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2384df2b
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: handle mv_xor_v2_prep_sw_desc() error properly · fdcadb5f
      Thomas Petazzoni authored
      commit eb8df543 upstream.
      
      The mv_xor_v2_prep_sw_desc() is called from a few different places in
      the driver, but we never take into account the fact that it might
      return NULL. This commit fixes that, ensuring that we don't panic if
      there are no more descriptors available.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdcadb5f
    • Alexander Sverdlin's avatar
      dmaengine: ep93xx: Don't drain the transfers in terminate_all() · 5c039176
      Alexander Sverdlin authored
      commit 98f9de36 upstream.
      
      Draining the transfers in terminate_all callback happens with IRQs disabled,
      therefore induces huge latency:
      
       irqsoff latency trace v1.1.5 on 4.11.0
       --------------------------------------------------------------------
       latency: 39770 us, #57/57, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0)
          -----------------
          | task: process-129 (uid:0 nice:0 policy:2 rt_prio:50)
          -----------------
        => started at: _snd_pcm_stream_lock_irqsave
        => ended at:   snd_pcm_stream_unlock_irqrestore
      
                        _------=> CPU#
                       / _-----=> irqs-off
                      | / _----=> need-resched
                      || / _---=> hardirq/softirq
                      ||| / _--=> preempt-depth
                      |||| /     delay
        cmd     pid   ||||| time  |   caller
           \   /      |||||  \    |   /
      process-129     0d.s.    3us : _snd_pcm_stream_lock_irqsave
      process-129     0d.s1    9us : snd_pcm_stream_lock <-_snd_pcm_stream_lock_irqsave
      process-129     0d.s1   15us : preempt_count_add <-snd_pcm_stream_lock
      process-129     0d.s2   22us : preempt_count_add <-snd_pcm_stream_lock
      process-129     0d.s3   32us : snd_pcm_update_hw_ptr0 <-snd_pcm_period_elapsed
      process-129     0d.s3   41us : soc_pcm_pointer <-snd_pcm_update_hw_ptr0
      process-129     0d.s3   50us : dmaengine_pcm_pointer <-soc_pcm_pointer
      process-129     0d.s3   58us+: snd_dmaengine_pcm_pointer_no_residue <-dmaengine_pcm_pointer
      process-129     0d.s3   96us : update_audio_tstamp <-snd_pcm_update_hw_ptr0
      process-129     0d.s3  103us : snd_pcm_update_state <-snd_pcm_update_hw_ptr0
      process-129     0d.s3  112us : xrun <-snd_pcm_update_state
      process-129     0d.s3  119us : snd_pcm_stop <-xrun
      process-129     0d.s3  126us : snd_pcm_action <-snd_pcm_stop
      process-129     0d.s3  134us : snd_pcm_action_single <-snd_pcm_action
      process-129     0d.s3  141us : snd_pcm_pre_stop <-snd_pcm_action_single
      process-129     0d.s3  150us : snd_pcm_do_stop <-snd_pcm_action_single
      process-129     0d.s3  157us : soc_pcm_trigger <-snd_pcm_do_stop
      process-129     0d.s3  166us : snd_dmaengine_pcm_trigger <-soc_pcm_trigger
      process-129     0d.s3  175us : ep93xx_dma_terminate_all <-snd_dmaengine_pcm_trigger
      process-129     0d.s3  182us : preempt_count_add <-ep93xx_dma_terminate_all
      process-129     0d.s4  189us*: m2p_hw_shutdown <-ep93xx_dma_terminate_all
      process-129     0d.s4 39472us : m2p_hw_setup <-ep93xx_dma_terminate_all
      
       ... rest skipped...
      
      process-129     0d.s. 40080us : <stack trace>
       => ep93xx_dma_tasklet
       => tasklet_action
       => __do_softirq
       => irq_exit
       => __handle_domain_irq
       => vic_handle_irq
       => __irq_usr
       => 0xb66c6668
      
      Just abort the transfers and warn if the HW state is not what we expect.
      Move draining into device_synchronize callback.
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c039176
    • Alexander Sverdlin's avatar
      dmaengine: ep93xx: Always start from BASE0 · 81a38a59
      Alexander Sverdlin authored
      commit 0037ae47 upstream.
      
      The current buffer is being reset to zero on device_free_chan_resources()
      but not on device_terminate_all(). It could happen that HW is restarted and
      expects BASE0 to be used, but the driver is not synchronized and will start
      from BASE1. One solution is to reset the buffer explicitly in
      m2p_hw_setup().
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81a38a59
    • Hiroyuki Yokoyama's avatar
      dmaengine: usb-dmac: Fix DMAOR AE bit definition · 9812dc2a
      Hiroyuki Yokoyama authored
      commit 9a445bbb upstream.
      
      This patch fixes the register definition of AE (Address Error flag) bit.
      
      Fixes: 0c1c8ff3 ("dmaengine: usb-dmac: Add Renesas USB DMA Controller (USB-DMAC) driver")
      Signed-off-by: default avatarHiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
      [Shimoda: add Fixes and Cc tags in the commit log]
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9812dc2a
    • Wanpeng Li's avatar
      KVM: async_pf: avoid async pf injection when in guest mode · 3e456059
      Wanpeng Li authored
      commit 9bc1f09f upstream.
      
       INFO: task gnome-terminal-:1734 blocked for more than 120 seconds.
             Not tainted 4.12.0-rc4+ #8
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       gnome-terminal- D    0  1734   1015 0x00000000
       Call Trace:
        __schedule+0x3cd/0xb30
        schedule+0x40/0x90
        kvm_async_pf_task_wait+0x1cc/0x270
        ? __vfs_read+0x37/0x150
        ? prepare_to_swait+0x22/0x70
        do_async_page_fault+0x77/0xb0
        ? do_async_page_fault+0x77/0xb0
        async_page_fault+0x28/0x30
      
      This is triggered by running both win7 and win2016 on L1 KVM simultaneously,
      and then gives stress to memory on L1, I can observed this hang on L1 when
      at least ~70% swap area is occupied on L0.
      
      This is due to async pf was injected to L2 which should be injected to L1,
      L2 guest starts receiving pagefault w/ bogus %cr2(apf token from the host
      actually), and L1 guest starts accumulating tasks stuck in D state in
      kvm_async_pf_task_wait() since missing PAGE_READY async_pfs.
      
      This patch fixes the hang by doing async pf when executing L1 guest.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e456059
    • Marc Zyngier's avatar
      arm: KVM: Allow unaligned accesses at HYP · 37b15215
      Marc Zyngier authored
      commit 33b5c388 upstream.
      
      We currently have the HSCTLR.A bit set, trapping unaligned accesses
      at HYP, but we're not really prepared to deal with it.
      
      Since the rest of the kernel is pretty happy about that, let's follow
      its example and set HSCTLR.A to zero. Modern CPUs don't really care.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37b15215
    • Marc Zyngier's avatar
      arm64: KVM: Allow unaligned accesses at EL2 · d06ca326
      Marc Zyngier authored
      commit 78fd6dcf upstream.
      
      We currently have the SCTLR_EL2.A bit set, trapping unaligned accesses
      at EL2, but we're not really prepared to deal with it. So far, this
      has been unnoticed, until GCC 7 started emitting those (in particular
      64bit writes on a 32bit boundary).
      
      Since the rest of the kernel is pretty happy about that, let's follow
      its example and set SCTLR_EL2.A to zero. Modern CPUs don't really
      care.
      Reported-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d06ca326
    • Marc Zyngier's avatar
      arm64: KVM: Preserve RES1 bits in SCTLR_EL2 · ff384c49
      Marc Zyngier authored
      commit d68c1f7f upstream.
      
      __do_hyp_init has the rather bad habit of ignoring RES1 bits and
      writing them back as zero. On a v8.0-8.2 CPU, this doesn't do anything
      bad, but may end-up being pretty nasty on future revisions of the
      architecture.
      
      Let's preserve those bits so that we don't have to fix this later on.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff384c49
    • Wanpeng Li's avatar
      KVM: cpuid: Fix read/write out-of-bounds vulnerability in cpuid emulation · 0d2c539e
      Wanpeng Li authored
      commit a3641631 upstream.
      
      If "i" is the last element in the vcpu->arch.cpuid_entries[] array, it
      potentially can be exploited the vulnerability. this will out-of-bounds
      read and write.  Luckily, the effect is small:
      
      	/* when no next entry is found, the current entry[i] is reselected */
      	for (j = i + 1; ; j = (j + 1) % nent) {
      		struct kvm_cpuid_entry2 *ej = &vcpu->arch.cpuid_entries[j];
      		if (ej->function == e->function) {
      
      It reads ej->maxphyaddr, which is user controlled.  However...
      
      			ej->flags |= KVM_CPUID_FLAG_STATE_READ_NEXT;
      
      After cpuid_entries there is
      
      	int maxphyaddr;
      	struct x86_emulate_ctxt emulate_ctxt;  /* 16-byte aligned */
      
      So we have:
      
      - cpuid_entries at offset 1B50 (6992)
      - maxphyaddr at offset 27D0 (6992 + 3200 = 10192)
      - padding at 27D4...27DF
      - emulate_ctxt at 27E0
      
      And it writes in the padding.  Pfew, writing the ops field of emulate_ctxt
      would have been much worse.
      
      This patch fixes it by modding the index to avoid the out-of-bounds
      access. Worst case, i == j and ej->function == e->function,
      the loop can bail out.
      Reported-by: default avatarMoguofang <moguofang@huawei.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Guofang Mo <moguofang@huawei.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d2c539e
    • Paolo Bonzini's avatar
      kvm: async_pf: fix rcu_irq_enter() with irqs enabled · 406aa22b
      Paolo Bonzini authored
      commit bbaf0e2b upstream.
      
      native_safe_halt enables interrupts, and you just shouldn't
      call rcu_irq_enter() with interrupts enabled.  Reorder the
      call with the following local_irq_disable() to respect the
      invariant.
      Reported-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      406aa22b
    • Dave Young's avatar
      efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot · f9ecf422
      Dave Young authored
      commit 7425826f upstream.
      
      Sabrina Dubroca reported an early panic:
      
        BUG: unable to handle kernel paging request at ffffffffff240001
        IP: efi_bgrt_init+0xdc/0x134
      
        [...]
      
        ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
      
      ... which was introduced by:
      
        7b0a9114 ("efi/x86: Move the EFI BGRT init code to early init code")
      
      The cause is that on this machine the firmware provides the EFI ACPI BGRT
      table even on legacy non-EFI bootups - which table should be EFI only.
      
      The garbage BGRT data causes the efi_bgrt_init() panic.
      
      Add a check to skip efi_bgrt_init() in case non-EFI bootup to work around
      this firmware bug.
      Tested-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 7b0a9114 ("efi/x86: Move the EFI BGRT init code to early init code")
      Link: http://lkml.kernel.org/r/20170526113652.21339-6-matt@codeblueprint.co.uk
      [ Rewrote the changelog to be more readable. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9ecf422
    • Juergen Gross's avatar
      efi: Don't issue error message when booted under Xen · c76a4a07
      Juergen Gross authored
      commit 1ea34adb upstream.
      
      When booted as Xen dom0 there won't be an EFI memmap allocated. Avoid
      issuing an error message in this case:
      
        [    0.144079] efi: Failed to allocate new EFI memmap
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170526113652.21339-2-matt@codeblueprint.co.ukSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c76a4a07
    • Jan Kara's avatar
      gfs2: Make flush bios explicitely sync · b8745dbb
      Jan Kara authored
      commit 0f0b9b63 upstream.
      
      Commit b685d3d6 "block: treat REQ_FUA and REQ_PREFLUSH as
      synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...}
      definitions.  generic_make_request_checks() however strips REQ_FUA and
      REQ_PREFLUSH flags from a bio when the storage doesn't report volatile
      write cache and thus write effectively becomes asynchronous which can
      lead to performance regressions
      
      Fix the problem by making sure all bios which are synchronous are
      properly marked with REQ_SYNC.
      
      Fixes: b685d3d6
      CC: Steven Whitehouse <swhiteho@redhat.com>
      CC: cluster-devel@redhat.com
      Acked-by: default avatarBob Peterson <rpeterso@redhat.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8745dbb