This is a note to let you know that I've just added the patch titled
dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63
to the 4.15-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:
dmaengine-ti-dma-crossbar-fix-event-mapping-for-tpcc_evt_mux_60_63.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Vignesh R <vigneshr(a)ti.com>
Date: Tue, 19 Dec 2017 12:51:16 +0200
Subject: dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63
From: Vignesh R <vigneshr(a)ti.com>
[ Upstream commit d087f15786021a9605b20f4c678312510be4cac1 ]
Register layout of a typical TPCC_EVT_MUX_M_N register is such that the
lowest numbered event is at the lowest byte address and highest numbered
event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is
different, in that the lowest numbered event is at the highest address
and highest numbered event is at the lowest address. Therefore, modify
ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register
accordingly.
Signed-off-by: Vignesh R <vigneshr(a)ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/ti-dma-crossbar.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -54,7 +54,15 @@ struct ti_am335x_xbar_map {
static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val, iomem + event);
+ /*
+ * TPCC_EVT_MUX_60_63 register layout is different than the
+ * rest, in the sense, that event 63 is mapped to lowest byte
+ * and event 60 is mapped to highest, handle it separately.
+ */
+ if (event >= 60 && event <= 63)
+ writeb_relaxed(val, iomem + (63 - event % 4));
+ else
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
Patches currently in stable-queue which might be from vigneshr(a)ti.com are
queue-4.15/dmaengine-ti-dma-crossbar-fix-event-mapping-for-tpcc_evt_mux_60_63.patch
This is a note to let you know that I've just added the patch titled
/dev/mem: Add bounce buffer for copy-out
to the 4.15-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:
dev-mem-add-bounce-buffer-for-copy-out.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:39 CET 2018
From: Kees Cook <keescook(a)chromium.org>
Date: Fri, 1 Dec 2017 13:19:39 -0800
Subject: /dev/mem: Add bounce buffer for copy-out
From: Kees Cook <keescook(a)chromium.org>
[ Upstream commit 22ec1a2aea73b9dfe340dff7945bd85af4cc6280 ]
As done for /proc/kcore in
commit df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
this adds a bounce buffer when reading memory via /dev/mem. This
is needed to allow kernel text memory to be read out when built with
CONFIG_HARDENED_USERCOPY (which refuses to read out kernel text) and
without CONFIG_STRICT_DEVMEM (which would have refused to read any RAM
contents at all).
Since this build configuration isn't common (most systems with
CONFIG_HARDENED_USERCOPY also have CONFIG_STRICT_DEVMEM), this also tries
to inform Kconfig about the recommended settings.
This patch is modified from Brad Spengler/PaX Team's changes to /dev/mem
code in the last public patch of grsecurity/PaX based on my understanding
of the code. Changes or omissions from the original code are mine and
don't reflect the original grsecurity/PaX code.
Reported-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
Fixes: f5509cc18daa ("mm: Hardened usercopy")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/mem.c | 27 ++++++++++++++++++++++-----
security/Kconfig | 1 +
2 files changed, 23 insertions(+), 5 deletions(-)
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -107,6 +107,8 @@ static ssize_t read_mem(struct file *fil
phys_addr_t p = *ppos;
ssize_t read, sz;
void *ptr;
+ char *bounce;
+ int err;
if (p != *ppos)
return 0;
@@ -129,15 +131,22 @@ static ssize_t read_mem(struct file *fil
}
#endif
+ bounce = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!bounce)
+ return -ENOMEM;
+
while (count > 0) {
unsigned long remaining;
int allowed;
sz = size_inside_page(p, count);
+ err = -EPERM;
allowed = page_is_allowed(p >> PAGE_SHIFT);
if (!allowed)
- return -EPERM;
+ goto failed;
+
+ err = -EFAULT;
if (allowed == 2) {
/* Show zeros for restricted memory. */
remaining = clear_user(buf, sz);
@@ -149,24 +158,32 @@ static ssize_t read_mem(struct file *fil
*/
ptr = xlate_dev_mem_ptr(p);
if (!ptr)
- return -EFAULT;
-
- remaining = copy_to_user(buf, ptr, sz);
+ goto failed;
+ err = probe_kernel_read(bounce, ptr, sz);
unxlate_dev_mem_ptr(p, ptr);
+ if (err)
+ goto failed;
+
+ remaining = copy_to_user(buf, bounce, sz);
}
if (remaining)
- return -EFAULT;
+ goto failed;
buf += sz;
p += sz;
count -= sz;
read += sz;
}
+ kfree(bounce);
*ppos += read;
return read;
+
+failed:
+ kfree(bounce);
+ return err;
}
static ssize_t write_mem(struct file *file, const char __user *buf,
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -154,6 +154,7 @@ config HARDENED_USERCOPY
bool "Harden memory copies between kernel and userspace"
depends on HAVE_HARDENED_USERCOPY_ALLOCATOR
select BUG
+ imply STRICT_DEVMEM
help
This option checks for obviously wrong memory regions when
copying memory to/from the kernel (via copy_to_user() and
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.15/dev-mem-add-bounce-buffer-for-copy-out.patch
This is a note to let you know that I've just added the patch titled
crypto: artpec6 - set correct iv size for gcm(aes)
to the 4.15-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:
crypto-artpec6-set-correct-iv-size-for-gcm-aes.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Lars Persson <lars.persson(a)axis.com>
Date: Tue, 12 Dec 2017 12:40:22 +0100
Subject: crypto: artpec6 - set correct iv size for gcm(aes)
From: Lars Persson <lars.persson(a)axis.com>
[ Upstream commit 6d6e71feb183aa588c849e20e7baa47cb162928a ]
The IV size should not include the 32 bit counter. Because we had the
IV size set as 16 the transform only worked when the IV input was zero
padded.
Fixes: a21eb94fc4d3 ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver")
Signed-off-by: Lars Persson <larper(a)axis.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/axis/artpec6_crypto.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/crypto/axis/artpec6_crypto.c
+++ b/drivers/crypto/axis/artpec6_crypto.c
@@ -22,6 +22,7 @@
#include <linux/slab.h>
#include <crypto/aes.h>
+#include <crypto/gcm.h>
#include <crypto/internal/aead.h>
#include <crypto/internal/hash.h>
#include <crypto/internal/skcipher.h>
@@ -1934,7 +1935,7 @@ static int artpec6_crypto_prepare_aead(s
memcpy(req_ctx->hw_ctx.J0, areq->iv, crypto_aead_ivsize(cipher));
// The HW omits the initial increment of the counter field.
- crypto_inc(req_ctx->hw_ctx.J0+12, 4);
+ memcpy(req_ctx->hw_ctx.J0 + GCM_AES_IV_SIZE, "\x00\x00\x00\x01", 4);
ret = artpec6_crypto_setup_out_descr(common, &req_ctx->hw_ctx,
sizeof(struct artpec6_crypto_aead_hw_ctx), false, false);
@@ -2956,7 +2957,7 @@ static struct aead_alg aead_algos[] = {
.setkey = artpec6_crypto_aead_set_key,
.encrypt = artpec6_crypto_aead_encrypt,
.decrypt = artpec6_crypto_aead_decrypt,
- .ivsize = AES_BLOCK_SIZE,
+ .ivsize = GCM_AES_IV_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
.base = {
Patches currently in stable-queue which might be from lars.persson(a)axis.com are
queue-4.15/crypto-artpec6-set-correct-iv-size-for-gcm-aes.patch
This is a note to let you know that I've just added the patch titled
cros_ec: fix nul-termination for firmware build info
to the 4.15-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:
cros_ec-fix-nul-termination-for-firmware-build-info.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:39 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Mon, 4 Dec 2017 15:49:48 +0100
Subject: cros_ec: fix nul-termination for firmware build info
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ]
As gcc-8 reports, we zero out the wrong byte:
drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
This changes the code back to what it did before changing to a
zero-length array structure.
Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Benson Leung <bleung(a)chromium.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/chrome/cros_ec_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -187,7 +187,7 @@ static ssize_t show_ec_version(struct de
count += scnprintf(buf + count, PAGE_SIZE - count,
"Build info: EC error %d\n", msg->result);
else {
- msg->data[sizeof(msg->data) - 1] = '\0';
+ msg->data[EC_HOST_PARAM_SIZE - 1] = '\0';
count += scnprintf(buf + count, PAGE_SIZE - count,
"Build info: %s\n", msg->data);
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/drm-tilcdc-ensure-nonatomic-iowrite64-is-not-used.patch
queue-4.15/cros_ec-fix-nul-termination-for-firmware-build-info.patch
This is a note to let you know that I've just added the patch titled
cpufreq: longhaul: Revert transition_delay_us to 200 ms
to the 4.15-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:
cpufreq-longhaul-revert-transition_delay_us-to-200-ms.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:39 CET 2018
From: Viresh Kumar <viresh.kumar(a)linaro.org>
Date: Thu, 7 Dec 2017 15:15:19 +0530
Subject: cpufreq: longhaul: Revert transition_delay_us to 200 ms
From: Viresh Kumar <viresh.kumar(a)linaro.org>
[ Upstream commit 1d0d064307cbfd8546841f6e9d94d02c55e45e1e ]
The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
value to 10 ms") caused a regression on EPIA-M min-ITX computer where
shutdown or reboot hangs occasionally with a print message like:
longhaul: Warning: Timeout while waiting for idle PCI bus
cpufreq: __target_index: Failed to change cpu frequency: -16
This probably happens because the cpufreq governor tries to change the
frequency of the CPU faster than allowed by the hardware.
Before the above commit, the default transition delay was set to 200 ms
for a transition_latency of 200000 ns. Lets revert back to that
transition delay value to fix it. Note that several other transition
delay values were tested like 20 ms and 30 ms and none of them have
resolved system hang issue completely.
Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
Reported-by: Meelis Roos <mroos(a)linux.ee>
Suggested-by: Rafael J. Wysocki <rjw(a)rjwysocki.net>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpufreq/longhaul.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpuf
if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0))
longhaul_setup_voltagescaling();
- policy->cpuinfo.transition_latency = 200000; /* nsec */
+ policy->transition_delay_us = 200000; /* usec */
return cpufreq_table_validate_and_show(policy, longhaul_table);
}
Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are
queue-4.15/cpufreq-longhaul-revert-transition_delay_us-to-200-ms.patch
This is a note to let you know that I've just added the patch titled
coresight: Fix disabling of CoreSight TPIU
to the 4.15-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:
coresight-fix-disabling-of-coresight-tpiu.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Robert Walker <robert.walker(a)arm.com>
Date: Mon, 18 Dec 2017 11:05:44 -0700
Subject: coresight: Fix disabling of CoreSight TPIU
From: Robert Walker <robert.walker(a)arm.com>
[ Upstream commit 11595db8e17faaa05fadc25746c870e31276962f ]
The CoreSight TPIU should be disabled when tracing to other sinks to allow
them to operate at full bandwidth.
This patch fixes tpiu_disable_hw() to correctly disable the TPIU by
configuring the TPIU to stop on flush, initiating a manual flush, waiting
for the flush to complete and then waits for the TPIU to indicate it has
stopped.
Signed-off-by: Robert Walker <robert.walker(a)arm.com>
Tested-by: Mike Leach <mike.leach(a)linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwtracing/coresight/coresight-tpiu.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -46,8 +46,11 @@
#define TPIU_ITATBCTR0 0xef8
/** register definition **/
+/* FFSR - 0x300 */
+#define FFSR_FT_STOPPED BIT(1)
/* FFCR - 0x304 */
#define FFCR_FON_MAN BIT(6)
+#define FFCR_STOP_FI BIT(12)
/**
* @base: memory mapped base address for this component.
@@ -85,10 +88,14 @@ static void tpiu_disable_hw(struct tpiu_
{
CS_UNLOCK(drvdata->base);
- /* Clear formatter controle reg. */
- writel_relaxed(0x0, drvdata->base + TPIU_FFCR);
+ /* Clear formatter and stop on flush */
+ writel_relaxed(FFCR_STOP_FI, drvdata->base + TPIU_FFCR);
/* Generate manual flush */
- writel_relaxed(FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
+ writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
+ /* Wait for flush to complete */
+ coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN, 0);
+ /* Wait for formatter to stop */
+ coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED, 1);
CS_LOCK(drvdata->base);
}
Patches currently in stable-queue which might be from robert.walker(a)arm.com are
queue-4.15/coresight-fix-disabling-of-coresight-tpiu.patch
This is a note to let you know that I've just added the patch titled
clk: use round rate to bail out early in set_rate
to the 4.15-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:
clk-use-round-rate-to-bail-out-early-in-set_rate.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Jerome Brunet <jbrunet(a)baylibre.com>
Date: Fri, 1 Dec 2017 22:51:55 +0100
Subject: clk: use round rate to bail out early in set_rate
From: Jerome Brunet <jbrunet(a)baylibre.com>
[ Upstream commit ca5e089a32c5ffba6c5101fdabdd6dea18041c34 ]
The current implementation of clk_core_set_rate_nolock() bails out early
if the requested rate is exactly the same as the one set. It should bail
out if the request would not result in a rate a change. This is important
when the rate is not exactly what is requested, which is fairly common
with PLLs.
Ex: provider able to give any rate with steps of 100Hz
- 1st consumer request 48000Hz and gets it.
- 2nd consumer request 48010Hz as well. If we were to perform the usual
mechanism, we would get 48000Hz as well. The clock would not change so
there is no point performing any checks to make sure the clock can
change, we know it won't.
This is important to prepare the addition of the clock protection
mechanism
Acked-by: Linus Walleij <linus.walleij(a)linaro.org>
Tested-by: Quentin Schulz <quentin.schulz(a)free-electrons.com>
Tested-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Acked-by: Michael Turquette <mturquette(a)baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Signed-off-by: Michael Turquette <mturquette(a)baylibre.com>
Link: lkml.kernel.org/r/20171201215200.23523-6-jbrunet@baylibre.com
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/clk.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1642,16 +1642,37 @@ static void clk_change_rate(struct clk_c
clk_pm_runtime_put(core);
}
+static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core,
+ unsigned long req_rate)
+{
+ int ret;
+ struct clk_rate_request req;
+
+ lockdep_assert_held(&prepare_lock);
+
+ if (!core)
+ return 0;
+
+ clk_core_get_boundaries(core, &req.min_rate, &req.max_rate);
+ req.rate = req_rate;
+
+ ret = clk_core_round_rate_nolock(core, &req);
+
+ return ret ? 0 : req.rate;
+}
+
static int clk_core_set_rate_nolock(struct clk_core *core,
unsigned long req_rate)
{
struct clk_core *top, *fail_clk;
- unsigned long rate = req_rate;
+ unsigned long rate;
int ret = 0;
if (!core)
return 0;
+ rate = clk_core_req_round_rate_nolock(core, req_rate);
+
/* bail early if nothing to do */
if (rate == clk_core_get_rate_nolock(core))
return 0;
@@ -1660,7 +1681,7 @@ static int clk_core_set_rate_nolock(stru
return -EBUSY;
/* calculate new rates and get the topmost changed clock */
- top = clk_calc_new_rates(core, rate);
+ top = clk_calc_new_rates(core, req_rate);
if (!top)
return -EINVAL;
Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are
queue-4.15/clk-check-ops-pointer-on-clock-register.patch
queue-4.15/net-phy-meson-gxl-check-phy_write-return-value.patch
queue-4.15/clk-use-round-rate-to-bail-out-early-in-set_rate.patch
This is a note to let you know that I've just added the patch titled
clk: si5351: Rename internal plls to avoid name collisions
to the 4.15-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:
clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Sergej Sawazki <sergej(a)taudac.com>
Date: Tue, 25 Jul 2017 23:21:02 +0200
Subject: clk: si5351: Rename internal plls to avoid name collisions
From: Sergej Sawazki <sergej(a)taudac.com>
[ Upstream commit cdba9a4fb0b53703959ac861e415816cb61aded4 ]
This drivers probe fails due to a clock name collision if a clock named
'plla' or 'pllb' is already registered when registering this drivers
internal plls.
Fix it by renaming internal plls to avoid name collisions.
Cc: Sebastian Hesselbarth <sebastian.hesselbarth(a)gmail.com>
Cc: Rabeeh Khoury <rabeeh(a)solid-run.com>
Signed-off-by: Sergej Sawazki <sergej(a)taudac.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/clk-si5351.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -72,7 +72,7 @@ static const char * const si5351_input_n
"xtal", "clkin"
};
static const char * const si5351_pll_names[] = {
- "plla", "pllb", "vxco"
+ "si5351_plla", "si5351_pllb", "si5351_vxco"
};
static const char * const si5351_msynth_names[] = {
"ms0", "ms1", "ms2", "ms3", "ms4", "ms5", "ms6", "ms7"
Patches currently in stable-queue which might be from sergej(a)taudac.com are
queue-4.15/clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch
This is a note to let you know that I've just added the patch titled
clk: Don't touch hardware when reparenting during registration
to the 4.15-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:
clk-don-t-touch-hardware-when-reparenting-during-registration.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Stephen Boyd <sboyd(a)codeaurora.org>
Date: Thu, 2 Nov 2017 00:36:09 -0700
Subject: clk: Don't touch hardware when reparenting during registration
From: Stephen Boyd <sboyd(a)codeaurora.org>
[ Upstream commit f8f8f1d04494d3a6546bee3f0618c4dba31d7b72 ]
The orphan clocks reparent operation shouldn't touch the hardware
if clocks are enabled, otherwise it may get a chance to disable a
newly registered critical clock which triggers the warning below.
Assuming we have two clocks: A and B, B is the parent of A.
Clock A has flag: CLK_OPS_PARENT_ENABLE
Clock B has flag: CLK_IS_CRITICAL
Step 1:
Clock A is registered, then it becomes orphan.
Step 2:
Clock B is registered. Before clock B reach the critical clock enable
operation, orphan A will find the newly registered parent B and do
reparent operation, then parent B will be finally disabled in
__clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's
still no users of B which will then trigger the following warning.
WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373
Hardware name: Generic DT based system
Backtrace:
[<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c)
r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000
[<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8)
[<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104)
r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000
r4:00000000 r3:c0e01d34
[<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30)
r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80
[<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0)
[<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c)
r4:000000d3 r3:c0e0af00
[<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28)
r5:00000000 r4:ef00bf80
[<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54)
r4:ef00bd80 r3:000010a0
[<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648)
r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4
[<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c)
r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500
[<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120)
[<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54)
r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001
r4:f0810030
[<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98)
r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808
[<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0)
r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0
r4:00000006
[<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38)
r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000
r4:00000000
[<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394)
[<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c)
r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918
r4:c0e78294
We know that the clk isn't enabled with any sort of prepare_count
here so we don't need to enable anything to prevent a race. And
we're holding the prepare mutex so set_rate/set_parent can't race
here either. Based on an earlier patch by Dong Aisheng.
Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
Cc: Michael Turquette <mturquette(a)baylibre.com>
Cc: Shawn Guo <shawnguo(a)kernel.org>
Reported-by: Dong Aisheng <aisheng.dong(a)nxp.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/clk.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2597,14 +2597,17 @@ static int __clk_core_init(struct clk_co
*/
hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) {
struct clk_core *parent = __clk_init_parent(orphan);
+ unsigned long flags;
/*
* we could call __clk_set_parent, but that would result in a
* redundant call to the .set_rate op, if it exists
*/
if (parent) {
- __clk_set_parent_before(orphan, parent);
- __clk_set_parent_after(orphan, parent, NULL);
+ /* update the clk tree topology */
+ flags = clk_enable_lock();
+ clk_reparent(orphan, parent);
+ clk_enable_unlock(flags);
__clk_recalc_accuracies(orphan);
__clk_recalc_rates(orphan, 0);
}
Patches currently in stable-queue which might be from sboyd(a)codeaurora.org are
queue-4.15/clk-at91-pmc-wait-for-clocks-when-resuming.patch
queue-4.15/clk-si5351-rename-internal-plls-to-avoid-name-collisions.patch
queue-4.15/clk-don-t-touch-hardware-when-reparenting-during-registration.patch
queue-4.15/clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch
This is a note to let you know that I've just added the patch titled
clk: check ops pointer on clock register
to the 4.15-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:
clk-check-ops-pointer-on-clock-register.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Jerome Brunet <jbrunet(a)baylibre.com>
Date: Tue, 19 Dec 2017 09:33:29 +0100
Subject: clk: check ops pointer on clock register
From: Jerome Brunet <jbrunet(a)baylibre.com>
[ Upstream commit 29fd2a34ef8d863e48183bd473ba57c8d7839e25 ]
Nothing really prevents a provider from (trying to) register a clock
without providing the clock ops structure.
We do check the individual fields before using them, but not the
structure pointer itself. This may have the usual nasty consequences when
the pointer is dereferenced, most likely when checking one the field
during the initialization.
This is fixed by returning an error on clock register if the ops pointer
is NULL.
Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Signed-off-by: Michael Turquette <mturquette(a)baylibre.com>
Link: lkml.kernel.org/r/20171219083329.24746-1-jbrunet@baylibre.com
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/clk.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2684,7 +2684,13 @@ struct clk *clk_register(struct device *
ret = -ENOMEM;
goto fail_name;
}
+
+ if (WARN_ON(!hw->init->ops)) {
+ ret = -EINVAL;
+ goto fail_ops;
+ }
core->ops = hw->init->ops;
+
if (dev && pm_runtime_enabled(dev))
core->dev = dev;
if (dev && dev->driver)
@@ -2746,6 +2752,7 @@ fail_parent_names_copy:
kfree_const(core->parent_names[i]);
kfree(core->parent_names);
fail_parent_names:
+fail_ops:
kfree_const(core->name);
fail_name:
kfree(core);
Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are
queue-4.15/clk-check-ops-pointer-on-clock-register.patch
queue-4.15/net-phy-meson-gxl-check-phy_write-return-value.patch
queue-4.15/clk-use-round-rate-to-bail-out-early-in-set_rate.patch
This is a note to let you know that I've just added the patch titled
clk: axi-clkgen: Correctly handle nocount bit in recalc_rate()
to the 4.15-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:
clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Tue, 5 Sep 2017 11:32:40 +0200
Subject: clk: axi-clkgen: Correctly handle nocount bit in recalc_rate()
From: Lars-Peter Clausen <lars(a)metafoo.de>
[ Upstream commit 063578dc5f407f67d149133818efabe457daafda ]
If the nocount bit is set the divider is bypassed and the settings for the
divider count should be ignored and a divider value of 1 should be assumed.
Handle this correctly in the driver recalc_rate() callback.
While the driver sets up the part so that the read back dividers values
yield the correct result the power-on reset settings of the part might not
reflect this and hence calling e.g. clk_get_rate() without prior calls to
clk_set_rate() will yield the wrong result.
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/clk-axi-clkgen.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
--- a/drivers/clk/clk-axi-clkgen.c
+++ b/drivers/clk/clk-axi-clkgen.c
@@ -40,6 +40,10 @@
#define MMCM_REG_FILTER1 0x4e
#define MMCM_REG_FILTER2 0x4f
+#define MMCM_CLKOUT_NOCOUNT BIT(6)
+
+#define MMCM_CLK_DIV_NOCOUNT BIT(12)
+
struct axi_clkgen {
void __iomem *base;
struct clk_hw clk_hw;
@@ -315,12 +319,27 @@ static unsigned long axi_clkgen_recalc_r
unsigned int reg;
unsigned long long tmp;
- axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_1, ®);
- dout = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+ axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_2, ®);
+ if (reg & MMCM_CLKOUT_NOCOUNT) {
+ dout = 1;
+ } else {
+ axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLKOUT0_1, ®);
+ dout = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+ }
+
axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_DIV, ®);
- d = (reg & 0x3f) + ((reg >> 6) & 0x3f);
- axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB1, ®);
- m = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+ if (reg & MMCM_CLK_DIV_NOCOUNT)
+ d = 1;
+ else
+ d = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+
+ axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB2, ®);
+ if (reg & MMCM_CLKOUT_NOCOUNT) {
+ m = 1;
+ } else {
+ axi_clkgen_mmcm_read(axi_clkgen, MMCM_REG_CLK_FB1, ®);
+ m = (reg & 0x3f) + ((reg >> 6) & 0x3f);
+ }
if (d == 0 || dout == 0)
return 0;
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-4.15/clk-axi-clkgen-correctly-handle-nocount-bit-in-recalc_rate.patch
This is a note to let you know that I've just added the patch titled
clk: at91: pmc: Wait for clocks when resuming
to the 4.15-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:
clk-at91-pmc-wait-for-clocks-when-resuming.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Romain Izard <romain.izard.pro(a)gmail.com>
Date: Mon, 11 Dec 2017 17:55:33 +0100
Subject: clk: at91: pmc: Wait for clocks when resuming
From: Romain Izard <romain.izard.pro(a)gmail.com>
[ Upstream commit 960e1c4d93be86d3b118fe22d4edc69e401b28b5 ]
Wait for the syncronization of all clocks when resuming, not only the
UPLL clock. Do not use regmap_read_poll_timeout, as it will call BUG()
when interrupts are masked, which is the case in here.
Signed-off-by: Romain Izard <romain.izard.pro(a)gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches(a)microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/at91/pmc.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -107,10 +107,20 @@ static int pmc_suspend(void)
return 0;
}
+static bool pmc_ready(unsigned int mask)
+{
+ unsigned int status;
+
+ regmap_read(pmcreg, AT91_PMC_SR, &status);
+
+ return ((status & mask) == mask) ? 1 : 0;
+}
+
static void pmc_resume(void)
{
- int i, ret = 0;
+ int i;
u32 tmp;
+ u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA;
regmap_read(pmcreg, AT91_PMC_MCKR, &tmp);
if (pmc_cache.mckr != tmp)
@@ -134,13 +144,11 @@ static void pmc_resume(void)
AT91_PMC_PCR_CMD);
}
- if (pmc_cache.uckr & AT91_PMC_UPLLEN) {
- ret = regmap_read_poll_timeout(pmcreg, AT91_PMC_SR, tmp,
- !(tmp & AT91_PMC_LOCKU),
- 10, 5000);
- if (ret)
- pr_crit("USB PLL didn't lock when resuming\n");
- }
+ if (pmc_cache.uckr & AT91_PMC_UPLLEN)
+ mask |= AT91_PMC_LOCKU;
+
+ while (!pmc_ready(mask))
+ cpu_relax();
}
static struct syscore_ops pmc_syscore_ops = {
Patches currently in stable-queue which might be from romain.izard.pro(a)gmail.com are
queue-4.15/clk-at91-pmc-wait-for-clocks-when-resuming.patch
This is a note to let you know that I've just added the patch titled
bpf/cgroup: fix a verification error for a CGROUP_DEVICE type prog
to the 4.15-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:
bpf-cgroup-fix-a-verification-error-for-a-cgroup_device-type-prog.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:39 CET 2018
From: Yonghong Song <yhs(a)fb.com>
Date: Mon, 18 Dec 2017 10:13:44 -0800
Subject: bpf/cgroup: fix a verification error for a CGROUP_DEVICE type prog
From: Yonghong Song <yhs(a)fb.com>
[ Upstream commit 06ef0ccb5a36e1feba9b413ff59a04ecc4407c1c ]
The tools/testing/selftests/bpf test program
test_dev_cgroup fails with the following error
when compiled with llvm 6.0. (I did not try
with earlier versions.)
libbpf: load bpf program failed: Permission denied
libbpf: -- BEGIN DUMP LOG ---
libbpf:
0: (61) r2 = *(u32 *)(r1 +4)
1: (b7) r0 = 0
2: (55) if r2 != 0x1 goto pc+8
R0=inv0 R1=ctx(id=0,off=0,imm=0) R2=inv1 R10=fp0
3: (69) r2 = *(u16 *)(r1 +0)
invalid bpf_context access off=0 size=2
...
The culprit is the following statement in dev_cgroup.c:
short type = ctx->access_type & 0xFFFF;
This code is typical as the ctx->access_type is assigned
as below in kernel/bpf/cgroup.c:
struct bpf_cgroup_dev_ctx ctx = {
.access_type = (access << 16) | dev_type,
.major = major,
.minor = minor,
};
The compiler converts it to u16 access while
the verifier cgroup_dev_is_valid_access rejects
any non u32 access.
This patch permits the field access_type to be accessible
with type u16 and u8 as well.
Signed-off-by: Yonghong Song <yhs(a)fb.com>
Tested-by: Roman Gushchin <guro(a)fb.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/bpf.h | 3 ++-
kernel/bpf/cgroup.c | 15 +++++++++++++--
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -995,7 +995,8 @@ struct bpf_perf_event_value {
#define BPF_DEVCG_DEV_CHAR (1ULL << 1)
struct bpf_cgroup_dev_ctx {
- __u32 access_type; /* (access << 16) | type */
+ /* access_type encoded as (BPF_DEVCG_ACC_* << 16) | BPF_DEVCG_DEV_* */
+ __u32 access_type;
__u32 major;
__u32 minor;
};
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -568,6 +568,8 @@ static bool cgroup_dev_is_valid_access(i
enum bpf_access_type type,
struct bpf_insn_access_aux *info)
{
+ const int size_default = sizeof(__u32);
+
if (type == BPF_WRITE)
return false;
@@ -576,8 +578,17 @@ static bool cgroup_dev_is_valid_access(i
/* The verifier guarantees that size > 0. */
if (off % size != 0)
return false;
- if (size != sizeof(__u32))
- return false;
+
+ switch (off) {
+ case bpf_ctx_range(struct bpf_cgroup_dev_ctx, access_type):
+ bpf_ctx_record_field_size(info, size_default);
+ if (!bpf_ctx_narrow_access_ok(off, size, size_default))
+ return false;
+ break;
+ default:
+ if (size != size_default)
+ return false;
+ }
return true;
}
Patches currently in stable-queue which might be from yhs(a)fb.com are
queue-4.15/bpf-cgroup-fix-a-verification-error-for-a-cgroup_device-type-prog.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_qca: Avoid setup failure on missing rampatch
to the 4.15-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:
bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:39 CET 2018
From: Loic Poulain <loic.poulain(a)linaro.org>
Date: Mon, 6 Nov 2017 12:16:56 +0100
Subject: Bluetooth: hci_qca: Avoid setup failure on missing rampatch
From: Loic Poulain <loic.poulain(a)linaro.org>
[ Upstream commit ba8f3597900291a93604643017fff66a14546015 ]
Assuming that the original code idea was to enable in-band sleeping
only if the setup_rome method returns succes and run in 'standard'
mode otherwise, we should not return setup_rome return value which
makes qca_setup fail if no rampatch/nvm file found.
This fixes BT issue on the dragonboard-820C p4 which includes the
following QCA controller:
hci0: Product:0x00000008
hci0: Patch :0x00000111
hci0: ROM :0x00000302
hci0: SOC :0x00000044
Since there is no rampatch for this controller revision, just make
it work as is.
Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_qca.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -932,6 +932,9 @@ static int qca_setup(struct hci_uart *hu
if (!ret) {
set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
qca_debugfs_init(hdev);
+ } else if (ret == -ENOENT) {
+ /* No patch/nvm-config found, run with original fw/config */
+ ret = 0;
}
/* Setup bdaddr */
Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are
queue-4.15/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch
queue-4.15/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btqcomsmd: Fix skb double free corruption
to the 4.15-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:
bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:39 CET 2018
From: Loic Poulain <loic.poulain(a)linaro.org>
Date: Wed, 22 Nov 2017 15:03:17 +0100
Subject: Bluetooth: btqcomsmd: Fix skb double free corruption
From: Loic Poulain <loic.poulain(a)linaro.org>
[ Upstream commit 67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ]
In case of hci send frame failure, skb is still owned
by the caller (hci_core) and then should not be freed.
This fixes crash on dragonboard-410c when sending SCO
packet. skb is freed by both btqcomsmd and hci_core.
Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btqcomsmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -88,7 +88,8 @@ static int btqcomsmd_send(struct hci_dev
break;
}
- kfree_skb(skb);
+ if (!ret)
+ kfree_skb(skb);
return ret;
}
Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are
queue-4.15/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch
queue-4.15/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch
This is a note to let you know that I've just added the patch titled
ath10k: handling qos at STA side based on AP WMM enable/disable
to the 4.15-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:
ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:39 CET 2018
From: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com>
Date: Thu, 7 Dec 2017 16:58:04 +0200
Subject: ath10k: handling qos at STA side based on AP WMM enable/disable
From: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com>
[ Upstream commit 07ffb4497360ae8789f05555fec8171ee952304d ]
Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.
This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.
This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.
For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.
Signed-off-by: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(stru
}
break;
case WMI_VDEV_TYPE_STA:
- if (vif->bss_conf.qos)
+ if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:
Patches currently in stable-queue which might be from bpothuno(a)qti.qualcomm.com are
queue-4.15/ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: aspeed-evb: Add unit name to memory node
to the 4.15-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:
arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch
and it can be found in the queue-4.15 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 foo@baz Thu Mar 22 14:03:40 CET 2018
From: Joel Stanley <joel(a)jms.id.au>
Date: Mon, 18 Dec 2017 23:27:03 +1030
Subject: ARM: dts: aspeed-evb: Add unit name to memory node
From: Joel Stanley <joel(a)jms.id.au>
[ Upstream commit e40ed274489a5f516da120186578eb379b452ac6 ]
Fixes a warning when building with W=1.
All of the ASPEED device trees build without warnings now.
Signed-off-by: Joel Stanley <joel(a)jms.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
@@ -16,7 +16,7 @@
bootargs = "console=ttyS4,115200 earlyprintk";
};
- memory {
+ memory@80000000 {
reg = <0x80000000 0x20000000>;
};
};
Patches currently in stable-queue which might be from joel(a)jms.id.au are
queue-4.15/arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
to the 4.9-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:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
and it can be found in the queue-4.9 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 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -718,16 +718,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.9/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
The fix for brightness setting when setting delay_off=0 introduces
a regression and has truncated commit message. Revert that patch
and apply the one-line change required to fix the original issue
in the way appropriate for the 4.9 code base.
Changes from v1:
- added Reported-by and Signed-off-by tags
Thanks,
Jacek Anaszewski
Jacek Anaszewski (2):
Revert "led: core: Fix brightness setting when setting delay_off=0"
led: core: Clear LED_BLINK_SW flag in led_blink_set()
drivers/leds/led-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.1.4
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
to the 4.4-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:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
and it can be found in the queue-4.4 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 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -703,16 +703,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.4/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
to the 4.15-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:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
and it can be found in the queue-4.15 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 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -709,16 +709,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.15/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
This is a note to let you know that I've just added the patch titled
staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
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:
staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.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 740a5759bf222332fbb5eda42f89aa25ba38f9b2 Mon Sep 17 00:00:00 2001
From: Yisheng Xie <xieyisheng1(a)huawei.com>
Date: Wed, 28 Feb 2018 14:59:22 +0800
Subject: staging: android: ashmem: Fix possible deadlock in ashmem_ioctl
From: Yisheng Xie <xieyisheng1(a)huawei.com>
commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.
ashmem_mutex may create a chain of dependencies like:
CPU0 CPU1
mmap syscall ioctl syscall
-> mmap_sem (acquired) -> ashmem_ioctl
-> ashmem_mmap -> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire) -> copy_from_user
-> mmap_sem (try to acquire)
There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.
[1] https://www.spinics.net/lists/kernel/msg2733200.html
Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36(a)syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie <xieyisheng1(a)huawei.com>
Cc: "Joel Fernandes (Google)" <joel.opensrc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ashmem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -709,16 +709,14 @@ static int ashmem_pin_unpin(struct ashme
size_t pgstart, pgend;
int ret = -EINVAL;
+ if (unlikely(copy_from_user(&pin, p, sizeof(pin))))
+ return -EFAULT;
+
mutex_lock(&ashmem_mutex);
if (unlikely(!asma->file))
goto out_unlock;
- if (unlikely(copy_from_user(&pin, p, sizeof(pin)))) {
- ret = -EFAULT;
- goto out_unlock;
- }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
Patches currently in stable-queue which might be from xieyisheng1(a)huawei.com are
queue-4.14/staging-android-ashmem-fix-possible-deadlock-in-ashmem_ioctl.patch
The patch below does not apply to the 4.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 0911287ce32b14fbc8aab0083151d9b54254091c Mon Sep 17 00:00:00 2001
From: Alexei Starovoitov <ast(a)kernel.org>
Date: Fri, 2 Feb 2018 15:14:05 -0800
Subject: [PATCH] bpf: fix bpf_prog_array_copy_to_user() issues
1. move copy_to_user out of rcu section to fix the following issue:
./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
stack backtrace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4592
rcu_preempt_sleep_check include/linux/rcupdate.h:301 [inline]
___might_sleep+0x385/0x470 kernel/sched/core.c:6079
__might_sleep+0x95/0x190 kernel/sched/core.c:6067
__might_fault+0xab/0x1d0 mm/memory.c:4532
_copy_to_user+0x2c/0xc0 lib/usercopy.c:25
copy_to_user include/linux/uaccess.h:155 [inline]
bpf_prog_array_copy_to_user+0x217/0x4d0 kernel/bpf/core.c:1587
bpf_prog_array_copy_info+0x17b/0x1c0 kernel/bpf/core.c:1685
perf_event_query_prog_array+0x196/0x280 kernel/trace/bpf_trace.c:877
_perf_ioctl kernel/events/core.c:4737 [inline]
perf_ioctl+0x3e1/0x1480 kernel/events/core.c:4757
2. move *prog under rcu, since it's not ok to dereference it afterwards
3. in a rare case of prog array being swapped between bpf_prog_array_length()
and bpf_prog_array_copy_to_user() calls make sure to copy zeros to user space,
so the user doesn't walk over uninited prog_ids while kernel reported
uattr->query.prog_cnt > 0
Reported-by: syzbot+7dbcd2d3b85f9b608b23(a)syzkaller.appspotmail.com
Fixes: 468e2f64d220 ("bpf: introduce BPF_PROG_QUERY command")
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 5f35f93dcab2..29ca9208dcfa 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1576,25 +1576,41 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
__u32 __user *prog_ids, u32 cnt)
{
struct bpf_prog **prog;
- u32 i = 0, id;
-
+ unsigned long err = 0;
+ u32 i = 0, *ids;
+ bool nospc;
+
+ /* users of this function are doing:
+ * cnt = bpf_prog_array_length();
+ * if (cnt > 0)
+ * bpf_prog_array_copy_to_user(..., cnt);
+ * so below kcalloc doesn't need extra cnt > 0 check, but
+ * bpf_prog_array_length() releases rcu lock and
+ * prog array could have been swapped with empty or larger array,
+ * so always copy 'cnt' prog_ids to the user.
+ * In a rare race the user will see zero prog_ids
+ */
+ ids = kcalloc(cnt, sizeof(u32), GFP_USER);
+ if (!ids)
+ return -ENOMEM;
rcu_read_lock();
prog = rcu_dereference(progs)->progs;
for (; *prog; prog++) {
if (*prog == &dummy_bpf_prog.prog)
continue;
- id = (*prog)->aux->id;
- if (copy_to_user(prog_ids + i, &id, sizeof(id))) {
- rcu_read_unlock();
- return -EFAULT;
- }
+ ids[i] = (*prog)->aux->id;
if (++i == cnt) {
prog++;
break;
}
}
+ nospc = !!(*prog);
rcu_read_unlock();
- if (*prog)
+ err = copy_to_user(prog_ids, ids, cnt * sizeof(u32));
+ kfree(ids);
+ if (err)
+ return -EFAULT;
+ if (nospc)
return -ENOSPC;
return 0;
}