1. 11 May, 2016 14 commits
  2. 03 May, 2016 16 commits
  3. 02 May, 2016 10 commits
    • Roman Pen's avatar
      workqueue: fix ghost PENDING flag while doing MQ IO · 4aa63af3
      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 avatarJiri Slaby <jslaby@suse.cz>
      4aa63af3
    • Laszlo Ersek's avatar
      efi: Fix out-of-bounds read in variable_matches() · 5114cf46
      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 avatarJiri Slaby <jslaby@suse.cz>
      5114cf46
    • Sugar Zhang's avatar
      ASoC: rt5640: Correct the digital interface data select · ac0f017d
      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 avatarJiri Slaby <jslaby@suse.cz>
      ac0f017d
    • Arnd Bergmann's avatar
      ASoC: s3c24xx: use const snd_soc_component_driver pointer · c0bc1ca7
      Arnd Bergmann authored
      commit ba4bc32e upstream.
      
      An older patch to convert the API in the s3c i2s driver
      ended up passing a const pointer into a function that takes
      a non-const pointer, so we now get a warning:
      
      sound/soc/samsung/s3c2412-i2s.c: In function 's3c2412_iis_dev_probe':
      sound/soc/samsung/s3c2412-i2s.c:172:9: error: passing argument 3 of 's3c_i2sv2_register_component' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
      
      However, the s3c_i2sv2_register_component() function again
      passes the pointer into another function taking a const, so
      we just need to change its prototype.
      
      Fixes: eca3b01d ("ASoC: switch over to use snd_soc_register_component() on s3c i2s")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c0bc1ca7
    • Tony Luck's avatar
      EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback · a4e2a2d5
      Tony Luck authored
      commit c4fc1956 upstream.
      
      Both of these drivers can return NOTIFY_BAD, but this terminates
      processing other callbacks that were registered later on the chain.
      Since the driver did nothing to log the error it seems wrong to prevent
      other interested parties from seeing it. E.g. neither of them had even
      bothered to check the type of the error to see if it was a memory error
      before the return NOTIFY_BAD.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Acked-by: default avatarAristeu Rozanski <aris@redhat.com>
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.comSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a4e2a2d5
    • Keerthy's avatar
      pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs · f03a30db
      Keerthy authored
      commit 56b367c0 upstream.
      
      pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
      ranging from 1 to MAX. This leads to a corner case where we try to request
      the pin number = MAX and fails.
      
      bit_pos value is being calculted using ffs. pin_num_from_lsb uses
      bit_pos value. pins array is populated with:
      
      pin + pin_num_from_lsb.
      
      The above is 1 more than usual bit indices as bit_pos uses ffs to compute
      first set bit. Hence the last of the pins array is populated with the MAX
      value and not MAX - 1 which causes error when we call pin_request.
      
      mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
      Consequently val_pos and submask are correct.
      
      Hence use __ffs which gives (ffs(x) - 1) as the first bit set.
      
      fixes: 4e7e8017 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
      Signed-off-by: default avatarKeerthy <j-keerthy@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f03a30db
    • Vladis Dronov's avatar
      Input: gtco - fix crash on detecting device without endpoints · 8c29c640
      Vladis Dronov authored
      commit 162f98de upstream.
      
      The gtco driver expects at least one valid endpoint. If given malicious
      descriptors that specify 0 for the number of endpoints, it will crash in
      the probe function. Ensure there is at least one endpoint on the interface
      before using it.
      
      Also let's fix a minor coding style issue.
      
      The full correct report of this issue can be found in the public
      Red Hat Bugzilla:
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1283385Reported-by: default avatarRalf Spenneberg <ralf@spenneberg.net>
      Signed-off-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8c29c640
    • Dmitry Ivanov's avatar
      nl80211: check netlink protocol in socket release notification · f0c7c896
      Dmitry Ivanov authored
      commit 8f815cdd upstream.
      
      A non-privileged user can create a netlink socket with the same port_id as
      used by an existing open nl80211 netlink socket (e.g. as used by a hostapd
      process) with a different protocol number.
      
      Closing this socket will then lead to the notification going to nl80211's
      socket release notification handler, and possibly cause an action such as
      removing a virtual interface.
      
      Fix this issue by checking that the netlink protocol is NETLINK_GENERIC.
      Since generic netlink has no notifier chain of its own, we can't fix the
      problem more generically.
      
      Fixes: 026331c4 ("cfg80211/mac80211: allow registering for and sending action frames")
      Signed-off-by: default avatarDmitry Ivanov <dima@ubnt.com>
      [rewrite commit message]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f0c7c896
    • John Keeping's avatar
      drm/qxl: fix cursor position with non-zero hotspot · ee520ba1
      John Keeping authored
      commit d59a1f71 upstream.
      
      The SPICE protocol considers the position of a cursor to be the location
      of its active pixel on the display, so the cursor is drawn with its
      top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor
      position gives the location where the top-left corner should be drawn,
      with the hotspot being a hint for drivers that need it.
      
      This fixes the location of the window resize cursors when using Fluxbox
      with the QXL DRM driver and both the QXL and modesetting X drivers.
      Signed-off-by: default avatarJohn Keeping <john@metanate.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.comSigned-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ee520ba1
    • Rui Salvaterra's avatar
      lib: lz4: fixed zram with lz4 on big endian machines · 79767740
      Rui Salvaterra authored
      commit 3e26a691 upstream.
      
      Based on Sergey's test patch [1], this fixes zram with lz4 compression
      on big endian cpus.
      
      Note that the 64-bit preprocessor test is not a cleanup, it's part of
      the fix, since those identifiers are bogus (for example, __ppc64__
      isn't defined anywhere else in the kernel, which means we'd fall into
      the 32-bit definitions on ppc64).
      
      Tested on ppc64 with no regression on x86_64.
      
      [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4Suggested-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarRui Salvaterra <rsalvaterra@gmail.com>
      Reviewed-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      79767740