1. 06 Jul, 2016 18 commits
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards. · 238459db
      Vittorio Gambaletta (VittGam) authored
      commit 0f9edcdd upstream.
      
      The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
      (active high instead of active low).
      
      The same PCI Subsystem ID is used by both cards, which are based on
      the same Atheros MB92 design.
      
      Cc: <linux-wireless@vger.kernel.org>
      Cc: <ath9k-devel@qca.qualcomm.com>
      Cc: <ath9k-devel@lists.ath9k.org>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      238459db
    • Vittorio Gambaletta (VittGam)'s avatar
      ath9k: Add a module parameter to invert LED polarity. · 7ab5b39f
      Vittorio Gambaletta (VittGam) authored
      commit cd84042c upstream.
      
      The LED can be active high instead of active low on some hardware.
      
      Add the led_active_high module parameter. It defaults to -1 to obey
      platform data as before.
      
      Setting the parameter to 1 or 0 will force the LED respectively
      active high or active low.
      
      Cc: <linux-wireless@vger.kernel.org>
      Cc: <ath9k-devel@qca.qualcomm.com>
      Cc: <ath9k-devel@lists.ath9k.org>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7ab5b39f
    • Krzysztof Kozlowski's avatar
      crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks · 0ea72331
      Krzysztof Kozlowski authored
      commit 79152e8d upstream.
      
      The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
      testing 8 kB size blocks:
      
      	$ sudo modprobe tcrypt sec=1 mode=500
      	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
      	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
      	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
      	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
      	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
      	test 4 (128 bit key, 8192 byte blocks):
      
      This was caused by a race issue of missed BRDMA_DONE ("Block cipher
      Receiving DMA") interrupt. Device starts processing the data in DMA mode
      immediately after setting length of DMA block: receiving (FCBRDMAL) or
      transmitting (FCBTDMAL). The driver sets these lengths from interrupt
      handler through s5p_set_dma_indata() function (or xxx_setdata()).
      
      However the interrupt handler was first dealing with receive buffer
      (dma-unmap old, dma-map new, set receive block length which starts the
      operation), then with transmit buffer and finally was clearing pending
      interrupts (FCINTPEND). Because of the time window between setting
      receive buffer length and clearing pending interrupts, the operation on
      receive buffer could end already and driver would miss new interrupt.
      
      User manual for Exynos5422 confirms in example code that setting DMA
      block lengths should be the last operation.
      
      The tcrypt hang could be also observed in following blocked-task dmesg:
      
      INFO: task modprobe:258 blocked for more than 120 seconds.
            Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      modprobe        D c06b09d8     0   258    256 0x00000000
      [<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac)
      [<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178)
      [<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144)
      [<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt])
      [<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt])
      [<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
      [<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c)
      [<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac)
      [<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08)
      [<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98)
      [<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
      
      Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [ kamal: backport to 4.2-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0ea72331
    • Ulf Hansson's avatar
      PM / Runtime: Fix error path in pm_runtime_force_resume() · 69a61689
      Ulf Hansson authored
      commit 0ae3aeef upstream.
      
      As pm_runtime_set_active() may fail because the device's parent isn't
      active, we can end up executing the ->runtime_resume() callback for the
      device when it isn't allowed.
      
      Fix this by invoking pm_runtime_set_active() before running the callback
      and let's also deal with the error code.
      
      Fixes: 37f20416 (PM: Add pm_runtime_suspend|resume_force functions)
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      69a61689
    • Hari Bathini's avatar
      powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel · bc6af97a
      Hari Bathini authored
      commit 8ed8ab40 upstream.
      
      Some of the interrupt vectors on 64-bit POWER server processors are only
      32 bytes long (8 instructions), which is not enough for the full
      first-level interrupt handler. For these we need to branch to an
      out-of-line (OOL) handler. But when we are running a relocatable kernel,
      interrupt vectors till __end_interrupts marker are copied down to real
      address 0x100. So, branching to labels (ie. OOL handlers) outside this
      section must be handled differently (see LOAD_HANDLER()), considering
      relocatable kernel, which would need at least 4 instructions.
      
      However, branching from interrupt vector means that we corrupt the
      CFAR (come-from address register) on POWER7 and later processors as
      mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)
      that contains the part up to the point where the CFAR is saved in the
      PACA should be part of the short interrupt vectors before we branch out
      to OOL handlers.
      
      But as mentioned already, there are interrupt vectors on 64-bit POWER
      server processors that are only 32 bytes long (like vectors 0x4f00,
      0x4f20, etc.), which cannot accomodate the above two cases at the same
      time owing to space constraint. Currently, in these interrupt vectors,
      we simply branch out to OOL handlers, without using LOAD_HANDLER(),
      which leaves us vulnerable when running a relocatable kernel (eg. kdump
      case). While this has been the case for sometime now and kdump is used
      widely, we were fortunate not to see any problems so far, for three
      reasons:
      
        1. In almost all cases, production kernel (relocatable) is used for
           kdump as well, which would mean that crashed kernel's OOL handler
           would be at the same place where we end up branching to, from short
           interrupt vector of kdump kernel.
        2. Also, OOL handler was unlikely the reason for crash in almost all
           the kdump scenarios, which meant we had a sane OOL handler from
           crashed kernel that we branched to.
        3. On most 64-bit POWER server processors, page size is large enough
           that marking interrupt vector code as executable (see commit
           429d2e83) leads to marking OOL handler code from crashed kernel,
           that sits right below interrupt vector code from kdump kernel, as
           executable as well.
      
      Let us fix this by moving the __end_interrupts marker down past OOL
      handlers to make sure that we also copy OOL handlers to real address
      0x100 when running a relocatable kernel.
      
      This fix has been tested successfully in kdump scenario, on an LPAR with
      4K page size by using different default/production kernel and kdump
      kernel.
      
      Also tested by manually corrupting the OOL handlers in the first kernel
      and then kdump'ing, and then causing the OOL handlers to fire - mpe.
      
      Fixes: c1fb6816 ("powerpc: Add relocation on exception vector handlers")
      Signed-off-by: default avatarHari Bathini <hbathini@linux.vnet.ibm.com>
      Signed-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      bc6af97a
    • Takashi Iwai's avatar
      Bluetooth: vhci: Fix race at creating hci device · 45e5d936
      Takashi Iwai authored
      commit c7c999cb upstream.
      
      hci_vhci driver creates a hci device object dynamically upon each
      HCI_VENDOR_PKT write.  Although it checks the already created object
      and returns an error, it's still racy and may build multiple hci_dev
      objects concurrently when parallel writes are performed, as the device
      tracks only a single hci_dev object.
      
      This patch introduces a mutex to protect against the concurrent device
      creations.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      45e5d936
    • Michal Nazarewicz's avatar
      usb: f_mass_storage: test whether thread is running before starting another · 07888464
      Michal Nazarewicz authored
      commit f78bbcae upstream.
      
      When binding the function to usb_configuration, check whether the thread
      is running before starting another one.  Without that, when function
      instance is added to multiple configurations, fsg_bing starts multiple
      threads with all but the latest one being forgotten by the driver.  This
      leads to obvious thread leaks, possible lockups when trying to halt the
      machine and possible more issues.
      
      This fixes issues with legacy/multi¹ gadget as well as configfs gadgets
      when mass_storage function is added to multiple configurations.
      
      This change also simplifies API since the legacy gadgets no longer need
      to worry about starting the thread by themselves (which was where bug
      in legacy/multi was in the first place).
      
      N.B., this patch doesn’t address adding single mass_storage function
      instance to a single configuration twice.  Thankfully, there’s no
      legitimate reason for such setup plus, if I’m not mistaken, configfs
      gadget doesn’t even allow it to be expressed.
      
      ¹ I have no example failure though.  Conclusion that legacy/multi has
        a bug is based purely on me reading the code.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Tested-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      [ kamal: backport to 4.2-stable: fsg_bind() decl 'common';
        no change to nokia.c (no fsg_opts) ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      
      squash! 334f47b
      07888464
    • Johannes Thumshirn's avatar
      Revert "scsi: fix soft lockup in scsi_remove_target() on module removal" · 01d6d113
      Johannes Thumshirn authored
      commit 305c2e71 upstream.
      
      Now that we've done a more comprehensive fix with the intermediate
      target state we can remove the previous hack introduced with commit
      90a88d6e ("scsi: fix soft lockup in scsi_remove_target() on module
      removal").
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      01d6d113
    • Johannes Thumshirn's avatar
      scsi: Add intermediate STARGET_REMOVE state to scsi_target_state · 2312f972
      Johannes Thumshirn authored
      commit f05795d3 upstream.
      
      Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
      running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
      state is only valid in the path from scsi_remove_target() to
      scsi_target_destroy() indicating this target is going to be removed.
      
      This re-fixes the problem introduced in commits bc3f02a7 ("[SCSI]
      scsi_remove_target: fix softlockup regression on hot remove") and
      40998193 ("scsi: restart list search after unlock in
      scsi_remove_target") in a more comprehensive way.
      
      [mkp: Included James' fix for scsi_target_destroy()]
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Fixes: 40998193Reported-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Tested-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarJames Bottomley <jejb@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2312f972
    • Tiffany Lin's avatar
      [media] media: v4l2-compat-ioctl32: fix missing reserved field copy in put_v4l2_create32 · 9e66000d
      Tiffany Lin authored
      commit baf43c6e upstream.
      
      In v4l2-compliance utility, test VIDIOC_CREATE_BUFS will check whether reserved
      filed of v4l2_create_buffers filled with zero
      Reserved field is filled with zero in v4l_create_bufs.
      This patch copy reserved field of v4l2_create_buffer from kernel space to user
      space
      Signed-off-by: default avatarTiffany Lin <tiffany.lin@mediatek.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9e66000d
    • Dave Gerlach's avatar
      cpuidle: Indicate when a device has been unregistered · 1197cd5b
      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>
      1197cd5b
    • Jiri Slaby's avatar
      Bluetooth: vhci: purge unhandled skbs · 63198342
      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>
      63198342
    • Jiri Slaby's avatar
      Bluetooth: vhci: fix open_timeout vs. hdev race · d1bd7df8
      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>
      d1bd7df8
    • Itai Handler's avatar
      drm/gma500: Fix possible out of bounds read · ee490f80
      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>
      ee490f80
    • Joseph Salisbury's avatar
      ath5k: Change led pin configuration for compaq c700 laptop · 10ba2be4
      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>
      10ba2be4
    • Anilkumar Kolli's avatar
      ath10k: fix debugfs pktlog_filter write · 5231c3df
      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>
      5231c3df
    • Lyude's avatar
      drm/i915: Fix race condition in intel_dp_destroy_mst_connector() · 0d5bd657
      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>
      0d5bd657
    • Rajkumar Manoharan's avatar
      ath10k: fix firmware assert in monitor mode · cd6e21c1
      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>
      cd6e21c1
  2. 22 Jun, 2016 1 commit
    • Hugh Dickins's avatar
      mm: migrate dirty page without clear_page_dirty_for_io etc · f1032b34
      Hugh Dickins authored
      commit 42cb14b1 upstream.
      
      clear_page_dirty_for_io() has accumulated writeback and memcg subtleties
      since v2.6.16 first introduced page migration; and the set_page_dirty()
      which completed its migration of PageDirty, later had to be moderated to
      __set_page_dirty_nobuffers(); then PageSwapBacked had to skip that too.
      
      No actual problems seen with this procedure recently, but if you look into
      what the clear_page_dirty_for_io(page)+set_page_dirty(newpage) is actually
      achieving, it turns out to be nothing more than moving the PageDirty flag,
      and its NR_FILE_DIRTY stat from one zone to another.
      
      It would be good to avoid a pile of irrelevant decrementations and
      incrementations, and improper event counting, and unnecessary descent of
      the radix_tree under tree_lock (to set the PAGECACHE_TAG_DIRTY which
      radix_tree_replace_slot() left in place anyway).
      
      Do the NR_FILE_DIRTY movement, like the other stats movements, while
      interrupts still disabled in migrate_page_move_mapping(); and don't even
      bother if the zone is the same.  Do the PageDirty movement there under
      tree_lock too, where old page is frozen and newpage not yet visible:
      bearing in mind that as soon as newpage becomes visible in radix_tree, an
      un-page-locked set_page_dirty() might interfere (or perhaps that's just
      not possible: anything doing so should already hold an additional
      reference to the old page, preventing its migration; but play safe).
      
      But we do still need to transfer PageDirty in migrate_page_copy(), for
      those who don't go the mapping route through migrate_page_move_mapping().
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: adjust context.  This is not just an optimisation,
       but turned out to fix a possible oops (CVE-2016-3070).]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f1032b34
  3. 31 May, 2016 1 commit
  4. 25 May, 2016 20 commits