1. 14 Jun, 2017 40 commits
    • David Sterba's avatar
      btrfs: use correct types for page indices in btrfs_page_exists_in_range · 6bc3d6a6
      David Sterba authored
      commit cc2b702c upstream.
      
      Variables start_idx and end_idx are supposed to hold a page index
      derived from the file offsets. The int type is not the right one though,
      offsets larger than 1 << 44 will get silently trimmed off the high bits.
      (1 << 44 is 16TiB)
      
      What can go wrong, if start is below the boundary and end gets trimmed:
      - if there's a page after start, we'll find it (radix_tree_gang_lookup_slot)
      - the final check "if (page->index <= end_idx)" will unexpectedly fail
      
      The function will return false, ie. "there's no page in the range",
      although there is at least one.
      
      btrfs_page_exists_in_range is used to prevent races in:
      
      * in hole punching, where we make sure there are not pages in the
        truncated range, otherwise we'll wait for them to finish and redo
        truncation, but we're going to replace the pages with holes anyway so
        the only problem is the intermediate state
      
      * lock_extent_direct: we want to make sure there are no pages before we
        lock and start DIO, to prevent stale data reads
      
      For practical occurence of the bug, there are several constaints.  The
      file must be quite large, the affected range must cross the 16TiB
      boundary and the internal state of the file pages and pending operations
      must match.  Also, we must not have started any ordered data in the
      range, otherwise we don't even reach the buggy function check.
      
      DIO locking tries hard in several places to avoid deadlocks with
      buffered IO and avoids waiting for ranges. The worst consequence seems
      to be stale data read.
      
      CC: Liu Bo <bo.li.liu@oracle.com>
      Fixes: fc4adbff ("btrfs: Drop EXTENT_UPTODATE check in hole punching and direct locking")
      Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bc3d6a6
    • Vaibhav Jain's avatar
      cxl: Avoid double free_irq() for psl,slice interrupts · 574ab1b8
      Vaibhav Jain authored
      commit b3aa20ba upstream.
      
      During an eeh call to cxl_remove can result in double free_irq of
      psl,slice interrupts. This can happen if perst_reloads_same_image == 1
      and call to cxl_configure_adapter() fails during slot_reset
      callback. In such a case we see a kernel oops with following back-trace:
      
      Oops: Kernel access of bad area, sig: 11 [#1]
      Call Trace:
        free_irq+0x88/0xd0 (unreliable)
        cxl_unmap_irq+0x20/0x40 [cxl]
        cxl_native_release_psl_irq+0x78/0xd8 [cxl]
        pci_deconfigure_afu+0xac/0x110 [cxl]
        cxl_remove+0x104/0x210 [cxl]
        pci_device_remove+0x6c/0x110
        device_release_driver_internal+0x204/0x2e0
        pci_stop_bus_device+0xa0/0xd0
        pci_stop_and_remove_bus_device+0x28/0x40
        pci_hp_remove_devices+0xb0/0x150
        pci_hp_remove_devices+0x68/0x150
        eeh_handle_normal_event+0x140/0x580
        eeh_handle_event+0x174/0x360
        eeh_event_handler+0x1e8/0x1f0
      
      This patch fixes the issue of double free_irq by checking that
      variables that hold the virqs (err_hwirq, serr_hwirq, psl_virq) are
      not '0' before un-mapping and resetting these variables to '0' when
      they are un-mapped.
      Signed-off-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      574ab1b8
    • Frederic Barrat's avatar
      cxl: Fix error path on bad ioctl · 0c94348b
      Frederic Barrat authored
      commit cec422c1 upstream.
      
      Fix error path if we can't copy user structure on CXL_IOCTL_START_WORK
      ioctl. We shouldn't unlock the context status mutex as it was not
      locked (yet).
      
      Fixes: 0712dc7e ("cxl: Fix issues when unmapping contexts")
      Signed-off-by: default avatarFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Reviewed-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c94348b
    • Al Viro's avatar
      excessive checks in ufs_write_failed() and ufs_evict_inode() · 4907e3bb
      Al Viro authored
      commit babef37d upstream.
      
      As it is, short copy in write() to append-only file will fail
      to truncate the excessive allocated blocks.  As the matter of
      fact, all checks in ufs_truncate_blocks() are either redundant
      or wrong for that caller.  As for the only other caller
      (ufs_evict_inode()), we only need the file type checks there.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4907e3bb
    • Al Viro's avatar
    • Al Viro's avatar
      ufs_extend_tail(): fix the braino in calling conventions of ufs_new_fragments() · c12c0c4f
      Al Viro authored
      commit 940ef1a0 upstream.
      
      ... and it really needs splitting into "new" and "extend" cases, but that's for
      later
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c12c0c4f
    • Al Viro's avatar
      ufs: set correct ->s_maxsize · 728154e9
      Al Viro authored
      commit 6b0d144f upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      728154e9
    • Al Viro's avatar
      ufs: restore maintaining ->i_blocks · d426b957
      Al Viro authored
      commit eb315d2a upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d426b957
    • Al Viro's avatar
      fix ufs_isblockset() · 386e884c
      Al Viro authored
      commit 414cf718 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      386e884c
    • Al Viro's avatar
      ufs: restore proper tail allocation · 823c065a
      Al Viro authored
      commit 8785d84d upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      823c065a
    • Tejun Heo's avatar
      cpuset: consider dying css as offline · 9be0c9d6
      Tejun Heo authored
      commit 41c25707 upstream.
      
      In most cases, a cgroup controller don't care about the liftimes of
      cgroups.  For the controller, a css becomes online when ->css_online()
      is called on it and offline when ->css_offline() is called.
      
      However, cpuset is special in that the user interface it exposes cares
      whether certain cgroups exist or not.  Combined with the RCU delay
      between cgroup removal and css offlining, this can lead to user
      visible behavior oddities where operations which should succeed after
      cgroup removals fail for some time period.  The effects of cgroup
      removals are delayed when seen from userland.
      
      This patch adds css_is_dying() which tests whether offline is pending
      and updates is_cpuset_online() so that the function returns false also
      while offline is pending.  This gets rid of the userland visible
      delays.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarDaniel Jordan <daniel.m.jordan@oracle.com>
      Link: http://lkml.kernel.org/r/327ca1f5-7957-fbb9-9e5f-9ba149d40ba2@oracle.comSigned-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9be0c9d6
    • Ulrik De Bie's avatar
      Input: elantech - add Fujitsu Lifebook E546/E557 to force crc_enabled · 48b2c7c8
      Ulrik De Bie authored
      commit 47eb0c8b upstream.
      
      The Lifebook E546 and E557 touchpad were also not functioning and
      worked after running:
      
              echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled
      
      Add them to the list of machines that need this workaround.
      Signed-off-by: default avatarUlrik De Bie <ulrik.debie-os@e2big.org>
      Reviewed-by: default avatarArjan Opmeer <arjan@opmeer.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48b2c7c8
    • Waiman Long's avatar
      cgroup: Prevent kill_css() from being called more than once · f3c1dfa8
      Waiman Long authored
      commit 33c35aa4 upstream.
      
      The kill_css() function may be called more than once under the condition
      that the css was killed but not physically removed yet followed by the
      removal of the cgroup that is hosting the css. This patch prevents any
      harmm from being done when that happens.
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3c1dfa8
    • Sean Young's avatar
      rc-core: race condition during ir_raw_event_register() · d31fff8c
      Sean Young authored
      commit 963761a0 upstream.
      
      A rc device can call ir_raw_event_handle() after rc_allocate_device(),
      but before rc_register_device() has completed. This is racey because
      rcdev->raw is set before rcdev->raw->thread has a valid value.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d31fff8c
    • Sui Chen's avatar
      ahci: Acer SA5-271 SSD Not Detected Fix · d9f48c46
      Sui Chen authored
      commit 8bfd1743 upstream.
      
      (Correction in this resend: fixed function name acer_sa5_271_workaround; fixed
       the always-true condition in the function; fixed description.)
      
      On the Acer Switch Alpha 12 (model number: SA5-271), the internal SSD may not
      get detected because the port_map and CAP.nr_ports combination causes the driver
      to skip the port that is actually connected to the SSD. More specifically,
      either all SATA ports are identified as DUMMY, or all ports get ``link down''
      and never get up again.
      
      This problem occurs occasionally. When this problem occurs, CAP may hold a
      value of 0xC734FF00 or 0xC734FF01 and port_map may hold a value of 0x00 or 0x01.
      When this problem does not occur, CAP holds a value of 0xC734FF02 and port_map
      may hold a value of 0x07. Overriding the CAP value to 0xC734FF02 and port_map to
      0x7 significantly reduces the occurrence of this problem.
      
      Link: https://bugzilla.kernel.org/attachment.cgi?id=253091Signed-off-by: default avatarSui Chen <suichen6@gmail.com>
      Tested-by: default avatarDamian Ivanov <damianatorrpm@gmail.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9f48c46
    • Rob Clark's avatar
      drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state() · 39d584db
      Rob Clark authored
      commit 786813c3 upstream.
      
      Somehow the helper was never retrofitted for mdp5.  Which meant when
      plane_state->fence was added, it could get copied into new state in
      mdp5_plane_duplicate_state().
      
      If an update to disable the plane (for example on rmfb) managed to sneak
      in after an nonblock update had swapped state, but before it was
      committed, we'd get a splat:
      
          WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 drm_atomic_helper_wait_for_fences+0xe0/0xf8
         Modules linked in:
      
         CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: G        W       4.11.0-rc8+ #1187
         Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
         Workqueue: events drm_mode_rmfb_work_fn
         task: ffffffc036560d00 task.stack: ffffffc036550000
         PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
         LR is at complete_commit.isra.1+0x44/0x1c0
         pc : [<ffffff80084f6040>] lr : [<ffffff800854176c>] pstate: 20000145
         sp : ffffffc036553b60
         x29: ffffffc036553b60 x28: ffffffc0264e6a00
         x27: ffffffc035659000 x26: 0000000000000000
         x25: ffffffc0240e8000 x24: 0000000000000038
         x23: 0000000000000000 x22: ffffff800858f200
         x21: ffffffc0240e8000 x20: ffffffc02f56a800
         x19: 0000000000000000 x18: 0000000000000000
         x17: 0000000000000000 x16: 0000000000000000
         x15: 0000000000000000 x14: ffffffc00a192700
         x13: 0000000000000004 x12: 0000000000000000
         x11: ffffff80089a1690 x10: 00000000000008f0
         x9 : ffffffc036553b20 x8 : ffffffc036561650
         x7 : ffffffc03fe6cb40 x6 : 0000000000000000
         x5 : 0000000000000001 x4 : 0000000000000002
         x3 : ffffffc035659000 x2 : ffffffc0240e8c80
         x1 : 0000000000000000 x0 : ffffffc02adbe588
      
         ---[ end trace 13aeec77c3fb55e2 ]---
         Call trace:
         Exception stack(0xffffffc036553990 to 0xffffffc036553ac0)
         3980:                                   0000000000000000 0000008000000000
         39a0: ffffffc036553b60 ffffff80084f6040 0000000000004ff0 0000000000000038
         39c0: ffffffc0365539d0 ffffff800857e098 ffffffc036553a00 ffffff800857e1b0
         39e0: ffffffc036553a10 ffffff800857c554 ffffffc0365e8400 ffffffc0365e8400
         3a00: ffffffc036553a20 ffffff8008103358 000000000001aad7 ffffff800851b72c
         3a20: ffffffc036553a50 ffffff80080e9228 ffffffc02adbe588 0000000000000000
         3a40: ffffffc0240e8c80 ffffffc035659000 0000000000000002 0000000000000001
         3a60: 0000000000000000 ffffffc03fe6cb40 ffffffc036561650 ffffffc036553b20
         3a80: 00000000000008f0 ffffff80089a1690 0000000000000000 0000000000000004
         3aa0: ffffffc00a192700 0000000000000000 0000000000000000 0000000000000000
         [<ffffff80084f6040>] drm_atomic_helper_wait_for_fences+0xe0/0xf8
         [<ffffff800854176c>] complete_commit.isra.1+0x44/0x1c0
         [<ffffff8008541c64>] msm_atomic_commit+0x32c/0x350
         [<ffffff8008516230>] drm_atomic_commit+0x50/0x60
         [<ffffff8008517548>] drm_atomic_remove_fb+0x158/0x250
         [<ffffff80085186d0>] drm_framebuffer_remove+0x50/0x158
         [<ffffff8008518818>] drm_mode_rmfb_work_fn+0x40/0x58
         [<ffffff80080d5668>] process_one_work+0x1d0/0x378
         [<ffffff80080d5a54>] worker_thread+0x244/0x488
         [<ffffff80080db7fc>] kthread+0xfc/0x128
         [<ffffff8008082ec0>] ret_from_fork+0x10/0x50
      
      Fixes: 96260142 ("drm/fence: add in-fences support")
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reported-by: default avatarStanimir Varbanov <stanimir.varbanov@linaro.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39d584db
    • Eric Anholt's avatar
      drm/msm: Expose our reservation object when exporting a dmabuf. · a5ab52b3
      Eric Anholt authored
      commit 43523eba upstream.
      
      Without this, polling on the dma-buf (and presumably other devices
      synchronizing against our rendering) would return immediately, even
      while the BO was busy.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5ab52b3
    • Nicholas Bellinger's avatar
      target: Re-add check to reject control WRITEs with overflow data · 0354d1d6
      Nicholas Bellinger authored
      commit 4ff83daa upstream.
      
      During v4.3 when the overflow/underflow check was relaxed by
      commit c72c5250:
      
        commit c72c5250
        Author: Roland Dreier <roland@purestorage.com>
        Date:   Wed Jul 22 15:08:18 2015 -0700
      
             target: allow underflow/overflow for PR OUT etc. commands
      
      to allow underflow/overflow for Windows compliance + FCP, a
      consequence was to allow control CDBs to process overflow
      data for iscsi-target with immediate data as well.
      
      As per Roland's original change, continue to allow underflow
      cases for control CDBs to make Windows compliance + FCP happy,
      but until overflow for control CDBs is supported tree-wide,
      explicitly reject all control WRITEs with overflow following
      pre v4.3.y logic.
      Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0354d1d6
    • David Arcari's avatar
      cpufreq: cpufreq_register_driver() should return -ENODEV if init fails · 0eedb783
      David Arcari authored
      commit 6c770036 upstream.
      
      For a driver that does not set the CPUFREQ_STICKY flag, if all of the
      ->init() calls fail, cpufreq_register_driver() should return an error.
      This will prevent the driver from loading.
      
      Fixes: ce1bcfe9 (cpufreq: check cpufreq_policy_list instead of scanning policies for all CPUs)
      Signed-off-by: default avatarDavid Arcari <darcari@redhat.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0eedb783
    • Jason A. Donenfeld's avatar
      random: invalidate batched entropy after crng init · 86f95e53
      Jason A. Donenfeld authored
      commit b169c13d upstream.
      
      It's possible that get_random_{u32,u64} is used before the crng has
      initialized, in which case, its output might not be cryptographically
      secure. For this problem, directly, this patch set is introducing the
      *_wait variety of functions, but even with that, there's a subtle issue:
      what happens to our batched entropy that was generated before
      initialization. Prior to this commit, it'd stick around, supplying bad
      numbers. After this commit, we force the entropy to be re-extracted
      after each phase of the crng has initialized.
      
      In order to avoid a race condition with the position counter, we
      introduce a simple rwlock for this invalidation. Since it's only during
      this awkward transition period, after things are all set up, we stop
      using it, so that it doesn't have an impact on performance.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86f95e53
    • Pratyush Anand's avatar
      mei: make sysfs modalias format similar as uevent modalias · 0524867e
      Pratyush Anand authored
      commit 6f9193ec upstream.
      
      modprobe is not able to resolve sysfs modalias for mei devices.
      
       # cat
      /sys/class/watchdog/watchdog0/device/watchdog/watchdog0/device/modalias
      mei::05b79a6f-4628-4d7f-899d-a91514cb32ab:
       # modprobe --set-version 4.9.6-200.fc25.x86_64 -R
      mei::05b79a6f-4628-4d7f-899d-a91514cb32ab:
      modprobe: FATAL: Module mei::05b79a6f-4628-4d7f-899d-a91514cb32ab: not
      found in directory /lib/modules/4.9.6-200.fc25.x86_64
       # cat /lib/modules/4.9.6-200.fc25.x86_64/modules.alias | grep
      05b79a6f-4628-4d7f-899d-a91514cb32ab
      alias mei:*:05b79a6f-4628-4d7f-899d-a91514cb32ab:*:* mei_wdt
      
      commit b26864ca ("mei: bus: add client protocol
      version to the device alias"), however sysfs modalias
      is still in formmat mei:S:uuid:*.
      
      This patch equates format of uevent and sysfs modalias so that modprobe
      is able to resolve the aliases.
      
      Fixes: commit b26864ca ("mei: bus: add client protocol version to the device alias")
      Signed-off-by: default avatarPratyush Anand <panand@redhat.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0524867e
    • Bart Van Assche's avatar
      block: Avoid that blk_exit_rl() triggers a use-after-free · 67125548
      Bart Van Assche authored
      commit b425e504 upstream.
      
      Since the introduction of .init_rq_fn() and .exit_rq_fn() it is
      essential that the memory allocated for struct request_queue
      stays around until all blk_exit_rl() calls have finished. Hence
      make blk_init_rl() take a reference on struct request_queue.
      
      This patch fixes the following crash:
      
      general protection fault: 0000 [#2] SMP
      CPU: 3 PID: 28 Comm: ksoftirqd/3 Tainted: G      D         4.12.0-rc2-dbg+ #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
      task: ffff88013a108040 task.stack: ffffc9000071c000
      RIP: 0010:free_request_size+0x1a/0x30
      RSP: 0018:ffffc9000071fd38 EFLAGS: 00010202
      RAX: 6b6b6b6b6b6b6b6b RBX: ffff880067362a88 RCX: 0000000000000003
      RDX: ffff880067464178 RSI: ffff880067362a88 RDI: ffff880135ea4418
      RBP: ffffc9000071fd40 R08: 0000000000000000 R09: 0000000100180009
      R10: ffffc9000071fd38 R11: ffffffff81110800 R12: ffff88006752d3d8
      R13: ffff88006752d3d8 R14: ffff88013a108040 R15: 000000000000000a
      FS:  0000000000000000(0000) GS:ffff88013fd80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fa8ec1edb00 CR3: 0000000138ee8000 CR4: 00000000001406e0
      Call Trace:
       mempool_destroy.part.10+0x21/0x40
       mempool_destroy+0xe/0x10
       blk_exit_rl+0x12/0x20
       blkg_free+0x4d/0xa0
       __blkg_release_rcu+0x59/0x170
       rcu_process_callbacks+0x260/0x4e0
       __do_softirq+0x116/0x250
       smpboot_thread_fn+0x123/0x1e0
       kthread+0x109/0x140
       ret_from_fork+0x31/0x40
      
      Fixes: commit e9c787e6 ("scsi: allocate scsi_cmnd structures as part of struct request")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67125548
    • 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