Skip to content

L
linux
Switch branch/tag
  1. 06 Jul, 2016 11 commits
    • 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
  3. 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
  5. 31 May, 2016 1 commit
  7. 25 May, 2016 27 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7