This is a note to let you know that I've just added the patch titled
dmaengine: zynqmp_dma: Fix race condition in the probe
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-zynqmp_dma-fix-race-condition-in-the-probe.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: Kedareswara rao Appana <appana.durga.rao(a)xilinx.com>
Date: Thu, 7 Dec 2017 10:54:28 +0530
Subject: dmaengine: zynqmp_dma: Fix race condition in the probe
From: Kedareswara rao Appana <appana.durga.rao(a)xilinx.com>
[ Upstream commit 5ba080aada5e739165e0f38d5cc3b04c82b323c8 ]
Incase of interrupt property is not present,
Driver is trying to free an invalid irq,
This patch fixes it by adding a check before freeing the irq.
Signed-off-by: Kedareswara rao Appana <appanad(a)xilinx.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/xilinx/zynqmp_dma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -838,7 +838,8 @@ static void zynqmp_dma_chan_remove(struc
if (!chan)
return;
- devm_free_irq(chan->zdev->dev, chan->irq, chan);
+ if (chan->irq)
+ devm_free_irq(chan->zdev->dev, chan->irq, chan);
tasklet_kill(&chan->tasklet);
list_del(&chan->common.device_node);
clk_disable_unprepare(chan->clk_apb);
Patches currently in stable-queue which might be from appana.durga.rao(a)xilinx.com are
queue-4.15/dmaengine-zynqmp_dma-fix-race-condition-in-the-probe.patch
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;
}
This is a note to let you know that I've just added the patch titled
tpm: fix potential buffer overruns caused by bit glitches on the bus
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:
tpm-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.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 3be23274755ee85771270a23af7691dc9b3a95db Mon Sep 17 00:00:00 2001
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Date: Thu, 8 Feb 2018 12:28:08 -0800
Subject: tpm: fix potential buffer overruns caused by bit glitches on the bus
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit 3be23274755ee85771270a23af7691dc9b3a95db upstream.
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: James Morris <james.morris(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/tpm/tpm-interface.c | 5 +++++
drivers/char/tpm/tpm2-cmd.c | 6 ++++++
2 files changed, 11 insertions(+)
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1078,6 +1078,11 @@ int tpm_get_random(u32 chip_num, u8 *out
break;
recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ if (recd > num_bytes) {
+ total = -EFAULT;
+ break;
+ }
+
memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
dest += recd;
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -668,6 +668,11 @@ static int tpm2_unseal_cmd(struct tpm_ch
if (!rc) {
data_len = be16_to_cpup(
(__be16 *) &buf.data[TPM_HEADER_SIZE + 4]);
+ if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) {
+ rc = -EFAULT;
+ goto out;
+ }
+
data = &buf.data[TPM_HEADER_SIZE + 6];
memcpy(payload->key, data, data_len - 1);
@@ -675,6 +680,7 @@ static int tpm2_unseal_cmd(struct tpm_ch
payload->migratable = data[data_len - 1];
}
+out:
tpm_buf_destroy(&buf);
return rc;
}
Patches currently in stable-queue which might be from jeremy.boone(a)nccgroup.trust are
queue-4.9/tpm-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.patch
This is a note to let you know that I've just added the patch titled
SMB3: Validate negotiate request must always be signed
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:
smb3-validate-negotiate-request-must-always-be-signed.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 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd Mon Sep 17 00:00:00 2001
From: Steve French <smfrench(a)gmail.com>
Date: Wed, 25 Oct 2017 15:58:31 -0500
Subject: SMB3: Validate negotiate request must always be signed
From: Steve French <smfrench(a)gmail.com>
commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.
According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned
See kernel bugzilla bug 197311
CC: Stable <stable(a)vger.kernel.org>
Acked-by: Ronnie Sahlberg <lsahlber.redhat.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1712,6 +1712,9 @@ SMB2_ioctl(const unsigned int xid, struc
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
+ /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+ if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+ req->hdr.Flags |= SMB2_FLAGS_SIGNED;
rc = SendReceive2(xid, ses, iov, num_iovecs, &resp_buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
Patches currently in stable-queue which might be from smfrench(a)gmail.com are
queue-4.9/smb3-validate-negotiate-request-must-always-be-signed.patch
queue-4.9/cifs-enable-encryption-during-session-setup-phase.patch
This is a note to let you know that I've just added the patch titled
CIFS: Enable encryption during session setup phase
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:
cifs-enable-encryption-during-session-setup-phase.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 cabfb3680f78981d26c078a26e5c748531257ebb Mon Sep 17 00:00:00 2001
From: Pavel Shilovsky <pshilov(a)microsoft.com>
Date: Mon, 7 Nov 2016 18:20:50 -0800
Subject: CIFS: Enable encryption during session setup phase
From: Pavel Shilovsky <pshilov(a)microsoft.com>
commit cabfb3680f78981d26c078a26e5c748531257ebb upstream.
In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.
Signed-off-by: Pavel Shilovsky <pshilov(a)microsoft.com>
Cc: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/sess.c | 22 ++++++++++------------
fs/cifs/smb2pdu.c | 12 ++----------
2 files changed, 12 insertions(+), 22 deletions(-)
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -344,13 +344,12 @@ void build_ntlmssp_negotiate_blob(unsign
/* BB is NTLMV2 session security format easier to use here? */
flags = NTLMSSP_NEGOTIATE_56 | NTLMSSP_REQUEST_TARGET |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
sec_blob->NegotiateFlags = cpu_to_le32(flags);
@@ -407,13 +406,12 @@ int build_ntlmssp_auth_blob(unsigned cha
flags = NTLMSSP_NEGOTIATE_56 |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_TARGET_INFO |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
tmp = *pbuffer + sizeof(AUTHENTICATE_MESSAGE);
sec_blob->NegotiateFlags = cpu_to_le32(flags);
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -707,15 +707,13 @@ SMB2_sess_establish_session(struct SMB2_
struct cifs_ses *ses = sess_data->ses;
mutex_lock(&ses->server->srv_mutex);
- if (ses->server->sign && ses->server->ops->generate_signingkey) {
+ if (ses->server->ops->generate_signingkey) {
rc = ses->server->ops->generate_signingkey(ses);
- kfree(ses->auth_key.response);
- ses->auth_key.response = NULL;
if (rc) {
cifs_dbg(FYI,
"SMB3 session key generation failed\n");
mutex_unlock(&ses->server->srv_mutex);
- goto keygen_exit;
+ return rc;
}
}
if (!ses->server->session_estab) {
@@ -729,12 +727,6 @@ SMB2_sess_establish_session(struct SMB2_
ses->status = CifsGood;
ses->need_reconnect = false;
spin_unlock(&GlobalMid_Lock);
-
-keygen_exit:
- if (!ses->server->sign) {
- kfree(ses->auth_key.response);
- ses->auth_key.response = NULL;
- }
return rc;
}
Patches currently in stable-queue which might be from pshilov(a)microsoft.com are
queue-4.9/cifs-enable-encryption-during-session-setup-phase.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: check src mod pointer for rsnd_mod_id()
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:
asoc-rsnd-check-src-mod-pointer-for-rsnd_mod_id.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 374503c6109e60f48fa9b11341b14466f07bd3f4 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 17 May 2017 06:50:32 +0000
Subject: ASoC: rsnd: check src mod pointer for rsnd_mod_id()
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
commit 374503c6109e60f48fa9b11341b14466f07bd3f4 upstream.
Without this patch, gcc 4.9.x says
sound/soc/sh/rcar/cmd.c: In function 'rsnd_cmd_init':
sound/soc/sh/rcar/cmd.c:85:14: warning: array subscript is below array\
bounds [-Warray-bounds]
data = path[rsnd_mod_id(src)] |
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/cmd.c | 3 +++
1 file changed, 3 insertions(+)
--- a/sound/soc/sh/rcar/cmd.c
+++ b/sound/soc/sh/rcar/cmd.c
@@ -82,6 +82,9 @@ static int rsnd_cmd_init(struct rsnd_mod
[9] = 0x2,
};
+ if (unlikely(!src))
+ return -EIO;
+
data = path[rsnd_mod_id(src)] |
cmd_case[rsnd_mod_id(src)] << 16;
}
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.9/asoc-rsnd-check-src-mod-pointer-for-rsnd_mod_id.patch
This is a note to let you know that I've just added the patch titled
tpm_tis: fix potential buffer overruns caused by bit glitches on the bus
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:
tpm_tis-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.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 6bb320ca4a4a7b5b3db8c8d7250cc40002046878 Mon Sep 17 00:00:00 2001
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Date: Thu, 8 Feb 2018 12:32:06 -0800
Subject: tpm_tis: fix potential buffer overruns caused by bit glitches on the bus
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit 6bb320ca4a4a7b5b3db8c8d7250cc40002046878 upstream.
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data. Also sanity check that the expected amount of data is
large enough for the TPM header.
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: James Morris <james.morris(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/tpm/tpm_tis.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -283,7 +283,8 @@ static int recv_data(struct tpm_chip *ch
static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
{
int size = 0;
- int expected, status;
+ int status;
+ u32 expected;
if (count < TPM_HEADER_SIZE) {
size = -EIO;
@@ -298,7 +299,7 @@ static int tpm_tis_recv(struct tpm_chip
}
expected = be32_to_cpu(*(__be32 *) (buf + 2));
- if (expected > count) {
+ if (expected > count || expected < TPM_HEADER_SIZE) {
size = -EIO;
goto out;
}
Patches currently in stable-queue which might be from jeremy.boone(a)nccgroup.trust are
queue-4.4/tpm-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.patch
queue-4.4/tpm_tis-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.patch
This is a note to let you know that I've just added the patch titled
tpm: fix potential buffer overruns caused by bit glitches on the bus
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:
tpm-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.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 3be23274755ee85771270a23af7691dc9b3a95db Mon Sep 17 00:00:00 2001
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Date: Thu, 8 Feb 2018 12:28:08 -0800
Subject: tpm: fix potential buffer overruns caused by bit glitches on the bus
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit 3be23274755ee85771270a23af7691dc9b3a95db upstream.
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: James Morris <james.morris(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/char/tpm/tpm-interface.c | 5 +++++
drivers/char/tpm/tpm2-cmd.c | 6 ++++++
2 files changed, 11 insertions(+)
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1040,6 +1040,11 @@ int tpm_get_random(u32 chip_num, u8 *out
break;
recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ if (recd > num_bytes) {
+ total = -EFAULT;
+ break;
+ }
+
memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
dest += recd;
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -622,6 +622,11 @@ static int tpm2_unseal_cmd(struct tpm_ch
if (!rc) {
data_len = be16_to_cpup(
(__be16 *) &buf.data[TPM_HEADER_SIZE + 4]);
+ if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) {
+ rc = -EFAULT;
+ goto out;
+ }
+
data = &buf.data[TPM_HEADER_SIZE + 6];
memcpy(payload->key, data, data_len - 1);
@@ -629,6 +634,7 @@ static int tpm2_unseal_cmd(struct tpm_ch
payload->migratable = data[data_len - 1];
}
+out:
tpm_buf_destroy(&buf);
return rc;
}
Patches currently in stable-queue which might be from jeremy.boone(a)nccgroup.trust are
queue-4.4/tpm-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.patch
queue-4.4/tpm_tis-fix-potential-buffer-overruns-caused-by-bit-glitches-on-the-bus.patch
This is a note to let you know that I've just added the patch titled
SMB3: Validate negotiate request must always be signed
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:
smb3-validate-negotiate-request-must-always-be-signed.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 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd Mon Sep 17 00:00:00 2001
From: Steve French <smfrench(a)gmail.com>
Date: Wed, 25 Oct 2017 15:58:31 -0500
Subject: SMB3: Validate negotiate request must always be signed
From: Steve French <smfrench(a)gmail.com>
commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.
According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned
See kernel bugzilla bug 197311
CC: Stable <stable(a)vger.kernel.org>
Acked-by: Ronnie Sahlberg <lsahlber.redhat.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa(a)csail.mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1558,6 +1558,9 @@ SMB2_ioctl(const unsigned int xid, struc
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
+ /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+ if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+ req->hdr.Flags |= SMB2_FLAGS_SIGNED;
rc = SendReceive2(xid, ses, iov, num_iovecs, &resp_buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
Patches currently in stable-queue which might be from smfrench(a)gmail.com are
queue-4.4/smb3-validate-negotiate-request-must-always-be-signed.patch
queue-4.4/cifs-enable-encryption-during-session-setup-phase.patch
This is a note to let you know that I've just added the patch titled
CIFS: Enable encryption during session setup phase
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:
cifs-enable-encryption-during-session-setup-phase.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 cabfb3680f78981d26c078a26e5c748531257ebb Mon Sep 17 00:00:00 2001
From: Pavel Shilovsky <pshilov(a)microsoft.com>
Date: Mon, 7 Nov 2016 18:20:50 -0800
Subject: CIFS: Enable encryption during session setup phase
From: Pavel Shilovsky <pshilov(a)microsoft.com>
commit cabfb3680f78981d26c078a26e5c748531257ebb upstream.
In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.
Signed-off-by: Pavel Shilovsky <pshilov(a)microsoft.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa(a)csail.mit.edu>
Cc: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/sess.c | 22 ++++++++++------------
fs/cifs/smb2pdu.c | 8 +-------
2 files changed, 11 insertions(+), 19 deletions(-)
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -344,13 +344,12 @@ void build_ntlmssp_negotiate_blob(unsign
/* BB is NTLMV2 session security format easier to use here? */
flags = NTLMSSP_NEGOTIATE_56 | NTLMSSP_REQUEST_TARGET |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
sec_blob->NegotiateFlags = cpu_to_le32(flags);
@@ -407,13 +406,12 @@ int build_ntlmssp_auth_blob(unsigned cha
flags = NTLMSSP_NEGOTIATE_56 |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_TARGET_INFO |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
tmp = *pbuffer + sizeof(AUTHENTICATE_MESSAGE);
sec_blob->NegotiateFlags = cpu_to_le32(flags);
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -832,10 +832,8 @@ ssetup_exit:
if (!rc) {
mutex_lock(&server->srv_mutex);
- if (server->sign && server->ops->generate_signingkey) {
+ if (server->ops->generate_signingkey) {
rc = server->ops->generate_signingkey(ses);
- kfree(ses->auth_key.response);
- ses->auth_key.response = NULL;
if (rc) {
cifs_dbg(FYI,
"SMB3 session key generation failed\n");
@@ -857,10 +855,6 @@ ssetup_exit:
}
keygen_exit:
- if (!server->sign) {
- kfree(ses->auth_key.response);
- ses->auth_key.response = NULL;
- }
if (spnego_key) {
key_invalidate(spnego_key);
key_put(spnego_key);
Patches currently in stable-queue which might be from pshilov(a)microsoft.com are
queue-4.4/cifs-enable-encryption-during-session-setup-phase.patch
This is a note to let you know that I've just added the patch titled
scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura controllers
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:
scsi-megaraid_sas-do-not-use-32-bit-atomic-request-descriptor-for-ventura-controllers.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 9ff97fa8db94caeab59a3c5401e975df468b4d8e Mon Sep 17 00:00:00 2001
From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com>
Date: Wed, 14 Feb 2018 00:10:52 -0800
Subject: scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura controllers
From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com>
commit 9ff97fa8db94caeab59a3c5401e975df468b4d8e upstream.
Problem Statement: Sending I/O through 32 bit descriptors to Ventura series of
controller results in IO timeout on certain conditions.
This error only occurs on systems with high I/O activity on Ventura series
controllers.
Changes in this patch will prevent driver from using 32 bit descriptor and use
64 bit Descriptors.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Kashyap Desai <kashyap.desai(a)broadcom.com>
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Tomas Henzl <thenzl(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 42 +++++++++-------------------
1 file changed, 14 insertions(+), 28 deletions(-)
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -216,36 +216,30 @@ inline void megasas_return_cmd_fusion(st
/**
* megasas_fire_cmd_fusion - Sends command to the FW
* @instance: Adapter soft state
- * @req_desc: 32bit or 64bit Request descriptor
+ * @req_desc: 64bit Request descriptor
*
- * Perform PCI Write. Ventura supports 32 bit Descriptor.
- * Prior to Ventura (12G) MR controller supports 64 bit Descriptor.
+ * Perform PCI Write.
*/
static void
megasas_fire_cmd_fusion(struct megasas_instance *instance,
union MEGASAS_REQUEST_DESCRIPTOR_UNION *req_desc)
{
- if (instance->adapter_type == VENTURA_SERIES)
- writel(le32_to_cpu(req_desc->u.low),
- &instance->reg_set->inbound_single_queue_port);
- else {
#if defined(writeq) && defined(CONFIG_64BIT)
- u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) |
- le32_to_cpu(req_desc->u.low));
+ u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) |
+ le32_to_cpu(req_desc->u.low));
- writeq(req_data, &instance->reg_set->inbound_low_queue_port);
+ writeq(req_data, &instance->reg_set->inbound_low_queue_port);
#else
- unsigned long flags;
- spin_lock_irqsave(&instance->hba_lock, flags);
- writel(le32_to_cpu(req_desc->u.low),
- &instance->reg_set->inbound_low_queue_port);
- writel(le32_to_cpu(req_desc->u.high),
- &instance->reg_set->inbound_high_queue_port);
- mmiowb();
- spin_unlock_irqrestore(&instance->hba_lock, flags);
+ unsigned long flags;
+ spin_lock_irqsave(&instance->hba_lock, flags);
+ writel(le32_to_cpu(req_desc->u.low),
+ &instance->reg_set->inbound_low_queue_port);
+ writel(le32_to_cpu(req_desc->u.high),
+ &instance->reg_set->inbound_high_queue_port);
+ mmiowb();
+ spin_unlock_irqrestore(&instance->hba_lock, flags);
#endif
- }
}
/**
@@ -982,7 +976,6 @@ megasas_ioc_init_fusion(struct megasas_i
const char *sys_info;
MFI_CAPABILITIES *drv_ops;
u32 scratch_pad_2;
- unsigned long flags;
struct timeval tv;
bool cur_fw_64bit_dma_capable;
@@ -1121,14 +1114,7 @@ megasas_ioc_init_fusion(struct megasas_i
break;
}
- /* For Ventura also IOC INIT required 64 bit Descriptor write. */
- spin_lock_irqsave(&instance->hba_lock, flags);
- writel(le32_to_cpu(req_desc.u.low),
- &instance->reg_set->inbound_low_queue_port);
- writel(le32_to_cpu(req_desc.u.high),
- &instance->reg_set->inbound_high_queue_port);
- mmiowb();
- spin_unlock_irqrestore(&instance->hba_lock, flags);
+ megasas_fire_cmd_fusion(instance, &req_desc);
wait_and_poll(instance, cmd, MFI_POLL_TIMEOUT_SECS);
Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are
queue-4.15/scsi-megaraid_sas-do-not-use-32-bit-atomic-request-descriptor-for-ventura-controllers.patch
This is a note to let you know that I've just added the patch titled
scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura controllers
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:
scsi-megaraid_sas-do-not-use-32-bit-atomic-request-descriptor-for-ventura-controllers.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 9ff97fa8db94caeab59a3c5401e975df468b4d8e Mon Sep 17 00:00:00 2001
From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com>
Date: Wed, 14 Feb 2018 00:10:52 -0800
Subject: scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura controllers
From: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com>
commit 9ff97fa8db94caeab59a3c5401e975df468b4d8e upstream.
Problem Statement: Sending I/O through 32 bit descriptors to Ventura series of
controller results in IO timeout on certain conditions.
This error only occurs on systems with high I/O activity on Ventura series
controllers.
Changes in this patch will prevent driver from using 32 bit descriptor and use
64 bit Descriptors.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Kashyap Desai <kashyap.desai(a)broadcom.com>
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Tomas Henzl <thenzl(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 42 +++++++++-------------------
1 file changed, 14 insertions(+), 28 deletions(-)
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -190,36 +190,30 @@ inline void megasas_return_cmd_fusion(st
/**
* megasas_fire_cmd_fusion - Sends command to the FW
* @instance: Adapter soft state
- * @req_desc: 32bit or 64bit Request descriptor
+ * @req_desc: 64bit Request descriptor
*
- * Perform PCI Write. Ventura supports 32 bit Descriptor.
- * Prior to Ventura (12G) MR controller supports 64 bit Descriptor.
+ * Perform PCI Write.
*/
static void
megasas_fire_cmd_fusion(struct megasas_instance *instance,
union MEGASAS_REQUEST_DESCRIPTOR_UNION *req_desc)
{
- if (instance->is_ventura)
- writel(le32_to_cpu(req_desc->u.low),
- &instance->reg_set->inbound_single_queue_port);
- else {
#if defined(writeq) && defined(CONFIG_64BIT)
- u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) |
- le32_to_cpu(req_desc->u.low));
+ u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) |
+ le32_to_cpu(req_desc->u.low));
- writeq(req_data, &instance->reg_set->inbound_low_queue_port);
+ writeq(req_data, &instance->reg_set->inbound_low_queue_port);
#else
- unsigned long flags;
- spin_lock_irqsave(&instance->hba_lock, flags);
- writel(le32_to_cpu(req_desc->u.low),
- &instance->reg_set->inbound_low_queue_port);
- writel(le32_to_cpu(req_desc->u.high),
- &instance->reg_set->inbound_high_queue_port);
- mmiowb();
- spin_unlock_irqrestore(&instance->hba_lock, flags);
+ unsigned long flags;
+ spin_lock_irqsave(&instance->hba_lock, flags);
+ writel(le32_to_cpu(req_desc->u.low),
+ &instance->reg_set->inbound_low_queue_port);
+ writel(le32_to_cpu(req_desc->u.high),
+ &instance->reg_set->inbound_high_queue_port);
+ mmiowb();
+ spin_unlock_irqrestore(&instance->hba_lock, flags);
#endif
- }
}
/**
@@ -772,7 +766,6 @@ megasas_ioc_init_fusion(struct megasas_i
const char *sys_info;
MFI_CAPABILITIES *drv_ops;
u32 scratch_pad_2;
- unsigned long flags;
fusion = instance->ctrl_context;
@@ -900,14 +893,7 @@ megasas_ioc_init_fusion(struct megasas_i
break;
}
- /* For Ventura also IOC INIT required 64 bit Descriptor write. */
- spin_lock_irqsave(&instance->hba_lock, flags);
- writel(le32_to_cpu(req_desc.u.low),
- &instance->reg_set->inbound_low_queue_port);
- writel(le32_to_cpu(req_desc.u.high),
- &instance->reg_set->inbound_high_queue_port);
- mmiowb();
- spin_unlock_irqrestore(&instance->hba_lock, flags);
+ megasas_fire_cmd_fusion(instance, &req_desc);
wait_and_poll(instance, cmd, MFI_POLL_TIMEOUT_SECS);
Patches currently in stable-queue which might be from shivasharan.srikanteshwara(a)broadcom.com are
queue-4.14/scsi-megaraid_sas-do-not-use-32-bit-atomic-request-descriptor-for-ventura-controllers.patch
Driver currently crashes due to NULL pointer deference
while updating PHY tune register if nvmem cell is NULL.
Since, fused value for Tune1/2 register is optional,
we'd rather bail out.
Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips")
Reviewed-by: Vivek Gautam <vivek.gautam(a)codeaurora.org>
Cc: stable <stable(a)vger.kernel.org> # 4.14+
Signed-off-by: Manu Gautam <mgautam(a)codeaurora.org>
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 94afeac..40fdef8 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -315,6 +315,10 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy *qphy)
const struct qusb2_phy_cfg *cfg = qphy->cfg;
u8 *val;
+ /* efuse register is optional */
+ if (!qphy->cell)
+ return;
+
/*
* Read efuse register having TUNE2/1 parameter's high nibble.
* If efuse register shows value as 0x0, or if we fail to find
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
If System V shmget/shmat operations are used to create a hugetlbfs
backed mapping, it is possible to munmap part of the mapping and
split the underlying vma such that it is not huge page aligned.
This will untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
8<--8<--8<--8< snip 8<--8<--8<--8<
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E
4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E
(4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER:
20040000
CFAR: c00000000036ee44 SOFTE: 1
GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40
GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000
GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000
GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554
GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40
GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950
NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760
LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50
Call Trace:
[c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable)
[c000003fbcdcfb50] [c00000000036ee48]
__unmap_hugepage_range_final+0x28/0x50
[c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190
[c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140
[c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0
[c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0
[c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80
[c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100
[c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30
[c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c
Instruction dump:
552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010
7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs:
introduce ->split() to vm_operations_struct"). A split function
was added to vm_operations_struct to determine if a mapping can
be split. This was mostly for device-dax and hugetlbfs mappings
which have specific alignment constraints.
Mappings initiated via shmget/shmat have their original vm_ops
overwritten with shm_vm_ops. shm_vm_ops functions will call back
to the original vm_ops if needed. Add such a split function to
shm_vm_ops.
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: stable(a)vger.kernel.org
---
Changes in v2
* Updated commit message
* Cc stable
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index 4643865e9171..93e0e3a4d009 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vmf)
return sfd->vm_ops->fault(vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -510,6 +521,7 @@ static const struct vm_operations_struct shm_vm_ops = {
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
--
2.13.6
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().
Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.
The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).
But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.
Cc: <stable(a)vger.kernel.org> # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Signed-off-by: Simon Gaiser <simon(a)invisiblethingslab.com>
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
index a493e99bed21..81a84b3c1c50 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -365,7 +365,7 @@ void xenbus_dev_queue_reply(struct xb_req_data *req)
if (WARN_ON(rc))
goto out;
}
- } else if (req->msg.type == XS_TRANSACTION_END) {
+ } else if (req->type == XS_TRANSACTION_END) {
trans = xenbus_get_transaction(u, req->msg.tx_id);
if (WARN_ON(!trans))
goto out;
--
2.16.2
The patch titled
Subject: mm/hugetlb: prevent hugetlb VMA to be misaligned
has been removed from the -mm tree. Its filename was
mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned.patch
This patch was dropped because an alternative patch was merged
------------------------------------------------------
From: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Subject: mm/hugetlb: prevent hugetlb VMA to be misaligned
When running the sampler detailed below, the kernel, if built with the VM
debug option turned on (as many distro do), is panicing with the following
message:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
8<--8<--8<--8< snip 8<--8<--8<--8<
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E
4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E
(4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER:
20040000
CFAR: c00000000036ee44 SOFTE: 1
GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40
GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000
GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000
GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554
GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40
GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950
NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760
LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50
Call Trace:
[c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable)
[c000003fbcdcfb50] [c00000000036ee48]
__unmap_hugepage_range_final+0x28/0x50
[c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190
[c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140
[c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0
[c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0
[c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80
[c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100
[c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30
[c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c
Instruction dump:
552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010
7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468
===[ end trace ee88f958a1c62605 ]===
The panic is due to a VMA pointing to a hugetlb area while the
vma->vm_start or vma->vm_end field are not aligned to the huge page
boundaries. The sampler is just unmapping a part of the hugetlb area,
leading to 2 VMAs which are not well aligned. The same could be achieved
by calling madvise() situation, as it is when running: stress-ng
--shm-sysv 1
The hugetlb code is assuming that the VMA will be well aligned when it is
unmapped, so we must prevent such a VMA from bing split or shrunk to a
misaligned address.
This patch prevents this by checking the new VMA's boundaries when a VMA
is modified by calling vma_adjust().
=== Sampler used to hit the panic
nclude <sys/ipc.h>
unsigned long page_size;
int main(void)
{
int shmid, ret=1;
void *addr;
setbuf(stdout, NULL);
page_size = getpagesize();
shmid = shmget(0x1410, LENGTH, IPC_CREAT | SHM_HUGETLB | SHM_R |
SHM_W);
if (shmid < 0) {
perror("shmget");
exit(1);
}
printf("shmid: %d
", shmid);
addr = shmat(shmid, NULL, 0);
if (addr == (void*)-1) {
perror("shmat");
goto out;
}
/*
* The following munmap() call will split the VMA in 2, leading to
* unaligned to huge page size VMAs which will trigger a check when
* shmdt() is called.
*/
if (munmap(addr + HPSIZE + page_size, page_size)) {
perror("munmap");
goto out;
}
if (shmdt(addr)) {
perror("shmdt");
goto out;
}
printf("test done.
");
ret = 0;
out:
shmctl(shmid, IPC_RMID, NULL);
return ret;
}
=== End of code
Link: http://lkml.kernel.org/r/1521566754-30390-1-git-send-email-ldufour@linux.vn…
Signed-off-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN mm/mmap.c~mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned mm/mmap.c
--- a/mm/mmap.c~mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned
+++ a/mm/mmap.c
@@ -692,6 +692,17 @@ int __vma_adjust(struct vm_area_struct *
long adjust_next = 0;
int remove_next = 0;
+ if (is_vm_hugetlb_page(vma)) {
+ /*
+ * We must check against the huge page boundarie to not
+ * create misaligned VMA.
+ */
+ struct hstate *h = hstate_vma(vma);
+
+ if (start & ~huge_page_mask(h) || end & ~huge_page_mask(h))
+ return -EINVAL;
+ }
+
if (next && !insert) {
struct vm_area_struct *exporter = NULL, *importer = NULL;
_
Patches currently in -mm which might be from ldufour(a)linux.vnet.ibm.com are
The patch titled
Subject: ipc/shm.c: add split function to shm_vm_ops
has been added to the -mm tree. Its filename is
shm-add-split-function-to-shm_vm_ops.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/shm-add-split-function-to-shm_vm_o…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/shm-add-split-function-to-shm_vm_o…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: ipc/shm.c: add split function to shm_vm_ops
If System V shmget/shmat operations are used to create a hugetlbfs backed
mapping, it is possible to munmap part of the mapping and split the
underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
8<--8<--8<--8< snip 8<--8<--8<--8<
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E
4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E
(4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER:
20040000
CFAR: c00000000036ee44 SOFTE: 1
GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40
GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000
GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000
GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554
GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40
GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950
NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760
LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50
Call Trace:
[c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable)
[c000003fbcdcfb50] [c00000000036ee48]
__unmap_hugepage_range_final+0x28/0x50
[c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190
[c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140
[c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0
[c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0
[c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80
[c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100
[c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30
[c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c
Instruction dump:
552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010
7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by 31383c6865a5 ("mm, hugetlbfs: introduce
->split() to vm_operations_struct"). A split function was added to
vm_operations_struct to determine if a mapping can be split. This was
mostly for device-dax and hugetlbfs mappings which have specific alignment
constraints.
Mappings initiated via shmget/shmat have their original vm_ops overwritten
with shm_vm_ops. shm_vm_ops functions will call back to the original
vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff -puN ipc/shm.c~shm-add-split-function-to-shm_vm_ops ipc/shm.c
--- a/ipc/shm.c~shm-add-split-function-to-shm_vm_ops
+++ a/ipc/shm.c
@@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vm
return sfd->vm_ops->fault(vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -510,6 +521,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
_
Patches currently in -mm which might be from mike.kravetz(a)oracle.com are
hugetlbfs-check-for-pgoff-value-overflow.patch
hugetlbfs-check-for-pgoff-value-overflow-v3.patch
shm-add-split-function-to-shm_vm_ops.patch
mm-hugetlbfs-move-hugetlbfs_i-outside-ifdef-config_hugetlbfs.patch
mm-memfd-split-out-memfd-for-use-by-multiple-filesystems.patch
mm-memfd-remove-memfd-code-from-shmem-files-and-use-new-memfd-files.patch
mm-make-start_isolate_page_range-fail-if-already-isolated.patch
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: atomisp_fops.c: disable atomisp_compat_ioctl32
Author: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Sun Feb 25 06:55:32 2018 -0500
The atomisp_compat_ioctl32() code has problems. This patch disables the
compat_ioctl32 support until those issues have been fixed.
Contact Sakari or me for more details.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: <stable(a)vger.kernel.org> # for v4.12 and up
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c | 6 ++++++
1 file changed, 6 insertions(+)
---
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
index 4f9f9dca5e6a..545ef024841d 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_fops.c
@@ -1279,7 +1279,10 @@ const struct v4l2_file_operations atomisp_fops = {
.mmap = atomisp_mmap,
.unlocked_ioctl = video_ioctl2,
#ifdef CONFIG_COMPAT
+ /*
+ * There are problems with this code. Disable this for now.
.compat_ioctl32 = atomisp_compat_ioctl32,
+ */
#endif
.poll = atomisp_poll,
};
@@ -1291,7 +1294,10 @@ const struct v4l2_file_operations atomisp_file_fops = {
.mmap = atomisp_file_mmap,
.unlocked_ioctl = video_ioctl2,
#ifdef CONFIG_COMPAT
+ /*
+ * There are problems with this code. Disable this for now.
.compat_ioctl32 = atomisp_compat_ioctl32,
+ */
#endif
.poll = atomisp_poll,
};
From: Alex Smith <alex.smith(a)imgtec.com>
A spinlock is held while updating the internal copy of the IRQ mask,
but not while writing it to the actual IMASK register. After the lock
is released, an IRQ can occur before the IMASK register is written.
If handling this IRQ causes the mask to be changed, when the handler
returns back to the middle of the first mask update, a stale value
will be written to the mask register.
If this causes an IRQ to become unmasked that cannot have its status
cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ,
then we can end up stuck with the same IRQ repeatedly being fired but
not handled. Normally the MMC IRQ handler attempts to clear any
unexpected IRQs by writing IREG, but for those that cannot be cleared
in this way then the IRQ will just repeatedly fire.
This was resulting in lockups after a while of using Wi-Fi on the
CI20 (GitHub issue #19).
Resolve by holding the spinlock until after the IMASK register has
been updated.
Cc: stable(a)vger.kernel.org
Link: https://github.com/MIPS/CI20_linux/issues/19
Fixes: 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.")
Tested-by: Mathieu Malaterre <malat(a)debian.org>
Signed-off-by: Alex Smith <alex.smith(a)imgtec.com>
---
drivers/mmc/host/jz4740_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 712e08d9a45e..a0168e9e4fce 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -362,9 +362,9 @@ static void jz4740_mmc_set_irq_enabled(struct jz4740_mmc_host *host,
host->irq_mask &= ~irq;
else
host->irq_mask |= irq;
- spin_unlock_irqrestore(&host->lock, flags);
writew(host->irq_mask, host->base + JZ_REG_MMC_IMASK);
+ spin_unlock_irqrestore(&host->lock, flags);
}
static void jz4740_mmc_clock_enable(struct jz4740_mmc_host *host,
--
2.16.2
Since commit 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only
feature") coupled CPU idle freezes from time to time on Exynos4210. Later
commit 313c8c16ee62 ("PM / CPU: replace raw_notifier with atomic_notifier")
changed the context in which the CPU idle code is executed, what results
in fully reproducible freeze all the time. However, almost the same coupled
CPU idle code works fine on Exynos3250 regarless of the changes made in
the mentioned commits.
It turned out that the IPI call used on Exynos4210 is conflicting with the
change done in the first mentioned commit in GIC. Fix this by using the
same code path as for Exynos3250, instead of the IPI call for
synchronization with second CPU core, call dsb_sev() directly.
Tested on Exynos4210-based Trats and Origen boards.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
CC: stable(a)vger.kernel.org # v4.13+
---
arch/arm/mach-exynos/pm.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index dc4346ecf16d..a1055a2b8d54 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -271,11 +271,7 @@ static int exynos_cpu0_enter_aftr(void)
goto fail;
call_firmware_op(cpu_boot, 1);
-
- if (soc_is_exynos3250())
- dsb_sev();
- else
- arch_send_wakeup_ipi_mask(cpumask_of(1));
+ dsb_sev();
}
}
fail:
--
2.15.0
There are only 19 PIOB pins having primary names PB0-PB18. Not all of them
have a 'C' function. So the pinctrl property mask ends up being the same as the
other SoC of the at91sam9x5 series.
Reported-by: Marek Sieranski <marek.sieranski(a)microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: <stable(a)vger.kernel.org> # v3.8+
---
arch/arm/boot/dts/at91sam9g25.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9g25.dtsi b/arch/arm/boot/dts/at91sam9g25.dtsi
index a7da0dd0c98f..0898213f3bb2 100644
--- a/arch/arm/boot/dts/at91sam9g25.dtsi
+++ b/arch/arm/boot/dts/at91sam9g25.dtsi
@@ -21,7 +21,7 @@
atmel,mux-mask = <
/* A B C */
0xffffffff 0xffe0399f 0xc000001c /* pioA */
- 0x0007ffff 0x8000fe3f 0x00000000 /* pioB */
+ 0x0007ffff 0x00047e3f 0x00000000 /* pioB */
0x80000000 0x07c0ffff 0xb83fffff /* pioC */
0x003fffff 0x003f8000 0x00000000 /* pioD */
>;
--
2.15.1
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: rc: oops in ir_timer_keyup after device unplug
Author: Sean Young <sean(a)mess.org>
Date: Tue Mar 6 08:57:57 2018 -0500
If there is IR in the raw kfifo when ir_raw_event_unregister() is called,
then kthread_stop() causes ir_raw_event_thread to be scheduled, decode
some scancodes and re-arm timer_keyup. The timer_keyup then fires when
the rc device is long gone.
Cc: stable(a)vger.kernel.org
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/rc/rc-main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 4a952108ba1e..8621761a680f 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1932,12 +1932,12 @@ void rc_unregister_device(struct rc_dev *dev)
if (!dev)
return;
- del_timer_sync(&dev->timer_keyup);
- del_timer_sync(&dev->timer_repeat);
-
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_event_unregister(dev);
+ del_timer_sync(&dev->timer_keyup);
+ del_timer_sync(&dev->timer_repeat);
+
rc_free_rx_device(dev);
mutex_lock(&dev->lock);
On Wed, 21 Mar 2018 10:08:03 +0100
Gerd Hoffmann <kraxel(a)redhat.com> wrote:
> On unknown/unhandled ioctls the driver should return an error, so
> userspace knows it tried to use something unsupported.
>
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 021f722e24..be881d53c2 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1284,7 +1284,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, unsigned int cmd,
>
> }
>
> - return 0;
> + return -EINVAL;
> }
>
> static ssize_t
Absolutely, but I'd prefer to continue the standard behavior among
other vfio drivers, and adopted from elsewhere in the kernel, to use
-ENOTTY for an unhandled ioctl, reserving -EINVAL as an error in
options for a supported ioctl. Thanks,
Alex
This is the start of the stable review cycle for the 4.15.12 release.
There are 52 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Mar 21 18:07:15 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.12-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.15.12-rc1
Al Cooper <al.cooper(a)broadcom.com>
phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled
Al Cooper <al.cooper(a)broadcom.com>
phy: phy-brcm-usb-init: DRD mode can cause crash on startup
Al Cooper <al.cooper(a)broadcom.com>
phy: phy-brcm-usb-init: Some Low Speed keyboards fail on 7271
Al Cooper <alcooperx(a)gmail.com>
phy: phy-brcm-usb: Fix two DT properties to match bindings doc
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove()
Enric Balletbo i Serra <enric.balletbo(a)collabora.com>
usb: dwc3: of-simple: fix oops by unbalanced clk disable call
Manu Gautam <mgautam(a)codeaurora.org>
usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
Wei Yongjun <weiyongjun1(a)huawei.com>
USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
Amelie Delaunay <amelie.delaunay(a)st.com>
dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding
Amelie Delaunay <amelie.delaunay(a)st.com>
usb: dwc2: fix STM32F7 USB OTG HS compatible
Bill Kuzeja <William.Kuzeja(a)stratus.com>
scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure
Himanshu Madhani <hmadhani(a)redhat.com>
scsi: qla2xxx: Fix logo flag for qlt_free_session_done()
Quinn Tran <quinn.tran(a)cavium.com>
scsi: qla2xxx: Fix NULL pointer access for fcport structure
Himanshu Madhani <himanshu.madhani(a)cavium.com>
scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que
Nikolay Borisov <nborisov(a)suse.com>
btrfs: Fix memory barriers usage with device stats counters
Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes
Nikolay Borisov <nborisov(a)suse.com>
btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
btrfs: alloc_chunk: fix DUP stripe size handling
Edmund Nadolski <enadolski(a)suse.com>
btrfs: add missing initialization in btrfs_check_shared
Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com>
btrfs: Fix NULL pointer exception in find_bio_stripe
Amir Goldstein <amir73il(a)gmail.com>
xfs: preserve i_rdev when recycling a reclaimable inode
Israel Rukshin <israelr(a)mellanox.com>
nvme: fix subsystem multiple controllers support check
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
Tejun Heo <tj(a)kernel.org>
RDMAVT: Fix synchronization around percpu_ref
Tejun Heo <tj(a)kernel.org>
fs/aio: Use RCU accessors for kioctx_table->table[]
Tejun Heo <tj(a)kernel.org>
fs/aio: Add explicit RCU grace period when freeing kioctx
Al Viro <viro(a)zeniv.linux.org.uk>
lock_parent() needs to recheck if dentry got __dentry_kill'ed under it
Marc Zyngier <marc.zyngier(a)arm.com>
KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid
Marc Zyngier <marc.zyngier(a)arm.com>
kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3
Christoffer Dall <cdall(a)kernel.org>
KVM: arm/arm64: Reset mapped IRQs on VM reset
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
KVM: arm/arm64: Reduce verbosity of KVM init log
Eric W. Biederman <ebiederm(a)xmission.com>
fs: Teach path_connected to handle nfs filesystems with multiple roots.
Michel Dänzer <michel.daenzer(a)amd.com>
drm/amdgpu/dce: Don't turn off DP sink when disconnected
Christian König <christian.koenig(a)amd.com>
drm/radeon: fix prime teardown order
Christian König <christian.koenig(a)amd.com>
drm/amdgpu: fix prime teardown order
Māris Nartišs <maris.nartiss(a)gmail.com>
drm/nouveau/mmu: ALIGN_DOWN correct variable
Lukas Wunner <lukas(a)wunner.de>
drm/nouveau/bl: Fix oops on driver unbind
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Clear client entry before deleting else at closing
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix possible UAF in snd_seq_check_queue()
Takashi Iwai <tiwai(a)suse.de>
ALSA: hda - Revert power_save option default value
Takashi Iwai <tiwai(a)suse.de>
ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()
John David Anglin <dave.anglin(a)bell.net>
parisc: Handle case where flush_cache_range is called with no context
Toshi Kani <toshi.kani(a)hpe.com>
x86/mm: Fix vmalloc_fault to use pXd_large
Tom Lendacky <thomas.lendacky(a)amd.com>
KVM: x86: Fix device passthrough when SME is active
Alexander Sergeyev <sergeev917(a)gmail.com>
x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist
Andy Whitcroft <apw(a)canonical.com>
x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels
Andy Lutomirski <luto(a)kernel.org>
x86/vm86/32: Fix POPF emulation
Andy Lutomirski <luto(a)kernel.org>
selftests/x86/entry_from_vm86: Add test cases for POPF
Andy Lutomirski <luto(a)kernel.org>
selftests/x86/entry_from_vm86: Exit with 1 if we fail
Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
x86/cpufeatures: Add Intel PCONFIG cpufeature
Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
x86/cpufeatures: Add Intel Total Memory Encryption cpufeature
-------------
Diffstat:
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +-
Makefile | 4 +-
arch/parisc/kernel/cache.c | 41 +++++++++---
arch/x86/include/asm/cpufeatures.h | 2 +
arch/x86/include/asm/nospec-branch.h | 5 +-
arch/x86/kernel/cpu/intel.c | 3 +-
arch/x86/kernel/vm86_32.c | 3 +-
arch/x86/kvm/mmu.c | 4 +-
arch/x86/mm/fault.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 31 ++++-----
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 2 -
drivers/gpu/drm/radeon/radeon_object.c | 2 +
drivers/infiniband/sw/rdmavt/mr.c | 10 +--
drivers/irqchip/irq-gic-v3-its.c | 9 ++-
drivers/nvme/host/core.c | 18 +++++-
drivers/phy/broadcom/phy-brcm-usb-init.c | 22 +++----
drivers/phy/broadcom/phy-brcm-usb.c | 4 +-
drivers/scsi/qla2xxx/qla_init.c | 13 ++--
drivers/scsi/qla2xxx/qla_mid.c | 6 +-
drivers/scsi/qla2xxx/qla_os.c | 59 ++++++++++-------
drivers/scsi/qla2xxx/qla_target.c | 1 +
drivers/usb/dwc2/params.c | 6 +-
drivers/usb/dwc3/core.c | 36 ++++++-----
drivers/usb/dwc3/core.h | 16 ++---
drivers/usb/dwc3/dwc3-of-simple.c | 1 +
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
fs/aio.c | 44 ++++++++-----
fs/btrfs/backref.c | 12 +++-
fs/btrfs/raid56.c | 1 +
fs/btrfs/volumes.c | 30 ++++++---
fs/btrfs/volumes.h | 12 ++++
fs/dcache.c | 11 +++-
fs/namei.c | 5 +-
fs/nfs/super.c | 2 +
fs/xfs/xfs_icache.c | 2 +
include/kvm/arm_vgic.h | 1 +
include/linux/fs.h | 1 +
include/linux/irqchip/arm-gic-v3.h | 1 +
include/linux/irqchip/arm-gic.h | 1 +
sound/core/oss/pcm_oss.c | 10 +--
sound/core/seq/seq_clientmgr.c | 4 +-
sound/core/seq/seq_prioq.c | 28 ++++-----
sound/core/seq/seq_prioq.h | 6 +-
sound/core/seq/seq_queue.c | 28 +++------
sound/pci/hda/hda_intel.c | 9 ++-
tools/testing/selftests/x86/entry_from_vm86.c | 32 ++++++++--
virt/kvm/arm/arch_timer.c | 6 +-
virt/kvm/arm/hyp/vgic-v3-sr.c | 3 +-
virt/kvm/arm/mmu.c | 6 +-
virt/kvm/arm/vgic/vgic-v2.c | 11 +++-
virt/kvm/arm/vgic/vgic-v3.c | 9 ++-
virt/kvm/arm/vgic/vgic.c | 87 +++++++++++++++++++++-----
virt/kvm/arm/vgic/vgic.h | 2 +
58 files changed, 461 insertions(+), 222 deletions(-)
This is the start of the stable review cycle for the 4.14.29 release.
There are 41 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Mar 21 18:07:09 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.29-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.29-rc1
Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
Wei Yongjun <weiyongjun1(a)huawei.com>
USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
Bill Kuzeja <William.Kuzeja(a)stratus.com>
scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure
Himanshu Madhani <hmadhani(a)redhat.com>
scsi: qla2xxx: Fix logo flag for qlt_free_session_done()
Quinn Tran <quinn.tran(a)cavium.com>
scsi: qla2xxx: Fix NULL pointer access for fcport structure
Himanshu Madhani <himanshu.madhani(a)cavium.com>
scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que
Nikolay Borisov <nborisov(a)suse.com>
btrfs: Fix memory barriers usage with device stats counters
Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes
Nikolay Borisov <nborisov(a)suse.com>
btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
btrfs: alloc_chunk: fix DUP stripe size handling
Edmund Nadolski <enadolski(a)suse.com>
btrfs: add missing initialization in btrfs_check_shared
Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com>
btrfs: Fix NULL pointer exception in find_bio_stripe
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
Tejun Heo <tj(a)kernel.org>
RDMAVT: Fix synchronization around percpu_ref
Tejun Heo <tj(a)kernel.org>
fs/aio: Use RCU accessors for kioctx_table->table[]
Tejun Heo <tj(a)kernel.org>
fs/aio: Add explicit RCU grace period when freeing kioctx
Al Viro <viro(a)zeniv.linux.org.uk>
lock_parent() needs to recheck if dentry got __dentry_kill'ed under it
Marc Zyngier <marc.zyngier(a)arm.com>
KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid
Marc Zyngier <marc.zyngier(a)arm.com>
kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
KVM: arm/arm64: Reduce verbosity of KVM init log
Eric W. Biederman <ebiederm(a)xmission.com>
fs: Teach path_connected to handle nfs filesystems with multiple roots.
Michel Dänzer <michel.daenzer(a)amd.com>
drm/amdgpu/dce: Don't turn off DP sink when disconnected
Christian König <christian.koenig(a)amd.com>
drm/radeon: fix prime teardown order
Christian König <christian.koenig(a)amd.com>
drm/amdgpu: fix prime teardown order
Lukas Wunner <lukas(a)wunner.de>
drm/nouveau/bl: Fix oops on driver unbind
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Clear client entry before deleting else at closing
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix possible UAF in snd_seq_check_queue()
Takashi Iwai <tiwai(a)suse.de>
ALSA: hda - Revert power_save option default value
Takashi Iwai <tiwai(a)suse.de>
ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()
John David Anglin <dave.anglin(a)bell.net>
parisc: Handle case where flush_cache_range is called with no context
Toshi Kani <toshi.kani(a)hpe.com>
x86/mm: Fix vmalloc_fault to use pXd_large
Tom Lendacky <thomas.lendacky(a)amd.com>
KVM: x86: Fix device passthrough when SME is active
Alexander Sergeyev <sergeev917(a)gmail.com>
x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist
Andy Whitcroft <apw(a)canonical.com>
x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels
Andy Lutomirski <luto(a)kernel.org>
x86/vm86/32: Fix POPF emulation
Andy Lutomirski <luto(a)kernel.org>
selftests/x86/entry_from_vm86: Add test cases for POPF
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
selftests/x86: Add tests for the STR and SLDT instructions
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
selftests/x86: Add tests for User-Mode Instruction Prevention
Andy Lutomirski <luto(a)kernel.org>
selftests/x86/entry_from_vm86: Exit with 1 if we fail
Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
x86/cpufeatures: Add Intel PCONFIG cpufeature
Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
x86/cpufeatures: Add Intel Total Memory Encryption cpufeature
-------------
Diffstat:
Makefile | 4 +-
arch/parisc/kernel/cache.c | 41 +++++++--
arch/x86/include/asm/cpufeatures.h | 2 +
arch/x86/include/asm/nospec-branch.h | 5 +-
arch/x86/kernel/cpu/intel.c | 3 +-
arch/x86/kernel/vm86_32.c | 3 +-
arch/x86/kvm/mmu.c | 4 +-
arch/x86/mm/fault.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 31 +++----
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +-
drivers/gpu/drm/radeon/radeon_gem.c | 2 -
drivers/gpu/drm/radeon/radeon_object.c | 2 +
drivers/infiniband/sw/rdmavt/mr.c | 10 ++-
drivers/irqchip/irq-gic-v3-its.c | 9 +-
drivers/scsi/qla2xxx/qla_init.c | 13 ++-
drivers/scsi/qla2xxx/qla_mid.c | 6 +-
drivers/scsi/qla2xxx/qla_os.c | 59 ++++++++-----
drivers/scsi/qla2xxx/qla_target.c | 1 +
drivers/usb/dwc3/core.h | 16 ++--
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
fs/aio.c | 44 +++++++---
fs/btrfs/backref.c | 12 ++-
fs/btrfs/raid56.c | 1 +
fs/btrfs/volumes.c | 30 +++++--
fs/btrfs/volumes.h | 12 +++
fs/dcache.c | 11 ++-
fs/namei.c | 5 +-
fs/nfs/super.c | 2 +
include/linux/fs.h | 1 +
include/linux/irqchip/arm-gic-v3.h | 1 +
include/linux/irqchip/arm-gic.h | 1 +
sound/core/oss/pcm_oss.c | 10 ++-
sound/core/seq/seq_clientmgr.c | 4 +-
sound/core/seq/seq_prioq.c | 28 +++---
sound/core/seq/seq_prioq.h | 6 +-
sound/core/seq/seq_queue.c | 28 ++----
sound/pci/hda/hda_intel.c | 9 +-
tools/testing/selftests/x86/entry_from_vm86.c | 117 ++++++++++++++++++++++++-
virt/kvm/arm/arch_timer.c | 2 +-
virt/kvm/arm/hyp/vgic-v3-sr.c | 3 +-
virt/kvm/arm/mmu.c | 6 +-
virt/kvm/arm/vgic/vgic-v2.c | 11 ++-
virt/kvm/arm/vgic/vgic-v3.c | 9 +-
virt/kvm/arm/vgic/vgic.c | 61 ++++++++++---
virt/kvm/arm/vgic/vgic.h | 2 +
47 files changed, 456 insertions(+), 186 deletions(-)
On Tue, Mar 20, 2018 at 05:50:27PM +0000, Harsh Shandilya wrote:
> On Tue 20 Mar, 2018, 2:14 AM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.101 release.
> > There are 68 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Mar 21 17:17:59 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.101-r…
> > or in the git tree and branch at:
> > git://
> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
>
> No merge issues with the CAF msm-3.18 tree, no regressions noticed on the
> OnePlus3T.
Wonderful, thanks for testing and letting me know.
greg k-h
Sehr geehrte Damen und Herren,
nach unserem Besuch Ihrer Homepage möchten wir Ihnen ein Angebot von Produkten vorstellen, das Ihnen ermöglichen wird, den Verkauf Ihrer Produkte sowie Dienstleistungen deutlich zu erhöhen.
Ich biete Ihnen den ganz neuen Adressenkatalog der Österreicher Unternehmen an, in dem sich direkte Kontaktdaten der Firmeninhaber und Manager befinden.
Die Datenbanken der Firmen sind in für Sie interessante und relevante Zielgruppen untergliedert.
Die Firmenangaben beinhalten:
Name der Firma, Ansprechpartner, E-mail Adresse, Tel. + Fax-Nr., PLZ, Ort, Straße etc.
***
1. Österreich 2018 ( 104 000 ) - 149 EUR ( bis zum 21.03.2018 )
***
Die Verwendungsmöglichkeiten der Datenbanken sind praktisch unbegrenzt und Sie können durch Verwendung
der von uns entwickelten Programme des personalisierten Versendens von Angeboten u.ä. mittels
E-mailing bzw. Fax effektive und sichere Werbekampagnen damit durchführen.
Bitte informieren Sie sich über die weiteren Details einmal unverbindlich auf unseren Webseite:
http://www.gbcdb.net/?page=catalog
MfG
Thomas Stein
http://www.gbcdb.net/?page=catalog
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit 3be23274755ee85771270a23af7691dc9b3a95db upstream
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
---
Backported to v4.9
v2: fixed the upstream ID
drivers/char/tpm/tpm-interface.c | 5 +++++
drivers/char/tpm/tpm2-cmd.c | 6 ++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index d0ac2d56520f..830d7e30e508 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1078,6 +1078,11 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max)
break;
recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ if (recd > num_bytes) {
+ total = -EFAULT;
+ break;
+ }
+
memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
dest += recd;
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 17896d654033..a5780ebe15ef 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -668,6 +668,11 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
if (!rc) {
data_len = be16_to_cpup(
(__be16 *) &buf.data[TPM_HEADER_SIZE + 4]);
+ if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) {
+ rc = -EFAULT;
+ goto out;
+ }
+
data = &buf.data[TPM_HEADER_SIZE + 6];
memcpy(payload->key, data, data_len - 1);
@@ -675,6 +680,7 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
payload->migratable = data[data_len - 1];
}
+out:
tpm_buf_destroy(&buf);
return rc;
}
--
2.15.1
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit 3be23274755ee85771270a23af7691dc9b3a95db upstream
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
---
Backported to v4.4.
v2: fixed the upstream ID
drivers/char/tpm/tpm-interface.c | 5 +++++
drivers/char/tpm/tpm2-cmd.c | 6 ++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index aaa5fa95dede..36afc1a21699 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1040,6 +1040,11 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max)
break;
recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ if (recd > num_bytes) {
+ total = -EFAULT;
+ break;
+ }
+
memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
dest += recd;
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 286bd090a488..389a009b83f2 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -622,6 +622,11 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
if (!rc) {
data_len = be16_to_cpup(
(__be16 *) &buf.data[TPM_HEADER_SIZE + 4]);
+ if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) {
+ rc = -EFAULT;
+ goto out;
+ }
+
data = &buf.data[TPM_HEADER_SIZE + 6];
memcpy(payload->key, data, data_len - 1);
@@ -629,6 +634,7 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
payload->migratable = data[data_len - 1];
}
+out:
tpm_buf_destroy(&buf);
return rc;
}
--
2.15.1
Tree/Branch: v3.2.101
Git describe: v3.2.101
Commit: 68f705428e Linux 3.2.101
Build Time: 0 min 4 sec
Passed: 0 / 5 ( 0.00 %)
Failed: 5 / 5 (100.00 %)
Errors: 6
Warnings: 20
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allmodconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm-allmodconfig
19 warnings 0 mismatches : arm-allnoconfig
-------------------------------------------------------------------------------
Errors summary: 6
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
Warnings Summary: 20
2 .config:27:warning: symbol value '' invalid for PHYS_OFFSET
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches
Warnings:
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
Warnings:
/home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.16.56
Git describe: v3.16.56
Commit: a413cc78bc Linux 3.16.56
Build Time: 29 min 33 sec
Passed: 8 / 8 (100.00 %)
Failed: 0 / 8 ( 0.00 %)
Errors: 0
Warnings: 4
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
1 warnings 0 mismatches : x86_64-allnoconfig
1 warnings 0 mismatches : arm64-allmodconfig
1 warnings 0 mismatches : x86_64-defconfig
2 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 4
2 ../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
1 ../arch/x86/kernel/cpu/common.c:1032:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../arch/x86/kernel/cpu/common.c:1032:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function]
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v7_defconfig
arm-allnoconfig
arm-multi_v5_defconfig
The patch titled
Subject: mm/hmm: hmm_pfns_bad() was accessing wrong struct
has been added to the -mm tree. Its filename is
mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-hmm_pfns_bad-was-accessing-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-hmm_pfns_bad-was-accessing-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jérôme Glisse <jglisse(a)redhat.com>
Subject: mm/hmm: hmm_pfns_bad() was accessing wrong struct
The private field of mm_walk struct point to an hmm_vma_walk struct and
not to the hmm_range struct desired. Fix to get proper struct pointer.
Link: http://lkml.kernel.org/r/20180320020038.3360-6-jglisse@redhat.com
Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com>
Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com>
Cc: Ralph Campbell <rcampbell(a)nvidia.com>
Cc: Mark Hairgrove <mhairgrove(a)nvidia.com>
Cc: John Hubbard <jhubbard(a)nvidia.com>
Cc: Balbir Singh <bsingharora(a)gmail.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Logan Gunthorpe <logang(a)deltatee.com>
Cc: Stephen Bates <sbates(a)raithlin.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN mm/hmm.c~mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct mm/hmm.c
--- a/mm/hmm.c~mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct
+++ a/mm/hmm.c
@@ -312,7 +312,8 @@ static int hmm_pfns_bad(unsigned long ad
unsigned long end,
struct mm_walk *walk)
{
- struct hmm_range *range = walk->private;
+ struct hmm_vma_walk *hmm_vma_walk = walk->private;
+ struct hmm_range *range = hmm_vma_walk->range;
hmm_pfn_t *pfns = range->pfns;
unsigned long i;
_
Patches currently in -mm which might be from jglisse(a)redhat.com are
mm-hmm-fix-header-file-if-else-endif-maze-v2.patch
mm-hmm-unregister-mmu_notifier-when-last-hmm-client-quit.patch
mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch
mm-hmm-use-struct-for-hmm_vma_fault-hmm_vma_get_pfns-parameters-v2.patch
mm-hmm-remove-hmm_pfn_read-flag-and-ignore-peculiar-architecture-v2.patch
mm-hmm-use-uint64_t-for-hmm-pfn-instead-of-defining-hmm_pfn_t-to-ulong-v2.patch
mm-hmm-cleanup-special-vma-handling-vm_special.patch
mm-hmm-do-not-differentiate-between-empty-entry-or-missing-directory-v2.patch
mm-hmm-rename-hmm_pfn_device_unaddressable-to-hmm_pfn_device_private.patch
mm-hmm-move-hmm_pfns_clear-closer-to-where-it-is-use.patch
mm-hmm-factor-out-pte-and-pmd-handling-to-simplify-hmm_vma_walk_pmd.patch
mm-hmm-change-hmm_vma_fault-to-allow-write-fault-on-page-basis.patch
mm-hmm-use-device-driver-encoding-for-hmm-pfn-v2.patch
The patch titled
Subject: mm/hmm: HMM should have a callback before MM is destroyed v2
has been added to the -mm tree. Its filename is
mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-hmm-should-have-a-callback-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-hmm-should-have-a-callback-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Ralph Campbell <rcampbell(a)nvidia.com>
Subject: mm/hmm: HMM should have a callback before MM is destroyed v2
The hmm_mirror_register() function registers a callback for when the CPU
pagetable is modified. Normally, the device driver will call
hmm_mirror_unregister() when the process using the device is finished.
However, if the process exits uncleanly, the struct_mm can be destroyed
with no warning to the device driver.
Link: http://lkml.kernel.org/r/20180320020038.3360-4-jglisse@redhat.com
Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com>
Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com>
Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com>
Cc: Mark Hairgrove <mhairgrove(a)nvidia.com>
Cc: John Hubbard <jhubbard(a)nvidia.com>
Cc: Balbir Singh <bsingharora(a)gmail.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Logan Gunthorpe <logang(a)deltatee.com>
Cc: Stephen Bates <sbates(a)raithlin.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN include/linux/hmm.h~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 include/linux/hmm.h
--- a/include/linux/hmm.h~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2
+++ a/include/linux/hmm.h
@@ -218,6 +218,16 @@ enum hmm_update_type {
* @update: callback to update range on a device
*/
struct hmm_mirror_ops {
+ /* release() - release hmm_mirror
+ *
+ * @mirror: pointer to struct hmm_mirror
+ *
+ * This is called when the mm_struct is being released.
+ * The callback should make sure no references to the mirror occur
+ * after the callback returns.
+ */
+ void (*release)(struct hmm_mirror *mirror);
+
/* sync_cpu_device_pagetables() - synchronize page tables
*
* @mirror: pointer to struct hmm_mirror
diff -puN mm/hmm.c~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 mm/hmm.c
--- a/mm/hmm.c~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2
+++ a/mm/hmm.c
@@ -160,6 +160,21 @@ static void hmm_invalidate_range(struct
up_read(&hmm->mirrors_sem);
}
+static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm)
+{
+ struct hmm *hmm = mm->hmm;
+ struct hmm_mirror *mirror;
+ struct hmm_mirror *mirror_next;
+
+ down_write(&hmm->mirrors_sem);
+ list_for_each_entry_safe(mirror, mirror_next, &hmm->mirrors, list) {
+ list_del_init(&mirror->list);
+ if (mirror->ops->release)
+ mirror->ops->release(mirror);
+ }
+ up_write(&hmm->mirrors_sem);
+}
+
static void hmm_invalidate_range_start(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long start,
@@ -185,6 +200,7 @@ static void hmm_invalidate_range_end(str
}
static const struct mmu_notifier_ops hmm_mmu_notifier_ops = {
+ .release = hmm_release,
.invalidate_range_start = hmm_invalidate_range_start,
.invalidate_range_end = hmm_invalidate_range_end,
};
@@ -230,7 +246,7 @@ void hmm_mirror_unregister(struct hmm_mi
struct hmm *hmm = mirror->hmm;
down_write(&hmm->mirrors_sem);
- list_del(&mirror->list);
+ list_del_init(&mirror->list);
up_write(&hmm->mirrors_sem);
}
EXPORT_SYMBOL(hmm_mirror_unregister);
_
Patches currently in -mm which might be from rcampbell(a)nvidia.com are
mm-hmm-documentation-editorial-update-to-hmm-documentation.patch
mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2.patch
The patch titled
Subject: mm/hmm: fix header file if/else/endif maze v2
has been added to the -mm tree. Its filename is
mm-hmm-fix-header-file-if-else-endif-maze-v2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-fix-header-file-if-else-end…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-fix-header-file-if-else-end…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jérôme Glisse <jglisse(a)redhat.com>
Subject: mm/hmm: fix header file if/else/endif maze v2
The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Because of
this after multiple include there was multiple definition of both
hmm_mm_init() and hmm_mm_destroy() leading to build failure if HMM was
enabled (CONFIG_HMM set).
Link: http://lkml.kernel.org/r/20180320020038.3360-3-jglisse@redhat.com
Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com>
Acked-by: Balbir Singh <bsingharora(a)gmail.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Ralph Campbell <rcampbell(a)nvidia.com>
Cc: John Hubbard <jhubbard(a)nvidia.com>
Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Logan Gunthorpe <logang(a)deltatee.com>
Cc: Mark Hairgrove <mhairgrove(a)nvidia.com>
Cc: Stephen Bates <sbates(a)raithlin.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN include/linux/hmm.h~mm-hmm-fix-header-file-if-else-endif-maze-v2 include/linux/hmm.h
--- a/include/linux/hmm.h~mm-hmm-fix-header-file-if-else-endif-maze-v2
+++ a/include/linux/hmm.h
@@ -498,23 +498,16 @@ struct hmm_device {
struct hmm_device *hmm_device_new(void *drvdata);
void hmm_device_put(struct hmm_device *hmm_device);
#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
-#endif /* IS_ENABLED(CONFIG_HMM) */
/* Below are for HMM internal use only! Not to be used by device driver! */
-#if IS_ENABLED(CONFIG_HMM_MIRROR)
void hmm_mm_destroy(struct mm_struct *mm);
static inline void hmm_mm_init(struct mm_struct *mm)
{
mm->hmm = NULL;
}
-#else /* IS_ENABLED(CONFIG_HMM_MIRROR) */
-static inline void hmm_mm_destroy(struct mm_struct *mm) {}
-static inline void hmm_mm_init(struct mm_struct *mm) {}
-#endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */
-
-
#else /* IS_ENABLED(CONFIG_HMM) */
static inline void hmm_mm_destroy(struct mm_struct *mm) {}
static inline void hmm_mm_init(struct mm_struct *mm) {}
+#endif /* IS_ENABLED(CONFIG_HMM) */
#endif /* LINUX_HMM_H */
_
Patches currently in -mm which might be from jglisse(a)redhat.com are
mm-hmm-fix-header-file-if-else-endif-maze-v2.patch
mm-hmm-unregister-mmu_notifier-when-last-hmm-client-quit.patch
mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch
mm-hmm-use-struct-for-hmm_vma_fault-hmm_vma_get_pfns-parameters-v2.patch
mm-hmm-remove-hmm_pfn_read-flag-and-ignore-peculiar-architecture-v2.patch
mm-hmm-use-uint64_t-for-hmm-pfn-instead-of-defining-hmm_pfn_t-to-ulong-v2.patch
mm-hmm-cleanup-special-vma-handling-vm_special.patch
mm-hmm-do-not-differentiate-between-empty-entry-or-missing-directory-v2.patch
mm-hmm-rename-hmm_pfn_device_unaddressable-to-hmm_pfn_device_private.patch
mm-hmm-move-hmm_pfns_clear-closer-to-where-it-is-use.patch
mm-hmm-factor-out-pte-and-pmd-handling-to-simplify-hmm_vma_walk_pmd.patch
mm-hmm-change-hmm_vma_fault-to-allow-write-fault-on-page-basis.patch
mm-hmm-use-device-driver-encoding-for-hmm-pfn-v2.patch
The patch titled
Subject: mm/hugetlb: prevent hugetlb VMA to be misaligned
has been added to the -mm tree. Its filename is
mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-prevent-hugetlb-vma-to-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-prevent-hugetlb-vma-to-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Subject: mm/hugetlb: prevent hugetlb VMA to be misaligned
When running the sampler detailed below, the kernel, if built with the VM
debug option turned on (as many distro do), is panicing with the following
message:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
8<--8<--8<--8< snip 8<--8<--8<--8<
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E
4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E
(4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER:
20040000
CFAR: c00000000036ee44 SOFTE: 1
GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40
GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000
GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000
GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554
GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40
GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950
NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760
LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50
Call Trace:
[c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable)
[c000003fbcdcfb50] [c00000000036ee48]
__unmap_hugepage_range_final+0x28/0x50
[c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190
[c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140
[c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0
[c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0
[c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80
[c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100
[c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30
[c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c
Instruction dump:
552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010
7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468
===[ end trace ee88f958a1c62605 ]===
The panic is due to a VMA pointing to a hugetlb area while the
vma->vm_start or vma->vm_end field are not aligned to the huge page
boundaries. The sampler is just unmapping a part of the hugetlb area,
leading to 2 VMAs which are not well aligned. The same could be achieved
by calling madvise() situation, as it is when running: stress-ng
--shm-sysv 1
The hugetlb code is assuming that the VMA will be well aligned when it is
unmapped, so we must prevent such a VMA from bing split or shrunk to a
misaligned address.
This patch prevents this by checking the new VMA's boundaries when a VMA
is modified by calling vma_adjust().
=== Sampler used to hit the panic
nclude <sys/ipc.h>
unsigned long page_size;
int main(void)
{
int shmid, ret=1;
void *addr;
setbuf(stdout, NULL);
page_size = getpagesize();
shmid = shmget(0x1410, LENGTH, IPC_CREAT | SHM_HUGETLB | SHM_R |
SHM_W);
if (shmid < 0) {
perror("shmget");
exit(1);
}
printf("shmid: %d
", shmid);
addr = shmat(shmid, NULL, 0);
if (addr == (void*)-1) {
perror("shmat");
goto out;
}
/*
* The following munmap() call will split the VMA in 2, leading to
* unaligned to huge page size VMAs which will trigger a check when
* shmdt() is called.
*/
if (munmap(addr + HPSIZE + page_size, page_size)) {
perror("munmap");
goto out;
}
if (shmdt(addr)) {
perror("shmdt");
goto out;
}
printf("test done.
");
ret = 0;
out:
shmctl(shmid, IPC_RMID, NULL);
return ret;
}
=== End of code
Link: http://lkml.kernel.org/r/1521566754-30390-1-git-send-email-ldufour@linux.vn…
Signed-off-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN mm/mmap.c~mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned mm/mmap.c
--- a/mm/mmap.c~mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned
+++ a/mm/mmap.c
@@ -692,6 +692,17 @@ int __vma_adjust(struct vm_area_struct *
long adjust_next = 0;
int remove_next = 0;
+ if (is_vm_hugetlb_page(vma)) {
+ /*
+ * We must check against the huge page boundarie to not
+ * create misaligned VMA.
+ */
+ struct hstate *h = hstate_vma(vma);
+
+ if (start & ~huge_page_mask(h) || end & ~huge_page_mask(h))
+ return -EINVAL;
+ }
+
if (next && !insert) {
struct vm_area_struct *exporter = NULL, *importer = NULL;
_
Patches currently in -mm which might be from ldufour(a)linux.vnet.ibm.com are
mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned.patch
kernel/locking/mutex.c: In function '__mutex_unlock_common_slowpath':
build/kernel/locking/mutex.c:721:2: error: implicit declaration of function 'WAKE_Q'
kernel/locking/mutex.c:721:9: error: 'wake_q' undeclared
This affects all architectures and all builds.
Guenter
If a task is holding a reference to a namespace on a removed controller,
the head will not be released. If the same controller is added again
later, its namespaces may not be successfully added. Instead, the user
will see kernel message "Duplicate IDs for nsid <X>".
This patch fixes that by skipping heads that don't have namespaces when
considering if a new namespace is safe to add.
Reported-by: Alex Gagniuc <Alex_Gagniuc(a)Dellteam.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Keith Busch <keith.busch(a)intel.com>
---
drivers/nvme/host/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 7aeca5db7916..0b9e60861e53 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2793,6 +2793,7 @@ static int __nvme_check_ids(struct nvme_subsystem *subsys,
list_for_each_entry(h, &subsys->nsheads, entry) {
if (nvme_ns_ids_valid(&new->ids) &&
+ !list_empty(&h->list) &&
nvme_ns_ids_equal(&new->ids, &h->ids))
return -EINVAL;
}
--
2.14.3
Hi,
unfortunately I missed message that the stable release queue repository
for 4.1.y changed. It looks like I am not copied on release announcements,
so I missed the last couple of releases. As a result, my builders did not
catch any changes for some time.
I just ran a test on v4.1.50 and got the following results.
Build results:
total: 139 pass: 133 fail: 6
Failed builds:
arm:axm55xx_defconfig
arm64:allmodconfig
i386:defconfig
i386:allyesconfig
i386:allmodconfig
i386:allnoconfig
Qemu test results:
total: 125 pass: 111 fail: 14
Failed tests:
arm64:virt:smp:defconfig:initrd
arm64:xlnx-zcu102:smp:defconfig:initrd:zynqmp-ep108
arm64:virt:nosmp:defconfig:initrd
arm64:xlnx-zcu102:nosmp:defconfig:initrd:zynqmp-ep108
x86:Broadwell:q35:x86_pc_defconfig
x86:Skylake-Client:q35:x86_pc_defconfig
x86:SandyBridge:q35:x86_pc_defconfig
x86:Haswell:pc:x86_pc_defconfig
x86:Nehalem:q35:x86_pc_defconfig
x86:phenom:pc:x86_pc_defconfig
x86:core2duo:q35:x86_pc_nosmp_defconfig
x86:Conroe:isapc:x86_pc_nosmp_defconfig
x86:Opteron_G1:pc:x86_pc_nosmp_defconfig
x86:n270:isapc:x86_pc_nosmp_defconfig
From the logs:
Building arm:axm55xx_defconfig ... failed
--------------
Error log:
arch/arm/kvm/handle_exit.c: In function 'handle_hvc':
arch/arm/kvm/handle_exit.c:48:3: error: implicit declaration of function 'vcpu_set_reg'
Building arm64:allmodconfig ... failed
--------------
Error log:
arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function ‘vcpu_set_reg’; did you mean ‘vcpu_sys_reg’?
Building i386:defconfig ... failed
--------------
Error log:
arch/x86/lib/checksum_32.S:32:31: fatal error: asm/nospec-branch.h
All other failures have the same cause.
Guenter
Hi Greg,
Hi Sasha,
commit 9b54d816e0042 ("blkcg: fix double free of new_blkg in blkcg_init_queue")
fixes CVE-2018-7480. See https://nvd.nist.gov/vuln/detail/CVE-2018-7480 for details.
Please apply to v4.1.y .. v4.9.y.
Thanks,
Guenter
Commit 726d061fbd36 ("mm: vmscan: kick flushers when we encounter
dirty pages on the LRU") added flusher invocation to
shrink_inactive_list() when many dirty pages on the LRU are encountered.
However, shrink_inactive_list() doesn't wake up flushers for legacy
cgroup reclaim, so the next commit bbef938429f5 ("mm: vmscan: remove
old flusher wakeup from direct reclaim path") removed the only source
of flusher's wake up in legacy mem cgroup reclaim path.
This leads to premature OOM if there is too many dirty pages in cgroup:
# mkdir /sys/fs/cgroup/memory/test
# echo $$ > /sys/fs/cgroup/memory/test/tasks
# echo 50M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes
# dd if=/dev/zero of=tmp_file bs=1M count=100
Killed
dd invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0
Call Trace:
dump_stack+0x46/0x65
dump_header+0x6b/0x2ac
oom_kill_process+0x21c/0x4a0
out_of_memory+0x2a5/0x4b0
mem_cgroup_out_of_memory+0x3b/0x60
mem_cgroup_oom_synchronize+0x2ed/0x330
pagefault_out_of_memory+0x24/0x54
__do_page_fault+0x521/0x540
page_fault+0x45/0x50
Task in /test killed as a result of limit of /test
memory: usage 51200kB, limit 51200kB, failcnt 73
memory+swap: usage 51200kB, limit 9007199254740988kB, failcnt 0
kmem: usage 296kB, limit 9007199254740988kB, failcnt 0
Memory cgroup stats for /test: cache:49632KB rss:1056KB rss_huge:0KB shmem:0KB
mapped_file:0KB dirty:49500KB writeback:0KB swap:0KB inactive_anon:0KB
active_anon:1168KB inactive_file:24760KB active_file:24960KB unevictable:0KB
Memory cgroup out of memory: Kill process 3861 (bash) score 88 or sacrifice child
Killed process 3876 (dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB
oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Wake up flushers in legacy cgroup reclaim too.
Fixes: bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path")
Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: <stable(a)vger.kernel.org>
---
mm/vmscan.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8fcd9f8d7390..4390a8d5be41 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1771,6 +1771,20 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
if (stat.nr_writeback && stat.nr_writeback == nr_taken)
set_bit(PGDAT_WRITEBACK, &pgdat->flags);
+ /*
+ * If dirty pages are scanned that are not queued for IO, it
+ * implies that flushers are not doing their job. This can
+ * happen when memory pressure pushes dirty pages to the end of
+ * the LRU before the dirty limits are breached and the dirty
+ * data has expired. It can also happen when the proportion of
+ * dirty pages grows not through writes but through memory
+ * pressure reclaiming all the clean cache. And in some cases,
+ * the flushers simply cannot keep up with the allocation
+ * rate. Nudge the flusher threads in case they are asleep.
+ */
+ if (stat.nr_unqueued_dirty == nr_taken)
+ wakeup_flusher_threads(WB_REASON_VMSCAN);
+
/*
* Legacy memcg will stall in page writeback so avoid forcibly
* stalling here.
@@ -1783,22 +1797,9 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
if (stat.nr_dirty && stat.nr_dirty == stat.nr_congested)
set_bit(PGDAT_CONGESTED, &pgdat->flags);
- /*
- * If dirty pages are scanned that are not queued for IO, it
- * implies that flushers are not doing their job. This can
- * happen when memory pressure pushes dirty pages to the end of
- * the LRU before the dirty limits are breached and the dirty
- * data has expired. It can also happen when the proportion of
- * dirty pages grows not through writes but through memory
- * pressure reclaiming all the clean cache. And in some cases,
- * the flushers simply cannot keep up with the allocation
- * rate. Nudge the flusher threads in case they are asleep, but
- * also allow kswapd to start writing pages during reclaim.
- */
- if (stat.nr_unqueued_dirty == nr_taken) {
- wakeup_flusher_threads(WB_REASON_VMSCAN);
+ /* Allow kswapd to start writing pages during reclaim. */
+ if (stat.nr_unqueued_dirty == nr_taken)
set_bit(PGDAT_DIRTY, &pgdat->flags);
- }
/*
* If kswapd scans pages marked marked for immediate
--
2.16.1
From: Mikhail Lappo <mikhail.lappo(a)esrlabs.com>
When device boots with T > T_trip_1 and requests interrupt,
the race condition takes place. The interrupt comes before
THERMAL_DEVICE_ENABLED is set. This leads to an attempt to
reading sensor value from irq and disabling the sensor, based on
the data->mode field, which expected to be THERMAL_DEVICE_ENABLED,
but still stays as THERMAL_DEVICE_DISABLED. Afher this issue
sensor is never re-enabled, as the driver state is wrong.
Fix this problem by setting the 'data' members prior to
requesting the interrupts.
Fixes: 37713a1e8e4c ("thermal: imx: implement thermal alarm interrupt handling")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Mikhail Lappo <mikhail.lappo(a)esrlabs.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
---
drivers/thermal/imx_thermal.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index a67781b..ee3a215 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -637,6 +637,9 @@ static int imx_thermal_probe(struct platform_device *pdev)
regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_POWER_DOWN);
regmap_write(map, TEMPSENSE0 + REG_SET, TEMPSENSE0_MEASURE_TEMP);
+ data->irq_enabled = true;
+ data->mode = THERMAL_DEVICE_ENABLED;
+
ret = devm_request_threaded_irq(&pdev->dev, data->irq,
imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
0, "imx_thermal", data);
@@ -649,9 +652,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
return ret;
}
- data->irq_enabled = true;
- data->mode = THERMAL_DEVICE_ENABLED;
-
return 0;
}
--
2.7.4
This is a note to let you know that I've just added the patch titled
phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From d7119224bfe6e8efbf821a52db7da9530d790f07 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Fri, 19 Jan 2018 17:25:41 +0800
Subject: phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving
VBUS
The AXP223 PMIC, like the AXP221, does not generate VBUS change
interrupts when N_VBUSEN is used to drive VBUS for the OTG port
on the board.
This was not noticed until recently, as most A23/A33 boards use
a GPIO pin that does not support interrupts for OTG ID detection.
This forces the driver to use polling. However the A33-OlinuXino
uses a pin that does support interrupts, so the driver uses them.
However the VBUS interrupt never fires, and the driver never gets
to update the VBUS status. This results in musb timing out waiting
for VBUS to rise.
This was worked around for the AXP221 by resorting to polling
changes in commit 91d96f06a760 ("phy-sun4i-usb: Add workaround for
missing Vbus det interrupts on A31"). This patch adds the A23 and
A33 to the list of SoCs that need the workaround.
Fixes: fc1f45ed3043 ("phy-sun4i-usb: Add support for the usb-phys on the
sun8i-a33 SoC")
Fixes: 123dfdbcfaf5 ("phy-sun4i-usb: Add support for the usb-phys on the
sun8i-a23 SoC")
Cc: <stable(a)vger.kernel.org> # 4.3.x: 68dbc2ce77bb phy-sun4i-usb:
Use of_match_node to get model specific config data
Cc: <stable(a)vger.kernel.org> # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb:
Fix optional gpios failing probe
Cc: <stable(a)vger.kernel.org> # 4.3.x: 04e59a0211ff phy-sun4i-usb:
Fix irq free conditions to match request conditions
Cc: <stable(a)vger.kernel.org> # 4.3.x: 91d96f06a760 phy-sun4i-usb:
Add workaround for missing Vbus det interrupts on A31
Cc: <stable(a)vger.kernel.org> # 4.3.x
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
---
drivers/phy/allwinner/phy-sun4i-usb.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index bee798892b21..d4dcd39b8d76 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -411,11 +411,13 @@ static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data)
return true;
/*
- * The A31 companion pmic (axp221) does not generate vbus change
- * interrupts when the board is driving vbus, so we must poll
+ * The A31/A23/A33 companion pmics (AXP221/AXP223) do not
+ * generate vbus change interrupts when the board is driving
+ * vbus using the N_VBUSEN pin on the pmic, so we must poll
* when using the pmic for vbus-det _and_ we're driving vbus.
*/
- if (data->cfg->type == sun6i_a31_phy &&
+ if ((data->cfg->type == sun6i_a31_phy ||
+ data->cfg->type == sun8i_a33_phy) &&
data->vbus_power_supply && data->phys[0].regulator_on)
return true;
@@ -886,7 +888,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.num_phys = 2,
- .type = sun4i_a10_phy,
+ .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
--
2.16.2
As per the IFC hardware manual, Most significant 2 bytes in
nand_fsr register are the outcome of NAND READ STATUS command.
So status value need to be shifted and aligned as per the nand
framework requirement.
Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller")
Cc: stable(a)vger.kernel.org # v3.18+
Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com>
---
Changes for v2: Incorporated comments from Boris Brezillon
- Added fixes tag
drivers/mtd/nand/fsl_ifc_nand.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 9390cbd..0aa03ba 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -643,12 +643,13 @@ static int fsl_ifc_wait(struct mtd_info *mtd, struct nand_chip *chip)
fsl_ifc_run_command(mtd);
nand_fsr = ifc_in32(&ifc->ifc_nand.nand_fsr);
-
+ nand_fsr >>= 16;
+ nand_fsr = (nand_fsr >> 8) | (nand_fsr << 8);
/*
* The chip always seems to report that it is
* write-protected, even when it is not.
*/
- return nand_fsr | NAND_STATUS_WP;
+ return (nand_fsr & 0xff) | NAND_STATUS_WP;
}
/*
--
1.9.1
This is the start of the stable review cycle for the 4.14.25 release.
There are 110 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Fri Mar 9 19:10:03 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.25-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.25-rc1
Sagi Grimberg <sagi(a)grimberg.me>
nvme-rdma: don't suppress send completions
NeilBrown <neilb(a)suse.com>
md: only allow remove_and_add_spares when no sync_thread running.
Adam Ford <aford173(a)gmail.com>
ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux
Adam Ford <aford173(a)gmail.com>
ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux
Kai Heng Feng <kai.heng.feng(a)canonical.com>
ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530
Eric Biggers <ebiggers(a)google.com>
KVM/x86: remove WARN_ON() for when vm_munmap() fails
Tianyu Lan <lantianyu1986(a)gmail.com>
KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs()
Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
PCI/ASPM: Deal with missing root ports in link state handling
Radim Krčmář <rkrcmar(a)redhat.com>
KVM: x86: fix vcpu initialization with userspace lapic
Paolo Bonzini <pbonzini(a)redhat.com>
KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely()
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: x86: move LAPIC initialization after VMCS creation
Paolo Bonzini <pbonzini(a)redhat.com>
KVM/x86: Remove indirect MSR op calls from SPEC_CTRL
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: mmu: Fix overlap between public and private memslots
Wanpeng Li <wanpengli(a)tencent.com>
KVM: X86: Fix SMRAM accessing even if VM is shutdown
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: x86: extend usage of RET_MMIO_PF_* constants
Arnd Bergmann <arnd(a)arndb.de>
ARM: kvm: fix building with gcc-8
Ulf Magnusson <ulfalizer(a)gmail.com>
ARM: mvebu: Fix broken PL310_ERRATA_753970 selects
Daniel Schultz <d.schultz(a)phytec.de>
ARM: dts: rockchip: Remove 1.8 GHz operation point from phycore som
Arnd Bergmann <arnd(a)arndb.de>
ARM: orion: fix orion_ge00_switch_board_info initialization
Jan Beulich <JBeulich(a)suse.com>
x86/mm: Fix {pmd,pud}_{set,clear}_flags()
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
nospec: Allow index argument to have const-qualified type
David Hildenbrand <david(a)redhat.com>
KVM: s390: consider epoch index on TOD clock syncs
David Hildenbrand <david(a)redhat.com>
KVM: s390: consider epoch index on hotplugged CPUs
David Hildenbrand <david(a)redhat.com>
KVM: s390: provide only a single function for setting the tod (fix SCK)
David Hildenbrand <david(a)redhat.com>
KVM: s390: take care of clock-comparator sign control
Anna Karbownik <anna.karbownik(a)intel.com>
EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL
Mauro Carvalho Chehab <mchehab(a)kernel.org>
media: m88ds3103: don't call a non-initalized function
Ming Lei <ming.lei(a)redhat.com>
blk-mq: don't call io sched's .requeue_request when requeueing rq to ->dispatch
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix IPA command submission race
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix IP address lookup for L3 devices
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
Revert "s390/qeth: fix using of ref counter for rxip addresses"
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix double-free on IP add/remove race
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix IP removal on offline cards
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix overestimated count of buffer elements
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix SETIP command handling
Ursula Braun <ubraun(a)linux.vnet.ibm.com>
s390/qeth: fix underestimated count of buffer elements
Jason Wang <jasowang(a)redhat.com>
virtio-net: disable NAPI only when enabled during XDP set
Jason Wang <jasowang(a)redhat.com>
tuntap: disable preemption during XDP processing
Jason Wang <jasowang(a)redhat.com>
tuntap: correctly add the missing XDP flush
Soheil Hassas Yeganeh <soheil(a)google.com>
tcp: purge write queue upon RST
Jason A. Donenfeld <Jason(a)zx2c4.com>
netlink: put module reference if dump start fails
Ido Schimmel <idosch(a)mellanox.com>
mlxsw: spectrum_router: Do not unconditionally clear route offload indication
Paolo Abeni <pabeni(a)redhat.com>
cls_u32: fix use after free in u32_destroy_key()
Tom Lendacky <thomas.lendacky(a)amd.com>
amd-xgbe: Restore PCI interrupt enablement setting on resume
Eran Ben Elisha <eranbe(a)mellanox.com>
net/mlx5e: Verify inline header size do not exceed SKB linear size
Ido Schimmel <idosch(a)mellanox.com>
bridge: Fix VLAN reference count problem
Alexey Kodanev <alexey.kodanev(a)oracle.com>
sctp: fix dst refcnt leak in sctp_v6_get_dst()
David Ahern <dsahern(a)gmail.com>
net: ipv4: Set addr_type in hash_keys for forwarded case
Jiri Pirko <jiri(a)mellanox.com>
mlxsw: spectrum_router: Fix error path in mlxsw_sp_vr_create
Yuchung Cheng <ycheng(a)google.com>
tcp: revert F-RTO extension to detect more spurious timeouts
Yuchung Cheng <ycheng(a)google.com>
tcp: revert F-RTO middle-box workaround
Xin Long <lucien.xin(a)gmail.com>
sctp: do not pr_err for the duplicated node in transport rhlist
Ivan Vecera <ivecera(a)redhat.com>
net/sched: cls_u32: fix cls_u32 on filter replace
Eric Dumazet <edumazet(a)google.com>
net_sched: gen_estimator: fix broken estimators based on percpu stats
Inbar Karmy <inbark(a)mellanox.com>
net/mlx5e: Fix loopback self test when GRO is off
Tonghao Zhang <xiangxia.m.yue(a)gmail.com>
doc: Change the min default value of tcp_wmem/tcp_rmem.
Eric Dumazet <edumazet(a)google.com>
tcp_bbr: better deal with suboptimal GSO
David Howells <dhowells(a)redhat.com>
rxrpc: Fix send in rxrpc_send_data_packet()
Ilya Lesokhin <ilyal(a)mellanox.com>
tcp: Honor the eor bit in tcp_mtu_probe
Heiner Kallweit <hkallweit1(a)gmail.com>
net: phy: fix phy_start to consider PHY_IGNORE_INTERRUPT
Gal Pressman <galp(a)mellanox.com>
net/mlx5e: Specify numa node when allocating drop rq
Shalom Toledo <shalomt(a)mellanox.com>
mlxsw: spectrum_switchdev: Check success of FDB add operation
Tommi Rantala <tommi.t.rantala(a)nokia.com>
sctp: fix dst refcnt leak in sctp_v4_get_dst
Gal Pressman <galp(a)mellanox.com>
net/mlx5e: Fix TCP checksum in LRO buffers
Alexey Kodanev <alexey.kodanev(a)oracle.com>
udplite: fix partial checksum initialization
Alexey Kodanev <alexey.kodanev(a)oracle.com>
sctp: verify size of a new chunk in _sctp_make_chunk()
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: prevent unregistered channels from connecting to PPP units
Roman Kapl <code(a)rkapl.cz>
net: sched: report if filter is too large to dump
Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
netlink: ensure to loop over all netns in genlmsg_multicast_allns()
Sabrina Dubroca <sd(a)queasysnail.net>
net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68
Jakub Kicinski <jakub.kicinski(a)netronome.com>
net: fix race on decreasing number of TX queues
Grygorii Strashko <grygorii.strashko(a)ti.com>
net: ethernet: ti: cpsw: fix net watchdog timeout
Wolfram Sang <wsa+renesas(a)sang-engineering.com>
net: amd-xgbe: fix comparison to bitshift when dealing with a mask
Arnd Bergmann <arnd(a)arndb.de>
ipv6 sit: work around bogus gcc-8 -Wrestrict warning
Denis Du <dudenis2000(a)yahoo.ca>
hdlc_ppp: carrier detect ok, don't turn off negotiation
Stefano Brivio <sbrivio(a)redhat.com>
fib_semantics: Don't match route with mismatching tclassid
Xin Long <lucien.xin(a)gmail.com>
bridge: check brport attr show in brport_show
Thomas Gleixner <tglx(a)linutronix.de>
x86/cpu_entry_area: Sync cpu_entry_area to initial_page_table
Sebastian Panceac <sebastian(a)resin.io>
x86/platform/intel-mid: Handle Intel Edison reboot correctly
Juergen Gross <jgross(a)suse.com>
x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend
Jan Kara <jack(a)suse.cz>
direct-io: Fix sleep in atomic due to sync AIO
Dan Williams <dan.j.williams(a)intel.com>
dax: fix vma_is_fsdax() helper
Viresh Kumar <viresh.kumar(a)linaro.org>
cpufreq: s3c24xx: Fix broken s3c_cpufreq_init()
Dan Williams <dan.j.williams(a)intel.com>
vfio: disable filesystem-dax page pinning
Ming Lei <ming.lei(a)redhat.com>
block: kyber: fix domain token leak during requeue
Jiufei Xue <jiufei.xue(a)linux.alibaba.com>
block: fix the count of PGPGOUT for WRITE_SAME
Anand Jain <anand.jain(a)oracle.com>
btrfs: use proper endianness accessors for super_copy
John David Anglin <dave.anglin(a)bell.net>
parisc: Fix ordering of cache and TLB flushes
Helge Deller <deller(a)gmx.de>
parisc: Reduce irq overhead when run in qemu
Helge Deller <deller(a)gmx.de>
parisc: Use cr16 interval timers unconditionally on qemu
Lingutla Chandrasekhar <clingutla(a)codeaurora.org>
timers: Forward timer base before migrating timers
Shawn Lin <shawn.lin(a)rock-chips.com>
mmc: dw_mmc: Fix out-of-bounds access for slot's caps
Shawn Lin <shawn.lin(a)rock-chips.com>
mmc: dw_mmc: Factor out dw_mci_init_slot_caps
Shawn Lin <shawn.lin(a)rock-chips.com>
mmc: dw_mmc: Avoid accessing registers in runtime suspended state
Geert Uytterhoeven <geert+renesas(a)glider.be>
mmc: dw_mmc-k3: Fix out-of-bounds access through DT alias
Adrian Hunter <adrian.hunter(a)intel.com>
mmc: sdhci-pci: Fix S0i3 for Intel BYT-based controllers
Takashi Iwai <tiwai(a)suse.de>
ALSA: hda - Fix pincfg at resume on Lenovo T470 dock
Hans de Goede <hdegoede(a)redhat.com>
ALSA: hda: Add a power_save blacklist
Takashi Iwai <tiwai(a)suse.de>
ALSA: x86: Fix missing spinlock and mutex initializations
Richard Fitzgerald <rf(a)opensource.cirrus.com>
ALSA: control: Fix memory corruption risk in snd_ctl_elem_read
Erik Veijola <erik.veijola(a)gmail.com>
ALSA: usb-audio: Add a quirck for B&W PX headphones
Alexander Steffen <Alexander.Steffen(a)infineon.com>
tpm_tis_spi: Use DMA-safe memory for SPI transfers
Arnd Bergmann <arnd(a)arndb.de>
tpm: constify transmit data pointers
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm_tis: fix potential buffer overruns caused by bit glitches on the bus
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm: fix potential buffer overruns caused by bit glitches on the bus
Jeremy Boone <jeremy.boone(a)nccgroup.trust>
tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the bus
Emil Tantilov <emil.s.tantilov(a)intel.com>
ixgbe: fix crash in build_skb Rx code path
Hans de Goede <hdegoede(a)redhat.com>
Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking
-------------
Diffstat:
Documentation/networking/ip-sysctl.txt | 4 +-
Makefile | 4 +-
arch/arm/boot/dts/logicpd-som-lv.dtsi | 9 +-
arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++
arch/arm/boot/dts/rk3288-phycore-som.dtsi | 20 ----
arch/arm/kvm/hyp/Makefile | 5 +
arch/arm/kvm/hyp/banked-sr.c | 4 +
arch/arm/mach-mvebu/Kconfig | 4 +-
arch/arm/plat-orion/common.c | 23 ++--
arch/parisc/include/asm/cacheflush.h | 1 +
arch/parisc/include/asm/processor.h | 2 +
arch/parisc/kernel/cache.c | 57 +++++-----
arch/parisc/kernel/pacache.S | 22 ++++
arch/parisc/kernel/time.c | 11 +-
arch/s390/kvm/interrupt.c | 25 ++++-
arch/s390/kvm/kvm-s390.c | 79 +++++++------
arch/s390/kvm/kvm-s390.h | 5 +-
arch/s390/kvm/priv.c | 9 +-
arch/x86/include/asm/pgtable.h | 8 +-
arch/x86/include/asm/pgtable_32.h | 1 +
arch/x86/include/asm/pgtable_64.h | 1 +
arch/x86/include/asm/pgtable_types.h | 10 ++
arch/x86/kernel/setup.c | 17 +--
arch/x86/kernel/setup_percpu.c | 17 +--
arch/x86/kvm/lapic.c | 11 +-
arch/x86/kvm/mmu.c | 97 ++++++++--------
arch/x86/kvm/paging_tmpl.h | 18 +--
arch/x86/kvm/svm.c | 9 +-
arch/x86/kvm/vmx.c | 9 +-
arch/x86/kvm/x86.c | 12 +-
arch/x86/mm/cpu_entry_area.c | 6 +
arch/x86/mm/init_32.c | 15 +++
arch/x86/platform/intel-mid/intel-mid.c | 2 +-
arch/x86/xen/suspend.c | 16 +++
block/blk-core.c | 2 +-
block/blk-mq.c | 4 +-
block/kyber-iosched.c | 1 +
drivers/acpi/bus.c | 38 +++++--
drivers/bluetooth/btusb.c | 25 ++++-
drivers/char/tpm/st33zp24/st33zp24.c | 4 +-
drivers/char/tpm/tpm-interface.c | 4 +
drivers/char/tpm/tpm2-cmd.c | 4 +
drivers/char/tpm/tpm_i2c_infineon.c | 5 +-
drivers/char/tpm/tpm_i2c_nuvoton.c | 8 +-
drivers/char/tpm/tpm_tis.c | 2 +-
drivers/char/tpm/tpm_tis_core.c | 9 +-
drivers/char/tpm/tpm_tis_core.h | 4 +-
drivers/char/tpm/tpm_tis_spi.c | 48 ++++----
drivers/cpufreq/s3c24xx-cpufreq.c | 8 +-
drivers/edac/sb_edac.c | 2 +-
drivers/md/md.c | 4 +
drivers/media/dvb-frontends/m88ds3103.c | 7 +-
drivers/mmc/host/dw_mmc-exynos.c | 1 +
drivers/mmc/host/dw_mmc-k3.c | 4 +
drivers/mmc/host/dw_mmc-rockchip.c | 1 +
drivers/mmc/host/dw_mmc-zx.c | 1 +
drivers/mmc/host/dw_mmc.c | 84 +++++++++-----
drivers/mmc/host/dw_mmc.h | 2 +
drivers/mmc/host/sdhci-pci-core.c | 35 +++++-
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 ++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 10 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 49 +++++---
.../net/ethernet/mellanox/mlx5/core/en_selftest.c | 3 +-
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +-
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 22 ++--
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 29 ++++-
drivers/net/ethernet/ti/cpsw.c | 16 ++-
drivers/net/phy/phy.c | 2 +-
drivers/net/ppp/ppp_generic.c | 9 ++
drivers/net/tun.c | 7 ++
drivers/net/virtio_net.c | 8 +-
drivers/net/wan/hdlc_ppp.c | 5 +-
drivers/nvme/host/rdma.c | 54 +++------
drivers/pci/pcie/aspm.c | 8 +-
drivers/s390/net/qeth_core.h | 7 +-
drivers/s390/net/qeth_core_main.c | 43 +++----
drivers/s390/net/qeth_l3.h | 34 +++++-
drivers/s390/net/qeth_l3_main.c | 123 +++++++++------------
drivers/vfio/vfio_iommu_type1.c | 18 ++-
fs/btrfs/sysfs.c | 8 +-
fs/btrfs/transaction.c | 20 ++--
fs/direct-io.c | 3 +-
include/linux/fs.h | 2 +-
include/linux/nospec.h | 3 +-
include/net/udplite.h | 1 +
kernel/time/timer.c | 6 +
net/bridge/br_sysfs_if.c | 3 +
net/bridge/br_vlan.c | 2 +
net/core/dev.c | 11 +-
net/core/gen_estimator.c | 1 +
net/ipv4/fib_semantics.c | 5 +
net/ipv4/route.c | 10 +-
net/ipv4/tcp_input.c | 24 ++--
net/ipv4/tcp_output.c | 33 +++++-
net/ipv4/udp.c | 5 +
net/ipv6/ip6_checksum.c | 5 +
net/ipv6/sit.c | 2 +-
net/netlink/af_netlink.c | 4 +-
net/netlink/genetlink.c | 12 +-
net/rxrpc/output.c | 2 +-
net/sched/cls_api.c | 7 +-
net/sched/cls_u32.c | 24 ++--
net/sctp/input.c | 5 +-
net/sctp/ipv6.c | 10 +-
net/sctp/protocol.c | 10 +-
net/sctp/sm_make_chunk.c | 7 +-
sound/core/control.c | 2 +-
sound/pci/hda/hda_intel.c | 38 ++++++-
sound/pci/hda/patch_realtek.c | 3 +-
sound/usb/quirks-table.h | 47 ++++++++
sound/x86/intel_hdmi_audio.c | 2 +
virt/kvm/kvm_main.c | 3 +-
114 files changed, 1065 insertions(+), 564 deletions(-)
From: Gabriel Matni <gabriel.matni(a)exfo.com>
Fixes missing characters on kernel console at low baud rates (i.e.9600).
The driver should poll TX_RDY or TX_FIFO_EMP instead of TX_EMP to ensure
that the transmitter holding register (THR) is ready to receive a new byte.
TX_EMP tells us when it is possible to send a break sequence via
SND_BRK_SEQ. While this also indicates that both the THR and the TSR are
empty, it does not guarantee that a new byte can be written just yet.
Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port")
Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Acked-by: Gregory CLEMENT <gregory.clement(a)bootlin.com>
Signed-off-by: Gabriel Matni <gabriel.matni(a)exfo.com>
---
drivers/tty/serial/mvebu-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index a100e98259d7..f0df0640208e 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -618,7 +618,7 @@ static void wait_for_xmitr(struct uart_port *port)
u32 val;
readl_poll_timeout_atomic(port->membase + UART_STAT, val,
- (val & STAT_TX_EMP), 1, 10000);
+ (val & STAT_TX_RDY(port)), 1, 10000);
}
static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
--
2.7.4
> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: March 5, 2018 4:47 AM
> To: Gabriel Matni <gabriel.matni(a)exfo.com>
> Cc: linux-arm-kernel(a)lists.infradead.org; gregkh(a)linuxfoundation.org;
> Grégory Clement <gregory.clement(a)bootlin.com>; Thomas Petazzoni
> <thomas.petazzoni(a)bootlin.com>
> Subject: Re: [PATCH] serial: mvebu_uart: fix tx lost characters
>
> Hi Gabriel,
>
> On Tue, 27 Feb 2018 21:56:03 +0000, Gabriel Matni
> <gabriel.matni(a)exfo.com> wrote:
>
> > Hi Miquèl,
> >
> > > -----Original Message-----
> > > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > > Sent: February 27, 2018 8:13 AM
> > > To: Gabriel Matni <gabriel.matni(a)exfo.com>
> > > Cc: linux-arm-kernel(a)lists.infradead.org; gregkh(a)linuxfoundation.org;
> > > Grégory Clement <gregory.clement(a)bootlin.com>; Thomas Petazzoni
> > > <thomas.petazzoni(a)bootlin.com>
> > > Subject: Re: [PATCH] serial: mvebu_uart: fix tx lost characters
> > >
> > > Hi Gabriel,
> > >
> > > On Thu, 22 Feb 2018 20:30:56 +0000, Gabriel Matni
> > > <gabriel.matni(a)exfo.com> wrote:
> > >
> > > > From: Gabriel Matni <gabriel.matni(a)exfo.com>
> > > >
> > > > Fixes missing characters on kernel console at low baud rates (i.e.9600).
> > > > The driver should poll TX_RDY instead of TX_EMPTY to ensure that the
> > > > transmitter holding is ready to receive a new byte. Polling TX_EMPTY
> > > > isn't enough as the hardware buffer can become empty but not yet
> ready
> > > > for CPU to write the next byte.
> > >
> > > I am kind of sceptic with the explanation. My understanding is that:
> > > - TX_EMPTY means the FIFO is empty
>
> I had a deeper look into the spec : TX_EMPTY != TX_FIFO_EMPTY. I was
> referring to TX_FIFO_EMPTY here so my understanding of your solution was
> wrong.
>
> > > - TX_RDY means the FIFO is not full, neither empty, it is a "half
> > > loaded" state.
> > > Polling TX_RDY instead of TX_EMPTY should work too, but I don't see why
> it
> > > would fix the loss of character by filling the FIFO when there are bytes in
> it
> > > rather than when it is fully empty.
> >
> > TX_READY is set whenever the UART Transmitter Holding register is ready
> to
> > receive a new byte. It gets cleared as soon as a new byte is written to the
> > register. If the FIFO is empty or still has room, the ready will be set.
> >
> > TX_EMPTY tells us when it is possible to send a break sequence via
> > SND_BRK_SEQ. While this also indicates that both the THR and the TSR are
> > empty, it does not guarantee that a new byte can be written just yet.
>
> I do agree with this statement. You are right that polling on TX_EMPTY
> looks wrong and we should definitively poll on TX_READY instead.
>
> > I am
> > unsure about the FIFO status in this case as I can encounter
> TX_FIFO_EMP=0
> > while TX_EMP=1, which suggests that the FIFO isn't necessarily empty
> when
> > TX_EMP is set.
>
> That is weird but maybe the TX_FIFO_EMPTY is asserted only when all
> bits have been shifted, which is a 10-bit period after TSR is
> cleared, while TX_EMPTY would not wait for these bits to be actually
> shifted out and would be asserted a bit earlier, as soon as TSR is
> cleared. That is just and idea.
>
> >
> > Therefore, the driver can either poll TX_FIFO_EMP or TX_READY to know
> > whether it can output a new byte. I personally like TX_READY as it takes
> > advantage of the FIFO.
>
> True.
>
> >
> > > >
> > > > Signed-off-by: Gabriel Matni <gabriel.matni(a)exfo.com>
>
> Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
>
> Thanks,
> Miquèl
>
> --
> Miquel Raynal, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
Recent patches broke build on multi_v7_defconfig (ARM), on
stable-rc/linux-4.4.y branch. The build error as follows:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error:
'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
.flags = HWMOD_CLKDM_NOAUTO,
^~~~~~~~~~~~~~~~~~
Pull in missing dependency patches to fix that build error.
1. "Allow modules to disable HW_AUTO": this commit is needed to fix
build error
2. "add usecounting support to autoidle APIs": this commit is a
dependency for 1
3. "provide space for more hwmod flags": this is also a dependency for 1
Tested on TI BeagleBoard X15.
Roger Quadros (1):
ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO
Sekhar Nori (1):
ARM: OMAP2+: omap_hwmod: provide space for more hwmod flags
Tero Kristo (1):
ARM: OMAP2+: clockdomain: add usecounting support to autoidle APIs
arch/arm/mach-omap2/clockdomain.c | 36 ++++++++++++++++++++++++------------
arch/arm/mach-omap2/clockdomain.h | 2 ++
arch/arm/mach-omap2/cpuidle44xx.c | 2 +-
arch/arm/mach-omap2/omap-smp.c | 2 +-
arch/arm/mach-omap2/omap_hwmod.c | 32 +++++++++++++++++---------------
arch/arm/mach-omap2/omap_hwmod.h | 7 ++++++-
arch/arm/mach-omap2/pm.c | 8 +-------
arch/arm/mach-omap2/powerdomain.c | 20 ++++++--------------
8 files changed, 58 insertions(+), 51 deletions(-)
--
2.16.1
This is a note to let you know that I've just added the patch titled
phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From d7119224bfe6e8efbf821a52db7da9530d790f07 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Fri, 19 Jan 2018 17:25:41 +0800
Subject: phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving
VBUS
The AXP223 PMIC, like the AXP221, does not generate VBUS change
interrupts when N_VBUSEN is used to drive VBUS for the OTG port
on the board.
This was not noticed until recently, as most A23/A33 boards use
a GPIO pin that does not support interrupts for OTG ID detection.
This forces the driver to use polling. However the A33-OlinuXino
uses a pin that does support interrupts, so the driver uses them.
However the VBUS interrupt never fires, and the driver never gets
to update the VBUS status. This results in musb timing out waiting
for VBUS to rise.
This was worked around for the AXP221 by resorting to polling
changes in commit 91d96f06a760 ("phy-sun4i-usb: Add workaround for
missing Vbus det interrupts on A31"). This patch adds the A23 and
A33 to the list of SoCs that need the workaround.
Fixes: fc1f45ed3043 ("phy-sun4i-usb: Add support for the usb-phys on the
sun8i-a33 SoC")
Fixes: 123dfdbcfaf5 ("phy-sun4i-usb: Add support for the usb-phys on the
sun8i-a23 SoC")
Cc: <stable(a)vger.kernel.org> # 4.3.x: 68dbc2ce77bb phy-sun4i-usb:
Use of_match_node to get model specific config data
Cc: <stable(a)vger.kernel.org> # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb:
Fix optional gpios failing probe
Cc: <stable(a)vger.kernel.org> # 4.3.x: 04e59a0211ff phy-sun4i-usb:
Fix irq free conditions to match request conditions
Cc: <stable(a)vger.kernel.org> # 4.3.x: 91d96f06a760 phy-sun4i-usb:
Add workaround for missing Vbus det interrupts on A31
Cc: <stable(a)vger.kernel.org> # 4.3.x
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
---
drivers/phy/allwinner/phy-sun4i-usb.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index bee798892b21..d4dcd39b8d76 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -411,11 +411,13 @@ static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data)
return true;
/*
- * The A31 companion pmic (axp221) does not generate vbus change
- * interrupts when the board is driving vbus, so we must poll
+ * The A31/A23/A33 companion pmics (AXP221/AXP223) do not
+ * generate vbus change interrupts when the board is driving
+ * vbus using the N_VBUSEN pin on the pmic, so we must poll
* when using the pmic for vbus-det _and_ we're driving vbus.
*/
- if (data->cfg->type == sun6i_a31_phy &&
+ if ((data->cfg->type == sun6i_a31_phy ||
+ data->cfg->type == sun8i_a33_phy) &&
data->vbus_power_supply && data->phys[0].regulator_on)
return true;
@@ -886,7 +888,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.num_phys = 2,
- .type = sun4i_a10_phy,
+ .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
--
2.16.2
Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
ceased to unregister SPI buses with fixed bus numbers. Moreover this is
visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register
the same SPI controller.
rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y):
[ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1]
modprobe spi_pxa2xx_platform:
[ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1'
[ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21
[ 37.902384] Call Trace:
...
[ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory.
[ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0
...
[ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master
[ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17
Fix this by not returning immediately from spi_unregister_controller() if
idr_find() doesn't find controller with given ID/bus number. It finds
only those controllers that were registered with dynamic SPI bus
numbers. Only conditional cleanup between dynamic and fixed bus numbers
is to remove allocated IDR.
Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
Cc: stable(a)vger.kernel.org
Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
---
This doesn't apply to v4.14 without commit 67f7b2781faf ("spi: fix
use-after-free at controller deregistration").
---
drivers/spi/spi.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index b33a727a0158..e90fd442b3f0 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2254,12 +2254,6 @@ void spi_unregister_controller(struct spi_controller *ctlr)
mutex_lock(&board_lock);
found = idr_find(&spi_master_idr, id);
mutex_unlock(&board_lock);
- if (found != ctlr) {
- dev_dbg(&ctlr->dev,
- "attempting to delete unregistered controller [%s]\n",
- dev_name(&ctlr->dev));
- return;
- }
if (ctlr->queued) {
if (spi_destroy_queue(ctlr))
dev_err(&ctlr->dev, "queue remove failed\n");
@@ -2272,7 +2266,8 @@ void spi_unregister_controller(struct spi_controller *ctlr)
device_unregister(&ctlr->dev);
/* free bus id */
mutex_lock(&board_lock);
- idr_remove(&spi_master_idr, id);
+ if (found == ctlr)
+ idr_remove(&spi_master_idr, id);
mutex_unlock(&board_lock);
}
EXPORT_SYMBOL_GPL(spi_unregister_controller);
--
2.16.1
Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
ceased to unregister SPI buses with fixed bus numbers. Moreover this is
visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register
the same SPI controller.
rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y):
[ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1]
modprobe spi_pxa2xx_platform:
[ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1'
[ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21
[ 37.902384] Call Trace:
...
[ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory.
[ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0
...
[ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master
[ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17
Fix this by not returning immediately from spi_unregister_controller() if
idr_find() doesn't find controller with given ID/bus number. It finds
only those controllers that were registered with dynamic SPI bus
numbers. Only conditional cleanup between dynamic and fixed bus numbers
is to remove allocated IDR.
Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
Cc: stable(a)vger.kernel.org
Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
---
This doesn't apply to v4.14 without commit 67f7b2781faf ("spi: fix
use-after-free at controller deregistration").
---
drivers/spi/spi.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index b33a727a0158..e90fd442b3f0 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2254,12 +2254,6 @@ void spi_unregister_controller(struct spi_controller *ctlr)
mutex_lock(&board_lock);
found = idr_find(&spi_master_idr, id);
mutex_unlock(&board_lock);
- if (found != ctlr) {
- dev_dbg(&ctlr->dev,
- "attempting to delete unregistered controller [%s]\n",
- dev_name(&ctlr->dev));
- return;
- }
if (ctlr->queued) {
if (spi_destroy_queue(ctlr))
dev_err(&ctlr->dev, "queue remove failed\n");
@@ -2272,7 +2266,8 @@ void spi_unregister_controller(struct spi_controller *ctlr)
device_unregister(&ctlr->dev);
/* free bus id */
mutex_lock(&board_lock);
- idr_remove(&spi_master_idr, id);
+ if (found == ctlr)
+ idr_remove(&spi_master_idr, id);
mutex_unlock(&board_lock);
}
EXPORT_SYMBOL_GPL(spi_unregister_controller);
--
2.16.2
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7794: Add DU1 clock to device tree
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:
arm-dts-r8a7794-add-du1-clock-to-device-tree.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 1764f8081f1524bf629e0744b277db751281ff56 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Tue, 28 Mar 2017 12:45:30 +0200
Subject: ARM: dts: r8a7794: Add DU1 clock to device tree
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
commit 1764f8081f1524bf629e0744b277db751281ff56 upstream.
Add the missing module clock for the second channel of the display unit.
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/r8a7794.dtsi | 8 +++++---
include/dt-bindings/clock/r8a7794-clock.h | 1 +
2 files changed, 6 insertions(+), 3 deletions(-)
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1261,19 +1261,21 @@
clocks = <&mp_clk>, <&hp_clk>,
<&zs_clk>, <&p_clk>, <&p_clk>, <&zs_clk>,
<&zs_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&zx_clk>;
+ <&zx_clk>, <&zx_clk>;
#clock-cells = <1>;
clock-indices = <
R8A7794_CLK_EHCI R8A7794_CLK_HSUSB
R8A7794_CLK_HSCIF2 R8A7794_CLK_SCIF5
R8A7794_CLK_SCIF4 R8A7794_CLK_HSCIF1 R8A7794_CLK_HSCIF0
R8A7794_CLK_SCIF3 R8A7794_CLK_SCIF2 R8A7794_CLK_SCIF1
- R8A7794_CLK_SCIF0 R8A7794_CLK_DU0
+ R8A7794_CLK_SCIF0
+ R8A7794_CLK_DU1 R8A7794_CLK_DU0
>;
clock-output-names =
"ehci", "hsusb",
"hscif2", "scif5", "scif4", "hscif1", "hscif0",
- "scif3", "scif2", "scif1", "scif0", "du0";
+ "scif3", "scif2", "scif1", "scif0",
+ "du1", "du0";
};
mstp8_clks: mstp8_clks@e6150990 {
compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
--- a/include/dt-bindings/clock/r8a7794-clock.h
+++ b/include/dt-bindings/clock/r8a7794-clock.h
@@ -81,6 +81,7 @@
#define R8A7794_CLK_SCIF2 19
#define R8A7794_CLK_SCIF1 20
#define R8A7794_CLK_SCIF0 21
+#define R8A7794_CLK_DU1 23
#define R8A7794_CLK_DU0 24
/* MSTP8 */
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch
queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7794-add-du1-clock-to-device-tree.patch
queue-4.9/arm-dts-silk-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch
queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch
queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch
queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch
queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch
This is a note to let you know that I've just added the patch titled
staging: comedi: ni_mio_common: ack ai fifo error interrupts.
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From e1d9fc04c41840a4688ef6ce90b6dcca157ea4d7 Mon Sep 17 00:00:00 2001
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Date: Thu, 15 Mar 2018 10:25:44 +0000
Subject: staging: comedi: ni_mio_common: ack ai fifo error interrupts.
Ack ai fifo error interrupts in interrupt handler to clear interrupt
after fifo overflow. It should prevent lock-ups after the ai fifo
overflows.
Cc: <stable(a)vger.kernel.org> # v4.2+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/comedi/drivers/ni_mio_common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c
index d6eb55b41814..e40a2c0a9543 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1275,6 +1275,8 @@ static void ack_a_interrupt(struct comedi_device *dev, unsigned short a_status)
ack |= NISTC_INTA_ACK_AI_START;
if (a_status & NISTC_AI_STATUS1_STOP)
ack |= NISTC_INTA_ACK_AI_STOP;
+ if (a_status & NISTC_AI_STATUS1_OVER)
+ ack |= NISTC_INTA_ACK_AI_ERR;
if (ack)
ni_stc_writew(dev, ack, NISTC_INTA_ACK_REG);
}
--
2.16.2
The patch
ASoC: ssm2602: Replace reg_default_raw with reg_default
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a01df75ce737951ad13a08d101306e88c3f57cb2 Mon Sep 17 00:00:00 2001
From: James Kelly <jamespeterkelly(a)gmail.com>
Date: Mon, 19 Mar 2018 21:29:50 +1100
Subject: [PATCH] ASoC: ssm2602: Replace reg_default_raw with reg_default
SSM2602 driver is broken on recent kernels (at least
since 4.9). User space applications such as amixer or
alsamixer get EIO when attempting to access codec
controls via the relevant IOCTLs.
Root cause of these failures is the regcache_hw_init
function in drivers/base/regmap/regcache.c, which
prevents regmap cache initalization from the
reg_defaults_raw element of the regmap_config structure
when registers are write only. It also disables the
regmap cache entirely when all registers are write only
or volatile as is the case for the SSM2602 driver.
Using the reg_defaults element of the regmap_config
structure rather than the reg_defaults_raw element to
initalize the regmap cache avoids the logic in the
regcache_hw_init function entirely. It also makes this
driver consistent with other ASoC codec drivers, as
this driver was the ONLY codec driver that used the
reg_defaults_raw element to initalize the cache.
Tested on Digilent Zybo Z7 development board which has
a SSM2603 codec chip connected to a Xilinx Zynq SoC.
Signed-off-by: James Kelly <jamespeterkelly(a)gmail.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/codecs/ssm2602.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/ssm2602.c b/sound/soc/codecs/ssm2602.c
index 9b341c23f62b..5e80867d09ef 100644
--- a/sound/soc/codecs/ssm2602.c
+++ b/sound/soc/codecs/ssm2602.c
@@ -54,10 +54,17 @@ struct ssm2602_priv {
* using 2 wire for device control, so we cache them instead.
* There is no point in caching the reset register
*/
-static const u16 ssm2602_reg[SSM2602_CACHEREGNUM] = {
- 0x0097, 0x0097, 0x0079, 0x0079,
- 0x000a, 0x0008, 0x009f, 0x000a,
- 0x0000, 0x0000
+static const struct reg_default ssm2602_reg[SSM2602_CACHEREGNUM] = {
+ { .reg = 0x00, .def = 0x0097 },
+ { .reg = 0x01, .def = 0x0097 },
+ { .reg = 0x02, .def = 0x0079 },
+ { .reg = 0x03, .def = 0x0079 },
+ { .reg = 0x04, .def = 0x000a },
+ { .reg = 0x05, .def = 0x0008 },
+ { .reg = 0x06, .def = 0x009f },
+ { .reg = 0x07, .def = 0x000a },
+ { .reg = 0x08, .def = 0x0000 },
+ { .reg = 0x09, .def = 0x0000 }
};
@@ -620,8 +627,8 @@ const struct regmap_config ssm2602_regmap_config = {
.volatile_reg = ssm2602_register_volatile,
.cache_type = REGCACHE_RBTREE,
- .reg_defaults_raw = ssm2602_reg,
- .num_reg_defaults_raw = ARRAY_SIZE(ssm2602_reg),
+ .reg_defaults = ssm2602_reg,
+ .num_reg_defaults = ARRAY_SIZE(ssm2602_reg),
};
EXPORT_SYMBOL_GPL(ssm2602_regmap_config);
--
2.16.2
From: James Bottomley <James.Bottomley(a)HansenPartnership.com>
My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns TPM_RC_TESTING
(meaning some tests are still running in the background). There are
various theories that resending the self-test command actually causes the
tests to restart and thus triggers more TPM_RC_TESTING returns until the
timeout is exceeded.
There are several issues here: firstly being we shouldn't slow down the
boot sequence waiting for the self test to complete once the TPM
backgrounds them. It will actually make available all functions that have
passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
command. So the fix is to kick off self tests once and if they return
TPM_RC_TESTING log that as a backgrounded self test and continue on. In
order to prevent other tpm users from seeing any TPM_RC_TESTING returns
(which it might if they send a command that needs a TPM subsystem which is
still under test), we loop in tpm_transmit_cmd until either a timeout or we
don't get a TPM_RC_TESTING return.
Finally, there have been observations of strange returns from a partial
test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
any unexpected return from a partial self test as an indication we need to
run a full self test.
[jarkko.sakkinen(a)linux.intel.com: cleaned up James' original commit and
added a proper Fixes line]
Fixes: 2482b1bba5122 ("tpm: Trigger only missing TPM 2.0 self tests")
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkine(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkine(a)linux.intel.com>
---
drivers/char/tpm/tpm-interface.c | 20 ++++++++++++---
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm2-cmd.c | 54 ++++++++++++----------------------------
3 files changed, 33 insertions(+), 42 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 9e80a953d693..1adb976a2e37 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -537,14 +537,26 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
const char *desc)
{
const struct tpm_output_header *header = buf;
+ unsigned int delay_msec = TPM2_DURATION_SHORT;
int err;
ssize_t len;
- len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
- if (len < 0)
- return len;
+ for (;;) {
+ len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
+ if (len < 0)
+ return len;
+ err = be32_to_cpu(header->return_code);
+ if (err != TPM2_RC_TESTING)
+ break;
+
+ delay_msec *= 2;
+ if (delay_msec > TPM2_DURATION_LONG) {
+ dev_err(&chip->dev, "the self test is still running\n");
+ break;
+ }
+ tpm_msleep(delay_msec);
+ }
- err = be32_to_cpu(header->return_code);
if (err != 0 && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f895fba4e20d..cccd5994a0e1 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -104,6 +104,7 @@ enum tpm2_return_codes {
TPM2_RC_HASH = 0x0083, /* RC_FMT1 */
TPM2_RC_HANDLE = 0x008B,
TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */
+ TPM2_RC_FAILURE = 0x0101,
TPM2_RC_DISABLED = 0x0120,
TPM2_RC_COMMAND_CODE = 0x0143,
TPM2_RC_TESTING = 0x090A, /* RC_WARN */
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index a700f8f9ead7..89a5397b18d2 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -31,10 +31,6 @@ struct tpm2_startup_in {
__be16 startup_type;
} __packed;
-struct tpm2_self_test_in {
- u8 full_test;
-} __packed;
-
struct tpm2_get_tpm_pt_in {
__be32 cap_id;
__be32 property_id;
@@ -60,7 +56,6 @@ struct tpm2_get_random_out {
union tpm2_cmd_params {
struct tpm2_startup_in startup_in;
- struct tpm2_self_test_in selftest_in;
struct tpm2_get_tpm_pt_in get_tpm_pt_in;
struct tpm2_get_tpm_pt_out get_tpm_pt_out;
struct tpm2_get_random_in getrandom_in;
@@ -827,16 +822,6 @@ unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal)
}
EXPORT_SYMBOL_GPL(tpm2_calc_ordinal_duration);
-#define TPM2_SELF_TEST_IN_SIZE \
- (sizeof(struct tpm_input_header) + \
- sizeof(struct tpm2_self_test_in))
-
-static const struct tpm_input_header tpm2_selftest_header = {
- .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
- .length = cpu_to_be32(TPM2_SELF_TEST_IN_SIZE),
- .ordinal = cpu_to_be32(TPM2_CC_SELF_TEST)
-};
-
/**
* tpm2_do_selftest() - ensure that all self tests have passed
*
@@ -852,27 +837,24 @@ static const struct tpm_input_header tpm2_selftest_header = {
*/
static int tpm2_do_selftest(struct tpm_chip *chip)
{
+ struct tpm_buf buf;
+ int full;
int rc;
- unsigned int delay_msec = 10;
- long duration;
- struct tpm2_cmd cmd;
- duration = jiffies_to_msecs(
- tpm2_calc_ordinal_duration(chip, TPM2_CC_SELF_TEST));
-
- while (1) {
- cmd.header.in = tpm2_selftest_header;
- cmd.params.selftest_in.full_test = 0;
-
- rc = tpm_transmit_cmd(chip, NULL, &cmd, TPM2_SELF_TEST_IN_SIZE,
- 0, 0, "continue selftest");
+ for (full = 0; full < 2; full++) {
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_SELF_TEST);
+ if (rc)
+ return rc;
- if (rc != TPM2_RC_TESTING || delay_msec >= duration)
- break;
+ tpm_buf_append_u8(&buf, full);
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
+ "attempting the self test");
+ tpm_buf_destroy(&buf);
- /* wait longer than before */
- delay_msec *= 2;
- tpm_msleep(delay_msec);
+ if (rc == TPM2_RC_TESTING)
+ rc = TPM2_RC_SUCCESS;
+ if (rc == TPM2_RC_INITIALIZE || rc == TPM2_RC_SUCCESS)
+ return rc;
}
return rc;
@@ -1058,10 +1040,8 @@ int tpm2_auto_startup(struct tpm_chip *chip)
goto out;
rc = tpm2_do_selftest(chip);
- if (rc != 0 && rc != TPM2_RC_INITIALIZE) {
- dev_err(&chip->dev, "TPM self test failed\n");
+ if (rc && rc != TPM2_RC_INITIALIZE)
goto out;
- }
if (rc == TPM2_RC_INITIALIZE) {
rc = tpm_startup(chip);
@@ -1069,10 +1049,8 @@ int tpm2_auto_startup(struct tpm_chip *chip)
goto out;
rc = tpm2_do_selftest(chip);
- if (rc) {
- dev_err(&chip->dev, "TPM self test failed\n");
+ if (rc)
goto out;
- }
}
rc = tpm2_get_pcr_allocation(chip);
--
2.15.1
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit 2c0a646268f2a3536866bf237733a52aec260594 upstream
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data. Also sanity check that the expected amount of data is
large enough for the TPM header.
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
---
Backported to v4.4 because of merge conflict.
drivers/char/tpm/tpm_tis.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 7f13221aeb30..9dd93a209ef2 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -283,7 +283,8 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t count)
static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
{
int size = 0;
- int expected, status;
+ int status;
+ u32 expected;
if (count < TPM_HEADER_SIZE) {
size = -EIO;
@@ -298,7 +299,7 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
}
expected = be32_to_cpu(*(__be32 *) (buf + 2));
- if (expected > count) {
+ if (expected > count || expected < TPM_HEADER_SIZE) {
size = -EIO;
goto out;
}
--
2.15.1
From: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
commit c8e3e06d252155ad0e38a64a65ebb85638893025 upstream
Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips. If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().
Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust>
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
---
Backport for v4.9 because of the merge conflict.
drivers/char/tpm/tpm-interface.c | 5 +++++
drivers/char/tpm/tpm2-cmd.c | 6 ++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index d0ac2d56520f..830d7e30e508 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1078,6 +1078,11 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max)
break;
recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ if (recd > num_bytes) {
+ total = -EFAULT;
+ break;
+ }
+
memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
dest += recd;
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 17896d654033..a5780ebe15ef 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -668,6 +668,11 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
if (!rc) {
data_len = be16_to_cpup(
(__be16 *) &buf.data[TPM_HEADER_SIZE + 4]);
+ if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) {
+ rc = -EFAULT;
+ goto out;
+ }
+
data = &buf.data[TPM_HEADER_SIZE + 6];
memcpy(payload->key, data, data_len - 1);
@@ -675,6 +680,7 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip,
payload->migratable = data[data_len - 1];
}
+out:
tpm_buf_destroy(&buf);
return rc;
}
--
2.15.1
Since blk_queue_enter() uses rcu_read_lock_sched() scsi_device_quiesce()
must use synchronize_sched().
Reported-by: Tejun Heo <tj(a)kernel.org>
Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Ming Lei <ming.lei(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Cc: Martin Steigerwald <martin(a)lichtvoll.de>
Cc: stable(a)vger.kernel.org # v4.15
---
drivers/scsi/scsi_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1d83f29aee74..0b99ee2fbbb5 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -3014,7 +3014,7 @@ scsi_device_quiesce(struct scsi_device *sdev)
* unfreeze even if the queue was already frozen before this function
* was called. See also https://lwn.net/Articles/573497/.
*/
- synchronize_rcu();
+ synchronize_sched();
blk_mq_unfreeze_queue(q);
mutex_lock(&sdev->state_mutex);
--
2.16.2
The patch titled
Subject: drivers/infiniband/ulp/srpt/ib_srpt.c: fix build with gcc-4.4.4
has been removed from the -mm tree. Its filename was
drivers-infiniband-ulp-srpt-ib_srptc-fix-build-with-gcc-444.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrew Morton <akpm(a)linux-foundation.org>
Subject: drivers/infiniband/ulp/srpt/ib_srpt.c: fix build with gcc-4.4.4
gcc-4.4.4 has issues with initialization of anonymous unions:
drivers/infiniband/ulp/srpt/ib_srpt.c: In function 'srpt_zerolength_write':
drivers/infiniband/ulp/srpt/ib_srpt.c:854: error: unknown field 'wr_cqe' specified in initializer
drivers/infiniband/ulp/srpt/ib_srpt.c:854: warning: initialization makes integer from pointer without a cast
Work aound this.
Fixes: 2a78cb4db487 ("IB/srpt: Fix an out-of-bounds stack access in srpt_zerolength_write()")
Cc: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN drivers/infiniband/ulp/srpt/ib_srpt.c~drivers-infiniband-ulp-srpt-ib_srptc-fix-build-with-gcc-444 drivers/infiniband/ulp/srpt/ib_srpt.c
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c~drivers-infiniband-ulp-srpt-ib_srptc-fix-build-with-gcc-444
+++ a/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -850,8 +850,9 @@ static int srpt_zerolength_write(struct
struct ib_send_wr *bad_wr;
struct ib_rdma_wr wr = {
.wr = {
+ .next = NULL,
+ { .wr_cqe = &ch->zw_cqe, },
.opcode = IB_WR_RDMA_WRITE,
- .wr_cqe = &ch->zw_cqe,
.send_flags = IB_SEND_SIGNALED,
}
};
_
Patches currently in -mm which might be from akpm(a)linux-foundation.org are
i-need-old-gcc.patch
mm-mempolicy-avoid-use-uninitialized-preferred_node-fix.patch
hugetlbfs-check-for-pgoff-value-overflow-v3-fix.patch
hugetlbfs-check-for-pgoff-value-overflow-v3-fix-fix.patch
mm-vmalloc-add-interfaces-to-free-unmapped-page-table-fix.patch
arm-arch-arm-include-asm-pageh-needs-personalityh.patch
ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes.patch
mm.patch
mm-initialize-pages-on-demand-during-boot-fix-4-fix.patch
mm-initialize-pages-on-demand-during-boot-v5-fix.patch
mm-initialize-pages-on-demand-during-boot-v6-checkpatch-fixes.patch
direct-io-minor-cleanups-in-do_blockdev_direct_io-fix.patch
mm-fix-races-between-swapoff-and-flush-dcache-fix.patch
headers-untangle-kmemleakh-from-mmh-fix.patch
mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-checkpatch-fixes.patch
list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch
mm-oom-cgroup-aware-oom-killer-fix.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2-fix.patch
proc-add-seq_put_decimal_ull_width-to-speed-up-proc-pid-smaps-fix.patch
linux-next-rejects.patch
linux-next-fixup.patch
fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix.patch
kernel-forkc-export-kernel_thread-to-modules.patch
slab-leaks3-default-y.patch
The patch titled
Subject: drivers/infiniband/core/verbs.c: fix build with gcc-4.4.4
has been removed from the -mm tree. Its filename was
drivers-infiniband-core-verbsc-fix-build-with-gcc-444.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrew Morton <akpm(a)linux-foundation.org>
Subject: drivers/infiniband/core/verbs.c: fix build with gcc-4.4.4
gcc-4.4.4 has issues with initialization of anonymous unions.
drivers/infiniband/core/verbs.c: In function '__ib_drain_sq':
drivers/infiniband/core/verbs.c:2204: error: unknown field 'wr_cqe' specified in initializer
drivers/infiniband/core/verbs.c:2204: warning: initialization makes integer from pointer without a cast
Work around this.
Fixes: a1ae7d0345edd5 ("RDMA/core: Avoid that ib_drain_qp() triggers an out-of-bounds stack access")
Cc: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Steve Wise <swise(a)opengridcomputing.com>
Cc: Sagi Grimberg <sagi(a)grimberg.me>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/infiniband/core/verbs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN drivers/infiniband/core/verbs.c~drivers-infiniband-core-verbsc-fix-build-with-gcc-444 drivers/infiniband/core/verbs.c
--- a/drivers/infiniband/core/verbs.c~drivers-infiniband-core-verbsc-fix-build-with-gcc-444
+++ a/drivers/infiniband/core/verbs.c
@@ -2200,8 +2200,9 @@ static void __ib_drain_sq(struct ib_qp *
struct ib_send_wr *bad_swr;
struct ib_rdma_wr swr = {
.wr = {
+ .next = NULL,
+ { .wr_cqe = &sdrain.cqe, },
.opcode = IB_WR_RDMA_WRITE,
- .wr_cqe = &sdrain.cqe,
},
};
int ret;
_
Patches currently in -mm which might be from akpm(a)linux-foundation.org are
i-need-old-gcc.patch
mm-mempolicy-avoid-use-uninitialized-preferred_node-fix.patch
hugetlbfs-check-for-pgoff-value-overflow-v3-fix.patch
hugetlbfs-check-for-pgoff-value-overflow-v3-fix-fix.patch
mm-vmalloc-add-interfaces-to-free-unmapped-page-table-fix.patch
arm-arch-arm-include-asm-pageh-needs-personalityh.patch
ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes.patch
mm.patch
mm-initialize-pages-on-demand-during-boot-fix-4-fix.patch
mm-initialize-pages-on-demand-during-boot-v5-fix.patch
mm-initialize-pages-on-demand-during-boot-v6-checkpatch-fixes.patch
direct-io-minor-cleanups-in-do_blockdev_direct_io-fix.patch
mm-fix-races-between-swapoff-and-flush-dcache-fix.patch
headers-untangle-kmemleakh-from-mmh-fix.patch
mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-checkpatch-fixes.patch
list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch
mm-oom-cgroup-aware-oom-killer-fix.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2-fix.patch
proc-add-seq_put_decimal_ull_width-to-speed-up-proc-pid-smaps-fix.patch
linux-next-rejects.patch
linux-next-fixup.patch
fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix.patch
kernel-forkc-export-kernel_thread-to-modules.patch
slab-leaks3-default-y.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.
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
scsi_device_quiesce() uses synchronize_rcu() to guarantee that the
effect of blk_set_preempt_only() will be visible for percpu_ref_tryget()
calls that occur after the queue unfreeze by using the approach
explained in https://lwn.net/Articles/573497/. The rcu read lock and
unlock calls in blk_queue_enter() form a pair with the synchronize_rcu()
call in scsi_device_quiesce(). Both scsi_device_quiesce() and
blk_queue_enter() must either use regular RCU or RCU-sched.
Since neither the RCU-protected code in blk_queue_enter() nor
blk_queue_usage_counter_release() sleeps, regular RCU protection
is sufficient. Note: scsi_device_quiesce() does not have to be
modified since it already uses synchronize_rcu().
Reported-by: Tejun Heo <tj(a)kernel.org>
Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Acked-by: Tejun Heo <tj(a)kernel.org>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Ming Lei <ming.lei(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Cc: Martin Steigerwald <martin(a)lichtvoll.de>
Cc: stable(a)vger.kernel.org # v4.15
---
Changes between v1 and v2:
- Explained in the interaction between scsi_device_quiesce() and
blk_queue_enter() in the patch description.
block/blk-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 5e88c579e896..a0f675f84f86 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -917,7 +917,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
bool success = false;
int ret;
- rcu_read_lock_sched();
+ rcu_read_lock();
if (percpu_ref_tryget_live(&q->q_usage_counter)) {
/*
* The code that sets the PREEMPT_ONLY flag is
@@ -930,7 +930,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
percpu_ref_put(&q->q_usage_counter);
}
}
- rcu_read_unlock_sched();
+ rcu_read_unlock();
if (success)
return 0;
--
2.16.2
This is a note to let you know that I've just added the patch titled
staging: comedi: ni_mio_common: ack ai fifo error interrupts.
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the staging-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From e1d9fc04c41840a4688ef6ce90b6dcca157ea4d7 Mon Sep 17 00:00:00 2001
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Date: Thu, 15 Mar 2018 10:25:44 +0000
Subject: staging: comedi: ni_mio_common: ack ai fifo error interrupts.
Ack ai fifo error interrupts in interrupt handler to clear interrupt
after fifo overflow. It should prevent lock-ups after the ai fifo
overflows.
Cc: <stable(a)vger.kernel.org> # v4.2+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/comedi/drivers/ni_mio_common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c
index d6eb55b41814..e40a2c0a9543 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1275,6 +1275,8 @@ static void ack_a_interrupt(struct comedi_device *dev, unsigned short a_status)
ack |= NISTC_INTA_ACK_AI_START;
if (a_status & NISTC_AI_STATUS1_STOP)
ack |= NISTC_INTA_ACK_AI_STOP;
+ if (a_status & NISTC_AI_STATUS1_OVER)
+ ack |= NISTC_INTA_ACK_AI_ERR;
if (ack)
ni_stc_writew(dev, ack, NISTC_INTA_ACK_REG);
}
--
2.16.2
Michal Kalderon has found some corner cases around device unload
with active NFS mounts that I didn't have the imagination to test
when xprtrdma device removal was added last year.
- The ULP device removal handler is responsible for deallocating
the PD. That wasn't clear to me initially, and my own testing
suggested it was not necessary, but that is incorrect.
- The transport destruction path can no longer assume that there
is a valid ID.
- When destroying a transport, ensure that ib_free_cq() is not
invoked on a CQ that was already released.
Reported-by: Michal Kalderon <Michal.Kalderon(a)cavium.com>
Fixes: bebd031866ca ("xprtrdma: Support unplugging an HCA from ...")
Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com>
Cc: stable(a)vger.kernel.org
---
net/sunrpc/xprtrdma/verbs.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index fe518b3..5e3afed 100644
--- a/net/sunrpc/xprtrdma/verbs.c
+++ b/net/sunrpc/xprtrdma/verbs.c
@@ -250,7 +250,6 @@
wait_for_completion(&ia->ri_remove_done);
ia->ri_id = NULL;
- ia->ri_pd = NULL;
ia->ri_device = NULL;
/* Return 1 to ensure the core destroys the id. */
return 1;
@@ -448,7 +447,9 @@
ia->ri_id->qp = NULL;
}
ib_free_cq(ep->rep_attr.recv_cq);
+ ep->rep_attr.recv_cq = NULL;
ib_free_cq(ep->rep_attr.send_cq);
+ ep->rep_attr.send_cq = NULL;
/* The ULP is responsible for ensuring all DMA
* mappings and MRs are gone.
@@ -461,6 +462,8 @@
rpcrdma_dma_unmap_regbuf(req->rl_recvbuf);
}
rpcrdma_mrs_destroy(buf);
+ ib_dealloc_pd(ia->ri_pd);
+ ia->ri_pd = NULL;
/* Allow waiters to continue */
complete(&ia->ri_remove_done);
@@ -628,14 +631,16 @@
{
cancel_delayed_work_sync(&ep->rep_connect_worker);
- if (ia->ri_id->qp) {
+ if (ia->ri_id && ia->ri_id->qp) {
rpcrdma_ep_disconnect(ep, ia);
rdma_destroy_qp(ia->ri_id);
ia->ri_id->qp = NULL;
}
- ib_free_cq(ep->rep_attr.recv_cq);
- ib_free_cq(ep->rep_attr.send_cq);
+ if (ep->rep_attr.recv_cq)
+ ib_free_cq(ep->rep_attr.recv_cq);
+ if (ep->rep_attr.send_cq)
+ ib_free_cq(ep->rep_attr.send_cq);
}
/* Re-establish a connection after a device removal event.
Since neither the RCU-protected code in blk_queue_enter() nor
blk_queue_usage_counter_release() sleeps, regular RCU protection
is sufficient. Note: scsi_device_quiesce() does not have to be
modified since it already uses synchronize_rcu().
Reported-by: Tejun Heo <tj(a)kernel.org>
Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Ming Lei <ming.lei(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Cc: Martin Steigerwald <martin(a)lichtvoll.de>
Cc: stable(a)vger.kernel.org # v4.15
---
block/blk-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 5e88c579e896..a0f675f84f86 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -917,7 +917,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
bool success = false;
int ret;
- rcu_read_lock_sched();
+ rcu_read_lock();
if (percpu_ref_tryget_live(&q->q_usage_counter)) {
/*
* The code that sets the PREEMPT_ONLY flag is
@@ -930,7 +930,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
percpu_ref_put(&q->q_usage_counter);
}
}
- rcu_read_unlock_sched();
+ rcu_read_unlock();
if (success)
return 0;
--
2.16.2
Tree/Branch: v4.1.50
Git describe: v4.1.50
Commit: 6f20f6d4c0 Linux 4.1.50
Build Time: 42 min 12 sec
Passed: 6 / 9 ( 66.67 %)
Failed: 2 / 9 ( 22.22 %)
Unknown: 1 / 9 ( 11.11 %)
Errors: 1
Warnings: 31
Section Mismatches: 1
Failed defconfigs:
arm64-allmodconfig
arm64-defconfig
Errors:
arm64-allmodconfig
../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration]
arm64-defconfig
../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration]
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
21 warnings 1 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-multi_v5_defconfig
2 warnings 0 mismatches : arm-multi_v7_defconfig
4 warnings 0 mismatches : x86_64-defconfig
23 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Errors summary: 1
2 ../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration]
Warnings Summary: 31
8 ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
5 ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
2 ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
2 ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
2 ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
2 ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
1 ../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion]
1 ../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
1 ../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/iommu/intel-iommu.c:3800:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
1 ../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
1 ../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
1 ../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
1 ../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
Section Mismatch Summary: 1
1 WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0xb0): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : FAIL, 1 errors, 21 warnings, 1 section mismatches
Errors:
../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration]
Warnings:
../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion]
Section Mismatches:
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0xb0): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
../drivers/iommu/intel-iommu.c:3800:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
-------------------------------------------------------------------------------
arm-allmodconfig : UNKNOWN, 0 errors, 23 warnings, 0 section mismatches
Warnings:
../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Hi!
Someone on Twitter
(https://twitter.com/vnik5287/status/974277953394651137) is pointing
out that the BPF fix commit 95a762e2c8c942780948091f8f2a4f32fce1ac6f
("bpf: fix incorrect sign extension in check_alu_op()") needs to be
applied all the way back to 4.4, and probably also 4.1; my "Fixes:"
tag on that commit is incorrect. I assumed that without map access,
math correctness issues don't matter, but actually, this one does
matter because check_cond_jmp_op() will omit verification for branches
that appear to be unreachable (comparison of CONST_IMM register and a
constant value). :/
FWIW, I checked by hand what the binary blob of BPF code in the linked
PoC does, and it's basically this (with some error checking and other
minor stuff omitted):
// trick the verifier into not checking any of the code below
r9 = (u32)-1
if (r9 == (s32)-1) exit 0
// read some configuration
r6 = *map_lookup_elem(MAP_FD, &0) // operation selector
r7 = *map_lookup_elem(MAP_FD, &1) // pointer to access
r8 = *map_lookup_elem(MAP_FD, &2) // value to write
r2 = map_lookup_elem(MAP_FD, &2)
if r6 == 0: // operation: read
r3 = *r7
*r2 = r3
exit
if r6 == 1: // operation: get frame pointer
*r2 = fp
exit
*r7 = r8 // operation: write
exit
The author of the tweet does point out that this exploit is mitigated
by sanitize_dead_code() (introduced in "bpf: fix branch pruning logic"
and backported all the way), but 95a762e2c8c9 should still be applied.
This is a note to let you know that I've just added the patch titled
USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
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:
usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.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 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Tue, 23 Jan 2018 09:35:14 +0000
Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
From: Wei Yongjun <weiyongjun1(a)huawei.com>
commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream.
Add the missing platform_device_put() before return from bdc_pci_probe()
in the platform_device_add_resources() error handling case.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c
@@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_dev
if (ret) {
dev_err(&pci->dev,
"couldn't add resources to bdc device\n");
+ platform_device_put(bdc);
return ret;
}
Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are
queue-4.9/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: bdc: 64-bit pointer capability check
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:
usb-gadget-bdc-64-bit-pointer-capability-check.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 c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 Mon Sep 17 00:00:00 2001
From: Srinath Mannam <srinath.mannam(a)broadcom.com>
Date: Thu, 15 Jun 2017 14:39:22 +0530
Subject: usb: gadget: bdc: 64-bit pointer capability check
From: Srinath Mannam <srinath.mannam(a)broadcom.com>
commit c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 upstream.
Corrected the register to check the 64-bit pointer
capability state. 64-bit pointer implementation capability
was checking in wrong register, which causes the BDC
enumeration failure in 64-bit memory address.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for
Broadcom USB3.0 device controller IP BDC")
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Srinath Mannam <srinath.mannam(a)broadcom.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -475,7 +475,7 @@ static int bdc_probe(struct platform_dev
bdc->dev = dev;
dev_dbg(bdc->dev, "bdc->regs: %p irq=%d\n", bdc->regs, bdc->irq);
- temp = bdc_readl(bdc->regs, BDC_BDCSC);
+ temp = bdc_readl(bdc->regs, BDC_BDCCAP1);
if ((temp & BDC_P64) &&
!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
dev_dbg(bdc->dev, "Using 64-bit address\n");
Patches currently in stable-queue which might be from srinath.mannam(a)broadcom.com are
queue-4.9/usb-gadget-bdc-64-bit-pointer-capability-check.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
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:
usb-dwc3-fix-gdbgfifospace_type-values.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 b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 2 Feb 2018 13:21:35 -0800
Subject: usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream.
The FIFO/Queue type values are incorrect. Correct them according to
DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25).
Additionally, this patch includes ProtocolStatusQ and AuxEventQ types.
Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/core.h | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -159,13 +159,15 @@
#define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
#define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0xffff)
-#define DWC3_TXFIFOQ 1
-#define DWC3_RXFIFOQ 3
-#define DWC3_TXREQQ 5
-#define DWC3_RXREQQ 7
-#define DWC3_RXINFOQ 9
-#define DWC3_DESCFETCHQ 13
-#define DWC3_EVENTQ 15
+#define DWC3_TXFIFOQ 0
+#define DWC3_RXFIFOQ 1
+#define DWC3_TXREQQ 2
+#define DWC3_RXREQQ 3
+#define DWC3_RXINFOQ 4
+#define DWC3_PSTATQ 5
+#define DWC3_DESCFETCHQ 6
+#define DWC3_EVENTQ 7
+#define DWC3_AUXEVENTQ 8
/* Global RX Threshold Configuration Register */
#define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.9/usb-dwc3-fix-gdbgfifospace_type-values.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix extraneous ref on sp's after adapter break
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:
scsi-qla2xxx-fix-extraneous-ref-on-sp-s-after-adapter-break.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 4cd3b6ebff8510b2139d64024411207090cfe0a9 Mon Sep 17 00:00:00 2001
From: Bill Kuzeja <William.Kuzeja(a)stratus.com>
Date: Thu, 25 May 2017 15:26:31 -0400
Subject: scsi: qla2xxx: Fix extraneous ref on sp's after adapter break
From: Bill Kuzeja <William.Kuzeja(a)stratus.com>
commit 4cd3b6ebff8510b2139d64024411207090cfe0a9 upstream.
Hung task timeouts can result if a qlogic board breaks unexpectedly
while running I/O. These tasks become hung because command srb reference
counts are not going to zero, hence the affected srbs and commands do
not get freed. This fix accounts for this extra reference in the srbs in
the case of a board failure.
Fixes: a465537ad1a4 ("qla2xxx: Disable the adapter and skip error recovery in case of register disconnect")
Signed-off-by: Bill Kuzeja <william.kuzeja(a)stratus.com>
Acked-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_os.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -1443,7 +1443,7 @@ qla2x00_loop_reset(scsi_qla_host_t *vha)
void
qla2x00_abort_all_cmds(scsi_qla_host_t *vha, int res)
{
- int que, cnt;
+ int que, cnt, status;
unsigned long flags;
srb_t *sp;
struct qla_hw_data *ha = vha->hw;
@@ -1473,8 +1473,12 @@ qla2x00_abort_all_cmds(scsi_qla_host_t *
*/
sp_get(sp);
spin_unlock_irqrestore(&ha->hardware_lock, flags);
- qla2xxx_eh_abort(GET_CMD_SP(sp));
+ status = qla2xxx_eh_abort(GET_CMD_SP(sp));
spin_lock_irqsave(&ha->hardware_lock, flags);
+ /* Get rid of extra reference if immediate exit
+ * from ql2xxx_eh_abort */
+ if (status == FAILED && (qla2x00_isp_reg_stat(ha)))
+ atomic_dec(&sp->ref_count);
}
req->outstanding_cmds[cnt] = NULL;
sp->done(vha, sp, res);
Patches currently in stable-queue which might be from William.Kuzeja(a)stratus.com are
queue-4.9/scsi-qla2xxx-fix-extraneous-ref-on-sp-s-after-adapter-break.patch
This is a note to let you know that I've just added the patch titled
USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
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:
usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.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 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Tue, 23 Jan 2018 09:35:14 +0000
Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
From: Wei Yongjun <weiyongjun1(a)huawei.com>
commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream.
Add the missing platform_device_put() before return from bdc_pci_probe()
in the platform_device_add_resources() error handling case.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c
@@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_dev
if (ret) {
dev_err(&pci->dev,
"couldn't add resources to bdc device\n");
+ platform_device_put(bdc);
return ret;
}
Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are
queue-4.4/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: bdc: 64-bit pointer capability check
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:
usb-gadget-bdc-64-bit-pointer-capability-check.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 c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 Mon Sep 17 00:00:00 2001
From: Srinath Mannam <srinath.mannam(a)broadcom.com>
Date: Thu, 15 Jun 2017 14:39:22 +0530
Subject: usb: gadget: bdc: 64-bit pointer capability check
From: Srinath Mannam <srinath.mannam(a)broadcom.com>
commit c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 upstream.
Corrected the register to check the 64-bit pointer
capability state. 64-bit pointer implementation capability
was checking in wrong register, which causes the BDC
enumeration failure in 64-bit memory address.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for
Broadcom USB3.0 device controller IP BDC")
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Srinath Mannam <srinath.mannam(a)broadcom.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -475,7 +475,7 @@ static int bdc_probe(struct platform_dev
bdc->dev = dev;
dev_dbg(bdc->dev, "bdc->regs: %p irq=%d\n", bdc->regs, bdc->irq);
- temp = bdc_readl(bdc->regs, BDC_BDCSC);
+ temp = bdc_readl(bdc->regs, BDC_BDCCAP1);
if ((temp & BDC_P64) &&
!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
dev_dbg(bdc->dev, "Using 64-bit address\n");
Patches currently in stable-queue which might be from srinath.mannam(a)broadcom.com are
queue-4.4/usb-gadget-bdc-64-bit-pointer-capability-check.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove()
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:
usb-gadget-udc-renesas_usb3-fix-oops-in-renesas_usb3_remove.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 e3190868e5f52fb26544f16463593d54ce46ce61 Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Fri, 12 Jan 2018 20:00:56 +0900
Subject: usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove()
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit e3190868e5f52fb26544f16463593d54ce46ce61 upstream.
This patch fixes an issue that the renesas_usb3_remove() causes
NULL pointer dereference because the usb3_to_dev() macro will use
the gadget instance and it will be deleted before.
Fixes: cf06df3fae28 ("usb: gadget: udc: renesas_usb3: move pm_runtime_{en,dis}able()")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -2410,7 +2410,7 @@ static int renesas_usb3_remove(struct pl
__renesas_usb3_ep_free_request(usb3->ep0_req);
if (usb3->phy)
phy_put(usb3->phy);
- pm_runtime_disable(usb3_to_dev(usb3));
+ pm_runtime_disable(&pdev->dev);
return 0;
}
Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are
queue-4.15/usb-gadget-udc-renesas_usb3-fix-oops-in-renesas_usb3_remove.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: of-simple: fix oops by unbalanced clk disable call
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:
usb-dwc3-of-simple-fix-oops-by-unbalanced-clk-disable-call.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 bff52352e0ccc2481f2b6b0d612ff8ff56c50f3a Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <enric.balletbo(a)collabora.com>
Date: Mon, 18 Dec 2017 16:14:36 +0100
Subject: usb: dwc3: of-simple: fix oops by unbalanced clk disable call
From: Enric Balletbo i Serra <enric.balletbo(a)collabora.com>
commit bff52352e0ccc2481f2b6b0d612ff8ff56c50f3a upstream.
dwc3_of_simple_dev_pm_ops has never been used since commit a0d8c4cfdf31
("usb: dwc3: of-simple: set dev_pm_ops"), but this commit has brought
and oops when unbind the device due this sequence:
dwc3_of_simple_remove
-> clk_disable ...
-> pm_runtime_put_sync
-> dwc3_of_simple_runtime_suspend
-> clk_disable (again)
This double call to clk_core_disable causes a kernel oops like this:
WARNING: CPU: 1 PID: 4022 at drivers/clk/clk.c:656 clk_core_disable+0x78/0x80
CPU: 1 PID: 4022 Comm: bash Not tainted 4.15.0-rc4+ #44
Hardware name: Google Kevin (DT)
pstate: 80000085 (Nzcv daIf -PAN -UAO)
pc : clk_core_disable+0x78/0x80
lr : clk_core_disable_lock+0x20/0x38
sp : ffff00000bbf3a90
...
Call trace:
clk_core_disable+0x78/0x80
clk_disable+0x1c/0x30
dwc3_of_simple_runtime_suspend+0x30/0x50
pm_generic_runtime_suspend+0x28/0x40
This patch fixes the unbalanced clk disable call by setting the num_clocks
variable to zero once the clocks were disabled.
Fixes: a0d8c4cfdf31 ("usb: dwc3: of-simple: set dev_pm_ops")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/dwc3-of-simple.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -143,6 +143,7 @@ static int dwc3_of_simple_remove(struct
clk_disable_unprepare(simple->clks[i]);
clk_put(simple->clks[i]);
}
+ simple->num_clocks = 0;
reset_control_assert(simple->resets);
reset_control_put(simple->resets);
Patches currently in stable-queue which might be from enric.balletbo(a)collabora.com are
queue-4.15/usb-dwc3-of-simple-fix-oops-by-unbalanced-clk-disable-call.patch
This is a note to let you know that I've just added the patch titled
USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
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:
usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.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 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Tue, 23 Jan 2018 09:35:14 +0000
Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
From: Wei Yongjun <weiyongjun1(a)huawei.com>
commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream.
Add the missing platform_device_put() before return from bdc_pci_probe()
in the platform_device_add_resources() error handling case.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c
@@ -77,6 +77,7 @@ static int bdc_pci_probe(struct pci_dev
if (ret) {
dev_err(&pci->dev,
"couldn't add resources to bdc device\n");
+ platform_device_put(bdc);
return ret;
}
Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are
queue-4.15/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode
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:
usb-dwc3-core-power-off-core-phys-on-system_suspend-in-host-mode.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 c4a5153e87fdf6805f63ff57556260e2554155a5 Mon Sep 17 00:00:00 2001
From: Manu Gautam <mgautam(a)codeaurora.org>
Date: Thu, 18 Jan 2018 16:54:30 +0530
Subject: usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode
From: Manu Gautam <mgautam(a)codeaurora.org>
commit c4a5153e87fdf6805f63ff57556260e2554155a5 upstream.
Commit 689bf72c6e0d ("usb: dwc3: Don't reinitialize core during
host bus-suspend/resume") updated suspend/resume routines to not
power_off and reinit PHYs/core for host mode.
It broke platforms that rely on DWC3 core to power_off PHYs to
enter low power state on system suspend.
Perform dwc3_core_exit/init only during host mode system_suspend/
resume to addresses power regression from above mentioned patch
and also allow USB session to stay connected across
runtime_suspend/resume in host mode. While at it also replace
existing checks for HOST only dr_mode with current_dr_role to
have similar core driver behavior for both Host-only and DRD+Host
configurations.
Fixes: 689bf72c6e0d ("usb: dwc3: Don't reinitialize core during host bus-suspend/resume")
Reviewed-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Manu Gautam <mgautam(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/core.c | 36 ++++++++++++++++++++++--------------
1 file changed, 22 insertions(+), 14 deletions(-)
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -100,6 +100,8 @@ static void dwc3_set_prtcap(struct dwc3
reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
reg |= DWC3_GCTL_PRTCAPDIR(mode);
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+
+ dwc->current_dr_role = mode;
}
static void __dwc3_set_mode(struct work_struct *work)
@@ -133,8 +135,6 @@ static void __dwc3_set_mode(struct work_
dwc3_set_prtcap(dwc, dwc->desired_dr_role);
- dwc->current_dr_role = dwc->desired_dr_role;
-
spin_unlock_irqrestore(&dwc->lock, flags);
switch (dwc->desired_dr_role) {
@@ -218,7 +218,7 @@ static int dwc3_core_soft_reset(struct d
* XHCI driver will reset the host block. If dwc3 was configured for
* host-only mode, then we can return early.
*/
- if (dwc->dr_mode == USB_DR_MODE_HOST)
+ if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
return 0;
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
@@ -915,7 +915,6 @@ static int dwc3_core_init_mode(struct dw
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
- dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
if (dwc->usb2_phy)
@@ -931,7 +930,6 @@ static int dwc3_core_init_mode(struct dw
}
break;
case USB_DR_MODE_HOST:
- dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
if (dwc->usb2_phy)
@@ -1279,7 +1277,7 @@ static int dwc3_remove(struct platform_d
}
#ifdef CONFIG_PM
-static int dwc3_suspend_common(struct dwc3 *dwc)
+static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg)
{
unsigned long flags;
@@ -1291,6 +1289,10 @@ static int dwc3_suspend_common(struct dw
dwc3_core_exit(dwc);
break;
case DWC3_GCTL_PRTCAP_HOST:
+ /* do nothing during host runtime_suspend */
+ if (!PMSG_IS_AUTO(msg))
+ dwc3_core_exit(dwc);
+ break;
default:
/* do nothing */
break;
@@ -1299,7 +1301,7 @@ static int dwc3_suspend_common(struct dw
return 0;
}
-static int dwc3_resume_common(struct dwc3 *dwc)
+static int dwc3_resume_common(struct dwc3 *dwc, pm_message_t msg)
{
unsigned long flags;
int ret;
@@ -1315,6 +1317,13 @@ static int dwc3_resume_common(struct dwc
spin_unlock_irqrestore(&dwc->lock, flags);
break;
case DWC3_GCTL_PRTCAP_HOST:
+ /* nothing to do on host runtime_resume */
+ if (!PMSG_IS_AUTO(msg)) {
+ ret = dwc3_core_init(dwc);
+ if (ret)
+ return ret;
+ }
+ break;
default:
/* do nothing */
break;
@@ -1326,12 +1335,11 @@ static int dwc3_resume_common(struct dwc
static int dwc3_runtime_checks(struct dwc3 *dwc)
{
switch (dwc->current_dr_role) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
+ case DWC3_GCTL_PRTCAP_DEVICE:
if (dwc->connected)
return -EBUSY;
break;
- case USB_DR_MODE_HOST:
+ case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
@@ -1348,7 +1356,7 @@ static int dwc3_runtime_suspend(struct d
if (dwc3_runtime_checks(dwc))
return -EBUSY;
- ret = dwc3_suspend_common(dwc);
+ ret = dwc3_suspend_common(dwc, PMSG_AUTO_SUSPEND);
if (ret)
return ret;
@@ -1364,7 +1372,7 @@ static int dwc3_runtime_resume(struct de
device_init_wakeup(dev, false);
- ret = dwc3_resume_common(dwc);
+ ret = dwc3_resume_common(dwc, PMSG_AUTO_RESUME);
if (ret)
return ret;
@@ -1411,7 +1419,7 @@ static int dwc3_suspend(struct device *d
struct dwc3 *dwc = dev_get_drvdata(dev);
int ret;
- ret = dwc3_suspend_common(dwc);
+ ret = dwc3_suspend_common(dwc, PMSG_SUSPEND);
if (ret)
return ret;
@@ -1427,7 +1435,7 @@ static int dwc3_resume(struct device *de
pinctrl_pm_select_default_state(dev);
- ret = dwc3_resume_common(dwc);
+ ret = dwc3_resume_common(dwc, PMSG_RESUME);
if (ret)
return ret;
Patches currently in stable-queue which might be from mgautam(a)codeaurora.org are
queue-4.15/usb-dwc3-core-power-off-core-phys-on-system_suspend-in-host-mode.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
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:
usb-dwc3-fix-gdbgfifospace_type-values.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 b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 2 Feb 2018 13:21:35 -0800
Subject: usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream.
The FIFO/Queue type values are incorrect. Correct them according to
DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25).
Additionally, this patch includes ProtocolStatusQ and AuxEventQ types.
Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/core.h | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -158,13 +158,15 @@
#define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
#define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0xffff)
-#define DWC3_TXFIFOQ 1
-#define DWC3_RXFIFOQ 3
-#define DWC3_TXREQQ 5
-#define DWC3_RXREQQ 7
-#define DWC3_RXINFOQ 9
-#define DWC3_DESCFETCHQ 13
-#define DWC3_EVENTQ 15
+#define DWC3_TXFIFOQ 0
+#define DWC3_RXFIFOQ 1
+#define DWC3_TXREQQ 2
+#define DWC3_RXREQQ 3
+#define DWC3_RXINFOQ 4
+#define DWC3_PSTATQ 5
+#define DWC3_DESCFETCHQ 6
+#define DWC3_EVENTQ 7
+#define DWC3_AUXEVENTQ 8
/* Global RX Threshold Configuration Register */
#define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.15/usb-dwc3-fix-gdbgfifospace_type-values.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: fix STM32F7 USB OTG HS compatible
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:
usb-dwc2-fix-stm32f7-usb-otg-hs-compatible.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 1a149e3554e0324a3d551dfb327bdb67b150a320 Mon Sep 17 00:00:00 2001
From: Amelie Delaunay <amelie.delaunay(a)st.com>
Date: Thu, 1 Mar 2018 11:05:35 +0100
Subject: usb: dwc2: fix STM32F7 USB OTG HS compatible
From: Amelie Delaunay <amelie.delaunay(a)st.com>
commit 1a149e3554e0324a3d551dfb327bdb67b150a320 upstream.
This patch fixes compatible for STM32F7 USB OTG HS and consistently rename
dw2_set_params function.
The v2 former patch [1] had been acked by Paul Young, but v1 was merged.
[1] https://patchwork.kernel.org/patch/9925573/
Fixes: d8fae8b93682 ("usb: dwc2: add support for STM32F7xx USB OTG HS")
Signed-off-by: Amelie Delaunay <amelie.delaunay(a)st.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/params.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -137,7 +137,7 @@ static void dwc2_set_stm32f4x9_fsotg_par
p->activate_stm_fs_transceiver = true;
}
-static void dwc2_set_stm32f7xx_hsotg_params(struct dwc2_hsotg *hsotg)
+static void dwc2_set_stm32f7_hsotg_params(struct dwc2_hsotg *hsotg)
{
struct dwc2_core_params *p = &hsotg->params;
@@ -164,8 +164,8 @@ const struct of_device_id dwc2_of_match_
{ .compatible = "st,stm32f4x9-fsotg",
.data = dwc2_set_stm32f4x9_fsotg_params },
{ .compatible = "st,stm32f4x9-hsotg" },
- { .compatible = "st,stm32f7xx-hsotg",
- .data = dwc2_set_stm32f7xx_hsotg_params },
+ { .compatible = "st,stm32f7-hsotg",
+ .data = dwc2_set_stm32f7_hsotg_params },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
Patches currently in stable-queue which might be from amelie.delaunay(a)st.com are
queue-4.15/usb-dwc2-fix-stm32f7-usb-otg-hs-compatible.patch
queue-4.15/dt-bindings-usb-fix-the-stm32f7-dwc2-otg-hs-core-binding.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que
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:
scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.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 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 Mon Sep 17 00:00:00 2001
From: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Date: Sat, 16 Dec 2017 16:05:09 -0800
Subject: scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que
From: Himanshu Madhani <himanshu.madhani(a)cavium.com>
commit 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 upstream.
This patch fixes following warnings reported by smatch:
drivers/scsi/qla2xxx/qla_mid.c:586 qla25xx_delete_req_que()
error: we previously assumed 'req' could be null (see line 580)
drivers/scsi/qla2xxx/qla_mid.c:602 qla25xx_delete_rsp_que()
error: we previously assumed 'rsp' could be null (see line 596)
Fixes: 7867b98dceb7 ("scsi: qla2xxx: Fix memory leak in dual/target mode")
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_mid.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_mid.c
+++ b/drivers/scsi/qla2xxx/qla_mid.c
@@ -582,8 +582,9 @@ qla25xx_delete_req_que(struct scsi_qla_h
ret = qla25xx_init_req_que(vha, req);
if (ret != QLA_SUCCESS)
return QLA_FUNCTION_FAILED;
+
+ qla25xx_free_req_que(vha, req);
}
- qla25xx_free_req_que(vha, req);
return ret;
}
@@ -598,8 +599,9 @@ qla25xx_delete_rsp_que(struct scsi_qla_h
ret = qla25xx_init_rsp_que(vha, rsp);
if (ret != QLA_SUCCESS)
return QLA_FUNCTION_FAILED;
+
+ qla25xx_free_rsp_que(vha, rsp);
}
- qla25xx_free_rsp_que(vha, rsp);
return ret;
}
Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are
queue-4.15/scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch
queue-4.15/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch
queue-4.15/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix NULL pointer access for fcport structure
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:
scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.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 5c25d451163cab9be80744cbc5448d6b95ab8d1a Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Thu, 28 Dec 2017 12:33:09 -0800
Subject: scsi: qla2xxx: Fix NULL pointer access for fcport structure
From: Quinn Tran <quinn.tran(a)cavium.com>
commit 5c25d451163cab9be80744cbc5448d6b95ab8d1a upstream.
when processing iocb in a timeout case, driver was trying to log messages
without verifying if the fcport structure could have valid data. This
results in a NULL pointer access.
Fixes: 726b85487067("qla2xxx: Add framework for async fabric discovery")
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_init.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -102,11 +102,16 @@ qla2x00_async_iocb_timeout(void *data)
struct srb_iocb *lio = &sp->u.iocb_cmd;
struct event_arg ea;
- ql_dbg(ql_dbg_disc, fcport->vha, 0x2071,
- "Async-%s timeout - hdl=%x portid=%06x %8phC.\n",
- sp->name, sp->handle, fcport->d_id.b24, fcport->port_name);
+ if (fcport) {
+ ql_dbg(ql_dbg_disc, fcport->vha, 0x2071,
+ "Async-%s timeout - hdl=%x portid=%06x %8phC.\n",
+ sp->name, sp->handle, fcport->d_id.b24, fcport->port_name);
- fcport->flags &= ~FCF_ASYNC_SENT;
+ fcport->flags &= ~FCF_ASYNC_SENT;
+ } else {
+ pr_info("Async-%s timeout - hdl=%x.\n",
+ sp->name, sp->handle);
+ }
switch (sp->type) {
case SRB_LOGIN_CMD:
Patches currently in stable-queue which might be from quinn.tran(a)cavium.com are
queue-4.15/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix logo flag for qlt_free_session_done()
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:
scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.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 a2390348c19d0819d525d375414a7cfdacb51a68 Mon Sep 17 00:00:00 2001
From: Himanshu Madhani <hmadhani(a)redhat.com>
Date: Mon, 22 Jan 2018 12:04:20 -0800
Subject: scsi: qla2xxx: Fix logo flag for qlt_free_session_done()
From: Himanshu Madhani <hmadhani(a)redhat.com>
commit a2390348c19d0819d525d375414a7cfdacb51a68 upstream.
Commit 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target
re-login.")fixed the target re-login after session relogin is complete,
but missed out the qlt_free_session_done() path.
This patch clears send_els_logo flag in qlt_free_session_done()
callback.
[mkp: checkpatch]
Fixes: 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.")
Signed-off-by: Himanshu Madhani <hmadhani(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_target.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -982,6 +982,7 @@ static void qlt_free_session_done(struct
logo.id = sess->d_id;
logo.cmd_count = 0;
+ sess->send_els_logo = 0;
qlt_send_first_logo(vha, &logo);
}
Patches currently in stable-queue which might be from hmadhani(a)redhat.com are
queue-4.15/scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch
This is a note to let you know that I've just added the patch titled
phy: phy-brcm-usb-init: DRD mode can cause crash on startup
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:
phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.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 0aa0c12262fd848c48448c39ff6c1c097be00dd4 Mon Sep 17 00:00:00 2001
From: Al Cooper <al.cooper(a)broadcom.com>
Date: Wed, 27 Dec 2017 14:28:51 -0500
Subject: phy: phy-brcm-usb-init: DRD mode can cause crash on startup
From: Al Cooper <al.cooper(a)broadcom.com>
commit 0aa0c12262fd848c48448c39ff6c1c097be00dd4 upstream.
This is caused by a bug in the BDC core. When the BDC core comes
out of reset and it's not selected, it gets a backup clock. When
the BDC core is selected, it get's the main clock. If HOST mode
is then selected the BDC core has the main clock shut off but
the backup clock is not restored.
The failure scenario and cause are as follows:
- DRD mode is active
- Device mode is selected first in bootloader
- When host mode is now selected, the clock to the BDC is cut off.
- BDC registers are inaccessible and therefore the BDC driver
crashes upon Linux boot.
The fix is to have the phy driver always force a BDC reset on
startup.
Fixes: 49859e55e364 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver")
Signed-off-by: Al Cooper <alcooperx(a)gmail.com>
Acked-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/phy/broadcom/phy-brcm-usb-init.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/phy/broadcom/phy-brcm-usb-init.c
+++ b/drivers/phy/broadcom/phy-brcm-usb-init.c
@@ -917,6 +917,7 @@ void brcm_usb_init_common(struct brcm_us
USB_CTRL_UNSET_FAMILY(params, USB_PM, BDC_SOFT_RESETB);
break;
default:
+ USB_CTRL_UNSET_FAMILY(params, USB_PM, BDC_SOFT_RESETB);
USB_CTRL_SET_FAMILY(params, USB_PM, BDC_SOFT_RESETB);
break;
}
Patches currently in stable-queue which might be from al.cooper(a)broadcom.com are
queue-4.15/phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch
queue-4.15/phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch
queue-4.15/phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch
This is a note to let you know that I've just added the patch titled
phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled
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:
phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.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 cd6f769fdea7ff7d77a6cc97658c60ca0b836d0e Mon Sep 17 00:00:00 2001
From: Al Cooper <al.cooper(a)broadcom.com>
Date: Wed, 27 Dec 2017 14:28:50 -0500
Subject: phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled
From: Al Cooper <al.cooper(a)broadcom.com>
commit cd6f769fdea7ff7d77a6cc97658c60ca0b836d0e upstream.
Set PHY3_IDDQ_OVERRIDE in the xhci uninit routine. This will save
additional power when the XHCI driver is not enabled.
Fixes: 49859e55e364 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver")
Signed-off-by: Al Cooper <alcooperx(a)gmail.com>
Acked-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/phy/broadcom/phy-brcm-usb-init.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/phy/broadcom/phy-brcm-usb-init.c
+++ b/drivers/phy/broadcom/phy-brcm-usb-init.c
@@ -73,6 +73,7 @@
#define USB_CTRL_USB30_CTL1_USB3_IPP_MASK 0x20000000 /* option */
#define USB_CTRL_USB30_PCTL 0x70
#define USB_CTRL_USB30_PCTL_PHY3_SOFT_RESETB_MASK 0x00000002
+#define USB_CTRL_USB30_PCTL_PHY3_IDDQ_OVERRIDE_MASK 0x00008000
#define USB_CTRL_USB30_PCTL_PHY3_SOFT_RESETB_P1_MASK 0x00020000
#define USB_CTRL_USB_DEVICE_CTL1 0x90
#define USB_CTRL_USB_DEVICE_CTL1_PORT_MODE_MASK 0x00000003 /* option */
@@ -999,6 +1000,7 @@ void brcm_usb_uninit_eohci(struct brcm_u
void brcm_usb_uninit_xhci(struct brcm_usb_init_params *params)
{
brcmusb_xhci_soft_reset(params, 1);
+ USB_CTRL_SET(params->ctrl_regs, USB30_PCTL, PHY3_IDDQ_OVERRIDE);
}
void brcm_usb_set_family_map(struct brcm_usb_init_params *params)
Patches currently in stable-queue which might be from al.cooper(a)broadcom.com are
queue-4.15/phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch
queue-4.15/phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch
queue-4.15/phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch
This is a note to let you know that I've just added the patch titled
phy: phy-brcm-usb: Fix two DT properties to match bindings doc
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:
phy-phy-brcm-usb-fix-two-dt-properties-to-match-bindings-doc.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 5e498ff117c19fd80181b5bb09ecb024b552ece8 Mon Sep 17 00:00:00 2001
From: Al Cooper <alcooperx(a)gmail.com>
Date: Wed, 27 Dec 2017 14:28:48 -0500
Subject: phy: phy-brcm-usb: Fix two DT properties to match bindings doc
From: Al Cooper <alcooperx(a)gmail.com>
commit 5e498ff117c19fd80181b5bb09ecb024b552ece8 upstream.
Change "brcm,has_xhci" and "brcm,has_eohci" device tree properties
to the preferred "brcm,has-xhci" and "brcm,has-eohci". This also
matches the existing device tree bindings document.
Fixes: 49859e55e364 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver")
Signed-off-by: Al Cooper <alcooperx(a)gmail.com>
Acked-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/phy/broadcom/phy-brcm-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/phy/broadcom/phy-brcm-usb.c
+++ b/drivers/phy/broadcom/phy-brcm-usb.c
@@ -338,9 +338,9 @@ static int brcm_usb_phy_probe(struct pla
ARRAY_SIZE(brcm_dr_mode_to_name),
mode, &priv->ini.mode);
}
- if (of_property_read_bool(dn, "brcm,has_xhci"))
+ if (of_property_read_bool(dn, "brcm,has-xhci"))
priv->has_xhci = true;
- if (of_property_read_bool(dn, "brcm,has_eohci"))
+ if (of_property_read_bool(dn, "brcm,has-eohci"))
priv->has_eohci = true;
err = brcm_usb_phy_dvr_init(dev, priv, dn);
Patches currently in stable-queue which might be from alcooperx(a)gmail.com are
queue-4.15/phy-phy-brcm-usb-fix-two-dt-properties-to-match-bindings-doc.patch
queue-4.15/phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch
queue-4.15/phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch
queue-4.15/phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch
This is a note to let you know that I've just added the patch titled
dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding
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:
dt-bindings-usb-fix-the-stm32f7-dwc2-otg-hs-core-binding.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 4c437920fa216f66f6a5d469cae2a0360cc2d9c7 Mon Sep 17 00:00:00 2001
From: Amelie Delaunay <amelie.delaunay(a)st.com>
Date: Thu, 1 Mar 2018 11:05:34 +0100
Subject: dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding
From: Amelie Delaunay <amelie.delaunay(a)st.com>
commit 4c437920fa216f66f6a5d469cae2a0360cc2d9c7 upstream.
This patch fixes binding documentation for DWC2 controller in HS mode
found on STMicroelectronics STM32F7 SoC.
The v2 former patch [1] had been acked by Rob Herring, but v1 was merged.
[1] https://patchwork.kernel.org/patch/9925575/
Fixes: 000777dadc7e ("dt-bindings: usb: Document the STM32F7xx DWC2 ...")
Signed-off-by: Amelie Delaunay <amelie.delaunay(a)st.com>
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -19,7 +19,7 @@ Required properties:
configured in FS mode;
- "st,stm32f4x9-hsotg": The DWC2 USB HS controller instance in STM32F4x9 SoCs
configured in HS mode;
- - "st,stm32f7xx-hsotg": The DWC2 USB HS controller instance in STM32F7xx SoCs
+ - "st,stm32f7-hsotg": The DWC2 USB HS controller instance in STM32F7 SoCs
configured in HS mode;
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
Patches currently in stable-queue which might be from amelie.delaunay(a)st.com are
queue-4.15/usb-dwc2-fix-stm32f7-usb-otg-hs-compatible.patch
queue-4.15/dt-bindings-usb-fix-the-stm32f7-dwc2-otg-hs-core-binding.patch
This is a note to let you know that I've just added the patch titled
USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
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:
usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.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 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Tue, 23 Jan 2018 09:35:14 +0000
Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
From: Wei Yongjun <weiyongjun1(a)huawei.com>
commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream.
Add the missing platform_device_put() before return from bdc_pci_probe()
in the platform_device_add_resources() error handling case.
Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c
@@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_dev
if (ret) {
dev_err(&pci->dev,
"couldn't add resources to bdc device\n");
+ platform_device_put(bdc);
return ret;
}
Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are
queue-4.14/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
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:
usb-dwc3-fix-gdbgfifospace_type-values.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 b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 2 Feb 2018 13:21:35 -0800
Subject: usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream.
The FIFO/Queue type values are incorrect. Correct them according to
DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25).
Additionally, this patch includes ProtocolStatusQ and AuxEventQ types.
Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/core.h | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -166,13 +166,15 @@
#define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
#define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0xffff)
-#define DWC3_TXFIFOQ 1
-#define DWC3_RXFIFOQ 3
-#define DWC3_TXREQQ 5
-#define DWC3_RXREQQ 7
-#define DWC3_RXINFOQ 9
-#define DWC3_DESCFETCHQ 13
-#define DWC3_EVENTQ 15
+#define DWC3_TXFIFOQ 0
+#define DWC3_RXFIFOQ 1
+#define DWC3_TXREQQ 2
+#define DWC3_RXREQQ 3
+#define DWC3_RXINFOQ 4
+#define DWC3_PSTATQ 5
+#define DWC3_DESCFETCHQ 6
+#define DWC3_EVENTQ 7
+#define DWC3_AUXEVENTQ 8
/* Global RX Threshold Configuration Register */
#define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-4.14/usb-dwc3-fix-gdbgfifospace_type-values.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que
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:
scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.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 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 Mon Sep 17 00:00:00 2001
From: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Date: Sat, 16 Dec 2017 16:05:09 -0800
Subject: scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que
From: Himanshu Madhani <himanshu.madhani(a)cavium.com>
commit 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 upstream.
This patch fixes following warnings reported by smatch:
drivers/scsi/qla2xxx/qla_mid.c:586 qla25xx_delete_req_que()
error: we previously assumed 'req' could be null (see line 580)
drivers/scsi/qla2xxx/qla_mid.c:602 qla25xx_delete_rsp_que()
error: we previously assumed 'rsp' could be null (see line 596)
Fixes: 7867b98dceb7 ("scsi: qla2xxx: Fix memory leak in dual/target mode")
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_mid.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_mid.c
+++ b/drivers/scsi/qla2xxx/qla_mid.c
@@ -582,8 +582,9 @@ qla25xx_delete_req_que(struct scsi_qla_h
ret = qla25xx_init_req_que(vha, req);
if (ret != QLA_SUCCESS)
return QLA_FUNCTION_FAILED;
+
+ qla25xx_free_req_que(vha, req);
}
- qla25xx_free_req_que(vha, req);
return ret;
}
@@ -598,8 +599,9 @@ qla25xx_delete_rsp_que(struct scsi_qla_h
ret = qla25xx_init_rsp_que(vha, rsp);
if (ret != QLA_SUCCESS)
return QLA_FUNCTION_FAILED;
+
+ qla25xx_free_rsp_que(vha, rsp);
}
- qla25xx_free_rsp_que(vha, rsp);
return ret;
}
Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are
queue-4.14/scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch
queue-4.14/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch
queue-4.14/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix logo flag for qlt_free_session_done()
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:
scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.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 a2390348c19d0819d525d375414a7cfdacb51a68 Mon Sep 17 00:00:00 2001
From: Himanshu Madhani <hmadhani(a)redhat.com>
Date: Mon, 22 Jan 2018 12:04:20 -0800
Subject: scsi: qla2xxx: Fix logo flag for qlt_free_session_done()
From: Himanshu Madhani <hmadhani(a)redhat.com>
commit a2390348c19d0819d525d375414a7cfdacb51a68 upstream.
Commit 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target
re-login.")fixed the target re-login after session relogin is complete,
but missed out the qlt_free_session_done() path.
This patch clears send_els_logo flag in qlt_free_session_done()
callback.
[mkp: checkpatch]
Fixes: 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.")
Signed-off-by: Himanshu Madhani <hmadhani(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_target.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -971,6 +971,7 @@ static void qlt_free_session_done(struct
logo.id = sess->d_id;
logo.cmd_count = 0;
+ sess->send_els_logo = 0;
qlt_send_first_logo(vha, &logo);
}
Patches currently in stable-queue which might be from hmadhani(a)redhat.com are
queue-4.14/scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch
This is a note to let you know that I've just added the patch titled
scsi: qla2xxx: Fix NULL pointer access for fcport structure
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:
scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.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 5c25d451163cab9be80744cbc5448d6b95ab8d1a Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Thu, 28 Dec 2017 12:33:09 -0800
Subject: scsi: qla2xxx: Fix NULL pointer access for fcport structure
From: Quinn Tran <quinn.tran(a)cavium.com>
commit 5c25d451163cab9be80744cbc5448d6b95ab8d1a upstream.
when processing iocb in a timeout case, driver was trying to log messages
without verifying if the fcport structure could have valid data. This
results in a NULL pointer access.
Fixes: 726b85487067("qla2xxx: Add framework for async fabric discovery")
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_init.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -102,11 +102,16 @@ qla2x00_async_iocb_timeout(void *data)
struct srb_iocb *lio = &sp->u.iocb_cmd;
struct event_arg ea;
- ql_dbg(ql_dbg_disc, fcport->vha, 0x2071,
- "Async-%s timeout - hdl=%x portid=%06x %8phC.\n",
- sp->name, sp->handle, fcport->d_id.b24, fcport->port_name);
+ if (fcport) {
+ ql_dbg(ql_dbg_disc, fcport->vha, 0x2071,
+ "Async-%s timeout - hdl=%x portid=%06x %8phC.\n",
+ sp->name, sp->handle, fcport->d_id.b24, fcport->port_name);
- fcport->flags &= ~FCF_ASYNC_SENT;
+ fcport->flags &= ~FCF_ASYNC_SENT;
+ } else {
+ pr_info("Async-%s timeout - hdl=%x.\n",
+ sp->name, sp->handle);
+ }
switch (sp->type) {
case SRB_LOGIN_CMD:
Patches currently in stable-queue which might be from quinn.tran(a)cavium.com are
queue-4.14/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch
(CC: davem, soheil & gregkh)
On 03/17/18 20:12, Holger Hoffstätte wrote:
> On 03/17/18 19:41, Carlos Carvalho wrote:
>> I've put 4.14.27 this morning in this machine and in about 2h it started
>> showing null dereferences identical to the following one. There were several of
>> them, with about 1/2h of interval. Strangely it continued to work and I saw no
>> other anomalies. I've just reverted to 4.14.26.
>>
>> It only happened in this machine, which has a net traffic of several Gb/s and
>> thousands of simultaneous connections.
>>
>> Mar 17 13:29:21 sagres kernel: : BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
>> Mar 17 13:29:21 sagres kernel: : IP: tcp_push+0x4e/0xe7
>> Mar 17 13:29:21 sagres kernel: : PGD 0 P4D 0
>> Mar 17 13:29:21 sagres kernel: : Oops: 0002 [#1] SMP PTI
>> Mar 17 13:29:21 sagres kernel: : CPU: 55 PID: 2658 Comm: apache2 Not tainted 4.14.27 #4
(snip)
>
> Fixed by: https://www.spinics.net/lists/netdev/msg489445.html
>
> -h
>
This patch is in the netdev patchwork at https://patchwork.ozlabs.org/patch/886324/
but has been marked as "not applicable" without further queued/rejected comment
from Dave, so I believe it became a victim of email lossage.
As the patch says it doesn't apply to anything older than 4.14, but it has been
tested & reported by several people as fixing the problem, and indeed works
fine. Since GregKH only accepts net patches from Dave I wanted to make sure
it got queued up for 4.14.
Thanks,
Holger
Quoting Eric Anholt (2018-03-13 09:56:57)
> Stephen Boyd <sboyd(a)kernel.org> writes:
> >
> > What exactly is going on here? It sounds like the framework isn't aware
> > of the 'on/off' boot state of certain clks (a known problem) and that's
> > causing some sort of problem when changing rates? This usually happens
> > with PLLs that are enabled at boot time and can't support their rate
> > changing when they're enabled. We really should start reading on/off
> > state and "hand off" that enabled state to something in the framework so
> > we at least know if a clk is enabled or not out of boot. There was some
> > work on clk handoff done a while ago by Mike that never landed which may
> > be useful to finish this off. Maybe we can pass that enabled state off
> > to the clk we always create for a clk_hw structure at registration time
> > and then have clk_disable_unused operate on that clk pointer at late
> > init.
>
> Yes, the usual problem of clk not handling boot-time clock state well.
>
> That said, it's patch 1 that's critical for fixing many of our users,
> and we need that in as soon as possible. #2 is also reviewed and ready.
Got it. I'll pick up the first two then.
This is a note to let you know that I've just added the patch titled
btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
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:
btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.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 fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 30 Jan 2018 16:07:37 +0200
Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
From: Nikolay Borisov <nborisov(a)suse.com>
commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream.
Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced
btrfs_free_stale_device which iterates the device lists for all
registered btrfs filesystems and deletes those devices which aren't
mounted. In a btrfs_devices structure has only 1 device attached to it
and it is unused then btrfs_free_stale_devices will proceed to also free
the btrfs_fs_devices struct itself. Currently this leads to a use after
free since list_for_each_entry will try to perform a check on the
already freed memory to see if it has to terminate the loop.
The fix is to use 'break' when we know we are freeing the current
fs_devs.
Fixes: 4fde46f0cc71 ("Btrfs: free the stale device")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Anand Jain <anand.jain(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -583,6 +583,7 @@ void btrfs_free_stale_device(struct btrf
btrfs_sysfs_remove_fsid(fs_devs);
list_del(&fs_devs->list);
free_fs_devices(fs_devs);
+ break;
} else {
fs_devs->num_devices--;
list_del(&dev->dev_list);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.9/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: alloc_chunk: fix DUP stripe size handling
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:
btrfs-alloc_chunk-fix-dup-stripe-size-handling.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 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Date: Mon, 5 Feb 2018 17:45:11 +0100
Subject: btrfs: alloc_chunk: fix DUP stripe size handling
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
commit 92e222df7b8f05c565009c7383321b593eca488b upstream.
In case of using DUP, we search for enough unallocated disk space on a
device to hold two stripes.
The devices_info[ndevs-1].max_avail that holds the amount of unallocated
space found is directly assigned to stripe_size, while it's actually
twice the stripe size.
Later on in the code, an unconditional division of stripe_size by
dev_stripes corrects the value, but in the meantime there's a check to
see if the stripe_size does not exceed max_chunk_size. Since during this
check stripe_size is twice the amount as intended, the check will reduce
the stripe_size to max_chunk_size if the actual correct to be used
stripe_size is more than half the amount of max_chunk_size.
The unconditional division later tries to correct stripe_size, but will
actually make sure we can't allocate more than half the max_chunk_size.
Fix this by moving the division by dev_stripes before the max chunk size
check, so it always contains the right value, instead of putting a duct
tape division in further on to get it fixed again.
Since in all other cases than DUP, dev_stripes is 1, this change only
affects DUP.
Other attempts in the past were made to fix this:
* 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried
to fix the same problem, but still resulted in part of the code acting
on a wrongly doubled stripe_size value.
* 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally
broke this fix again.
The real problem was already introduced with the rest of the code in
73c5de0051.
The user visible result however will be that the max chunk size for DUP
will suddenly double, while it's actually acting according to the limits
in the code again like it was 5 years ago.
Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com>
Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html
Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation")
Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6")
Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ update comment ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4748,10 +4748,13 @@ static int __btrfs_alloc_chunk(struct bt
if (devs_max && ndevs > devs_max)
ndevs = devs_max;
/*
- * the primary goal is to maximize the number of stripes, so use as many
- * devices as possible, even if the stripes are not maximum sized.
+ * The primary goal is to maximize the number of stripes, so use as
+ * many devices as possible, even if the stripes are not maximum sized.
+ *
+ * The DUP profile stores more than one stripe per device, the
+ * max_avail is the total size so we have to adjust.
*/
- stripe_size = devices_info[ndevs-1].max_avail;
+ stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes);
num_stripes = ndevs * dev_stripes;
/*
@@ -4791,8 +4794,6 @@ static int __btrfs_alloc_chunk(struct bt
stripe_size = devices_info[ndevs-1].max_avail;
}
- stripe_size = div_u64(stripe_size, dev_stripes);
-
/* align to BTRFS_STRIPE_LEN */
stripe_size = div_u64(stripe_size, raid_stripe_len);
stripe_size *= raid_stripe_len;
Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are
queue-4.9/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
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:
btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.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 fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 30 Jan 2018 16:07:37 +0200
Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
From: Nikolay Borisov <nborisov(a)suse.com>
commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream.
Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced
btrfs_free_stale_device which iterates the device lists for all
registered btrfs filesystems and deletes those devices which aren't
mounted. In a btrfs_devices structure has only 1 device attached to it
and it is unused then btrfs_free_stale_devices will proceed to also free
the btrfs_fs_devices struct itself. Currently this leads to a use after
free since list_for_each_entry will try to perform a check on the
already freed memory to see if it has to terminate the loop.
The fix is to use 'break' when we know we are freeing the current
fs_devs.
Fixes: 4fde46f0cc71 ("Btrfs: free the stale device")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Anand Jain <anand.jain(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -568,6 +568,7 @@ void btrfs_free_stale_device(struct btrf
btrfs_sysfs_remove_fsid(fs_devs);
list_del(&fs_devs->list);
free_fs_devices(fs_devs);
+ break;
} else {
fs_devs->num_devices--;
list_del(&dev->dev_list);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.4/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: alloc_chunk: fix DUP stripe size handling
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:
btrfs-alloc_chunk-fix-dup-stripe-size-handling.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 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Date: Mon, 5 Feb 2018 17:45:11 +0100
Subject: btrfs: alloc_chunk: fix DUP stripe size handling
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
commit 92e222df7b8f05c565009c7383321b593eca488b upstream.
In case of using DUP, we search for enough unallocated disk space on a
device to hold two stripes.
The devices_info[ndevs-1].max_avail that holds the amount of unallocated
space found is directly assigned to stripe_size, while it's actually
twice the stripe size.
Later on in the code, an unconditional division of stripe_size by
dev_stripes corrects the value, but in the meantime there's a check to
see if the stripe_size does not exceed max_chunk_size. Since during this
check stripe_size is twice the amount as intended, the check will reduce
the stripe_size to max_chunk_size if the actual correct to be used
stripe_size is more than half the amount of max_chunk_size.
The unconditional division later tries to correct stripe_size, but will
actually make sure we can't allocate more than half the max_chunk_size.
Fix this by moving the division by dev_stripes before the max chunk size
check, so it always contains the right value, instead of putting a duct
tape division in further on to get it fixed again.
Since in all other cases than DUP, dev_stripes is 1, this change only
affects DUP.
Other attempts in the past were made to fix this:
* 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried
to fix the same problem, but still resulted in part of the code acting
on a wrongly doubled stripe_size value.
* 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally
broke this fix again.
The real problem was already introduced with the rest of the code in
73c5de0051.
The user visible result however will be that the max chunk size for DUP
will suddenly double, while it's actually acting according to the limits
in the code again like it was 5 years ago.
Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com>
Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html
Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation")
Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6")
Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ update comment ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4638,10 +4638,13 @@ static int __btrfs_alloc_chunk(struct bt
if (devs_max && ndevs > devs_max)
ndevs = devs_max;
/*
- * the primary goal is to maximize the number of stripes, so use as many
- * devices as possible, even if the stripes are not maximum sized.
+ * The primary goal is to maximize the number of stripes, so use as
+ * many devices as possible, even if the stripes are not maximum sized.
+ *
+ * The DUP profile stores more than one stripe per device, the
+ * max_avail is the total size so we have to adjust.
*/
- stripe_size = devices_info[ndevs-1].max_avail;
+ stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes);
num_stripes = ndevs * dev_stripes;
/*
@@ -4681,8 +4684,6 @@ static int __btrfs_alloc_chunk(struct bt
stripe_size = devices_info[ndevs-1].max_avail;
}
- stripe_size = div_u64(stripe_size, dev_stripes);
-
/* align to BTRFS_STRIPE_LEN */
stripe_size = div_u64(stripe_size, raid_stripe_len);
stripe_size *= raid_stripe_len;
Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are
queue-4.4/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch
This is a note to let you know that I've just added the patch titled
btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes
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:
btrfs-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.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 c8195a7b1ad5648857ce20ba24f384faed8512bc Mon Sep 17 00:00:00 2001
From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
Date: Tue, 23 Jan 2018 22:22:09 -0500
Subject: btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes
From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
commit c8195a7b1ad5648857ce20ba24f384faed8512bc upstream.
Until v4.14, this warning was very infrequent:
WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0
Modules linked in: [...]
CPU: 3 PID: 18172 Comm: bees Tainted: G D W L 4.11.9-zb64+ #1
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2101 12/02/2014
Call Trace:
dump_stack+0x85/0xc2
__warn+0xd1/0xf0
warn_slowpath_null+0x1d/0x20
find_parent_nodes+0xc41/0x14e0
__btrfs_find_all_roots+0xad/0x120
? extent_same_check_offsets+0x70/0x70
iterate_extent_inodes+0x168/0x300
iterate_inodes_from_logical+0x87/0xb0
? iterate_inodes_from_logical+0x87/0xb0
? extent_same_check_offsets+0x70/0x70
btrfs_ioctl+0x8ac/0x2820
? lock_acquire+0xc2/0x200
do_vfs_ioctl+0x91/0x700
? __fget+0x112/0x200
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x23/0xc6
? trace_hardirqs_off_caller+0x1f/0x140
Starting with v4.14 (specifically 86d5f9944252 ("btrfs: convert prelimary
reference tracking to use rbtrees")) the WARN_ON occurs three orders of
magnitude more frequently--almost once per second while running workloads
like bees.
Replace the WARN_ON() with a comment rationale for its removal.
The rationale is paraphrased from an explanation by Edmund Nadolski
<enadolski(a)suse.de> on the linux-btrfs mailing list.
Fixes: 8da6d5815c59 ("Btrfs: added btrfs_find_all_roots()")
Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
Reviewed-by: Lu Fengqi <lufq.fnst(a)cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/backref.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1263,7 +1263,16 @@ again:
while (node) {
ref = rb_entry(node, struct prelim_ref, rbnode);
node = rb_next(&ref->rbnode);
- WARN_ON(ref->count < 0);
+ /*
+ * ref->count < 0 can happen here if there are delayed
+ * refs with a node->action of BTRFS_DROP_DELAYED_REF.
+ * prelim_ref_insert() relies on this when merging
+ * identical refs to keep the overall count correct.
+ * prelim_ref_insert() will merge only those refs
+ * which compare identically. Any refs having
+ * e.g. different offsets would not be merged,
+ * and would retain their original ref->count < 0.
+ */
if (roots && ref->count && ref->root_id && ref->parent == 0) {
if (sc && sc->root_objectid &&
ref->root_id != sc->root_objectid) {
Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are
queue-4.15/btrfs-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
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:
btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.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 fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 30 Jan 2018 16:07:37 +0200
Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
From: Nikolay Borisov <nborisov(a)suse.com>
commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream.
Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced
btrfs_free_stale_device which iterates the device lists for all
registered btrfs filesystems and deletes those devices which aren't
mounted. In a btrfs_devices structure has only 1 device attached to it
and it is unused then btrfs_free_stale_devices will proceed to also free
the btrfs_fs_devices struct itself. Currently this leads to a use after
free since list_for_each_entry will try to perform a check on the
already freed memory to see if it has to terminate the loop.
The fix is to use 'break' when we know we are freeing the current
fs_devs.
Fixes: 4fde46f0cc71 ("Btrfs: free the stale device")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Anand Jain <anand.jain(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -574,6 +574,7 @@ static void btrfs_free_stale_device(stru
btrfs_sysfs_remove_fsid(fs_devs);
list_del(&fs_devs->list);
free_fs_devices(fs_devs);
+ break;
} else {
fs_devs->num_devices--;
list_del(&dev->dev_list);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.15/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch
queue-4.15/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix memory barriers usage with device stats counters
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:
btrfs-fix-memory-barriers-usage-with-device-stats-counters.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 9deae9689231964972a94bb56a79b669f9d47ac1 Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 24 Oct 2017 13:47:37 +0300
Subject: btrfs: Fix memory barriers usage with device stats counters
From: Nikolay Borisov <nborisov(a)suse.com>
commit 9deae9689231964972a94bb56a79b669f9d47ac1 upstream.
Commit addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev
stats is cleared") reworked the way device stats changes are tracked. A
new atomic dev_stats_ccnt counter was introduced which is incremented
every time any of the device stats counters are changed. This serves as
a flag whether there are any pending stats changes. However, this patch
only partially implemented the correct memory barriers necessary:
- It only ordered the stores to the counters but not the reads e.g.
btrfs_run_dev_stats
- It completely omitted any comments documenting the intended design and
how the memory barriers pair with each-other
This patch provides the necessary comments as well as adds a missing
smp_rmb in btrfs_run_dev_stats. Furthermore since dev_stats_cnt is only
a snapshot at best there was no point in reading the counter twice -
once in btrfs_dev_stats_dirty and then again when assigning stats_cnt.
Just collapse both reads into 1.
Fixes: addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats is cleared")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.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/volumes.c | 18 ++++++++++++++++--
fs/btrfs/volumes.h | 12 ++++++++++++
2 files changed, 28 insertions(+), 2 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -7093,10 +7093,24 @@ int btrfs_run_dev_stats(struct btrfs_tra
mutex_lock(&fs_devices->device_list_mutex);
list_for_each_entry(device, &fs_devices->devices, dev_list) {
- if (!device->dev_stats_valid || !btrfs_dev_stats_dirty(device))
+ stats_cnt = atomic_read(&device->dev_stats_ccnt);
+ if (!device->dev_stats_valid || stats_cnt == 0)
continue;
- stats_cnt = atomic_read(&device->dev_stats_ccnt);
+
+ /*
+ * There is a LOAD-LOAD control dependency between the value of
+ * dev_stats_ccnt and updating the on-disk values which requires
+ * reading the in-memory counters. Such control dependencies
+ * require explicit read memory barriers.
+ *
+ * This memory barriers pairs with smp_mb__before_atomic in
+ * btrfs_dev_stat_inc/btrfs_dev_stat_set and with the full
+ * barrier implied by atomic_xchg in
+ * btrfs_dev_stats_read_and_reset
+ */
+ smp_rmb();
+
ret = update_dev_stat_item(trans, fs_info, device);
if (!ret)
atomic_sub(stats_cnt, &device->dev_stats_ccnt);
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -498,6 +498,12 @@ static inline void btrfs_dev_stat_inc(st
int index)
{
atomic_inc(dev->dev_stat_values + index);
+ /*
+ * This memory barrier orders stores updating statistics before stores
+ * updating dev_stats_ccnt.
+ *
+ * It pairs with smp_rmb() in btrfs_run_dev_stats().
+ */
smp_mb__before_atomic();
atomic_inc(&dev->dev_stats_ccnt);
}
@@ -523,6 +529,12 @@ static inline void btrfs_dev_stat_set(st
int index, unsigned long val)
{
atomic_set(dev->dev_stat_values + index, val);
+ /*
+ * This memory barrier orders stores updating statistics before stores
+ * updating dev_stats_ccnt.
+ *
+ * It pairs with smp_rmb() in btrfs_run_dev_stats().
+ */
smp_mb__before_atomic();
atomic_inc(&dev->dev_stats_ccnt);
}
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.15/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch
queue-4.15/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: alloc_chunk: fix DUP stripe size handling
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:
btrfs-alloc_chunk-fix-dup-stripe-size-handling.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 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Date: Mon, 5 Feb 2018 17:45:11 +0100
Subject: btrfs: alloc_chunk: fix DUP stripe size handling
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
commit 92e222df7b8f05c565009c7383321b593eca488b upstream.
In case of using DUP, we search for enough unallocated disk space on a
device to hold two stripes.
The devices_info[ndevs-1].max_avail that holds the amount of unallocated
space found is directly assigned to stripe_size, while it's actually
twice the stripe size.
Later on in the code, an unconditional division of stripe_size by
dev_stripes corrects the value, but in the meantime there's a check to
see if the stripe_size does not exceed max_chunk_size. Since during this
check stripe_size is twice the amount as intended, the check will reduce
the stripe_size to max_chunk_size if the actual correct to be used
stripe_size is more than half the amount of max_chunk_size.
The unconditional division later tries to correct stripe_size, but will
actually make sure we can't allocate more than half the max_chunk_size.
Fix this by moving the division by dev_stripes before the max chunk size
check, so it always contains the right value, instead of putting a duct
tape division in further on to get it fixed again.
Since in all other cases than DUP, dev_stripes is 1, this change only
affects DUP.
Other attempts in the past were made to fix this:
* 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried
to fix the same problem, but still resulted in part of the code acting
on a wrongly doubled stripe_size value.
* 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally
broke this fix again.
The real problem was already introduced with the rest of the code in
73c5de0051.
The user visible result however will be that the max chunk size for DUP
will suddenly double, while it's actually acting according to the limits
in the code again like it was 5 years ago.
Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com>
Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html
Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation")
Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6")
Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ update comment ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4737,10 +4737,13 @@ static int __btrfs_alloc_chunk(struct bt
ndevs = min(ndevs, devs_max);
/*
- * the primary goal is to maximize the number of stripes, so use as many
- * devices as possible, even if the stripes are not maximum sized.
+ * The primary goal is to maximize the number of stripes, so use as
+ * many devices as possible, even if the stripes are not maximum sized.
+ *
+ * The DUP profile stores more than one stripe per device, the
+ * max_avail is the total size so we have to adjust.
*/
- stripe_size = devices_info[ndevs-1].max_avail;
+ stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes);
num_stripes = ndevs * dev_stripes;
/*
@@ -4775,8 +4778,6 @@ static int __btrfs_alloc_chunk(struct bt
stripe_size = devices_info[ndevs-1].max_avail;
}
- stripe_size = div_u64(stripe_size, dev_stripes);
-
/* align to BTRFS_STRIPE_LEN */
stripe_size = round_down(stripe_size, BTRFS_STRIPE_LEN);
Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are
queue-4.15/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch
This is a note to let you know that I've just added the patch titled
btrfs: add missing initialization in btrfs_check_shared
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:
btrfs-add-missing-initialization-in-btrfs_check_shared.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 18bf591ba9753e3e5ba91f38f756a800693408f4 Mon Sep 17 00:00:00 2001
From: Edmund Nadolski <enadolski(a)suse.com>
Date: Wed, 14 Mar 2018 09:03:11 -0600
Subject: btrfs: add missing initialization in btrfs_check_shared
From: Edmund Nadolski <enadolski(a)suse.com>
commit 18bf591ba9753e3e5ba91f38f756a800693408f4 upstream.
This patch addresses an issue that causes fiemap to falsely
report a shared extent. The test case is as follows:
xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5
sync
xfs_io -c "fiemap -v" /media/scratch/file5
which gives the resulting output:
wrote 65536/65536 bytes at offset 0
64 KiB, 4 ops; 0.0000 sec (121.359 MiB/sec and 7766.9903 ops/sec)
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x2001
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
This is because btrfs_check_shared calls find_parent_nodes
repeatedly in a loop, passing a share_check struct to report
the count of shared extent. But btrfs_check_shared does not
re-initialize the count value to zero for subsequent calls
from the loop, resulting in a false share count value. This
is a regressive behavior from 4.13.
With proper re-initialization the test result is as follows:
wrote 65536/65536 bytes at offset 0
64 KiB, 4 ops; 0.0000 sec (110.035 MiB/sec and 7042.2535 ops/sec)
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
which corrects the regression.
Fixes: 3ec4d3238ab ("btrfs: allow backref search checks for shared extents")
Signed-off-by: Edmund Nadolski <enadolski(a)suse.com>
[ add text from cover letter to changelog ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/backref.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1509,6 +1509,7 @@ int btrfs_check_shared(struct btrfs_root
if (!node)
break;
bytenr = node->val;
+ shared.share_count = 0;
cond_resched();
}
Patches currently in stable-queue which might be from enadolski(a)suse.com are
queue-4.15/btrfs-add-missing-initialization-in-btrfs_check_shared.patch
This is a note to let you know that I've just added the patch titled
btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes
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-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.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 c8195a7b1ad5648857ce20ba24f384faed8512bc Mon Sep 17 00:00:00 2001
From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
Date: Tue, 23 Jan 2018 22:22:09 -0500
Subject: btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes
From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
commit c8195a7b1ad5648857ce20ba24f384faed8512bc upstream.
Until v4.14, this warning was very infrequent:
WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0
Modules linked in: [...]
CPU: 3 PID: 18172 Comm: bees Tainted: G D W L 4.11.9-zb64+ #1
Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2101 12/02/2014
Call Trace:
dump_stack+0x85/0xc2
__warn+0xd1/0xf0
warn_slowpath_null+0x1d/0x20
find_parent_nodes+0xc41/0x14e0
__btrfs_find_all_roots+0xad/0x120
? extent_same_check_offsets+0x70/0x70
iterate_extent_inodes+0x168/0x300
iterate_inodes_from_logical+0x87/0xb0
? iterate_inodes_from_logical+0x87/0xb0
? extent_same_check_offsets+0x70/0x70
btrfs_ioctl+0x8ac/0x2820
? lock_acquire+0xc2/0x200
do_vfs_ioctl+0x91/0x700
? __fget+0x112/0x200
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x23/0xc6
? trace_hardirqs_off_caller+0x1f/0x140
Starting with v4.14 (specifically 86d5f9944252 ("btrfs: convert prelimary
reference tracking to use rbtrees")) the WARN_ON occurs three orders of
magnitude more frequently--almost once per second while running workloads
like bees.
Replace the WARN_ON() with a comment rationale for its removal.
The rationale is paraphrased from an explanation by Edmund Nadolski
<enadolski(a)suse.de> on the linux-btrfs mailing list.
Fixes: 8da6d5815c59 ("Btrfs: added btrfs_find_all_roots()")
Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
Reviewed-by: Lu Fengqi <lufq.fnst(a)cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/backref.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1252,7 +1252,16 @@ again:
while (node) {
ref = rb_entry(node, struct prelim_ref, rbnode);
node = rb_next(&ref->rbnode);
- WARN_ON(ref->count < 0);
+ /*
+ * ref->count < 0 can happen here if there are delayed
+ * refs with a node->action of BTRFS_DROP_DELAYED_REF.
+ * prelim_ref_insert() relies on this when merging
+ * identical refs to keep the overall count correct.
+ * prelim_ref_insert() will merge only those refs
+ * which compare identically. Any refs having
+ * e.g. different offsets would not be merged,
+ * and would retain their original ref->count < 0.
+ */
if (roots && ref->count && ref->root_id && ref->parent == 0) {
if (sc && sc->root_objectid &&
ref->root_id != sc->root_objectid) {
Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are
queue-4.14/btrfs-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
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-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.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 fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 30 Jan 2018 16:07:37 +0200
Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
From: Nikolay Borisov <nborisov(a)suse.com>
commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream.
Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced
btrfs_free_stale_device which iterates the device lists for all
registered btrfs filesystems and deletes those devices which aren't
mounted. In a btrfs_devices structure has only 1 device attached to it
and it is unused then btrfs_free_stale_devices will proceed to also free
the btrfs_fs_devices struct itself. Currently this leads to a use after
free since list_for_each_entry will try to perform a check on the
already freed memory to see if it has to terminate the loop.
The fix is to use 'break' when we know we are freeing the current
fs_devs.
Fixes: 4fde46f0cc71 ("Btrfs: free the stale device")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Anand Jain <anand.jain(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -589,6 +589,7 @@ void btrfs_free_stale_device(struct btrf
btrfs_sysfs_remove_fsid(fs_devs);
list_del(&fs_devs->list);
free_fs_devices(fs_devs);
+ break;
} else {
fs_devs->num_devices--;
list_del(&dev->dev_list);
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch
queue-4.14/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix memory barriers usage with device stats counters
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-memory-barriers-usage-with-device-stats-counters.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 9deae9689231964972a94bb56a79b669f9d47ac1 Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 24 Oct 2017 13:47:37 +0300
Subject: btrfs: Fix memory barriers usage with device stats counters
From: Nikolay Borisov <nborisov(a)suse.com>
commit 9deae9689231964972a94bb56a79b669f9d47ac1 upstream.
Commit addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev
stats is cleared") reworked the way device stats changes are tracked. A
new atomic dev_stats_ccnt counter was introduced which is incremented
every time any of the device stats counters are changed. This serves as
a flag whether there are any pending stats changes. However, this patch
only partially implemented the correct memory barriers necessary:
- It only ordered the stores to the counters but not the reads e.g.
btrfs_run_dev_stats
- It completely omitted any comments documenting the intended design and
how the memory barriers pair with each-other
This patch provides the necessary comments as well as adds a missing
smp_rmb in btrfs_run_dev_stats. Furthermore since dev_stats_cnt is only
a snapshot at best there was no point in reading the counter twice -
once in btrfs_dev_stats_dirty and then again when assigning stats_cnt.
Just collapse both reads into 1.
Fixes: addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats is cleared")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.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/volumes.c | 18 ++++++++++++++++--
fs/btrfs/volumes.h | 12 ++++++++++++
2 files changed, 28 insertions(+), 2 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -7082,10 +7082,24 @@ int btrfs_run_dev_stats(struct btrfs_tra
mutex_lock(&fs_devices->device_list_mutex);
list_for_each_entry(device, &fs_devices->devices, dev_list) {
- if (!device->dev_stats_valid || !btrfs_dev_stats_dirty(device))
+ stats_cnt = atomic_read(&device->dev_stats_ccnt);
+ if (!device->dev_stats_valid || stats_cnt == 0)
continue;
- stats_cnt = atomic_read(&device->dev_stats_ccnt);
+
+ /*
+ * There is a LOAD-LOAD control dependency between the value of
+ * dev_stats_ccnt and updating the on-disk values which requires
+ * reading the in-memory counters. Such control dependencies
+ * require explicit read memory barriers.
+ *
+ * This memory barriers pairs with smp_mb__before_atomic in
+ * btrfs_dev_stat_inc/btrfs_dev_stat_set and with the full
+ * barrier implied by atomic_xchg in
+ * btrfs_dev_stats_read_and_reset
+ */
+ smp_rmb();
+
ret = update_dev_stat_item(trans, fs_info, device);
if (!ret)
atomic_sub(stats_cnt, &device->dev_stats_ccnt);
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -498,6 +498,12 @@ static inline void btrfs_dev_stat_inc(st
int index)
{
atomic_inc(dev->dev_stat_values + index);
+ /*
+ * This memory barrier orders stores updating statistics before stores
+ * updating dev_stats_ccnt.
+ *
+ * It pairs with smp_rmb() in btrfs_run_dev_stats().
+ */
smp_mb__before_atomic();
atomic_inc(&dev->dev_stats_ccnt);
}
@@ -523,6 +529,12 @@ static inline void btrfs_dev_stat_set(st
int index, unsigned long val)
{
atomic_set(dev->dev_stat_values + index, val);
+ /*
+ * This memory barrier orders stores updating statistics before stores
+ * updating dev_stats_ccnt.
+ *
+ * It pairs with smp_rmb() in btrfs_run_dev_stats().
+ */
smp_mb__before_atomic();
atomic_inc(&dev->dev_stats_ccnt);
}
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch
queue-4.14/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch
This is a note to let you know that I've just added the patch titled
btrfs: alloc_chunk: fix DUP stripe size handling
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-alloc_chunk-fix-dup-stripe-size-handling.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 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Date: Mon, 5 Feb 2018 17:45:11 +0100
Subject: btrfs: alloc_chunk: fix DUP stripe size handling
From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
commit 92e222df7b8f05c565009c7383321b593eca488b upstream.
In case of using DUP, we search for enough unallocated disk space on a
device to hold two stripes.
The devices_info[ndevs-1].max_avail that holds the amount of unallocated
space found is directly assigned to stripe_size, while it's actually
twice the stripe size.
Later on in the code, an unconditional division of stripe_size by
dev_stripes corrects the value, but in the meantime there's a check to
see if the stripe_size does not exceed max_chunk_size. Since during this
check stripe_size is twice the amount as intended, the check will reduce
the stripe_size to max_chunk_size if the actual correct to be used
stripe_size is more than half the amount of max_chunk_size.
The unconditional division later tries to correct stripe_size, but will
actually make sure we can't allocate more than half the max_chunk_size.
Fix this by moving the division by dev_stripes before the max chunk size
check, so it always contains the right value, instead of putting a duct
tape division in further on to get it fixed again.
Since in all other cases than DUP, dev_stripes is 1, this change only
affects DUP.
Other attempts in the past were made to fix this:
* 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried
to fix the same problem, but still resulted in part of the code acting
on a wrongly doubled stripe_size value.
* 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally
broke this fix again.
The real problem was already introduced with the rest of the code in
73c5de0051.
The user visible result however will be that the max chunk size for DUP
will suddenly double, while it's actually acting according to the limits
in the code again like it was 5 years ago.
Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com>
Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html
Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation")
Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6")
Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ update comment ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4733,10 +4733,13 @@ static int __btrfs_alloc_chunk(struct bt
ndevs = min(ndevs, devs_max);
/*
- * the primary goal is to maximize the number of stripes, so use as many
- * devices as possible, even if the stripes are not maximum sized.
+ * The primary goal is to maximize the number of stripes, so use as
+ * many devices as possible, even if the stripes are not maximum sized.
+ *
+ * The DUP profile stores more than one stripe per device, the
+ * max_avail is the total size so we have to adjust.
*/
- stripe_size = devices_info[ndevs-1].max_avail;
+ stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes);
num_stripes = ndevs * dev_stripes;
/*
@@ -4771,8 +4774,6 @@ static int __btrfs_alloc_chunk(struct bt
stripe_size = devices_info[ndevs-1].max_avail;
}
- stripe_size = div_u64(stripe_size, dev_stripes);
-
/* align to BTRFS_STRIPE_LEN */
stripe_size = round_down(stripe_size, BTRFS_STRIPE_LEN);
Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are
queue-4.14/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch
This is a note to let you know that I've just added the patch titled
btrfs: add missing initialization in btrfs_check_shared
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-add-missing-initialization-in-btrfs_check_shared.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 18bf591ba9753e3e5ba91f38f756a800693408f4 Mon Sep 17 00:00:00 2001
From: Edmund Nadolski <enadolski(a)suse.com>
Date: Wed, 14 Mar 2018 09:03:11 -0600
Subject: btrfs: add missing initialization in btrfs_check_shared
From: Edmund Nadolski <enadolski(a)suse.com>
commit 18bf591ba9753e3e5ba91f38f756a800693408f4 upstream.
This patch addresses an issue that causes fiemap to falsely
report a shared extent. The test case is as follows:
xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5
sync
xfs_io -c "fiemap -v" /media/scratch/file5
which gives the resulting output:
wrote 65536/65536 bytes at offset 0
64 KiB, 4 ops; 0.0000 sec (121.359 MiB/sec and 7766.9903 ops/sec)
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x2001
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
This is because btrfs_check_shared calls find_parent_nodes
repeatedly in a loop, passing a share_check struct to report
the count of shared extent. But btrfs_check_shared does not
re-initialize the count value to zero for subsequent calls
from the loop, resulting in a false share count value. This
is a regressive behavior from 4.13.
With proper re-initialization the test result is as follows:
wrote 65536/65536 bytes at offset 0
64 KiB, 4 ops; 0.0000 sec (110.035 MiB/sec and 7042.2535 ops/sec)
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
which corrects the regression.
Fixes: 3ec4d3238ab ("btrfs: allow backref search checks for shared extents")
Signed-off-by: Edmund Nadolski <enadolski(a)suse.com>
[ add text from cover letter to changelog ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/backref.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1496,6 +1496,7 @@ int btrfs_check_shared(struct btrfs_root
if (!node)
break;
bytenr = node->val;
+ shared.share_count = 0;
cond_resched();
}
Patches currently in stable-queue which might be from enadolski(a)suse.com are
queue-4.14/btrfs-add-missing-initialization-in-btrfs_check_shared.patch
This is a note to let you know that I've just added the patch titled
staging: ncpfs: memory corruption in ncp_read_kernel()
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 4c41aa24baa4ed338241d05494f2c595c885af8f Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Mon, 19 Mar 2018 14:07:45 +0300
Subject: staging: ncpfs: memory corruption in ncp_read_kernel()
If the server is malicious then *bytes_read could be larger than the
size of the "target" buffer. It would lead to memory corruption when we
do the memcpy().
Reported-by: Dr Silvio Cesare of InfoSect <Silvio Cesare <silvio.cesare(a)gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/ncpfs/ncplib_kernel.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/ncpfs/ncplib_kernel.c b/drivers/staging/ncpfs/ncplib_kernel.c
index 804adfebba2f..3e047eb4cc7c 100644
--- a/drivers/staging/ncpfs/ncplib_kernel.c
+++ b/drivers/staging/ncpfs/ncplib_kernel.c
@@ -981,6 +981,10 @@ ncp_read_kernel(struct ncp_server *server, const char *file_id,
goto out;
}
*bytes_read = ncp_reply_be16(server, 0);
+ if (*bytes_read > to_read) {
+ result = -EINVAL;
+ goto out;
+ }
source = ncp_reply_data(server, 2 + (offset & 1));
memcpy(target, source, *bytes_read);
--
2.16.2
This is a note to let you know that I've just added the patch titled
iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock()
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 3c3e4b3a708a9d6451052e348981f37d2b3e92b0 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Thu, 8 Mar 2018 12:31:53 +0300
Subject: iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock()
The meson_sar_adc_lock() function is not supposed to hold the
"indio_dev->mlock" on the error path.
Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/adc/meson_saradc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 29fa7736d80c..ede955d9b2a4 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -462,8 +462,10 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
- if (timeout < 0)
+ if (timeout < 0) {
+ mutex_unlock(&indio_dev->mlock);
return -ETIMEDOUT;
+ }
}
return 0;
--
2.16.2
This is a note to let you know that I've just added the patch titled
iio: chemical: ccs811: Corrected firmware boot/application mode
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From b91e146c38b003c899710ede6d05fc824675e386 Mon Sep 17 00:00:00 2001
From: Richard Lai <richard(a)richardman.com>
Date: Sat, 17 Feb 2018 16:28:24 +0000
Subject: iio: chemical: ccs811: Corrected firmware boot/application mode
transition
CCS811 has different I2C register maps in boot and application mode. When
CCS811 is in boot mode, register APP_START (0xF4) is used to transit the
firmware state from boot to application mode. However, APP_START is not a
valid register location when CCS811 is in application mode (refer to
"CCS811 Bootloader Register Map" and "CCS811 Application Register Map" in
CCS811 datasheet). The driver should not attempt to perform a write to
APP_START while CCS811 is in application mode, as this is not a valid or
documented register location.
When prob function is being called, the driver assumes the CCS811 sensor
is in boot mode, and attempts to perform a write to APP_START. Although
CCS811 powers-up in boot mode, it may have already been transited to
application mode by previous instances, e.g. unload and reload device
driver by the system, or explicitly by user. Depending on the system
design, CCS811 sensor may be permanently connected to system power source
rather than power controlled by GPIO, hence it is possible that the sensor
is never power reset, thus the firmware could be in either boot or
application mode at any given time when driver prob function is being
called.
This patch checks the STATUS register before attempting to send a write to
APP_START. Only if the firmware is not in application mode and has valid
firmware application loaded, then it will continue to start transiting the
firmware boot to application mode.
Signed-off-by: Richard Lai <richard(a)richardman.com>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/chemical/ccs811.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iio/chemical/ccs811.c b/drivers/iio/chemical/ccs811.c
index fbe2431f5b81..1ea9f5513b02 100644
--- a/drivers/iio/chemical/ccs811.c
+++ b/drivers/iio/chemical/ccs811.c
@@ -133,6 +133,9 @@ static int ccs811_start_sensor_application(struct i2c_client *client)
if (ret < 0)
return ret;
+ if ((ret & CCS811_STATUS_FW_MODE_APPLICATION))
+ return 0;
+
if ((ret & CCS811_STATUS_APP_VALID_MASK) !=
CCS811_STATUS_APP_VALID_LOADED)
return -EIO;
--
2.16.2
There have been reports of the Crucial M500 480GB model not working
with LPM set to min_power / med_power_with_dipm level.
It has not been tested with medium_power, but that typically has no
measurable power-savings.
Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03
and there is a MU05 update available, but that update does not mention any
LPM fixes in its changelog, so the quirk matches all firmware versions.
In my experience the LPM problems with (older) Crucial SSDs seem to be
limited to higher capacity versions of the SSDs (different firmware?),
so this commit adds a NOLPM quirk for the 480 and 960GB versions of the
M500, to avoid LPM causing issues with these SSDs.
Cc: stable(a)vger.kernel.org
Reported-and-tested-by: Martin Steigerwald <martin(a)lichtvoll.de>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/ata/libata-core.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index aec609f80c4e..53400ce09818 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4538,6 +4538,14 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
ATA_HORKAGE_ZERO_AFTER_TRIM |
ATA_HORKAGE_NOLPM, },
+ /* 480GB+ M500 SSDs have both queued TRIM and LPM issues */
+ { "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+ { "Crucial_CT960M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
--
2.14.3
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>
---
drivers/bluetooth/hci_qca.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 392f412b4575..c9f0ac083a3e 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -933,6 +933,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 */
--
2.14.1
Commit 99759869faf1 "acpi: Add acpi_map_pxm_to_online_node()" added
support for mapping a given proximity to its nearest, by SLIT distance,
online node. However, it sometimes returns unexpected results due to the
fact that it switches from comparing the PXM node to the last node that
was closer than the current max.
for_each_online_node(n) {
dist = node_distance(node, n);
if (dist < min_dist) {
min_dist = dist;
node = n; <---- from this point we're using the
wrong node for node_distance()
Fixes: 99759869faf1 ("acpi: Add acpi_map_pxm_to_online_node()")
Cc: <stable(a)vger.kernel.org>
Cc: Toshi Kani <toshi.kani(a)hp.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
Rafael, I can take this through the nvdimm tree with your ack. I have a
few other nvdimm fixes pending for 4.16.
drivers/acpi/numa.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 8ccaae3550d2..85167603b9c9 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -103,25 +103,27 @@ int acpi_map_pxm_to_node(int pxm)
*/
int acpi_map_pxm_to_online_node(int pxm)
{
- int node, n, dist, min_dist;
+ int node, min_node;
node = acpi_map_pxm_to_node(pxm);
if (node == NUMA_NO_NODE)
node = 0;
+ min_node = node;
if (!node_online(node)) {
- min_dist = INT_MAX;
+ int min_dist = INT_MAX, dist, n;
+
for_each_online_node(n) {
dist = node_distance(node, n);
if (dist < min_dist) {
min_dist = dist;
- node = n;
+ min_node = n;
}
}
}
- return node;
+ return min_node;
}
EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.
The pinmuxing was missing for I2C1 which was causing intermittent issues
with the PMIC which is connected to I2C1. The bootloader did not quite
configure the I2C1 either, so when running at 2.6MHz, it was generating
errors at time.
This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz
Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo
DM3730 devkit")
For linux-4.4.y
Signed-off-by: Adam Ford <aford173(a)gmail.com>
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 80f6c78..e056704 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -90,6 +90,8 @@
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
clock-frequency = <2600000>;
twl: twl@48 {
@@ -137,6 +139,12 @@
OMAP3_CORE1_IOPAD(0x218e, PIN_OUTPUT | MUX_MODE4) /* mcbsp1_fsr.gpio_157 */
>;
};
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
+ OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
+ >;
+ };
};
&omap3_pmx_core2 {
--
2.7.4
On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david(a)fromorbit.com> wrote:
> On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote:
>> On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch(a)lst.de> wrote:
>> > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote:
>> >> OK, found the patches the fix soft lockups in generic/269 and
>> >> assertion in generic/232, so expunging those 2 tests from v4.15.y
>> >> test runs.
>> >
>> > Which patches are those? We should probably backport them to 4.15-stable.
>>
>> Probably, but I guess Darrick has those in his TODO.
>>
>> There is this series that refers to failure in generic/232:
>> https://marc.info/?l=linux-xfs&m=151701545720824&w=2
>>
>> These 2 commits refer to generic/269 specifically in commit message:
>> 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate
>> be78ff0e7277 xfs: recheck reflink / dirty page status before freeing
>> CoW reservations
>> and the thread on the second commit also mentions generic/270
>> (I found out the hard way that it also soft locks).
>>
>> But there are surely more patches for stable in master.
>> I recon CC: stable and/or Fixes: tags could have been helpful,
>> but I don't see any of those in v4.16-rcX from the core xfs developers.
>
> AS I always say: if you want to maintain a stable backport kernel
> with all the fixes that go into the bleeding edge, you're more than
> welcome to do it.
>
> Everyone else is flat out just keeping up with on going development
> and fixing bugs in the kernel as it's moving forward. So if you have
> the need for stable backports, please keep backporting patches you
> need, testing them and asking the stable maintainers to include
> them.
>
Greg,
I tested the patch in question per Darrick's request.
I found no regressions with full "auto" run on xfs with reflinks enabled.
Please include this patch in stable 4.15.
Dave,
It is often the case, though maybe not always, that the author of a patch
has the knowledge of the 'Fixes' commit and/or the stable kernel version
patch is relevant to or would easily apply to.
It is therefore a relatively low effort for a developer to include
this information
as courtesy to stable maintainers, whether they are maintaining kernel.org
stable kernels or distro stable kernels.
That's just my opinion.
Christoph/Darrick,
FYI, with stable kernel 4.15.y, I found the following failures with -g auto:
Assert (mostly on quota related):
generic/232 xfs/222 xfs/305 xfs/440 xfs/442
Soft lockup (likely fixed by be78ff0e7277):
generic/269 generic/270 xfs/442
Failures (output mismatch):
xfs/170 xfs/191-input-validation xfs/348
Thanks,
Amir.
This is a note to let you know that I've just added the patch titled
xfs: preserve i_rdev when recycling a reclaimable inode
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:
xfs-preserve-i_rdev-when-recycling-a-reclaimable-inode.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 acd1d71598f7654b6d7718bcbe979992295c672a Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Fri, 26 Jan 2018 11:24:40 -0800
Subject: xfs: preserve i_rdev when recycling a reclaimable inode
From: Amir Goldstein <amir73il(a)gmail.com>
commit acd1d71598f7654b6d7718bcbe979992295c672a upstream.
Commit 66f364649d870 ("xfs: remove if_rdev") moved storing of rdev
value for special inodes to VFS inodes, but forgot to preserve the
value of i_rdev when recycling a reclaimable xfs_inode.
This was detected by xfstest overlay/017 with inodex=on mount option
and xfs base fs. The test does a lookup of overlay chardev and blockdev
right after drop caches.
Overlayfs inodes hold a reference on underlying xfs inodes when mount
option index=on is configured. If drop caches reclaim xfs inodes, before
it relclaims overlayfs inodes, that can sometimes leave a reclaimable xfs
inode and that test hits that case quite often.
When that happens, the xfs inode cache remains broken (zere i_rdev)
until the next cycle mount or drop caches.
Fixes: 66f364649d870 ("xfs: remove if_rdev")
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_icache.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/xfs/xfs_icache.c
+++ b/fs/xfs/xfs_icache.c
@@ -295,6 +295,7 @@ xfs_reinit_inode(
uint32_t generation = inode->i_generation;
uint64_t version = inode->i_version;
umode_t mode = inode->i_mode;
+ dev_t dev = inode->i_rdev;
error = inode_init_always(mp->m_super, inode);
@@ -302,6 +303,7 @@ xfs_reinit_inode(
inode->i_generation = generation;
inode->i_version = version;
inode->i_mode = mode;
+ inode->i_rdev = dev;
return error;
}
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.15/xfs-preserve-i_rdev-when-recycling-a-reclaimable-inode.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: only check for dxfer_len greater than 256M
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:
scsi-sg-only-check-for-dxfer_len-greater-than-256m.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 f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Thu, 27 Jul 2017 09:11:26 +0200
Subject: scsi: sg: only check for dxfer_len greater than 256M
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit f930c7043663188429cd9b254e9d761edfc101ce upstream.
Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the
sg_io_hdr_t::dxferp in order to determine if it is a valid request. The
only way we can check for bad requests is by checking if the length
exceeds 256M.
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request)
Reported-by: Jason L Tibbitts III <tibbs(a)math.uh.edu>
Tested-by: Jason L Tibbitts III <tibbs(a)math.uh.edu>
Suggested-by: Doug Gilbert <dgilbert(a)interlog.com>
Cc: Doug Gilbert <dgilbert(a)interlog.com>
Cc: <stable(a)vger.kernel.org>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 31 +------------------------------
1 file changed, 1 insertion(+), 30 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -751,35 +751,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi
return count;
}
-static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
-{
- switch (hp->dxfer_direction) {
- case SG_DXFER_NONE:
- if (hp->dxferp || hp->dxfer_len > 0)
- return false;
- return true;
- case SG_DXFER_FROM_DEV:
- /*
- * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
- * can either be NULL or != NULL so there's no point in checking
- * it either. So just return true.
- */
- return true;
- case SG_DXFER_TO_DEV:
- case SG_DXFER_TO_FROM_DEV:
- if (!hp->dxferp || hp->dxfer_len == 0)
- return false;
- return true;
- case SG_DXFER_UNKNOWN:
- if ((!hp->dxferp && hp->dxfer_len) ||
- (hp->dxferp && hp->dxfer_len == 0))
- return false;
- return true;
- default:
- return false;
- }
-}
-
static int
sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -800,7 +771,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));
- if (!sg_is_valid_dxfer(hp))
+ if (hp->dxfer_len >= SZ_256M)
return -EINVAL;
k = sg_start_req(srp, cmnd);
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: fix static checker warning in sg_is_valid_dxfer
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:
scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.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 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Mon, 17 Jul 2017 15:11:42 +0200
Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream.
dxfer_len is an unsigned int and we always assign a value > 0 to it, so
it doesn't make any sense to check if it is < 0. We can't really check
dxferp as well as we have both NULL and not NULL cases in the possible
call paths.
So just return true for SG_DXFER_FROM_DEV transfer in
sg_is_valid_dxfer().
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reported-by: Colin Ian King <colin.king(a)canonical.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -759,8 +759,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
return false;
return true;
case SG_DXFER_FROM_DEV:
- if (hp->dxfer_len < 0)
- return false;
+ /*
+ * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
+ * can either be NULL or != NULL so there's no point in checking
+ * it either. So just return true.
+ */
return true;
case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: fix SG_DXFER_FROM_DEV transfers
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:
scsi-sg-fix-sg_dxfer_from_dev-transfers.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 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Fri, 7 Jul 2017 10:56:38 +0200
Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream.
SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set
it to NULL for the old sg_io read/write interface, but must have a
length bigger than 0. This fixes a regression introduced by commit
28676d869bbb ("scsi: sg: check for valid direction before starting the
request")
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request")
Reported-by: Chris Clayton <chris2553(a)googlemail.com>
Tested-by: Chris Clayton <chris2553(a)googlemail.com>
Cc: Douglas Gilbert <dgilbert(a)interlog.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Tested-by: Chris Clayton <chris2553(a)googlemail.com>
Acked-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -758,8 +758,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
if (hp->dxferp || hp->dxfer_len > 0)
return false;
return true;
- case SG_DXFER_TO_DEV:
case SG_DXFER_FROM_DEV:
+ if (hp->dxfer_len < 0)
+ return false;
+ return true;
+ case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:
if (!hp->dxferp || hp->dxfer_len == 0)
return false;
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
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:
irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Tue, 6 Mar 2018 15:51:32 +0000
Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream.
When struct its_device instances are created, the nr_ites member
will be set to a power of 2 that equals or exceeds the requested
number of MSIs passed to the msi_prepare() callback. At the same
time, the LPI map is allocated to be some multiple of 32 in size,
where the allocated size may be less than the requested size
depending on whether a contiguous range of sufficient size is
available in the global LPI bitmap.
This may result in the situation where the nr_ites < nr_lpis, and
since nr_ites is what we program into the hardware when we map the
device, the additional LPIs will be non-functional.
For bog standard hardware, this does not really matter. However,
in cases where ITS device IDs are shared between different PCIe
devices, we may end up allocating these additional LPIs without
taking into account that they don't actually work.
So let's make nr_ites at least 32. This ensures that all allocated
LPIs are 'live', and that its_alloc_device_irq() will fail when
attempts are made to allocate MSIs beyond what was allocated in
the first place.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[maz: updated comment]
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
[ardb: trivial tweak of unrelated context]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3-its.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -684,7 +684,7 @@ static struct irq_chip its_irq_chip = {
* This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
*/
#define IRQS_PER_CHUNK_SHIFT 5
-#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)
static unsigned long *lpi_bitmap;
static u32 lpi_chunks;
@@ -1320,11 +1320,10 @@ static struct its_device *its_create_dev
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
/*
- * At least one bit of EventID is being used, hence a minimum
- * of two entries. No, the architecture doesn't let you
- * express an ITT with a single entry.
+ * We allocate at least one chunk worth of LPIs bet device,
+ * and thus that many ITEs. The device may require less though.
*/
- nr_ites = max(2UL, roundup_pow_of_two(nvecs));
+ nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
sz = nr_ites * its->ite_size;
sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
itt = kzalloc(sz, GFP_KERNEL);
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch
queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch
queue-4.9/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch
This is a note to let you know that I've just added the patch titled
nvme: fix subsystem multiple controllers support check
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:
nvme-fix-subsystem-multiple-controllers-support-check.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 b837b28394fb76993c28bb242db7061ee0417da6 Mon Sep 17 00:00:00 2001
From: Israel Rukshin <israelr(a)mellanox.com>
Date: Thu, 4 Jan 2018 17:56:14 +0200
Subject: nvme: fix subsystem multiple controllers support check
From: Israel Rukshin <israelr(a)mellanox.com>
commit b837b28394fb76993c28bb242db7061ee0417da6 upstream.
There is a problem when another module (e.g. nvmet) takes a reference on
the nvme block device and the physical nvme drive is removed. In that
case nvme_free_ctrl() will not be called and the controller state will be
"deleting" or "dead" unless nvmet module releases the block device.
Later on, the same nvme drive probes back and nvme_init_subsystem() will
be called and fail due to duplicate subnqn (if the nvme device doesn't
support subsystem with multiple controllers). This will cause a probe
failure. This commit changes the check of multiple controllers support
at nvme_init_subsystem() by not counting all the controllers at "dead" or
"deleting" state (this is safe because controllers at this state will
never be active again).
Fixes: ab9e00cc72fa ("nvme: track subsystems")
Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com>
Signed-off-by: Israel Rukshin <israelr(a)mellanox.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Keith Busch <keith.busch(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/host/core.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2052,6 +2052,22 @@ static const struct attribute_group *nvm
NULL,
};
+static int nvme_active_ctrls(struct nvme_subsystem *subsys)
+{
+ int count = 0;
+ struct nvme_ctrl *ctrl;
+
+ mutex_lock(&subsys->lock);
+ list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) {
+ if (ctrl->state != NVME_CTRL_DELETING &&
+ ctrl->state != NVME_CTRL_DEAD)
+ count++;
+ }
+ mutex_unlock(&subsys->lock);
+
+ return count;
+}
+
static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id)
{
struct nvme_subsystem *subsys, *found;
@@ -2090,7 +2106,7 @@ static int nvme_init_subsystem(struct nv
* Verify that the subsystem actually supports multiple
* controllers, else bail out.
*/
- if (!(id->cmic & (1 << 1))) {
+ if (nvme_active_ctrls(found) && !(id->cmic & (1 << 1))) {
dev_err(ctrl->device,
"ignoring ctrl due to duplicate subnqn (%s).\n",
found->subnqn);
Patches currently in stable-queue which might be from israelr(a)mellanox.com are
queue-4.15/nvme-fix-subsystem-multiple-controllers-support-check.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
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:
irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Tue, 6 Mar 2018 15:51:32 +0000
Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream.
When struct its_device instances are created, the nr_ites member
will be set to a power of 2 that equals or exceeds the requested
number of MSIs passed to the msi_prepare() callback. At the same
time, the LPI map is allocated to be some multiple of 32 in size,
where the allocated size may be less than the requested size
depending on whether a contiguous range of sufficient size is
available in the global LPI bitmap.
This may result in the situation where the nr_ites < nr_lpis, and
since nr_ites is what we program into the hardware when we map the
device, the additional LPIs will be non-functional.
For bog standard hardware, this does not really matter. However,
in cases where ITS device IDs are shared between different PCIe
devices, we may end up allocating these additional LPIs without
taking into account that they don't actually work.
So let's make nr_ites at least 32. This ensures that all allocated
LPIs are 'live', and that its_alloc_device_irq() will fail when
attempts are made to allocate MSIs beyond what was allocated in
the first place.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[maz: updated comment]
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3-its.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1412,7 +1412,7 @@ static struct irq_chip its_irq_chip = {
* This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
*/
#define IRQS_PER_CHUNK_SHIFT 5
-#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)
#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */
static unsigned long *lpi_bitmap;
@@ -2119,11 +2119,10 @@ static struct its_device *its_create_dev
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
/*
- * At least one bit of EventID is being used, hence a minimum
- * of two entries. No, the architecture doesn't let you
- * express an ITT with a single entry.
+ * We allocate at least one chunk worth of LPIs bet device,
+ * and thus that many ITEs. The device may require less though.
*/
- nr_ites = max(2UL, roundup_pow_of_two(nvecs));
+ nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
sz = nr_ites * its->ite_size;
sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
itt = kzalloc(sz, GFP_KERNEL);
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.15/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch
queue-4.15/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
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:
irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Tue, 6 Mar 2018 15:51:32 +0000
Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream.
When struct its_device instances are created, the nr_ites member
will be set to a power of 2 that equals or exceeds the requested
number of MSIs passed to the msi_prepare() callback. At the same
time, the LPI map is allocated to be some multiple of 32 in size,
where the allocated size may be less than the requested size
depending on whether a contiguous range of sufficient size is
available in the global LPI bitmap.
This may result in the situation where the nr_ites < nr_lpis, and
since nr_ites is what we program into the hardware when we map the
device, the additional LPIs will be non-functional.
For bog standard hardware, this does not really matter. However,
in cases where ITS device IDs are shared between different PCIe
devices, we may end up allocating these additional LPIs without
taking into account that they don't actually work.
So let's make nr_ites at least 32. This ensures that all allocated
LPIs are 'live', and that its_alloc_device_irq() will fail when
attempts are made to allocate MSIs beyond what was allocated in
the first place.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[maz: updated comment]
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3-its.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1310,7 +1310,7 @@ static struct irq_chip its_irq_chip = {
* This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
*/
#define IRQS_PER_CHUNK_SHIFT 5
-#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)
#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */
static unsigned long *lpi_bitmap;
@@ -2026,11 +2026,10 @@ static struct its_device *its_create_dev
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
/*
- * At least one bit of EventID is being used, hence a minimum
- * of two entries. No, the architecture doesn't let you
- * express an ITT with a single entry.
+ * We allocate at least one chunk worth of LPIs bet device,
+ * and thus that many ITEs. The device may require less though.
*/
- nr_ites = max(2UL, roundup_pow_of_two(nvecs));
+ nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
sz = nr_ites * its->ite_size;
sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
itt = kzalloc(sz, GFP_KERNEL);
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.14/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch
queue-4.14/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: only check for dxfer_len greater than 256M
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:
scsi-sg-only-check-for-dxfer_len-greater-than-256m.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 f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Thu, 27 Jul 2017 09:11:26 +0200
Subject: scsi: sg: only check for dxfer_len greater than 256M
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit f930c7043663188429cd9b254e9d761edfc101ce upstream.
Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the
sg_io_hdr_t::dxferp in order to determine if it is a valid request. The
only way we can check for bad requests is by checking if the length
exceeds 256M.
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request)
Reported-by: Jason L Tibbitts III <tibbs(a)math.uh.edu>
Tested-by: Jason L Tibbitts III <tibbs(a)math.uh.edu>
Suggested-by: Doug Gilbert <dgilbert(a)interlog.com>
Cc: Doug Gilbert <dgilbert(a)interlog.com>
Cc: <stable(a)vger.kernel.org>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 31 +------------------------------
1 file changed, 1 insertion(+), 30 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -762,35 +762,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi
return count;
}
-static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
-{
- switch (hp->dxfer_direction) {
- case SG_DXFER_NONE:
- if (hp->dxferp || hp->dxfer_len > 0)
- return false;
- return true;
- case SG_DXFER_FROM_DEV:
- /*
- * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
- * can either be NULL or != NULL so there's no point in checking
- * it either. So just return true.
- */
- return true;
- case SG_DXFER_TO_DEV:
- case SG_DXFER_TO_FROM_DEV:
- if (!hp->dxferp || hp->dxfer_len == 0)
- return false;
- return true;
- case SG_DXFER_UNKNOWN:
- if ((!hp->dxferp && hp->dxfer_len) ||
- (hp->dxferp && hp->dxfer_len == 0))
- return false;
- return true;
- default:
- return false;
- }
-}
-
static int
sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -811,7 +782,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));
- if (!sg_is_valid_dxfer(hp))
+ if (hp->dxfer_len >= SZ_256M)
return -EINVAL;
k = sg_start_req(srp, cmnd);
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: fix static checker warning in sg_is_valid_dxfer
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:
scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.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 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Mon, 17 Jul 2017 15:11:42 +0200
Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream.
dxfer_len is an unsigned int and we always assign a value > 0 to it, so
it doesn't make any sense to check if it is < 0. We can't really check
dxferp as well as we have both NULL and not NULL cases in the possible
call paths.
So just return true for SG_DXFER_FROM_DEV transfer in
sg_is_valid_dxfer().
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reported-by: Colin Ian King <colin.king(a)canonical.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -770,8 +770,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
return false;
return true;
case SG_DXFER_FROM_DEV:
- if (hp->dxfer_len < 0)
- return false;
+ /*
+ * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
+ * can either be NULL or != NULL so there's no point in checking
+ * it either. So just return true.
+ */
return true;
case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: fix SG_DXFER_FROM_DEV transfers
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:
scsi-sg-fix-sg_dxfer_from_dev-transfers.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 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Fri, 7 Jul 2017 10:56:38 +0200
Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream.
SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set
it to NULL for the old sg_io read/write interface, but must have a
length bigger than 0. This fixes a regression introduced by commit
28676d869bbb ("scsi: sg: check for valid direction before starting the
request")
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request")
Reported-by: Chris Clayton <chris2553(a)googlemail.com>
Tested-by: Chris Clayton <chris2553(a)googlemail.com>
Cc: Douglas Gilbert <dgilbert(a)interlog.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Tested-by: Chris Clayton <chris2553(a)googlemail.com>
Acked-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -769,8 +769,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
if (hp->dxferp || hp->dxfer_len > 0)
return false;
return true;
- case SG_DXFER_TO_DEV:
case SG_DXFER_FROM_DEV:
+ if (hp->dxfer_len < 0)
+ return false;
+ return true;
+ case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:
if (!hp->dxferp || hp->dxfer_len == 0)
return false;
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
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:
irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.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 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Tue, 6 Mar 2018 15:51:32 +0000
Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream.
When struct its_device instances are created, the nr_ites member
will be set to a power of 2 that equals or exceeds the requested
number of MSIs passed to the msi_prepare() callback. At the same
time, the LPI map is allocated to be some multiple of 32 in size,
where the allocated size may be less than the requested size
depending on whether a contiguous range of sufficient size is
available in the global LPI bitmap.
This may result in the situation where the nr_ites < nr_lpis, and
since nr_ites is what we program into the hardware when we map the
device, the additional LPIs will be non-functional.
For bog standard hardware, this does not really matter. However,
in cases where ITS device IDs are shared between different PCIe
devices, we may end up allocating these additional LPIs without
taking into account that they don't actually work.
So let's make nr_ites at least 32. This ensures that all allocated
LPIs are 'live', and that its_alloc_device_irq() will fail when
attempts are made to allocate MSIs beyond what was allocated in
the first place.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[maz: updated comment]
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
[ardb: trivial tweak of unrelated context]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3-its.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -663,7 +663,7 @@ static struct irq_chip its_irq_chip = {
* This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
*/
#define IRQS_PER_CHUNK_SHIFT 5
-#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)
static unsigned long *lpi_bitmap;
static u32 lpi_chunks;
@@ -1168,11 +1168,10 @@ static struct its_device *its_create_dev
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
/*
- * At least one bit of EventID is being used, hence a minimum
- * of two entries. No, the architecture doesn't let you
- * express an ITT with a single entry.
+ * We allocate at least one chunk worth of LPIs bet device,
+ * and thus that many ITEs. The device may require less though.
*/
- nr_ites = max(2UL, roundup_pow_of_two(nvecs));
+ nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
sz = nr_ites * its->ite_size;
sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
itt = kzalloc(sz, GFP_KERNEL);
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.4/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: only check for dxfer_len greater than 256M
to the 3.18-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:
scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
and it can be found in the queue-3.18 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 f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Thu, 27 Jul 2017 09:11:26 +0200
Subject: scsi: sg: only check for dxfer_len greater than 256M
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit f930c7043663188429cd9b254e9d761edfc101ce upstream.
Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the
sg_io_hdr_t::dxferp in order to determine if it is a valid request. The
only way we can check for bad requests is by checking if the length
exceeds 256M.
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request)
Reported-by: Jason L Tibbitts III <tibbs(a)math.uh.edu>
Tested-by: Jason L Tibbitts III <tibbs(a)math.uh.edu>
Suggested-by: Doug Gilbert <dgilbert(a)interlog.com>
Cc: Doug Gilbert <dgilbert(a)interlog.com>
Cc: <stable(a)vger.kernel.org>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 31 +------------------------------
1 file changed, 1 insertion(+), 30 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -762,35 +762,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi
return count;
}
-static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
-{
- switch (hp->dxfer_direction) {
- case SG_DXFER_NONE:
- if (hp->dxferp || hp->dxfer_len > 0)
- return false;
- return true;
- case SG_DXFER_FROM_DEV:
- /*
- * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
- * can either be NULL or != NULL so there's no point in checking
- * it either. So just return true.
- */
- return true;
- case SG_DXFER_TO_DEV:
- case SG_DXFER_TO_FROM_DEV:
- if (!hp->dxferp || hp->dxfer_len == 0)
- return false;
- return true;
- case SG_DXFER_UNKNOWN:
- if ((!hp->dxferp && hp->dxfer_len) ||
- (hp->dxferp && hp->dxfer_len == 0))
- return false;
- return true;
- default:
- return false;
- }
-}
-
static int
sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -811,7 +782,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));
- if (!sg_is_valid_dxfer(hp))
+ if (hp->dxfer_len >= SZ_256M)
return -EINVAL;
k = sg_start_req(srp, cmnd);
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: fix static checker warning in sg_is_valid_dxfer
to the 3.18-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:
scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
and it can be found in the queue-3.18 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 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Mon, 17 Jul 2017 15:11:42 +0200
Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream.
dxfer_len is an unsigned int and we always assign a value > 0 to it, so
it doesn't make any sense to check if it is < 0. We can't really check
dxferp as well as we have both NULL and not NULL cases in the possible
call paths.
So just return true for SG_DXFER_FROM_DEV transfer in
sg_is_valid_dxfer().
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reported-by: Colin Ian King <colin.king(a)canonical.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -770,8 +770,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
return false;
return true;
case SG_DXFER_FROM_DEV:
- if (hp->dxfer_len < 0)
- return false;
+ /*
+ * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
+ * can either be NULL or != NULL so there's no point in checking
+ * it either. So just return true.
+ */
return true;
case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
This is a note to let you know that I've just added the patch titled
scsi: sg: fix SG_DXFER_FROM_DEV transfers
to the 3.18-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:
scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
and it can be found in the queue-3.18 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 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001
From: Johannes Thumshirn <jthumshirn(a)suse.de>
Date: Fri, 7 Jul 2017 10:56:38 +0200
Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers
From: Johannes Thumshirn <jthumshirn(a)suse.de>
commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream.
SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set
it to NULL for the old sg_io read/write interface, but must have a
length bigger than 0. This fixes a regression introduced by commit
28676d869bbb ("scsi: sg: check for valid direction before starting the
request")
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request")
Reported-by: Chris Clayton <chris2553(a)googlemail.com>
Tested-by: Chris Clayton <chris2553(a)googlemail.com>
Cc: Douglas Gilbert <dgilbert(a)interlog.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Tested-by: Chris Clayton <chris2553(a)googlemail.com>
Acked-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/sg.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -769,8 +769,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
if (hp->dxferp || hp->dxfer_len > 0)
return false;
return true;
- case SG_DXFER_TO_DEV:
case SG_DXFER_FROM_DEV:
+ if (hp->dxfer_len < 0)
+ return false;
+ return true;
+ case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:
if (!hp->dxferp || hp->dxfer_len == 0)
return false;
Patches currently in stable-queue which might be from jthumshirn(a)suse.de are
queue-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch
queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch
queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch
queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch
queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch
Commit 4f2c7583e33e upstream.
When struct its_device instances are created, the nr_ites member
will be set to a power of 2 that equals or exceeds the requested
number of MSIs passed to the msi_prepare() callback. At the same
time, the LPI map is allocated to be some multiple of 32 in size,
where the allocated size may be less than the requested size
depending on whether a contiguous range of sufficient size is
available in the global LPI bitmap.
This may result in the situation where the nr_ites < nr_lpis, and
since nr_ites is what we program into the hardware when we map the
device, the additional LPIs will be non-functional.
For bog standard hardware, this does not really matter. However,
in cases where ITS device IDs are shared between different PCIe
devices, we may end up allocating these additional LPIs without
taking into account that they don't actually work.
So let's make nr_ites at least 32. This ensures that all allocated
LPIs are 'live', and that its_alloc_device_irq() will fail when
attempts are made to allocate MSIs beyond what was allocated in
the first place.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[maz: updated comment]
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
[ardb: trivial tweak of unrelated context]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
---
drivers/irqchip/irq-gic-v3-its.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index acb9d250a905..ac15e5d5d9b2 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -684,7 +684,7 @@ static struct irq_chip its_irq_chip = {
* This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
*/
#define IRQS_PER_CHUNK_SHIFT 5
-#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)
static unsigned long *lpi_bitmap;
static u32 lpi_chunks;
@@ -1320,11 +1320,10 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
/*
- * At least one bit of EventID is being used, hence a minimum
- * of two entries. No, the architecture doesn't let you
- * express an ITT with a single entry.
+ * We allocate at least one chunk worth of LPIs bet device,
+ * and thus that many ITEs. The device may require less though.
*/
- nr_ites = max(2UL, roundup_pow_of_two(nvecs));
+ nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
sz = nr_ites * its->ite_size;
sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
itt = kzalloc(sz, GFP_KERNEL);
--
2.11.0
Tree/Branch: v3.9.11
Git describe: v3.9.11
Commit: 896f5009ed Linux 3.9.11
Build Time: 0 min 12 sec
Passed: 0 / 9 ( 0.00 %)
Failed: 9 / 9 (100.00 %)
Errors: 4
Warnings: 9
Section Mismatches: 0
Failed defconfigs:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
x86_64-allmodconfig
arm64-defconfig
Errors:
arm64-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm64-allmodconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm-multi_v7_defconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allmodconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm64-defconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
5 warnings 0 mismatches : arm64-allmodconfig
3 warnings 0 mismatches : arm-multi_v7_defconfig
8 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm-allnoconfig
4 warnings 0 mismatches : x86_64-allnoconfig
5 warnings 0 mismatches : x86_64-allmodconfig
1 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 4
12 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings Summary: 9
4 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
3 warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
3 /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
2 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
arm64-allmodconfig : FAIL, 2 errors, 5 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 3 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 2 errors, 8 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 2 errors, 1 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 3 errors, 4 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 3 errors, 5 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 2 errors, 1 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.8.13
Git describe: v3.8.13
Commit: dbf932a9b3 Linux 3.8.13
Build Time: 0 min 12 sec
Passed: 0 / 9 ( 0.00 %)
Failed: 9 / 9 (100.00 %)
Errors: 3
Warnings: 10
Section Mismatches: 0
Failed defconfigs:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
x86_64-allmodconfig
arm64-defconfig
Errors:
arm64-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm64-allmodconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm-multi_v7_defconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allmodconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm64-defconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
8 warnings 0 mismatches : arm64-allmodconfig
3 warnings 0 mismatches : arm-multi_v7_defconfig
8 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm-allnoconfig
4 warnings 0 mismatches : x86_64-allnoconfig
5 warnings 0 mismatches : x86_64-allmodconfig
1 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 3
6 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings Summary: 10
4 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
3 warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
3 warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
3 /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
2 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
arm64-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : FAIL, 1 errors, 3 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 4 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 5 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.7.10
Git describe: v3.7.10
Commit: 356d8c6fb2 Linux 3.7.10
Build Time: 0 min 11 sec
Passed: 0 / 9 ( 0.00 %)
Failed: 9 / 9 (100.00 %)
Errors: 3
Warnings: 10
Section Mismatches: 0
Failed defconfigs:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
x86_64-allmodconfig
arm64-defconfig
Errors:
arm64-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm64-allmodconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm-multi_v7_defconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allmodconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
arm-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm64-defconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
8 warnings 0 mismatches : arm64-allmodconfig
8 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm-allnoconfig
4 warnings 0 mismatches : x86_64-allnoconfig
5 warnings 0 mismatches : x86_64-allmodconfig
1 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Errors summary: 3
6 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings Summary: 10
3 warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
3 warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
3 /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
arm64-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS)
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C)
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 4 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 5 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch]
/home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch]
-------------------------------------------------------------------------------
arm64-defconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings:
/home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.6.11
Git describe: v3.6.11
Commit: b2824f4e09 Linux 3.6.11
Build Time: 0 min 5 sec
Passed: 0 / 5 ( 0.00 %)
Failed: 5 / 5 (100.00 %)
Errors: 3
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allmodconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : x86_64-allnoconfig
2 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Errors summary: 3
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings Summary: 3
2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
2 .config:20:warning: symbol value '' invalid for PHYS_OFFSET
1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches
Warnings:
.config:20:warning: symbol value '' invalid for PHYS_OFFSET
.config:20:warning: symbol value '' invalid for PHYS_OFFSET
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.5.7
Git describe: v3.5.7
Commit: f2b152564a Linux 3.5.7
Build Time: 0 min 3 sec
Passed: 0 / 5 ( 0.00 %)
Failed: 5 / 5 (100.00 %)
Errors: 3
Warnings: 3
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allmodconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
3 warnings 0 mismatches : x86_64-allnoconfig
2 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Errors summary: 3
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings Summary: 3
2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
2 .config:20:warning: symbol value '' invalid for PHYS_OFFSET
1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Warnings:
/home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
/home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches
Warnings:
.config:20:warning: symbol value '' invalid for PHYS_OFFSET
.config:20:warning: symbol value '' invalid for PHYS_OFFSET
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.4.113
Git describe: v3.4.113
Commit: 8d1988f838 Linux 3.4.113
Build Time: 0 min 4 sec
Passed: 0 / 5 ( 0.00 %)
Failed: 5 / 5 (100.00 %)
Errors: 6
Warnings: 20
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allmodconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm-allmodconfig
19 warnings 0 mismatches : arm-allnoconfig
-------------------------------------------------------------------------------
Errors summary: 6
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
Warnings Summary: 20
2 .config:26:warning: symbol value '' invalid for PHYS_OFFSET
1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:46:29: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:26:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:81:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:103:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:40:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:33:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:108:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:9:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:20:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:16:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:10:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches
Warnings:
.config:26:warning: symbol value '' invalid for PHYS_OFFSET
.config:26:warning: symbol value '' invalid for PHYS_OFFSET
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
Warnings:
/home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:26:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:46:29: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:9:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:10:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:16:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:20:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:81:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:103:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:33:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:40:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:108:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.3.8
Git describe: v3.3.8
Commit: 845720650c Linux 3.3.8
Build Time: 0 min 3 sec
Passed: 0 / 5 ( 0.00 %)
Failed: 5 / 5 (100.00 %)
Errors: 3
Warnings: 2
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allmodconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory
x86_64-allmodconfig
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
5 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Errors summary: 3
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory
Warnings Summary: 2
3 warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86)
2 .config:26:warning: symbol value '' invalid for PHYS_OFFSET
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 5 warnings, 0 section mismatches
Warnings:
warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86)
.config:26:warning: symbol value '' invalid for PHYS_OFFSET
warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86)
.config:26:warning: symbol value '' invalid for PHYS_OFFSET
warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86)
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.2.100
Git describe: v3.2.100
Commit: 1c7cb8cda9 Linux 3.2.100
Build Time: 0 min 4 sec
Passed: 0 / 5 ( 0.00 %)
Failed: 5 / 5 (100.00 %)
Errors: 6
Warnings: 20
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allmodconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
x86_64-allmodconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm-allmodconfig
19 warnings 0 mismatches : arm-allnoconfig
-------------------------------------------------------------------------------
Errors summary: 6
3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
Warnings Summary: 20
2 .config:27:warning: symbol value '' invalid for PHYS_OFFSET
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches
Warnings:
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
Warnings:
/home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
-------------------------------------------------------------------------------
x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
The patch
spi: Fix unregistration of controller with fixed SPI bus number
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9fca7d15487654dab119d0868501db30f80ac46a Mon Sep 17 00:00:00 2001
From: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Date: Tue, 6 Mar 2018 17:47:22 +0200
Subject: [PATCH] spi: Fix unregistration of controller with fixed SPI bus
number
Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
ceased to unregister SPI buses with fixed bus numbers. Moreover this is
visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register
the same SPI controller.
rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y):
[ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1]
modprobe spi_pxa2xx_platform:
[ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1'
[ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21
[ 37.902384] Call Trace:
...
[ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory.
[ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0
...
[ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master
[ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17
Fix this by not returning immediately from spi_unregister_controller() if
idr_find() doesn't find controller with given ID/bus number. It finds
only those controllers that were registered with dynamic SPI bus
numbers. Only conditional cleanup between dynamic and fixed bus numbers
is to remove allocated IDR.
Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/spi/spi.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index b33a727a0158..e90fd442b3f0 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2254,12 +2254,6 @@ void spi_unregister_controller(struct spi_controller *ctlr)
mutex_lock(&board_lock);
found = idr_find(&spi_master_idr, id);
mutex_unlock(&board_lock);
- if (found != ctlr) {
- dev_dbg(&ctlr->dev,
- "attempting to delete unregistered controller [%s]\n",
- dev_name(&ctlr->dev));
- return;
- }
if (ctlr->queued) {
if (spi_destroy_queue(ctlr))
dev_err(&ctlr->dev, "queue remove failed\n");
@@ -2272,7 +2266,8 @@ void spi_unregister_controller(struct spi_controller *ctlr)
device_unregister(&ctlr->dev);
/* free bus id */
mutex_lock(&board_lock);
- idr_remove(&spi_master_idr, id);
+ if (found == ctlr)
+ idr_remove(&spi_master_idr, id);
mutex_unlock(&board_lock);
}
EXPORT_SYMBOL_GPL(spi_unregister_controller);
--
2.16.2
As per the IFC hardware manual, Most significant 2 bytes in
nand_fsr register are the outcome of NAND READ STATUS command.
So status value need to be shifted and aligned as per the nand
framework requirement.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com>
---
drivers/mtd/nand/fsl_ifc_nand.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index d9ce398..951dd89 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -643,12 +643,13 @@ static int fsl_ifc_wait(struct mtd_info *mtd, struct nand_chip *chip)
fsl_ifc_run_command(mtd);
nand_fsr = ifc_in32(&ifc->ifc_nand.nand_fsr);
-
+ nand_fsr >>= 16;
+ nand_fsr = (nand_fsr >> 8) | (nand_fsr << 8);
/*
* The chip always seems to report that it is
* write-protected, even when it is not.
*/
- return nand_fsr | NAND_STATUS_WP;
+ return (nand_fsr & 0xff) | NAND_STATUS_WP;
}
/*
--
1.9.1
USB controller ASM1042 stops working after commit de3ef1eb1cd0 ("PM /
core: Drop run_wake flag from struct dev_pm_info").
The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Before the commit, the device never gets runtime suspended. After the
commit, the device gets runtime suspended, so it does not respond to any
PME#.
usb_hcd_pci_probe() mandatorily calls device_wakeup_enable(), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.
So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.
Fixes: de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct dev_pm_info")
Cc: stable(a)vger.kernel.org # 4.13+
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
---
drivers/pci/pci.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd10d9b0..e026d8f313ec 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2125,16 +2125,13 @@ bool pci_dev_run_wake(struct pci_dev *dev)
{
struct pci_bus *bus = dev->bus;
- if (device_can_wakeup(&dev->dev))
- return true;
-
- if (!dev->pme_support)
- return false;
-
/* PME-capable in principle, but not from the target power state */
- if (!pci_pme_capable(dev, pci_target_state(dev, false)))
+ if (!pci_pme_capable(dev, pci_target_state(dev, true)))
return false;
+ if (device_can_wakeup(&dev->dev))
+ return true;
+
while (bus->parent) {
struct pci_dev *bridge = bus->self;
--
2.15.1