1. 09 May, 2016 13 commits
    • Roman Pen's avatar
      workqueue: fix ghost PENDING flag while doing MQ IO · ce75b13e
      Roman Pen authored
      commit 346c09f8 upstream.
      
      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
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ce75b13e
    • Conrad Kostecki's avatar
      ALSA: hda - Add dock support for ThinkPad X260 · 79b636f7
      Conrad Kostecki authored
      commit 037e1197 upstream.
      
      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>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      79b636f7
    • Hans Verkuil's avatar
      [media] v4l2-dv-timings.h: fix polarity for 4k formats · 56db89fa
      Hans Verkuil authored
      commit 3020ca71 upstream.
      
      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>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      56db89fa
    • Jasem Mutlaq's avatar
      USB: serial: cp210x: add Straizona Focusers device ids · c0feac89
      Jasem Mutlaq authored
      commit 613ac23a upstream.
      
      Adding VID:PID for Straizona Focusers to cp210x driver.
      Signed-off-by: default avatarJasem Mutlaq <mutlaqja@ikarustech.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      c0feac89
    • Mike Manning's avatar
      USB: serial: cp210x: add ID for Link ECU · ed62a6f8
      Mike Manning authored
      commit 1d377f4d upstream.
      
      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>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ed62a6f8
    • Laszlo Ersek's avatar
      efi: Fix out-of-bounds read in variable_matches() · a0b95d34
      Laszlo Ersek authored
      commit 630ba0cc upstream.
      
      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>
      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 avatarKamal Mostafa <kamal@canonical.com>
      a0b95d34
    • Javier Martinez Canillas's avatar
      i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared · 364d78d4
      Javier Martinez Canillas authored
      commit 10ff4c52 upstream.
      
      The exynos5 I2C controller driver always prepares and enables a clock
      before using it and then disables unprepares it when the clock is not
      used anymore.
      
      But this can cause a possible ABBA deadlock in some scenarios since a
      driver that uses regmap to access its I2C registers, will first grab
      the regmap lock and then the I2C xfer function will grab the prepare
      lock when preparing the I2C clock. But since the clock driver also
      uses regmap for I2C accesses, preparing a clock will first grab the
      prepare lock and then the regmap lock when using the regmap API.
      
      An example of this happens on the Exynos5422 Odroid XU4 board where a
      s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
      share the same I2C regmap.
      
      The possible deadlock is reported by the kernel lockdep:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(sec_core:428:(regmap)->lock);
                                      lock(prepare_lock);
                                      lock(sec_core:428:(regmap)->lock);
         lock(prepare_lock);
      
        *** DEADLOCK ***
      
      Fix it by leaving the code prepared on probe and use {en,dis}able in
      the I2C transfer function.
      
      This patch is similar to commit 34e81ad5 ("i2c: s3c2410: fix ABBA
      deadlock by keeping clock prepared") that fixes the same bug in other
      driver for an I2C controller found in Samsung SoCs.
      Reported-by: default avatarAnand Moon <linux.amoon@gmail.com>
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Reviewed-by: default avatarAnand Moon <linux.amoon@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      364d78d4
    • Michael Ellerman's avatar
      i2c: cpm: Fix build break due to incompatible pointer types · 376c18ac
      Michael Ellerman authored
      commit 609d5a1b upstream.
      
      Since commit ea8daa7b ("kbuild: Add option to turn incompatible
      pointer check into error"), assignments from an incompatible pointer
      types have become a hard error, eg:
      
        drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
        'dma_alloc_coherent' from incompatible pointer type
      
      Fix the build break by converting txdma & rxdma to dma_addr_t.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Fixes: ea8daa7bSigned-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      376c18ac
    • Richard Leitner's avatar
      iio: ak8975: fix maybe-uninitialized warning · 2ec66bab
      Richard Leitner authored
      commit 05be8d41 upstream.
      
      If i2c_device_id *id is NULL and acpi_match_device returns NULL too,
      then chipset may be unitialized when accessing &ak_def_array[chipset] in
      ak8975_probe. Therefore initialize chipset to AK_MAX_TYPE, which will
      return an error when not changed.
      
      This patch fixes the following maybe-uninitialized warning:
      
      drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’:
      drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used
      uninitialized in this function [-Wmaybe-uninitialized]
        data->def = &ak_def_array[chipset];
      Signed-off-by: default avatarRichard Leitner <dev@g0hl1n.net>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2ec66bab
    • Krzysztof Kozlowski's avatar
      iio: ak8975: Fix NULL pointer exception on early interrupt · 7f209cc1
      Krzysztof Kozlowski authored
      commit 07d2390e upstream.
      
      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.
      
      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 avatarKamal Mostafa <kamal@canonical.com>
      7f209cc1
    • Oleksij Rempel's avatar
      ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation · 9b2dfb26
      Oleksij Rempel authored
      commit de478a61 upstream.
      
      by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
      mask_m & mask_p initialisation. This coused a performance regression
      on ar9281.
      
      Fixes: f911085f ("ath9k: split ar5008_hw_spur_mitigate and reuse common code in ar9002_hw_spur_mitigate.")
      Reported-by: default avatarGustav Frederiksen <lkml2017@openmailbox.org>
      Tested-by: default avatarGustav Frederiksen <lkml2017@openmailbox.org>
      Signed-off-by: default avatarOleksij Rempel <linux@rempel-privat.de>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9b2dfb26
    • Mark Brown's avatar
      ASoC: dapm: Make sure we have a card when displaying component widgets · e58e8daa
      Mark Brown authored
      commit 47325078 upstream.
      
      The dummy component is reused for all cards so we special case and don't
      bind it to any of them.  This means that code like that displaying the
      component widgets that tries to look at the card will crash.  In the
      future we will fix this by ensuring that the dummy component looks like
      other components but that is invasive and so not suitable for a fix.
      Instead add a special case check here.
      Reported-by: default avatarHarry Pan <harry.pan@intel.com>
      Suggested-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      [ kamal: backport to 4.2-stable ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e58e8daa
    • Sugar Zhang's avatar
      ASoC: rt5640: Correct the digital interface data select · 1c4cd5c5
      Sugar Zhang authored
      commit 653aa464 upstream.
      
      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>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1c4cd5c5
  2. 02 May, 2016 2 commits
    • Ignat Korchagin's avatar
      USB: usbip: fix potential out-of-bounds write · 7679a59d
      Ignat Korchagin authored
      commit b348d7dd upstream.
      
      Fix potential out-of-bounds write to urb->transfer_buffer
      usbip handles network communication directly in the kernel. When receiving a
      packet from its peer, usbip code parses headers according to protocol. As
      part of this parsing urb->actual_length is filled. Since the input for
      urb->actual_length comes from the network, it should be treated as untrusted.
      Any entity controlling the network may put any value in the input and the
      preallocated urb->transfer_buffer may not be large enough to hold the data.
      Thus, the malicious entity is able to write arbitrary data to kernel memory.
      Signed-off-by: default avatarIgnat Korchagin <ignat.korchagin@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reference: CVE-2016-3955
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7679a59d
    • Hector Marco-Gisbert's avatar
      x86/mm/32: Enable full randomization on i386 and X86_32 · 861d04db
      Hector Marco-Gisbert authored
      commit 8b8addf8 upstream.
      
      Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
      the stack and the executable are randomized but not other mmapped files
      (libraries, vDSO, etc.). This patch enables randomization for the
      libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.
      
      By default on i386 there are 8 bits for the randomization of the libraries,
      vDSO and mmaps which only uses 1MB of VA.
      
      This patch preserves the original randomness, using 1MB of VA out of 3GB or
      4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.
      
      The first obvious security benefit is that all objects are randomized (not
      only the stack and the executable) in legacy mode which highly increases
      the ASLR effectiveness, otherwise the attackers may use these
      non-randomized areas. But also sensitive setuid/setgid applications are
      more secure because currently, attackers can disable the randomization of
      these applications by setting the ulimit stack to "unlimited". This is a
      very old and widely known trick to disable the ASLR in i386 which has been
      allowed for too long.
      
      Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
      personality flag, but fortunately this doesn't work on setuid/setgid
      applications because there is security checks which clear Security-relevant
      flags.
      
      This patch always randomizes the mmap_legacy_base address, removing the
      possibility to disable the ASLR by setting the stack to "unlimited".
      Signed-off-by: default avatarHector Marco-Gisbert <hecmargi@upv.es>
      Acked-by: default avatarIsmael Ripoll Ripoll <iripoll@upv.es>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: kees Cook <keescook@chromium.org>
      Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.esSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reference: CVE-2016-3672
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      861d04db
  3. 29 Apr, 2016 1 commit
  4. 26 Apr, 2016 24 commits