This is a note to let you know that I've just added the patch titled
IB/core: Avoid unnecessary return value check
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-avoid-unnecessary-return-value-check.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2e4c85c6edc80fa532b2c7e1eb3597ef4d4bbb8f Mon Sep 17 00:00:00 2001
From: Parav Pandit <parav(a)mellanox.com>
Date: Thu, 2 Nov 2017 15:22:27 +0200
Subject: IB/core: Avoid unnecessary return value check
From: Parav Pandit <parav(a)mellanox.com>
commit 2e4c85c6edc80fa532b2c7e1eb3597ef4d4bbb8f upstream.
Since there is nothing done with non zero return value, such check is
avoided.
Signed-off-by: Parav Pandit <parav(a)mellanox.com>
Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/security.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
--- a/drivers/infiniband/core/security.c
+++ b/drivers/infiniband/core/security.c
@@ -697,20 +697,13 @@ void ib_mad_agent_security_cleanup(struc
int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index)
{
- int ret;
-
if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed)
return -EACCES;
- ret = ib_security_pkey_access(map->agent.device,
- map->agent.port_num,
- pkey_index,
- map->agent.security);
-
- if (ret)
- return ret;
-
- return 0;
+ return ib_security_pkey_access(map->agent.device,
+ map->agent.port_num,
+ pkey_index,
+ map->agent.security);
}
#endif /* CONFIG_SECURITY_INFINIBAND */
Patches currently in stable-queue which might be from parav(a)mellanox.com are
queue-4.14/ib-core-avoid-unnecessary-return-value-check.patch
queue-4.14/ib-core-only-enforce-security-for-infiniband.patch
This is a note to let you know that I've just added the patch titled
hv: kvp: Avoid reading past allocated blocks from KVP file
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 297d6b6e56c2977fc504c61bbeeaa21296923f89 Mon Sep 17 00:00:00 2001
From: Paul Meyer <Paul.Meyer(a)microsoft.com>
Date: Tue, 14 Nov 2017 13:06:47 -0700
Subject: hv: kvp: Avoid reading past allocated blocks from KVP file
From: Paul Meyer <Paul.Meyer(a)microsoft.com>
commit 297d6b6e56c2977fc504c61bbeeaa21296923f89 upstream.
While reading in more than one block (50) of KVP records, the allocation
goes per block, but the reads used the total number of allocated records
(without resetting the pointer/stream). This causes the records buffer to
overrun when the refresh reads more than one block over the previous
capacity (e.g. reading more than 100 KVP records whereas the in-memory
database was empty before).
Fix this by reading the correct number of KVP records from file each time.
Signed-off-by: Paul Meyer <Paul.Meyer(a)microsoft.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/hv/hv_kvp_daemon.c | 70 +++++++++--------------------------------------
1 file changed, 14 insertions(+), 56 deletions(-)
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -193,11 +193,14 @@ static void kvp_update_mem_state(int poo
for (;;) {
readp = &record[records_read];
records_read += fread(readp, sizeof(struct kvp_record),
- ENTRIES_PER_BLOCK * num_blocks,
- filep);
+ ENTRIES_PER_BLOCK * num_blocks - records_read,
+ filep);
if (ferror(filep)) {
- syslog(LOG_ERR, "Failed to read file, pool: %d", pool);
+ syslog(LOG_ERR,
+ "Failed to read file, pool: %d; error: %d %s",
+ pool, errno, strerror(errno));
+ kvp_release_lock(pool);
exit(EXIT_FAILURE);
}
@@ -210,6 +213,7 @@ static void kvp_update_mem_state(int poo
if (record == NULL) {
syslog(LOG_ERR, "malloc failed");
+ kvp_release_lock(pool);
exit(EXIT_FAILURE);
}
continue;
@@ -224,15 +228,11 @@ static void kvp_update_mem_state(int poo
fclose(filep);
kvp_release_lock(pool);
}
+
static int kvp_file_init(void)
{
int fd;
- FILE *filep;
- size_t records_read;
char *fname;
- struct kvp_record *record;
- struct kvp_record *readp;
- int num_blocks;
int i;
int alloc_unit = sizeof(struct kvp_record) * ENTRIES_PER_BLOCK;
@@ -246,61 +246,19 @@ static int kvp_file_init(void)
for (i = 0; i < KVP_POOL_COUNT; i++) {
fname = kvp_file_info[i].fname;
- records_read = 0;
- num_blocks = 1;
sprintf(fname, "%s/.kvp_pool_%d", KVP_CONFIG_LOC, i);
fd = open(fname, O_RDWR | O_CREAT | O_CLOEXEC, 0644 /* rw-r--r-- */);
if (fd == -1)
return 1;
-
- filep = fopen(fname, "re");
- if (!filep) {
- close(fd);
- return 1;
- }
-
- record = malloc(alloc_unit * num_blocks);
- if (record == NULL) {
- fclose(filep);
- close(fd);
- return 1;
- }
- for (;;) {
- readp = &record[records_read];
- records_read += fread(readp, sizeof(struct kvp_record),
- ENTRIES_PER_BLOCK,
- filep);
-
- if (ferror(filep)) {
- syslog(LOG_ERR, "Failed to read file, pool: %d",
- i);
- exit(EXIT_FAILURE);
- }
-
- if (!feof(filep)) {
- /*
- * We have more data to read.
- */
- num_blocks++;
- record = realloc(record, alloc_unit *
- num_blocks);
- if (record == NULL) {
- fclose(filep);
- close(fd);
- return 1;
- }
- continue;
- }
- break;
- }
kvp_file_info[i].fd = fd;
- kvp_file_info[i].num_blocks = num_blocks;
- kvp_file_info[i].records = record;
- kvp_file_info[i].num_records = records_read;
- fclose(filep);
-
+ kvp_file_info[i].num_blocks = 1;
+ kvp_file_info[i].records = malloc(alloc_unit);
+ if (kvp_file_info[i].records == NULL)
+ return 1;
+ kvp_file_info[i].num_records = 0;
+ kvp_update_mem_state(i);
}
return 0;
Patches currently in stable-queue which might be from Paul.Meyer(a)microsoft.com are
queue-4.14/hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.patch
This is a note to let you know that I've just added the patch titled
firmware: vpd: Tie firmware kobject to device lifetime
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e4b28b3c3a405b251fa25db58abe1512814a680a Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Wed, 15 Nov 2017 13:00:44 -0800
Subject: firmware: vpd: Tie firmware kobject to device lifetime
From: Guenter Roeck <linux(a)roeck-us.net>
commit e4b28b3c3a405b251fa25db58abe1512814a680a upstream.
It doesn't make sense to have /sys/firmware/vpd if the device is not
instantiated, so tie its lifetime to the device.
Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Tested-by: Randy Dunlap <rdunlap(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/google/vpd.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
--- a/drivers/firmware/google/vpd.c
+++ b/drivers/firmware/google/vpd.c
@@ -295,7 +295,17 @@ static int vpd_probe(struct platform_dev
if (ret)
return ret;
- return vpd_sections_init(entry.cbmem_addr);
+ vpd_kobj = kobject_create_and_add("vpd", firmware_kobj);
+ if (!vpd_kobj)
+ return -ENOMEM;
+
+ ret = vpd_sections_init(entry.cbmem_addr);
+ if (ret) {
+ kobject_put(vpd_kobj);
+ return ret;
+ }
+
+ return 0;
}
static int vpd_remove(struct platform_device *pdev)
@@ -303,6 +313,8 @@ static int vpd_remove(struct platform_de
vpd_section_destroy(&ro_vpd);
vpd_section_destroy(&rw_vpd);
+ kobject_put(vpd_kobj);
+
return 0;
}
@@ -322,10 +334,6 @@ static int __init vpd_platform_init(void
if (IS_ERR(pdev))
return PTR_ERR(pdev);
- vpd_kobj = kobject_create_and_add("vpd", firmware_kobj);
- if (!vpd_kobj)
- return -ENOMEM;
-
platform_driver_register(&vpd_driver);
return 0;
@@ -333,7 +341,6 @@ static int __init vpd_platform_init(void
static void __exit vpd_platform_exit(void)
{
- kobject_put(vpd_kobj);
}
module_init(vpd_platform_init);
Patches currently in stable-queue which might be from linux(a)roeck-us.net are
queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch
queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch
queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch
This is a note to let you know that I've just added the patch titled
firmware: vpd: Fix platform driver and device registration/unregistration
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0631fb8b027f5968c2f5031f0b3ff7be3e4bebcc Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Wed, 15 Nov 2017 13:00:45 -0800
Subject: firmware: vpd: Fix platform driver and device registration/unregistration
From: Guenter Roeck <linux(a)roeck-us.net>
commit 0631fb8b027f5968c2f5031f0b3ff7be3e4bebcc upstream.
The driver exit function needs to unregister both platform device and
driver. Also, during registration, register driver first and perform
error checks.
Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Tested-by: Randy Dunlap <rdunlap(a)infradead.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/google/vpd.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
--- a/drivers/firmware/google/vpd.c
+++ b/drivers/firmware/google/vpd.c
@@ -326,21 +326,29 @@ static struct platform_driver vpd_driver
},
};
+static struct platform_device *vpd_pdev;
+
static int __init vpd_platform_init(void)
{
- struct platform_device *pdev;
-
- pdev = platform_device_register_simple("vpd", -1, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
+ int ret;
- platform_driver_register(&vpd_driver);
+ ret = platform_driver_register(&vpd_driver);
+ if (ret)
+ return ret;
+
+ vpd_pdev = platform_device_register_simple("vpd", -1, NULL, 0);
+ if (IS_ERR(vpd_pdev)) {
+ platform_driver_unregister(&vpd_driver);
+ return PTR_ERR(vpd_pdev);
+ }
return 0;
}
static void __exit vpd_platform_exit(void)
{
+ platform_device_unregister(vpd_pdev);
+ platform_driver_unregister(&vpd_driver);
}
module_init(vpd_platform_init);
Patches currently in stable-queue which might be from linux(a)roeck-us.net are
queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch
queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch
queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch
This is a note to let you know that I've just added the patch titled
firmware: vpd: Destroy vpd sections in remove function
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
firmware-vpd-destroy-vpd-sections-in-remove-function.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 811d7e0215fb738fb9a9f0bcb1276516ad161ed1 Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux(a)roeck-us.net>
Date: Wed, 15 Nov 2017 13:00:43 -0800
Subject: firmware: vpd: Destroy vpd sections in remove function
From: Guenter Roeck <linux(a)roeck-us.net>
commit 811d7e0215fb738fb9a9f0bcb1276516ad161ed1 upstream.
vpd sections are initialized during probe and thus should be destroyed
in the remove function.
Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Tested-by: Randy Dunlap <rdunlap(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/google/vpd.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/drivers/firmware/google/vpd.c
+++ b/drivers/firmware/google/vpd.c
@@ -298,8 +298,17 @@ static int vpd_probe(struct platform_dev
return vpd_sections_init(entry.cbmem_addr);
}
+static int vpd_remove(struct platform_device *pdev)
+{
+ vpd_section_destroy(&ro_vpd);
+ vpd_section_destroy(&rw_vpd);
+
+ return 0;
+}
+
static struct platform_driver vpd_driver = {
.probe = vpd_probe,
+ .remove = vpd_remove,
.driver = {
.name = "vpd",
},
@@ -324,8 +333,6 @@ static int __init vpd_platform_init(void
static void __exit vpd_platform_exit(void)
{
- vpd_section_destroy(&ro_vpd);
- vpd_section_destroy(&rw_vpd);
kobject_put(vpd_kobj);
}
Patches currently in stable-queue which might be from linux(a)roeck-us.net are
queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch
queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch
queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch
This is a note to let you know that I've just added the patch titled
firmware: cleanup FIRMWARE_IN_KERNEL message
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
firmware-cleanup-firmware_in_kernel-message.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0946b2fb38fdb6585a5ac3ca84ac73924f645952 Mon Sep 17 00:00:00 2001
From: "Robin H. Johnson" <robbat2(a)gentoo.org>
Date: Thu, 16 Nov 2017 14:36:12 -0800
Subject: firmware: cleanup FIRMWARE_IN_KERNEL message
From: Robin H. Johnson <robbat2(a)gentoo.org>
commit 0946b2fb38fdb6585a5ac3ca84ac73924f645952 upstream.
The help for FIRMWARE_IN_KERNEL still references the firmware_install
command that was recently removed by commit 5620a0d1aacd ("firmware:
delete in-kernel firmware").
Clean up the message to direct the user to their distribution's
linux-firmware package, and remove any reference to firmware being
included in the kernel source tree.
Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware").
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: David Woodhouse <dwmw2(a)infradead.org>
Signed-off-by: Robin H. Johnson <robbat2(a)gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/Kconfig | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -91,22 +91,23 @@ config FIRMWARE_IN_KERNEL
depends on FW_LOADER
default y
help
- The kernel source tree includes a number of firmware 'blobs'
- that are used by various drivers. The recommended way to
- use these is to run "make firmware_install", which, after
- converting ihex files to binary, copies all of the needed
- binary files in firmware/ to /lib/firmware/ on your system so
- that they can be loaded by userspace helpers on request.
+ Various drivers in the kernel source tree may require firmware,
+ which is generally available in your distribution's linux-firmware
+ package.
+
+ The linux-firmware package should install firmware into
+ /lib/firmware/ on your system, so they can be loaded by userspace
+ helpers on request.
Enabling this option will build each required firmware blob
- into the kernel directly, where request_firmware() will find
- them without having to call out to userspace. This may be
- useful if your root file system requires a device that uses
- such firmware and do not wish to use an initrd.
+ specified by EXTRA_FIRMWARE into the kernel directly, where
+ request_firmware() will find them without having to call out to
+ userspace. This may be useful if your root file system requires a
+ device that uses such firmware and you do not wish to use an
+ initrd.
This single option controls the inclusion of firmware for
- every driver that uses request_firmware() and ships its
- firmware in the kernel source tree, which avoids a
+ every driver that uses request_firmware(), which avoids a
proliferation of 'Include firmware for xxx device' options.
Say 'N' and let firmware be loaded from userspace.
Patches currently in stable-queue which might be from robbat2(a)gentoo.org are
queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch
This is a note to let you know that I've just added the patch titled
efi/esrt: Use memunmap() instead of kfree() to free the remapping
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 89c5a2d34bda58319e3075e8e7dd727ea25a435c Mon Sep 17 00:00:00 2001
From: Pan Bian <bianpan2016(a)163.com>
Date: Wed, 6 Dec 2017 09:50:09 +0000
Subject: efi/esrt: Use memunmap() instead of kfree() to free the remapping
From: Pan Bian <bianpan2016(a)163.com>
commit 89c5a2d34bda58319e3075e8e7dd727ea25a435c upstream.
The remapping result of memremap() should be freed with memunmap(), not kfree().
Signed-off-by: Pan Bian <bianpan2016(a)163.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matt Fleming <matt(a)codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-efi(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20171206095010.24170-3-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/efi/esrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -428,7 +428,7 @@ err_remove_group:
err_remove_esrt:
kobject_put(esrt_kobj);
err:
- kfree(esrt);
+ memunmap(esrt);
esrt = NULL;
return error;
}
Patches currently in stable-queue which might be from bianpan2016(a)163.com are
queue-4.14/efi-esrt-use-memunmap-instead-of-kfree-to-free-the-remapping.patch
queue-4.14/iio-adc-cpcap-fix-incorrect-validation.patch
This is a note to let you know that I've just added the patch titled
drm: safely free connectors from connector_iter
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-safely-free-connectors-from-connector_iter.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a703c55004e1c5076d57e43771b3e11117796ea0 Mon Sep 17 00:00:00 2001
From: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Date: Mon, 4 Dec 2017 21:48:18 +0100
Subject: drm: safely free connectors from connector_iter
From: Daniel Vetter <daniel.vetter(a)ffwll.ch>
commit a703c55004e1c5076d57e43771b3e11117796ea0 upstream.
In
commit 613051dac40da1751ab269572766d3348d45a197
Author: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Date: Wed Dec 14 00:08:06 2016 +0100
drm: locking&new iterators for connector_list
we've went to extreme lengths to make sure connector iterations works
in any context, without introducing any additional locking context.
This worked, except for a small fumble in the implementation:
When we actually race with a concurrent connector unplug event, and
our temporary connector reference turns out to be the final one, then
everything breaks: We call the connector release function from
whatever context we happen to be in, which can be an irq/atomic
context. And connector freeing grabs all kinds of locks and stuff.
Fix this by creating a specially safe put function for connetor_iter,
which (in this rare case) punts the cleanup to a worker.
Reported-by: Ben Widawsky <ben(a)bwidawsk.net>
Cc: Ben Widawsky <ben(a)bwidawsk.net>
Fixes: 613051dac40d ("drm: locking&new iterators for connector_list")
Cc: Dave Airlie <airlied(a)gmail.com>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Sean Paul <seanpaul(a)chromium.org>
Reviewed-by: Dave Airlie <airlied(a)gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171204204818.24745-1-daniel…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_connector.c | 28 ++++++++++++++++++++++++++--
drivers/gpu/drm/drm_mode_config.c | 2 ++
include/drm/drm_connector.h | 8 ++++++++
3 files changed, 36 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -152,6 +152,16 @@ static void drm_connector_free(struct kr
connector->funcs->destroy(connector);
}
+static void drm_connector_free_work_fn(struct work_struct *work)
+{
+ struct drm_connector *connector =
+ container_of(work, struct drm_connector, free_work);
+ struct drm_device *dev = connector->dev;
+
+ drm_mode_object_unregister(dev, &connector->base);
+ connector->funcs->destroy(connector);
+}
+
/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
@@ -181,6 +191,8 @@ int drm_connector_init(struct drm_device
if (ret)
return ret;
+ INIT_WORK(&connector->free_work, drm_connector_free_work_fn);
+
connector->base.properties = &connector->properties;
connector->dev = dev;
connector->funcs = funcs;
@@ -525,6 +537,18 @@ void drm_connector_list_iter_begin(struc
}
EXPORT_SYMBOL(drm_connector_list_iter_begin);
+/*
+ * Extra-safe connector put function that works in any context. Should only be
+ * used from the connector_iter functions, where we never really expect to
+ * actually release the connector when dropping our final reference.
+ */
+static void
+drm_connector_put_safe(struct drm_connector *conn)
+{
+ if (refcount_dec_and_test(&conn->base.refcount.refcount))
+ schedule_work(&conn->free_work);
+}
+
/**
* drm_connector_list_iter_next - return next connector
* @iter: connectr_list iterator
@@ -557,7 +581,7 @@ drm_connector_list_iter_next(struct drm_
spin_unlock_irqrestore(&config->connector_list_lock, flags);
if (old_conn)
- drm_connector_put(old_conn);
+ drm_connector_put_safe(old_conn);
return iter->conn;
}
@@ -576,7 +600,7 @@ void drm_connector_list_iter_end(struct
{
iter->dev = NULL;
if (iter->conn)
- drm_connector_put(iter->conn);
+ drm_connector_put_safe(iter->conn);
lock_release(&connector_list_iter_dep_map, 0, _RET_IP_);
}
EXPORT_SYMBOL(drm_connector_list_iter_end);
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -428,6 +428,8 @@ void drm_mode_config_cleanup(struct drm_
drm_connector_put(connector);
}
drm_connector_list_iter_end(&conn_iter);
+ /* connector_iter drops references in a work item. */
+ flush_scheduled_work();
if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter)
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -905,6 +905,14 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+ /**
+ * @free_work:
+ *
+ * Work used only by &drm_connector_iter to be able to clean up a
+ * connector from any context.
+ */
+ struct work_struct free_work;
};
#define obj_to_connector(x) container_of(x, struct drm_connector, base)
Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are
queue-4.14/drm-safely-free-connectors-from-connector_iter.patch
queue-4.14/drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Fix vblank timestamp/frame counter jumps on gen2
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a87e55f89f0b0dc541d89248a8445635936a3858 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Wed, 29 Nov 2017 17:37:30 +0200
Subject: drm/i915: Fix vblank timestamp/frame counter jumps on gen2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
commit a87e55f89f0b0dc541d89248a8445635936a3858 upstream.
Previously I was under the impression that the scanline counter
reads 0 when the pipe is off. Turns out that's not correct, and
instead the scanline counter simply stops when the pipe stops, and
it retains it's last value until the pipe starts up again, at which
point the scanline counter jumps to vblank start.
These jumps can cause the timestamp to jump backwards by one frame.
Since we use the timestamps to guesstimage also the frame counter
value on gen2, that would cause the frame counter to also jump
backwards, which leads to a massice difference from the previous value.
The end result is that flips/vblank events don't appear to complete as
they're stuck waiting for the frame counter to catch up to that massive
difference.
Fix the problem properly by actually making sure the scanline counter
has started to move before we assume that it's safe to enable vblank
processing.
v2: Less pointless duplication in the code (Chris)
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-1-ville.s…
(cherry picked from commit 8fedd64dabc86d0f31a0d1e152be3aa23c323553)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_display.c | 53 +++++++++++++++++++++++------------
1 file changed, 36 insertions(+), 17 deletions(-)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1000,7 +1000,8 @@ enum transcoder intel_pipe_to_cpu_transc
return crtc->config->cpu_transcoder;
}
-static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe)
+static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
{
i915_reg_t reg = PIPEDSL(pipe);
u32 line1, line2;
@@ -1015,7 +1016,28 @@ static bool pipe_dsl_stopped(struct drm_
msleep(5);
line2 = I915_READ(reg) & line_mask;
- return line1 == line2;
+ return line1 != line2;
+}
+
+static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc, bool state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Wait for the display line to settle/start moving */
+ if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
+ DRM_ERROR("pipe %c scanline %s wait timed out\n",
+ pipe_name(pipe), onoff(state));
+}
+
+static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
+{
+ wait_for_pipe_scanline_moving(crtc, false);
+}
+
+static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc)
+{
+ wait_for_pipe_scanline_moving(crtc, true);
}
/*
@@ -1038,7 +1060,6 @@ static void intel_wait_for_pipe_off(stru
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
- enum pipe pipe = crtc->pipe;
if (INTEL_GEN(dev_priv) >= 4) {
i915_reg_t reg = PIPECONF(cpu_transcoder);
@@ -1049,9 +1070,7 @@ static void intel_wait_for_pipe_off(stru
100))
WARN(1, "pipe_off wait timed out\n");
} else {
- /* Wait for the display line to settle */
- if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
- WARN(1, "pipe_off wait timed out\n");
+ intel_wait_for_pipe_scanline_stopped(crtc);
}
}
@@ -1944,15 +1963,14 @@ static void intel_enable_pipe(struct int
POSTING_READ(reg);
/*
- * Until the pipe starts DSL will read as 0, which would cause
- * an apparent vblank timestamp jump, which messes up also the
- * frame count when it's derived from the timestamps. So let's
- * wait for the pipe to start properly before we call
- * drm_crtc_vblank_on()
- */
- if (dev->max_vblank_count == 0 &&
- wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50))
- DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe));
+ * Until the pipe starts PIPEDSL reads will return a stale value,
+ * which causes an apparent vblank timestamp jump when PIPEDSL
+ * resets to its proper value. That also messes up the frame count
+ * when it's derived from the timestamps. So let's wait for the
+ * pipe to start properly before we call drm_crtc_vblank_on()
+ */
+ if (dev->max_vblank_count == 0)
+ intel_wait_for_pipe_scanline_moving(crtc);
}
/**
@@ -14682,6 +14700,8 @@ void i830_enable_pipe(struct drm_i915_pr
void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+
DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
pipe_name(pipe));
@@ -14691,8 +14711,7 @@ void i830_disable_pipe(struct drm_i915_p
I915_WRITE(PIPECONF(pipe), 0);
POSTING_READ(PIPECONF(pipe));
- if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100))
- DRM_ERROR("pipe %c off wait timed out\n", pipe_name(pipe));
+ intel_wait_for_pipe_scanline_stopped(crtc);
I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
POSTING_READ(DPLL(pipe));
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-4.14/drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch
This is a note to let you know that I've just added the patch titled
drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 120a264f9c2782682027d931d83dcbd22e01da80 Mon Sep 17 00:00:00 2001
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
Date: Wed, 22 Nov 2017 14:14:47 +0100
Subject: drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
commit 120a264f9c2782682027d931d83dcbd22e01da80 upstream.
When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
are contiguous, because of the underlying dma_alloc_attrs() function
provides only such buffers. In such case it makes no sense to keep
BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
failures for buffer contiguity checks in the subsequent operations on GEM
objects.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Inki Dae <inki.dae(a)samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_cr
if (IS_ERR(exynos_gem))
return exynos_gem;
+ if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) {
+ /*
+ * when no IOMMU is available, all allocated buffers are
+ * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag
+ */
+ flags &= ~EXYNOS_BO_NONCONTIG;
+ DRM_WARN("Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer\n");
+ }
+
/* set memory type and cache attribute from user side. */
exynos_gem->flags = flags;
Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are
queue-4.14/drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch
queue-4.14/drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 510353a63796d467b41237ab4f136136f68c297d Mon Sep 17 00:00:00 2001
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
Date: Tue, 21 Nov 2017 08:49:36 +0100
Subject: drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
commit 510353a63796d467b41237ab4f136136f68c297d upstream.
get_modes() callback might be called asynchronously from the DRM core and
it is not synchronized with bridge_enable(), which sets proper runtime PM
state of the main DP device. Fix this by calling pm_runtime_get_sync()
before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and
analogix_dp_transfer() to ensure that main DP device is runtime active
when doing any access to its registers.
This fixes the following kernel issue on Samsung Exynos5250 Snow board:
Unhandled fault: imprecise external abort (0x406) at 0x00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: : 406 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 62 Comm: kworker/0:2 Not tainted 4.13.0-rc2-00364-g4a97a3da420b #3357
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events output_poll_execute
task: edc14800 task.stack: edcb2000
PC is at analogix_dp_transfer+0x15c/0x2fc
LR is at analogix_dp_transfer+0x134/0x2fc
pc : [<c0468538>] lr : [<c0468510>] psr: 60000013
sp : edcb3be8 ip : 0000002a fp : 00000001
r10: 00000000 r9 : edcb3cd8 r8 : edcb3c40
r7 : 00000000 r6 : edd3b380 r5 : edd3b010 r4 : 00000064
r3 : 00000000 r2 : f0ad3000 r1 : edcb3c40 r0 : edd3b010
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 4000406a DAC: 00000051
Process kworker/0:2 (pid: 62, stack limit = 0xedcb2210)
Stack: (0xedcb3be8 to 0xedcb4000)
[<c0468538>] (analogix_dp_transfer) from [<c0424ba4>] (drm_dp_i2c_do_msg+0x8c/0x2b4)
[<c0424ba4>] (drm_dp_i2c_do_msg) from [<c0424e64>] (drm_dp_i2c_xfer+0x98/0x214)
[<c0424e64>] (drm_dp_i2c_xfer) from [<c057b2d8>] (__i2c_transfer+0x140/0x29c)
[<c057b2d8>] (__i2c_transfer) from [<c057b4a4>] (i2c_transfer+0x70/0xe4)
[<c057b4a4>] (i2c_transfer) from [<c0441de4>] (drm_do_probe_ddc_edid+0xb4/0x114)
[<c0441de4>] (drm_do_probe_ddc_edid) from [<c0441e5c>] (drm_probe_ddc+0x18/0x28)
[<c0441e5c>] (drm_probe_ddc) from [<c0445728>] (drm_get_edid+0x124/0x2d4)
[<c0445728>] (drm_get_edid) from [<c0465ea0>] (analogix_dp_get_modes+0x90/0x114)
[<c0465ea0>] (analogix_dp_get_modes) from [<c0425e8c>] (drm_helper_probe_single_connector_modes+0x198/0x68c)
[<c0425e8c>] (drm_helper_probe_single_connector_modes) from [<c04325d4>] (drm_setup_crtcs+0x1b4/0xd18)
[<c04325d4>] (drm_setup_crtcs) from [<c04344a8>] (drm_fb_helper_hotplug_event+0x94/0xd0)
[<c04344a8>] (drm_fb_helper_hotplug_event) from [<c0425a50>] (drm_kms_helper_hotplug_event+0x24/0x28)
[<c0425a50>] (drm_kms_helper_hotplug_event) from [<c04263ec>] (output_poll_execute+0x6c/0x174)
[<c04263ec>] (output_poll_execute) from [<c0136f18>] (process_one_work+0x188/0x3fc)
[<c0136f18>] (process_one_work) from [<c01371f4>] (worker_thread+0x30/0x4b8)
[<c01371f4>] (worker_thread) from [<c013daf8>] (kthread+0x128/0x164)
[<c013daf8>] (kthread) from [<c0108510>] (ret_from_fork+0x14/0x24)
Code: 0a000002 ea000009 e2544001 0a00004a (e59537c8)
---[ end trace cddc7919c79f7878 ]---
Reported-by: Misha Komarovskiy <zombah(a)gmail.com>
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Archit Taneja <architt(a)codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121074936.22520-1-m.szyp…
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -946,7 +946,9 @@ static int analogix_dp_get_modes(struct
return 0;
}
+ pm_runtime_get_sync(dp->dev);
edid = drm_get_edid(connector, &dp->aux.ddc);
+ pm_runtime_put(dp->dev);
if (edid) {
drm_mode_connector_update_edid_property(&dp->connector,
edid);
Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are
queue-4.14/drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch
queue-4.14/drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch
This is a note to let you know that I've just added the patch titled
Drivers: hv: vmbus: Fix a rescind issue
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-hv-vmbus-fix-a-rescind-issue.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7fa32e5ec28b1609abc0b797b58267f725fc3964 Mon Sep 17 00:00:00 2001
From: "K. Y. Srinivasan" <kys(a)microsoft.com>
Date: Tue, 14 Nov 2017 06:53:33 -0700
Subject: Drivers: hv: vmbus: Fix a rescind issue
From: K. Y. Srinivasan <kys(a)microsoft.com>
commit 7fa32e5ec28b1609abc0b797b58267f725fc3964 upstream.
The current rescind processing code will not correctly handle
the case where the host immediately rescinds a channel that has
been offerred. In this case, we could be blocked in the open call and
since the channel is rescinded, the host will not respond and we could
be blocked forever in the vmbus open call.i Fix this problem.
Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hv/channel.c | 10 ++++++++--
drivers/hv/channel_mgmt.c | 7 ++++---
include/linux/hyperv.h | 1 +
3 files changed, 13 insertions(+), 5 deletions(-)
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -640,22 +640,28 @@ void vmbus_close(struct vmbus_channel *c
*/
return;
}
- mutex_lock(&vmbus_connection.channel_mutex);
/*
* Close all the sub-channels first and then close the
* primary channel.
*/
list_for_each_safe(cur, tmp, &channel->sc_list) {
cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
- vmbus_close_internal(cur_channel);
if (cur_channel->rescind) {
+ wait_for_completion(&cur_channel->rescind_event);
+ mutex_lock(&vmbus_connection.channel_mutex);
+ vmbus_close_internal(cur_channel);
hv_process_channel_removal(
cur_channel->offermsg.child_relid);
+ } else {
+ mutex_lock(&vmbus_connection.channel_mutex);
+ vmbus_close_internal(cur_channel);
}
+ mutex_unlock(&vmbus_connection.channel_mutex);
}
/*
* Now close the primary.
*/
+ mutex_lock(&vmbus_connection.channel_mutex);
vmbus_close_internal(channel);
mutex_unlock(&vmbus_connection.channel_mutex);
}
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -333,6 +333,7 @@ static struct vmbus_channel *alloc_chann
return NULL;
spin_lock_init(&channel->lock);
+ init_completion(&channel->rescind_event);
INIT_LIST_HEAD(&channel->sc_list);
INIT_LIST_HEAD(&channel->percpu_list);
@@ -883,6 +884,7 @@ static void vmbus_onoffer_rescind(struct
/*
* Now wait for offer handling to complete.
*/
+ vmbus_rescind_cleanup(channel);
while (READ_ONCE(channel->probe_done) == false) {
/*
* We wait here until any channel offer is currently
@@ -898,7 +900,6 @@ static void vmbus_onoffer_rescind(struct
if (channel->device_obj) {
if (channel->chn_rescind_callback) {
channel->chn_rescind_callback(channel);
- vmbus_rescind_cleanup(channel);
return;
}
/*
@@ -907,7 +908,6 @@ static void vmbus_onoffer_rescind(struct
*/
dev = get_device(&channel->device_obj->device);
if (dev) {
- vmbus_rescind_cleanup(channel);
vmbus_device_unregister(channel->device_obj);
put_device(dev);
}
@@ -921,13 +921,14 @@ static void vmbus_onoffer_rescind(struct
* 2. Then close the primary channel.
*/
mutex_lock(&vmbus_connection.channel_mutex);
- vmbus_rescind_cleanup(channel);
if (channel->state == CHANNEL_OPEN_STATE) {
/*
* The channel is currently not open;
* it is safe for us to cleanup the channel.
*/
hv_process_channel_removal(rescind->child_relid);
+ } else {
+ complete(&channel->rescind_event);
}
mutex_unlock(&vmbus_connection.channel_mutex);
}
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -708,6 +708,7 @@ struct vmbus_channel {
u8 monitor_bit;
bool rescind; /* got rescind msg */
+ struct completion rescind_event;
u32 ringbuffer_gpadlhandle;
Patches currently in stable-queue which might be from kys(a)microsoft.com are
queue-4.14/hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.patch
queue-4.14/drivers-hv-vmbus-fix-a-rescind-issue.patch
This is a note to let you know that I've just added the patch titled
bus: arm-ccn: Fix use of smp_processor_id() in preemptible context
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b18c2b9487d8e797fc0a757e57ac3645348c5fba Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 3 Oct 2017 18:14:12 +0100
Subject: bus: arm-ccn: Fix use of smp_processor_id() in preemptible context
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit b18c2b9487d8e797fc0a757e57ac3645348c5fba upstream.
Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system
results in the following splat:
[...]
arm-ccn e8000000.ccn: No access to interrupts, using timer.
BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
caller is debug_smp_processor_id+0x1c/0x28
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0 #6111
Hardware name: AMD Seattle/Seattle, BIOS 17:08:23 Jun 26 2017
Call trace:
[<ffff000008089e78>] dump_backtrace+0x0/0x278
[<ffff00000808a22c>] show_stack+0x24/0x30
[<ffff000008bc3bc4>] dump_stack+0x8c/0xb0
[<ffff00000852b534>] check_preemption_disabled+0xfc/0x100
[<ffff00000852b554>] debug_smp_processor_id+0x1c/0x28
[<ffff000008551bd8>] arm_ccn_probe+0x358/0x4f0
[...]
as we use smp_processor_id() in the wrong context.
Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug
registration, making sure that we don't race against a CPU down operation.
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Acked-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Pawel Moll <pawel.moll(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bus/arm-ccn.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/bus/arm-ccn.c
+++ b/drivers/bus/arm-ccn.c
@@ -1301,7 +1301,7 @@ static int arm_ccn_pmu_init(struct arm_c
}
/* Pick one CPU which we will use to collect data from CCN... */
- cpumask_set_cpu(smp_processor_id(), &ccn->dt.cpu);
+ cpumask_set_cpu(get_cpu(), &ccn->dt.cpu);
/* Also make sure that the overflow interrupt is handled by this CPU */
if (ccn->irq) {
@@ -1318,10 +1318,12 @@ static int arm_ccn_pmu_init(struct arm_c
cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCN_ONLINE,
&ccn->dt.node);
+ put_cpu();
return 0;
error_pmu_register:
error_set_affinity:
+ put_cpu();
error_choose_name:
ida_simple_remove(&arm_ccn_pmu_ida, ccn->dt.id);
for (i = 0; i < ccn->num_xps; i++)
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch
queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch
queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch
queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch
queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch
This is a note to let you know that I've just added the patch titled
bus: arm-ccn: Check memory allocation failure
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bus-arm-ccn-check-memory-allocation-failure.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 24771179c5c138f0ea3ef88b7972979f62f2d5db Mon Sep 17 00:00:00 2001
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 27 Aug 2017 11:06:50 +0100
Subject: bus: arm-ccn: Check memory allocation failure
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
commit 24771179c5c138f0ea3ef88b7972979f62f2d5db upstream.
Check memory allocation failures and return -ENOMEM in such cases
This avoids a potential NULL pointer dereference.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Acked-by: Scott Branden <scott.branden(a)broadcom.com>
Signed-off-by: Pawel Moll <pawel.moll(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bus/arm-ccn.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/bus/arm-ccn.c
+++ b/drivers/bus/arm-ccn.c
@@ -1271,6 +1271,10 @@ static int arm_ccn_pmu_init(struct arm_c
int len = snprintf(NULL, 0, "ccn_%d", ccn->dt.id);
name = devm_kzalloc(ccn->dev, len + 1, GFP_KERNEL);
+ if (!name) {
+ err = -ENOMEM;
+ goto error_choose_name;
+ }
snprintf(name, len + 1, "ccn_%d", ccn->dt.id);
}
@@ -1318,6 +1322,7 @@ static int arm_ccn_pmu_init(struct arm_c
error_pmu_register:
error_set_affinity:
+error_choose_name:
ida_simple_remove(&arm_ccn_pmu_ida, ccn->dt.id);
for (i = 0; i < ccn->num_xps; i++)
writel(0, ccn->xp[i].base + CCN_XP_DT_CONTROL);
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/bus-arm-ccn-check-memory-allocation-failure.patch
This is a note to let you know that I've just added the patch titled
bus: arm-cci: Fix use of smp_processor_id() in preemptible context
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4608af8aa53e7f3922ddee695d023b7bcd5cb35b Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 3 Oct 2017 18:14:13 +0100
Subject: bus: arm-cci: Fix use of smp_processor_id() in preemptible context
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 4608af8aa53e7f3922ddee695d023b7bcd5cb35b upstream.
The ARM CCI driver seem to be using smp_processor_id() in a
preemptible context, which is likely to make a DEBUG_PREMPT
kernel scream at boot time.
Turn this into a get_cpu()/put_cpu() that extends over the CPU
hotplug registration, making sure that we don't race against
a CPU down operation.
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Acked-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Pawel Moll <pawel.moll(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bus/arm-cci.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -1755,14 +1755,17 @@ static int cci_pmu_probe(struct platform
raw_spin_lock_init(&cci_pmu->hw_events.pmu_lock);
mutex_init(&cci_pmu->reserve_mutex);
atomic_set(&cci_pmu->active_events, 0);
- cpumask_set_cpu(smp_processor_id(), &cci_pmu->cpus);
+ cpumask_set_cpu(get_cpu(), &cci_pmu->cpus);
ret = cci_pmu_init(cci_pmu, pdev);
- if (ret)
+ if (ret) {
+ put_cpu();
return ret;
+ }
cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCI_ONLINE,
&cci_pmu->node);
+ put_cpu();
pr_info("ARM %s PMU driver probed", cci_pmu->model->name);
return 0;
}
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch
queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch
queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch
queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch
queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch
This is a note to let you know that I've just added the patch titled
btrfs: handle errors while updating refcounts in update_ref_for_cow
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-handle-errors-while-updating-refcounts-in-update_ref_for_cow.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 692826b2738101549f032a761a9191636e83be4e Mon Sep 17 00:00:00 2001
From: Jeff Mahoney <jeffm(a)suse.com>
Date: Tue, 21 Nov 2017 13:58:49 -0500
Subject: btrfs: handle errors while updating refcounts in update_ref_for_cow
From: Jeff Mahoney <jeffm(a)suse.com>
commit 692826b2738101549f032a761a9191636e83be4e upstream.
Since commit fb235dc06fa (btrfs: qgroup: Move half of the qgroup
accounting time out of commit trans) the assumption that
btrfs_add_delayed_{data,tree}_ref can only return 0 or -ENOMEM has
been false. The qgroup operations call into btrfs_search_slot
and friends and can now return the full spectrum of error codes.
Fortunately, the fix here is easy since update_ref_for_cow failing
is already handled so we just need to bail early with the error
code.
Fixes: fb235dc06fa (btrfs: qgroup: Move half of the qgroup accounting ...)
Signed-off-by: Jeff Mahoney <jeffm(a)suse.com>
Reviewed-by: Edmund Nadolski <enadolski(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/ctree.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -1032,14 +1032,17 @@ static noinline int update_ref_for_cow(s
root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) &&
!(flags & BTRFS_BLOCK_FLAG_FULL_BACKREF)) {
ret = btrfs_inc_ref(trans, root, buf, 1);
- BUG_ON(ret); /* -ENOMEM */
+ if (ret)
+ return ret;
if (root->root_key.objectid ==
BTRFS_TREE_RELOC_OBJECTID) {
ret = btrfs_dec_ref(trans, root, buf, 0);
- BUG_ON(ret); /* -ENOMEM */
+ if (ret)
+ return ret;
ret = btrfs_inc_ref(trans, root, cow, 1);
- BUG_ON(ret); /* -ENOMEM */
+ if (ret)
+ return ret;
}
new_flags |= BTRFS_BLOCK_FLAG_FULL_BACKREF;
} else {
@@ -1049,7 +1052,8 @@ static noinline int update_ref_for_cow(s
ret = btrfs_inc_ref(trans, root, cow, 1);
else
ret = btrfs_inc_ref(trans, root, cow, 0);
- BUG_ON(ret); /* -ENOMEM */
+ if (ret)
+ return ret;
}
if (new_flags != 0) {
int level = btrfs_header_level(buf);
@@ -1068,9 +1072,11 @@ static noinline int update_ref_for_cow(s
ret = btrfs_inc_ref(trans, root, cow, 1);
else
ret = btrfs_inc_ref(trans, root, cow, 0);
- BUG_ON(ret); /* -ENOMEM */
+ if (ret)
+ return ret;
ret = btrfs_dec_ref(trans, root, buf, 1);
- BUG_ON(ret); /* -ENOMEM */
+ if (ret)
+ return ret;
}
clean_tree_block(fs_info, buf);
*last_ref = 1;
Patches currently in stable-queue which might be from jeffm(a)suse.com are
queue-4.14/btrfs-fix-missing-error-return-in-btrfs_drop_snapshot.patch
queue-4.14/btrfs-handle-errors-while-updating-refcounts-in-update_ref_for_cow.patch
This is a note to let you know that I've just added the patch titled
btrfs: fix missing error return in btrfs_drop_snapshot
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-fix-missing-error-return-in-btrfs_drop_snapshot.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e19182c0fff451e3744c1107d98f072e7ca377a0 Mon Sep 17 00:00:00 2001
From: Jeff Mahoney <jeffm(a)suse.com>
Date: Mon, 4 Dec 2017 13:11:45 -0500
Subject: btrfs: fix missing error return in btrfs_drop_snapshot
From: Jeff Mahoney <jeffm(a)suse.com>
commit e19182c0fff451e3744c1107d98f072e7ca377a0 upstream.
If btrfs_del_root fails in btrfs_drop_snapshot, we'll pick up the
error but then return 0 anyway due to mixing err and ret.
Fixes: 79787eaab4612 ("btrfs: replace many BUG_ONs with proper error handling")
Signed-off-by: Jeff Mahoney <jeffm(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/extent-tree.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -9283,6 +9283,7 @@ int btrfs_drop_snapshot(struct btrfs_roo
ret = btrfs_del_root(trans, fs_info, &root->root_key);
if (ret) {
btrfs_abort_transaction(trans, ret);
+ err = ret;
goto out_end_trans;
}
Patches currently in stable-queue which might be from jeffm(a)suse.com are
queue-4.14/btrfs-fix-missing-error-return-in-btrfs_drop_snapshot.patch
queue-4.14/btrfs-handle-errors-while-updating-refcounts-in-update_ref_for_cow.patch
This is a note to let you know that I've just added the patch titled
brcmfmac: change driver unbind order of the sdio function devices
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
brcmfmac-change-driver-unbind-order-of-the-sdio-function-devices.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5c3de777bdaf48bd0cfb43097c0d0fb85056cab7 Mon Sep 17 00:00:00 2001
From: Arend Van Spriel <arend.vanspriel(a)broadcom.com>
Date: Sat, 25 Nov 2017 21:39:25 +0100
Subject: brcmfmac: change driver unbind order of the sdio function devices
From: Arend Van Spriel <arend.vanspriel(a)broadcom.com>
commit 5c3de777bdaf48bd0cfb43097c0d0fb85056cab7 upstream.
In the function brcmf_sdio_firmware_callback() the driver is
unbound from the sdio function devices in the error path.
However, the order in which it is done resulted in a use-after-free
issue (see brcmf_ops_sdio_remove() in bcmsdh.c). Hence change
the order and first unbind sdio function #2 device and then
unbind sdio function #1 device.
Fixes: 7a51461fc2da ("brcmfmac: unbind all devices upon failure in firmware callback")
Reported-by: Stefan Wahren <stefan.wahren(a)i2se.com>
Reviewed-by: Hante Meuleman <hante.meuleman(a)broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts(a)broadcom.com>
Reviewed-by: Franky Lin <franky.lin(a)broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel(a)broadcom.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4096,8 +4096,8 @@ release:
sdio_release_host(sdiodev->func[1]);
fail:
brcmf_dbg(TRACE, "failed: dev=%s, err=%d\n", dev_name(dev), err);
- device_release_driver(dev);
device_release_driver(&sdiodev->func[2]->dev);
+ device_release_driver(dev);
}
struct brcmf_sdio *brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev)
Patches currently in stable-queue which might be from arend.vanspriel(a)broadcom.com are
queue-4.14/brcmfmac-change-driver-unbind-order-of-the-sdio-function-devices.patch
This is a note to let you know that I've just added the patch titled
ASN.1: fix out-of-bounds read when parsing indefinite length item
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e0058f3a874ebb48b25be7ff79bc3b4e59929f90 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 8 Dec 2017 15:13:27 +0000
Subject: ASN.1: fix out-of-bounds read when parsing indefinite length item
From: Eric Biggers <ebiggers(a)google.com>
commit e0058f3a874ebb48b25be7ff79bc3b4e59929f90 upstream.
In asn1_ber_decoder(), indefinitely-sized ASN.1 items were being passed
to the action functions before their lengths had been computed, using
the bogus length of 0x80 (ASN1_INDEFINITE_LENGTH). This resulted in
reading data past the end of the input buffer, when given a specially
crafted message.
Fix it by rearranging the code so that the indefinite length is resolved
before the action is called.
This bug was originally found by fuzzing the X.509 parser in userspace
using libFuzzer from the LLVM project.
KASAN report (cleaned up slightly):
BUG: KASAN: slab-out-of-bounds in memcpy ./include/linux/string.h:341 [inline]
BUG: KASAN: slab-out-of-bounds in x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
Read of size 128 at addr ffff880035dd9eaf by task keyctl/195
CPU: 1 PID: 195 Comm: keyctl Not tainted 4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xd1/0x175 lib/dump_stack.c:53
print_address_description+0x78/0x260 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x23f/0x350 mm/kasan/report.c:409
memcpy+0x1f/0x50 mm/kasan/kasan.c:302
memcpy ./include/linux/string.h:341 [inline]
x509_fabricate_name.constprop.1+0x1a4/0x940 crypto/asymmetric_keys/x509_cert_parser.c:366
asn1_ber_decoder+0xb4a/0x1fd0 lib/asn1_decoder.c:447
x509_cert_parse+0x1c7/0x620 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Allocated by task 195:
__do_kmalloc_node mm/slab.c:3675 [inline]
__kmalloc_node+0x47/0x60 mm/slab.c:3682
kvmalloc ./include/linux/mm.h:540 [inline]
SYSC_add_key security/keys/keyctl.c:104 [inline]
SyS_add_key+0x19e/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Reported-by: Alexander Potapenko <glider(a)google.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/asn1_decoder.c | 47 ++++++++++++++++++++++++++---------------------
1 file changed, 26 insertions(+), 21 deletions(-)
--- a/lib/asn1_decoder.c
+++ b/lib/asn1_decoder.c
@@ -313,42 +313,47 @@ next_op:
/* Decide how to handle the operation */
switch (op) {
- case ASN1_OP_MATCH_ANY_ACT:
- case ASN1_OP_MATCH_ANY_ACT_OR_SKIP:
- case ASN1_OP_COND_MATCH_ANY_ACT:
- case ASN1_OP_COND_MATCH_ANY_ACT_OR_SKIP:
- ret = actions[machine[pc + 1]](context, hdr, tag, data + dp, len);
- if (ret < 0)
- return ret;
- goto skip_data;
-
- case ASN1_OP_MATCH_ACT:
- case ASN1_OP_MATCH_ACT_OR_SKIP:
- case ASN1_OP_COND_MATCH_ACT_OR_SKIP:
- ret = actions[machine[pc + 2]](context, hdr, tag, data + dp, len);
- if (ret < 0)
- return ret;
- goto skip_data;
-
case ASN1_OP_MATCH:
case ASN1_OP_MATCH_OR_SKIP:
+ case ASN1_OP_MATCH_ACT:
+ case ASN1_OP_MATCH_ACT_OR_SKIP:
case ASN1_OP_MATCH_ANY:
case ASN1_OP_MATCH_ANY_OR_SKIP:
+ case ASN1_OP_MATCH_ANY_ACT:
+ case ASN1_OP_MATCH_ANY_ACT_OR_SKIP:
case ASN1_OP_COND_MATCH_OR_SKIP:
+ case ASN1_OP_COND_MATCH_ACT_OR_SKIP:
case ASN1_OP_COND_MATCH_ANY:
case ASN1_OP_COND_MATCH_ANY_OR_SKIP:
- skip_data:
+ case ASN1_OP_COND_MATCH_ANY_ACT:
+ case ASN1_OP_COND_MATCH_ANY_ACT_OR_SKIP:
+
if (!(flags & FLAG_CONS)) {
if (flags & FLAG_INDEFINITE_LENGTH) {
+ size_t tmp = dp;
+
ret = asn1_find_indefinite_length(
- data, datalen, &dp, &len, &errmsg);
+ data, datalen, &tmp, &len, &errmsg);
if (ret < 0)
goto error;
- } else {
- dp += len;
}
pr_debug("- LEAF: %zu\n", len);
}
+
+ if (op & ASN1_OP_MATCH__ACT) {
+ unsigned char act;
+
+ if (op & ASN1_OP_MATCH__ANY)
+ act = machine[pc + 1];
+ else
+ act = machine[pc + 2];
+ ret = actions[act](context, hdr, tag, data + dp, len);
+ if (ret < 0)
+ return ret;
+ }
+
+ if (!(flags & FLAG_CONS))
+ dp += len;
pc += asn1_op_lengths[op];
goto next_op;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/x.509-reject-invalid-bit-string-for-subjectpublickey.patch
queue-4.14/asn.1-check-for-error-from-asn1_op_end__act-actions.patch
queue-4.14/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.14/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch
queue-4.14/keys-reject-null-restriction-string-when-type-is-specified.patch
queue-4.14/x.509-fix-comparisons-of-pkey_algo.patch
This is a note to let you know that I've just added the patch titled
ASN.1: check for error from ASN1_OP_END__ACT actions
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asn.1-check-for-error-from-asn1_op_end__act-actions.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 81a7be2cd69b412ab6aeacfe5ebf1bb6e5bce955 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 8 Dec 2017 15:13:27 +0000
Subject: ASN.1: check for error from ASN1_OP_END__ACT actions
From: Eric Biggers <ebiggers(a)google.com>
commit 81a7be2cd69b412ab6aeacfe5ebf1bb6e5bce955 upstream.
asn1_ber_decoder() was ignoring errors from actions associated with the
opcodes ASN1_OP_END_SEQ_ACT, ASN1_OP_END_SET_ACT,
ASN1_OP_END_SEQ_OF_ACT, and ASN1_OP_END_SET_OF_ACT. In practice, this
meant the pkcs7_note_signed_info() action (since that was the only user
of those opcodes). Fix it by checking for the error, just like the
decoder does for actions associated with the other opcodes.
This bug allowed users to leak slab memory by repeatedly trying to add a
specially crafted "pkcs7_test" key (requires CONFIG_PKCS7_TEST_KEY).
In theory, this bug could also be used to bypass module signature
verification, by providing a PKCS#7 message that is misparsed such that
a signature's ->authattrs do not contain its ->msgdigest. But it
doesn't seem practical in normal cases, due to restrictions on the
format of the ->authattrs.
Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/asn1_decoder.c | 2 ++
1 file changed, 2 insertions(+)
--- a/lib/asn1_decoder.c
+++ b/lib/asn1_decoder.c
@@ -439,6 +439,8 @@ next_op:
else
act = machine[pc + 1];
ret = actions[act](context, hdr, 0, data + tdp, len);
+ if (ret < 0)
+ return ret;
}
pc += asn1_op_lengths[op];
goto next_op;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/x.509-reject-invalid-bit-string-for-subjectpublickey.patch
queue-4.14/asn.1-check-for-error-from-asn1_op_end__act-actions.patch
queue-4.14/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.14/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch
queue-4.14/keys-reject-null-restriction-string-when-type-is-specified.patch
queue-4.14/x.509-fix-comparisons-of-pkey_algo.patch
This is a note to let you know that I've just added the patch titled
arm64: SW PAN: Update saved ttbr0 value on enter_lazy_tlb
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-sw-pan-update-saved-ttbr0-value-on-enter_lazy_tlb.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d96cc49bff5a7735576cc6f6f111f875d101cec8 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Wed, 6 Dec 2017 10:51:12 +0000
Subject: arm64: SW PAN: Update saved ttbr0 value on enter_lazy_tlb
From: Will Deacon <will.deacon(a)arm.com>
commit d96cc49bff5a7735576cc6f6f111f875d101cec8 upstream.
enter_lazy_tlb is called when a kernel thread rides on the back of
another mm, due to a context switch or an explicit call to unuse_mm
where a call to switch_mm is elided.
In these cases, it's important to keep the saved ttbr value up to date
with the active mm, otherwise we can end up with a stale value which
points to a potentially freed page table.
This patch implements enter_lazy_tlb for arm64, so that the saved ttbr0
is kept up-to-date with the active mm for kernel threads.
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Vinayak Menon <vinmenon(a)codeaurora.org>
Fixes: 39bc88e5e38e9b21 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com>
Reviewed-by: Mark Rutland <mark.rutland(a)arm.com>
Reported-by: Vinayak Menon <vinmenon(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/mmu_context.h | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -156,20 +156,6 @@ void check_and_switch_context(struct mm_
#define init_new_context(tsk,mm) ({ atomic64_set(&(mm)->context.id, 0); 0; })
-/*
- * This is called when "tsk" is about to enter lazy TLB mode.
- *
- * mm: describes the currently active mm context
- * tsk: task which is entering lazy tlb
- * cpu: cpu number which is entering lazy tlb
- *
- * tsk->mm will be NULL
- */
-static inline void
-enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
-{
-}
-
#ifdef CONFIG_ARM64_SW_TTBR0_PAN
static inline void update_saved_ttbr0(struct task_struct *tsk,
struct mm_struct *mm)
@@ -193,6 +179,16 @@ static inline void update_saved_ttbr0(st
}
#endif
+static inline void
+enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
+{
+ /*
+ * We don't actually care about the ttbr0 mapping, so point it at the
+ * zero page.
+ */
+ update_saved_ttbr0(tsk, &init_mm);
+}
+
static inline void __switch_mm(struct mm_struct *next)
{
unsigned int cpu = smp_processor_id();
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-sw-pan-update-saved-ttbr0-value-on-enter_lazy_tlb.patch
queue-4.14/arm64-sw-pan-point-saved-ttbr0-at-the-zero-page-when-switching-to-init_mm.patch
queue-4.14/arm64-fpsimd-prevent-registers-leaking-from-dead-tasks.patch
This is a note to let you know that I've just added the patch titled
arm64: SW PAN: Point saved ttbr0 at the zero page when switching to init_mm
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-sw-pan-point-saved-ttbr0-at-the-zero-page-when-switching-to-init_mm.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0adbdfde8cfc9415aeed2a4955d2d17b3bd9bf13 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon(a)arm.com>
Date: Wed, 6 Dec 2017 10:42:10 +0000
Subject: arm64: SW PAN: Point saved ttbr0 at the zero page when switching to init_mm
From: Will Deacon <will.deacon(a)arm.com>
commit 0adbdfde8cfc9415aeed2a4955d2d17b3bd9bf13 upstream.
update_saved_ttbr0 mandates that mm->pgd is not swapper, since swapper
contains kernel mappings and should never be installed into ttbr0. However,
this means that callers must avoid passing the init_mm to update_saved_ttbr0
which in turn can cause the saved ttbr0 value to be out-of-date in the context
of the idle thread. For example, EFI runtime services may leave the saved ttbr0
pointing at the EFI page table, and kernel threads may end up with stale
references to freed page tables.
This patch changes update_saved_ttbr0 so that the init_mm points the saved
ttbr0 value to the empty zero page, which always exists and never contains
valid translations. EFI and switch can then call into update_saved_ttbr0
unconditionally.
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Vinayak Menon <vinmenon(a)codeaurora.org>
Fixes: 39bc88e5e38e9b21 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com>
Reviewed-by: Mark Rutland <mark.rutland(a)arm.com>
Reported-by: Vinayak Menon <vinmenon(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/efi.h | 4 +---
arch/arm64/include/asm/mmu_context.h | 22 +++++++++++++---------
2 files changed, 14 insertions(+), 12 deletions(-)
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -132,11 +132,9 @@ static inline void efi_set_pgd(struct mm
* Defer the switch to the current thread's TTBR0_EL1
* until uaccess_enable(). Restore the current
* thread's saved ttbr0 corresponding to its active_mm
- * (if different from init_mm).
*/
cpu_set_reserved_ttbr0();
- if (current->active_mm != &init_mm)
- update_saved_ttbr0(current, current->active_mm);
+ update_saved_ttbr0(current, current->active_mm);
}
}
}
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -174,11 +174,17 @@ enter_lazy_tlb(struct mm_struct *mm, str
static inline void update_saved_ttbr0(struct task_struct *tsk,
struct mm_struct *mm)
{
- if (system_uses_ttbr0_pan()) {
- BUG_ON(mm->pgd == swapper_pg_dir);
- task_thread_info(tsk)->ttbr0 =
- virt_to_phys(mm->pgd) | ASID(mm) << 48;
- }
+ u64 ttbr;
+
+ if (!system_uses_ttbr0_pan())
+ return;
+
+ if (mm == &init_mm)
+ ttbr = __pa_symbol(empty_zero_page);
+ else
+ ttbr = virt_to_phys(mm->pgd) | ASID(mm) << 48;
+
+ task_thread_info(tsk)->ttbr0 = ttbr;
}
#else
static inline void update_saved_ttbr0(struct task_struct *tsk,
@@ -214,11 +220,9 @@ switch_mm(struct mm_struct *prev, struct
* Update the saved TTBR0_EL1 of the scheduled-in task as the previous
* value may have not been initialised yet (activate_mm caller) or the
* ASID has changed since the last run (following the context switch
- * of another thread of the same process). Avoid setting the reserved
- * TTBR0_EL1 to swapper_pg_dir (init_mm; e.g. via idle_task_exit).
+ * of another thread of the same process).
*/
- if (next != &init_mm)
- update_saved_ttbr0(tsk, next);
+ update_saved_ttbr0(tsk, next);
}
#define deactivate_mm(tsk,mm) do { } while (0)
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-sw-pan-update-saved-ttbr0-value-on-enter_lazy_tlb.patch
queue-4.14/arm64-sw-pan-point-saved-ttbr0-at-the-zero-page-when-switching-to-init_mm.patch
queue-4.14/arm64-fpsimd-prevent-registers-leaking-from-dead-tasks.patch
This is a note to let you know that I've just added the patch titled
arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 26aa7b3b1c0fb3f1a6176a0c1847204ef4355693 Mon Sep 17 00:00:00 2001
From: Kristina Martsenko <kristina.martsenko(a)arm.com>
Date: Thu, 16 Nov 2017 17:58:20 +0000
Subject: arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one
From: Kristina Martsenko <kristina.martsenko(a)arm.com>
commit 26aa7b3b1c0fb3f1a6176a0c1847204ef4355693 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 47-bit addresses (instead of 48-bit) and also
insufficiently checking the alignment. This patch fixes it.
As an example, with 4k pages, before this patch we have:
PHYS_MASK_SHIFT = 48
VTTBR_X = 37 - 24 = 13
VTTBR_BADDR_SHIFT = 13 - 1 = 12
VTTBR_BADDR_MASK = ((1 << 35) - 1) << 12 = 0x00007ffffffff000
Which is wrong, because the mask doesn't allow bit 47 of the VTTBR
address to be set, and only requires the address to be 12-bit (4k)
aligned, while it actually needs to be 13-bit (8k) aligned because we
concatenate two 4k tables.
With this patch, the mask becomes 0x0000ffffffffe000, which is what we
want.
Fixes: 0369f6a34b9f ("arm64: KVM: EL2 register definitions")
Reviewed-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Kristina Martsenko <kristina.martsenko(a)arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/kvm_arm.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -170,8 +170,7 @@
#define VTCR_EL2_FLAGS (VTCR_EL2_COMMON_BITS | VTCR_EL2_TGRAN_FLAGS)
#define VTTBR_X (VTTBR_X_TGRAN_MAGIC - VTCR_EL2_T0SZ_IPA)
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((UL(1) << (PHYS_MASK_SHIFT - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((UL(1) << (PHYS_MASK_SHIFT - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT (UL(48))
#define VTTBR_VMID_MASK(size) (_AT(u64, (1 << size) - 1) << VTTBR_VMID_SHIFT)
Patches currently in stable-queue which might be from kristina.martsenko(a)arm.com are
queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch