1. 17 May, 2016 14 commits
    • cpaul@redhat.com's avatar
      drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1() · 85489830
      cpaul@redhat.com authored
      [ Upstream commit 263efde3 ]
      
      We can thank KASAN for finding this, otherwise I probably would have spent
      hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
      while enabling MST where the port we were currently updating the payload on
      would have all of it's refs dropped before we finished what we were doing:
      
      ==================================================================
      BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
      Read of size 4 by task Xorg/973
      =============================================================================
      BUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
      	___slab_alloc+0x472/0x490
      	__slab_alloc+0x20/0x40
      	kmem_cache_alloc_trace+0x151/0x190
      	drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
      	drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
      	drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
      	drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
      	__slab_free+0x17f/0x2d0
      	kfree+0x169/0x180
      	drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
      	drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      
      which on this T460s, would eventually lead to kernel panics in somewhat
      random places later in intel_mst_enable_dp() if we got lucky enough.
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      85489830
    • Roman Pen's avatar
      workqueue: fix ghost PENDING flag while doing MQ IO · 14794cfb
      Roman Pen authored
      [ Upstream commit 346c09f8 ]
      
      The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
      with the following backtrace:
      
      [  601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
      [  601.347574]       Tainted: G           O    4.4.5-1-storage+ #6
      [  601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  601.348142] kworker/u129:5  D ffff880803077988     0  1636      2 0x00000000
      [  601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]
      [  601.348999]  ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000
      [  601.349662]  ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0
      [  601.350333]  ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38
      [  601.350965] Call Trace:
      [  601.351203]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.351444]  [<ffffffff815b01d5>] schedule+0x35/0x80
      [  601.351709]  [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230
      [  601.351958]  [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220
      [  601.352208]  [<ffffffff810bd737>] ? ktime_get+0x37/0xa0
      [  601.352446]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
      [  601.352688]  [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110
      [  601.352951]  [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10
      [  601.353196]  [<ffffffff815b093b>] bit_wait_io+0x1b/0x70
      [  601.353440]  [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90
      [  601.353689]  [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0
      [  601.353958]  [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40
      [  601.354200]  [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140
      [  601.354441]  [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30
      [  601.354688]  [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70
      [  601.354932]  [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50
      [  601.355193]  [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0
      [  601.355432]  [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100
      [  601.355679]  [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0
      [  601.355925]  [<ffffffff81198379>] vfs_write+0xa9/0x1a0
      [  601.356164]  [<ffffffff811c59d8>] kernel_write+0x38/0x50
      
      The underlying device is a null_blk, with default parameters:
      
        queue_mode    = MQ
        submit_queues = 1
      
      Verification that nullb0 has something inflight:
      
      root@pserver8:~# cat /sys/block/nullb0/inflight
             0        1
      root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \;
      ...
      /sys/block/nullb0/mq/0/cpu2/rq_list
      CTX pending:
              ffff8838038e2400
      ...
      
      During debug it became clear that stalled request is always inserted in
      the rq_list from the following path:
      
         save_stack_trace_tsk + 34
         blk_mq_insert_requests + 231
         blk_mq_flush_plug_list + 281
         blk_flush_plug_list + 199
         wait_on_page_bit + 192
         __filemap_fdatawait_range + 228
         filemap_fdatawait_range + 20
         filemap_write_and_wait_range + 63
         blkdev_fsync + 27
         vfs_fsync_range + 73
         blkdev_write_iter + 202
         __vfs_write + 170
         vfs_write + 169
         kernel_write + 56
      
      So blk_flush_plug_list() was called with from_schedule == true.
      
      If from_schedule is true, that means that finally blk_mq_insert_requests()
      offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
      i.e. it calls kblockd_schedule_delayed_work_on().
      
      That means, that we race with another CPU, which is about to execute
      __blk_mq_run_hw_queue() work.
      
      Further debugging shows the following traces from different CPUs:
      
        CPU#0                                  CPU#1
        ----------------------------------     -------------------------------
        reqeust A inserted
        STORE hctx->ctx_map[0] bit marked
        kblockd_schedule...() returns 1
        <schedule to kblockd workqueue>
                                               request B inserted
                                               STORE hctx->ctx_map[1] bit marked
                                               kblockd_schedule...() returns 0
        *** WORK PENDING bit is cleared ***
        flush_busy_ctxs() is executed, but
        bit 1, set by CPU#1, is not observed
      
      As a result request B pended forever.
      
      This behaviour can be explained by speculative LOAD of hctx->ctx_map on
      CPU#0, which is reordered with clear of PENDING bit and executed _before_
      actual STORE of bit 1 on CPU#1.
      
      The proper fix is an explicit full barrier <mfence>, which guarantees
      that clear of PENDING bit is to be executed before all possible
      speculative LOADS or STORES inside actual work function.
      Signed-off-by: default avatarRoman Pen <roman.penyaev@profitbricks.com>
      Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
      Cc: Michael Wang <yun.wang@profitbricks.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: linux-block@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      14794cfb
    • Conrad Kostecki's avatar
      ALSA: hda - Add dock support for ThinkPad X260 · 2519c9fc
      Conrad Kostecki authored
      [ Upstream commit 037e1197 ]
      
      Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
      docking station series (basic, pro, ultra).
      Signed-off-by: default avatarConrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      2519c9fc
    • Shaohua Li's avatar
      MD: make bio mergeable · cdfac06e
      Shaohua Li authored
      [ Upstream commit 9c573de3 ]
      
      blk_queue_split marks bio unmergeable, which makes sense for normal bio.
      But if dispatching the bio to underlayer disk, the blk_queue_split
      checks are invalid, hence it's possible the bio becomes mergeable.
      
      In the reported bug, this bug causes trim against raid0 performance slash
      https://bugzilla.kernel.org/show_bug.cgi?id=117051Reported-and-tested-by: default avatarPark Ju Hyung <qkrwngud825@gmail.com>
      Fixes: 6ac45aeb(block: avoid to merge splitted bio)
      Cc: stable@vger.kernel.org (v4.3+)
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Neil Brown <neilb@suse.de>
      Reviewed-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      cdfac06e
    • Hans Verkuil's avatar
      [media] v4l2-dv-timings.h: fix polarity for 4k formats · 4f194898
      Hans Verkuil authored
      [ Upstream commit 3020ca71 ]
      
      The VSync polarity was negative instead of positive for the 4k CEA formats.
      I probably copy-and-pasted these from the DMT 4k format, which does have a
      negative VSync polarity.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: default avatarMartin Bugge <marbugge@cisco.com>
      Cc: <stable@vger.kernel.org>      # for v4.1 and up
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4f194898
    • Jasem Mutlaq's avatar
      USB: serial: cp210x: add Straizona Focusers device ids · b4782b68
      Jasem Mutlaq authored
      [ Upstream commit 613ac23a ]
      
      Adding VID:PID for Straizona Focusers to cp210x driver.
      Signed-off-by: default avatarJasem Mutlaq <mutlaqja@ikarustech.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b4782b68
    • Mike Manning's avatar
      USB: serial: cp210x: add ID for Link ECU · 35f45c8a
      Mike Manning authored
      [ Upstream commit 1d377f4d ]
      
      The Link ECU is an aftermarket ECU computer for vehicles that provides
      full tuning abilities as well as datalogging and displaying capabilities
      via the USB to Serial adapter built into the device.
      Signed-off-by: default avatarMike Manning <michael@bsch.com.au>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      35f45c8a
    • Laszlo Ersek's avatar
      efi: Fix out-of-bounds read in variable_matches() · 83619523
      Laszlo Ersek authored
      [ Upstream commit 630ba0cc ]
      
      The variable_matches() function can currently read "var_name[len]", for
      example when:
      
       - var_name[0] == 'a',
       - len == 1
       - match_name points to the NUL-terminated string "ab".
      
      This function is supposed to accept "var_name" inputs that are not
      NUL-terminated (hence the "len" parameter"). Document the function, and
      access "var_name[*match]" only if "*match" is smaller than "len".
      Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Matthew Garrett <mjg59@coreos.com>
      Cc: Jason Andryuk <jandryuk@gmail.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v3.10+
      Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      83619523
    • Krzysztof Kozlowski's avatar
      iio: ak8975: Fix NULL pointer exception on early interrupt · e7e16bb6
      Krzysztof Kozlowski authored
      [ Upstream commit 07d2390e ]
      
      In certain probe conditions the interrupt came right after registering
      the handler causing a NULL pointer exception because of uninitialized
      waitqueue:
      
      $ udevadm trigger
      i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL)
      i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL)
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = e8b38000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c
      CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      (...)
      (__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c)
      (__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30)
      (ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)
      (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)
      (handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c)
      (handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)
      (generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68)
      (exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)
      (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)
      (handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194)
      (handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)
      (generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4)
      (__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94)
      (gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80)
      
      The bug was reproduced on exynos4412-trats2 (with a max77693 device also
      using i2c-gpio) after building max77693 as a module.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 94a6d5cf ("iio:ak8975 Implement data ready interrupt handling")
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: default avatarGregor Boirie <gregor.boirie@parrot.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e7e16bb6
    • Jack Pham's avatar
      regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case · 24a50739
      Jack Pham authored
      [ Upstream commit dec8e8f6 ]
      
      Specifically for the case of reads that use the Extended Register
      Read Long command, a multi-byte read operation is broken up into
      8-byte chunks.  However the call to spmi_ext_register_readl() is
      incorrectly passing 'val_size', which if greater than 8 will
      always fail.  The argument should instead be 'len'.
      
      Fixes: c9afbb05 ("regmap: spmi: support base and extended register spaces")
      Signed-off-by: default avatarJack Pham <jackp@codeaurora.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      24a50739
    • Srinivas Kandagatla's avatar
      ata: ahci-platform: Add ports-implemented DT bindings. · eab51598
      Srinivas Kandagatla authored
      [ Upstream commit 17dcc37e ]
      
      On some SOCs PORTS_IMPL register value is never programmed by the
      firmware and left at zero value. Which means that no sata ports are
      available for software. AHCI driver used to cope up with this by
      fabricating the port_map if the PORTS_IMPL register is read zero,
      but recent patch broke this workaround as zero value was valid for
      NVMe disks.
      
      This patch adds ports-implemented DT bindings as workaround for this issue
      in a way that DT can can override the PORTS_IMPL register in cases where
      the firmware did not program it already.
      
      Fixes: 566d1827 ("libata: disable forced PORTS_IMPL for >= AHCI 1.3")
      Cc: stable@vger.kernel.org # v4.5+
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      eab51598
    • Srinivas Kandagatla's avatar
      libahci: save port map for forced port map · a5d2af4c
      Srinivas Kandagatla authored
      [ Upstream commit 2fd0f46c ]
      
      In usecases where force_port_map is used saved_port_map is never set,
      resulting in not programming the PORTS_IMPL register as part of initial
      config. This patch fixes this by setting it to port_map even in case
      where force_port_map is used, making it more inline with other parts of
      the code.
      
      Fixes: 566d1827 ("libata: disable forced PORTS_IMPL for >= AHCI 1.3")
      Cc: stable@vger.kernel.org # v4.5+
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a5d2af4c
    • Krzysztof Kozlowski's avatar
      regulator: s2mps11: Fix invalid selector mask and voltages for buck9 · e1bab756
      Krzysztof Kozlowski authored
      [ Upstream commit 3b672623 ]
      
      The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
      instead of 0x1f) thus reading entire register as buck9's voltage. This
      effectively caused regulator core to interpret values as higher voltages
      than they were and then to set real voltage much lower than intended.
      
      The buck9 provides power to other regulators, including LDO13
      and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
      voltage caused SD card detection errors on Odroid XU3/XU4:
      	mmc1: card never left busy state
      	mmc1: error -110 whilst initialising SD card
      
      During driver probe the regulator core was checking whether initial
      voltage matches the constraints. With incorrect vsel_mask of 0xff and
      default value of 0x50, the core interpreted this as 5 V which is outside
      of constraints (3-3.775 V). Then the regulator core was adjusting the
      voltage to match the constraints. With incorrect vsel_mask this new
      voltage mapped to a vere low voltage in the driver.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Tested-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e1bab756
    • Sugar Zhang's avatar
      ASoC: rt5640: Correct the digital interface data select · 35d34788
      Sugar Zhang authored
      [ Upstream commit 653aa464 ]
      
      this patch corrects the interface adc/dac control register definition
      according to datasheet.
      Signed-off-by: default avatarSugar Zhang <sugar.zhang@rock-chips.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      35d34788
  2. 13 May, 2016 3 commits
  3. 11 May, 2016 1 commit
  4. 10 May, 2016 17 commits
  5. 08 May, 2016 5 commits