1. 10 Jun, 2016 10 commits
    • Stephen Boyd's avatar
      mfd: intel_quark_i2c_gpio: Use clkdev_create() · 4cadc5da
      Stephen Boyd authored
      commit c4726abc upstream.
      
      Convert this driver to use clkdev_create() instead of
      clk_register_clkdevs(). The latter API is only used by this driver,
      although this driver only allocates one clk to add anyway.
      Furthermore, this driver allocates the clk_lookup structure with
      devm, but clkdev_drop() will free that structure when passed,
      leading to a double free when this driver is removed. Clean it
      all up and pave the way for the removal of clk_register_clkdevs().
      
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      4cadc5da
    • Dave Gerlach's avatar
      cpuidle: Indicate when a device has been unregistered · 9046e134
      Dave Gerlach authored
      commit c998c078 upstream.
      
      Currently the 'registered' member of the cpuidle_device struct is set
      to 1 during cpuidle_register_device. In this same function there are
      checks to see if the device is already registered to prevent duplicate
      calls to register the device, but this value is never set to 0 even on
      unregister of the device. Because of this, any attempt to call
      cpuidle_register_device after a call to cpuidle_unregister_device will
      fail which shouldn't be the case.
      
      To prevent this, set registered to 0 when the device is unregistered.
      
      Fixes: c878a52d (cpuidle: Check if device is already registered)
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9046e134
    • Jiri Slaby's avatar
      Bluetooth: vhci: purge unhandled skbs · cc6024fe
      Jiri Slaby authored
      commit 13407376 upstream.
      
      The write handler allocates skbs and queues them into data->readq.
      Read side should read them, if there is any. If there is none, skbs
      should be dropped by hdev->flush. But this happens only if the device
      is HCI_UP, i.e. hdev->power_on work was triggered already. When it was
      not, skbs stay allocated in the queue when /dev/vhci is closed. So
      purge the queue in ->release.
      
      Program to reproduce:
      	#include <err.h>
      	#include <fcntl.h>
      	#include <stdio.h>
      	#include <unistd.h>
      
      	#include <sys/stat.h>
      	#include <sys/types.h>
      	#include <sys/uio.h>
      
      	int main()
      	{
      		char buf[] = { 0xff, 0 };
      		struct iovec iov = {
      			.iov_base = buf,
      			.iov_len = sizeof(buf),
      		};
      		int fd;
      
      		while (1) {
      			fd = open("/dev/vhci", O_RDWR);
      			if (fd < 0)
      				err(1, "open");
      
      			usleep(50);
      
      			if (writev(fd, &iov, 1) < 0)
      				err(1, "writev");
      
      			usleep(50);
      
      			close(fd);
      		}
      
      		return 0;
      	}
      
      Result:
      kmemleak: 4609 new suspected memory leaks
      unreferenced object 0xffff88059f4d5440 (size 232):
        comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s)
        hex dump (first 32 bytes):
          20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff   .#..... .#.....
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
      ...
          [<ffffffff81ece010>] __alloc_skb+0x0/0x5a0
          [<ffffffffa021886c>] vhci_create_device+0x5c/0x580 [hci_vhci]
          [<ffffffffa0219436>] vhci_write+0x306/0x4c8 [hci_vhci]
      
      Fixes: 23424c0d (Bluetooth: Add support creating virtual AMP controllers)
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cc6024fe
    • Jiri Slaby's avatar
      Bluetooth: vhci: fix open_timeout vs. hdev race · 75a11928
      Jiri Slaby authored
      commit 373a32c8 upstream.
      
      Both vhci_get_user and vhci_release race with open_timeout work. They
      both contain cancel_delayed_work_sync, but do not test whether the
      work actually created hdev or not. Since the work can be in progress
      and _sync will wait for finishing it, we can have data->hdev allocated
      when cancel_delayed_work_sync returns. But the call sites do 'if
      (data->hdev)' *before* cancel_delayed_work_sync.
      
      As a result:
      * vhci_get_user allocates a second hdev and puts it into
        data->hdev. The former is leaked.
      * vhci_release does not release data->hdev properly as it thinks there
        is none.
      
      Fix both cases by moving the actual test *after* the call to
      cancel_delayed_work_sync.
      
      This can be hit by this program:
      	#include <err.h>
      	#include <fcntl.h>
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <time.h>
      	#include <unistd.h>
      
      	#include <sys/stat.h>
      	#include <sys/types.h>
      
      	int main(int argc, char **argv)
      	{
      		int fd;
      
      		srand(time(NULL));
      
      		while (1) {
      			const int delta = (rand() % 200 - 100) * 100;
      
      			fd = open("/dev/vhci", O_RDWR);
      			if (fd < 0)
      				err(1, "open");
      
      			usleep(1000000 + delta);
      
      			close(fd);
      		}
      
      		return 0;
      	}
      
      And the result is:
      BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228
      Read of size 8 by task kworker/u13:1/32068
      =============================================================================
      BUG kmalloc-192 (Tainted: G            E     ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
      ...
      	kmem_cache_alloc_trace+0x150/0x190
      	vhci_open+0x50/0x330 [hci_vhci]
      	misc_open+0x35b/0x4e0
      	chrdev_open+0x23b/0x510
      ...
      INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
      ...
      	__slab_free+0x204/0x310
      	vhci_release+0xa4/0xd0 [hci_vhci]
      ...
      INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080
      INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600
      Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00  ...k............
      Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff  ...k.......k....
      Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff  .F.k.....F.k....
      Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00  ................
      Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff  @..k....@..k....
      Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de  P.n.............
      Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00  .........b......
      Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff  ........8..k....
      Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00  .. .............
      Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff  ...........=....
      Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  . ..............
      Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb                          ........
      Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00                          ........
      CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G    B       E      4.4.6-0-default #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
      Workqueue: hci0 hci_cmd_work [bluetooth]
       00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180
       ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320
       ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80
      Call Trace:
      ...
       [<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150
       [<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci]
       [<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth]
       [<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth]
       [<ffffffff811a1375>] ? process_one_work+0x815/0x1340
       [<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0
       [<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340
       [<ffffffff811b3c68>] ? kthread+0x1c8/0x230
      ...
      Memory state around the buggy address:
       ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                        ^
       ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Fixes: 23424c0d (Bluetooth: Add support creating virtual AMP controllers)
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      75a11928
    • Itai Handler's avatar
      drm/gma500: Fix possible out of bounds read · 7dd306cc
      Itai Handler authored
      commit 7ccca1d5 upstream.
      
      Fix possible out of bounds read, by adding missing comma.
      The code may read pass the end of the dsi_errors array
      when the most significant bit (bit #31) in the intr_stat register
      is set.
      This bug has been detected using CppCheck (static analysis tool).
      Signed-off-by: default avatarItai Handler <itai_handler@hotmail.com>
      Signed-off-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7dd306cc
    • Larry Finger's avatar
      rtlwifi: btcoexist: Implement antenna selection · 7878f58e
      Larry Finger authored
      commit baa17022 upstream.
      
      The previous patch added an option to rtl8723be to manually select the
      antenna for those cases when only a single antenna is present, and the
      on-board EEPROM is incorrectly programmed. This patch implements the
      necessary changes in the Bluetooth coexistence driver.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      [ kamal: backport to 4.2-stable: files moved ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7878f58e
    • Larry Finger's avatar
      rtlwifi: rtl8723be: Add antenna select module parameter · 305c1f38
      Larry Finger authored
      commit c18d8f50 upstream.
      
      A number of new laptops have been delivered with only a single antenna.
      In principle, this is OK; however, a problem arises when the on-board
      EEPROM is programmed to use the other antenna connection. The option
      of opening the computer and moving the connector is not always possible
      as it will void the warranty in some cases. In addition, this solution
      breaks the Windows driver when the box dual boots Linux and Windows.
      
      A fix involving a new module parameter has been developed.  This commit
      adds the new parameter and implements the changes needed for the driver.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      [ kamal: backport to 4.2-stable: files moved ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      305c1f38
    • Dave Chinner's avatar
      xfs: Don't wrap growfs AGFL indexes · 3440f11a
      Dave Chinner authored
      commit ad747e3b upstream.
      
      Commit 96f859d5 ("libxfs: pack the agfl header structure so
      XFS_AGFL_SIZE is correct") allowed the freelist to use the empty
      slot at the end of the freelist on 64 bit systems that was not
      being used due to sizeof() rounding up the structure size.
      
      This has caused versions of xfs_repair prior to 4.5.0 (which also
      has the fix) to report this as a corruption once the filesystem has
      been grown. Older kernels can also have problems (seen from a whacky
      container/vm management environment) mounting filesystems grown on a
      system with a newer kernel than the vm/container it is deployed on.
      
      To avoid this problem, change the initial free list indexes not to
      wrap across the end of the AGFL, hence avoiding the initialisation
      of agf_fllast to the last index in the AGFL.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarCarlos Maiolino <cmaiolino@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3440f11a
    • Eric Sandeen's avatar
      xfs: disallow rw remount on fs with unknown ro-compat features · fd87bcb7
      Eric Sandeen authored
      commit d0a58e83 upstream.
      
      Today, a kernel which refuses to mount a filesystem read-write
      due to unknown ro-compat features can still transition to read-write
      via the remount path.  The old kernel is most likely none the wiser,
      because it's unaware of the new feature, and isn't using it.  However,
      writing to the filesystem may well corrupt metadata related to that
      new feature, and moving to a newer kernel which understand the feature
      will have problems.
      
      Right now the only ro-compat feature we have is the free inode btree,
      which showed up in v3.16.  It would be good to push this back to
      all the active stable kernels, I think, so that if anyone is using
      newer mkfs (which enables the finobt feature) with older kernel
      releases, they'll be protected.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Reviewed-by: default avatarBill O'Donnell <billodo@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      fd87bcb7
    • Joseph Salisbury's avatar
      ath5k: Change led pin configuration for compaq c700 laptop · 8859409e
      Joseph Salisbury authored
      commit 7b9bc799 upstream.
      
      BugLink: http://bugs.launchpad.net/bugs/972604
      
      Commit 09c9bae2 ("ath5k: add led pin
      configuration for compaq c700 laptop") added a pin configuration for the Compaq
      c700 laptop.  However, the polarity of the led pin is reversed.  It should be
      red for wifi off and blue for wifi on, but it is the opposite.  This bug was
      reported in the following bug report:
      http://pad.lv/972604
      
      Fixes: 09c9bae2 ("ath5k: add led pin configuration for compaq c700 laptop")
      Signed-off-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8859409e
  2. 08 Jun, 2016 2 commits
  3. 07 Jun, 2016 3 commits
    • Anilkumar Kolli's avatar
      ath10k: fix debugfs pktlog_filter write · af27c436
      Anilkumar Kolli authored
      commit 9ddc486a upstream.
      
      It is observed that, we are disabling the packet log if we write same
      value to the pktlog_filter for the second time. Always enable pktlogs
      on non zero filter.
      
      Fixes: 90174455 ("ath10k: add support to configure pktlog filter")
      Signed-off-by: default avatarAnilkumar Kolli <akolli@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      af27c436
    • Lyude's avatar
      drm/i915: Fix race condition in intel_dp_destroy_mst_connector() · ab7060c9
      Lyude authored
      commit 1f771755 upstream.
      
      After unplugging a DP MST display from the system, we have to go through
      and destroy all of the DRM connectors associated with it since none of
      them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
      doesn't do a good enough job of ensuring that throughout the destruction
      process that no modesettings can be done with the connectors. As it is
      right now, intel_dp_destroy_mst_connector() works like this:
      
      * Take all modeset locks
      * Clear the configuration of the crtc on the connector, if there is one
      * Drop all modeset locks, this is required because of circular
        dependency issues that arise with trying to remove the connector from
        sysfs with modeset locks held
      * Unregister the connector
      * Take all modeset locks, again
      * Do the rest of the required cleaning for destroying the connector
      * Finally drop all modeset locks for good
      
      This only works sometimes. During the destruction process, it's very
      possible that a userspace application will attempt to do a modesetting
      using the connector. When we drop the modeset locks, an ioctl handler
      such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
      locks from us. When this happens, one thing leads to another and
      eventually we end up committing a mode with the non-existent connector:
      
      	[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
      	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
      	[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
      	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
      	[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
      
      And in some cases, such as with the T460s using an MST dock, this
      results in breaking modesetting and/or panicking the system.
      
      To work around this, we now unregister the connector at the very
      beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
      locks, and then hold them until we finish the rest of the function.
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Signed-off-by: default avatarRob Clark <rclark@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com
      [ kamal: backport to 4.2-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ab7060c9
    • Rajkumar Manoharan's avatar
      ath10k: fix firmware assert in monitor mode · 9c2868d7
      Rajkumar Manoharan authored
      commit 8a75fc54 upstream.
      
      commit 166de3f1 ("ath10k: remove supported chain mask") had revealed
      an issue on monitor mode. Configuring NSS upon monitor interface
      creation is causing target assert in all qca9888x and qca6174 firmware.
      Firmware assert issue can be reproduced by below sequence even after
      reverting commit 166de3f1 ("ath10k: remove supported chain mask").
      
      ip link set wlan0 down
      iw wlan0 set type monitor
      iw phy0 set antenna 7
      ip link set wlan0 up
      
      This issue is originally reported on qca9888 with 10.1 firmware.
      
      Fixes: 5572a95b ("ath10k: apply chainmask settings to vdev on creation")
      Reported-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9c2868d7
  4. 27 May, 2016 1 commit
  5. 24 May, 2016 24 commits