The patch below does not apply to the 4.18-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 bbcda30271752bb7490f2e2aef5411dbcae69116 Mon Sep 17 00:00:00 2001
From: Brian Norris <briannorris(a)chromium.org>
Date: Mon, 8 Oct 2018 19:08:05 -0700
Subject: [PATCH] remoteproc: qcom: q6v5-mss: add SCM probe dependency
The memory ownership transfer request is performed using SCM, ensure
that SCM is available before we probe the driver if memory protection is
needed by the subsystem.
Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch")
Cc: stable(a)vger.kernel.org
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
[bjorn: Added condition for need_mem_protection, updated commit message]
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 3448f1df2e87..4c47f5e0a87c 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1152,6 +1152,9 @@ static int q6v5_probe(struct platform_device *pdev)
if (!desc)
return -EINVAL;
+ if (desc->need_mem_protection && !qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
desc->hexagon_mba_image, sizeof(*qproc));
if (!rproc) {
The patch below does not apply to the 4.19-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 bbcda30271752bb7490f2e2aef5411dbcae69116 Mon Sep 17 00:00:00 2001
From: Brian Norris <briannorris(a)chromium.org>
Date: Mon, 8 Oct 2018 19:08:05 -0700
Subject: [PATCH] remoteproc: qcom: q6v5-mss: add SCM probe dependency
The memory ownership transfer request is performed using SCM, ensure
that SCM is available before we probe the driver if memory protection is
needed by the subsystem.
Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch")
Cc: stable(a)vger.kernel.org
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
[bjorn: Added condition for need_mem_protection, updated commit message]
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 3448f1df2e87..4c47f5e0a87c 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1152,6 +1152,9 @@ static int q6v5_probe(struct platform_device *pdev)
if (!desc)
return -EINVAL;
+ if (desc->need_mem_protection && !qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
desc->hexagon_mba_image, sizeof(*qproc));
if (!rproc) {
The patch below does not apply to the 4.18-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 490d84f6d73c12f4204241cff8651eed60aae914 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Mon, 15 Oct 2018 06:14:22 -0400
Subject: [PATCH] media: cec: forgot to cancel delayed work
If the wait for completion was interrupted, then make sure to cancel
any delayed work.
This can only happen if a transmit is waiting for a reply, and you press
Ctrl-C or reboot/poweroff or something like that which interrupts the
thread waiting for the reply and then proceeds to delete the CEC message.
Since the delayed work wasn't canceled, once it would trigger it referred
to stale data and resulted in a kernel oops.
Fixes: 7ec2b3b941a6 ("cec: add new tx/rx status bits to detect aborts/timeouts")
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: <stable(a)vger.kernel.org> # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 0c0d9107383e..31d1f4ab915e 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -844,6 +844,8 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
*/
mutex_unlock(&adap->lock);
wait_for_completion_killable(&data->c);
+ if (!data->completed)
+ cancel_delayed_work_sync(&data->work);
mutex_lock(&adap->lock);
/* Cancel the transmit if it was interrupted */
The patch below does not apply to the 4.19-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 490d84f6d73c12f4204241cff8651eed60aae914 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Mon, 15 Oct 2018 06:14:22 -0400
Subject: [PATCH] media: cec: forgot to cancel delayed work
If the wait for completion was interrupted, then make sure to cancel
any delayed work.
This can only happen if a transmit is waiting for a reply, and you press
Ctrl-C or reboot/poweroff or something like that which interrupts the
thread waiting for the reply and then proceeds to delete the CEC message.
Since the delayed work wasn't canceled, once it would trigger it referred
to stale data and resulted in a kernel oops.
Fixes: 7ec2b3b941a6 ("cec: add new tx/rx status bits to detect aborts/timeouts")
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: <stable(a)vger.kernel.org> # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 0c0d9107383e..31d1f4ab915e 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -844,6 +844,8 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
*/
mutex_unlock(&adap->lock);
wait_for_completion_killable(&data->c);
+ if (!data->completed)
+ cancel_delayed_work_sync(&data->work);
mutex_lock(&adap->lock);
/* Cancel the transmit if it was interrupted */
The patch below does not apply to the 4.4-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 250854eed5d45a73d81e4137dfd85180af6f2ec3 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Mon, 8 Oct 2018 15:08:27 -0400
Subject: [PATCH] media: v4l2-tpg: fix kernel oops when enabling HFLIP and OSD
When the OSD is on (i.e. vivid displays text on top of the test pattern), and
you enable hflip, then the driver crashes.
The cause turned out to be a division of a negative number by an unsigned value.
You expect that -8 / 2U would be -4, but in reality it is 2147483644 :-(
Fixes: 3e14e7a82c1ef ("vivid-tpg: add hor/vert downsampling support to tpg_gen_text")
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Reported-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
Cc: <stable(a)vger.kernel.org> # for v4.1 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 76b125ebee6d..fa483b95bc5a 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -1801,7 +1801,7 @@ typedef struct { u16 __; u8 _; } __packed x24;
pos[7] = (chr & (0x01 << 0) ? fg : bg); \
} \
\
- pos += (tpg->hflip ? -8 : 8) / hdiv; \
+ pos += (tpg->hflip ? -8 : 8) / (int)hdiv; \
} \
} \
} while (0)
The patch below does not apply to the 4.4-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 ef739b2175dde9c05594f768cb78149f1ce2ac36 Mon Sep 17 00:00:00 2001
From: Chuck Lever <chuck.lever(a)oracle.com>
Date: Mon, 1 Oct 2018 14:25:14 -0400
Subject: [PATCH] xprtrdma: Reset credit grant properly after a disconnect
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com>
Cc: stable(a)kernel.org
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
index a68180090554..b9827665ff35 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 143ce2579ba9..98cbc7b060ba 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+ * its credit grant to one (see RFC 8166, Section 3.3.3).
+ */
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
The patch below does not apply to the 4.9-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 ef739b2175dde9c05594f768cb78149f1ce2ac36 Mon Sep 17 00:00:00 2001
From: Chuck Lever <chuck.lever(a)oracle.com>
Date: Mon, 1 Oct 2018 14:25:14 -0400
Subject: [PATCH] xprtrdma: Reset credit grant properly after a disconnect
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com>
Cc: stable(a)kernel.org
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
index a68180090554..b9827665ff35 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 143ce2579ba9..98cbc7b060ba 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+ * its credit grant to one (see RFC 8166, Section 3.3.3).
+ */
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
Fix a commit 8a8158c85e1e ("MIPS: memset.S: EVA & fault support for
small_memset") regression and remove assembly warnings:
arch/mips/lib/memset.S: Assembler messages:
arch/mips/lib/memset.S:243: Warning: Macro instruction expanded into multiple instructions in a branch delay slot
triggering with the CPU_DADDI_WORKAROUNDS option set and this code:
PTR_SUBU a2, t1, a0
jr ra
PTR_ADDIU a2, 1
This is because with that option in place the DADDIU instruction, which
the PTR_ADDIU CPP macro expands to, becomes a GAS macro, which in turn
expands to an LI/DADDU (or actually ADDIU/DADDU) sequence:
13c: 01a4302f dsubu a2,t1,a0
140: 03e00008 jr ra
144: 24010001 li at,1
148: 00c1302d daddu a2,a2,at
...
Correct this by switching off the `noreorder' assembly mode and letting
GAS schedule this jump's delay slot, as there is nothing special about
it that would require manual scheduling. With this change in place
correct code is produced:
13c: 01a4302f dsubu a2,t1,a0
140: 24010001 li at,1
144: 03e00008 jr ra
148: 00c1302d daddu a2,a2,at
...
Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org>
Fixes: 8a8158c85e1e ("MIPS: memset.S: EVA & fault support for small_memset")
Cc: stable(a)vger.kernel.org # 4.17+
---
Hi,
This is a version (one I originally made actually) of commit 148b9aba99e0
for 4.18-stable and before. No functional changes. Please apply.
Maciej
---
arch/mips/lib/memset.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
linux-mips-memset-jr-ra-nodaddi-fix.patch
Index: linux-20180812-4maxp64-defconfig/arch/mips/lib/memset.S
===================================================================
--- linux-20180812-4maxp64-defconfig.orig/arch/mips/lib/memset.S
+++ linux-20180812-4maxp64-defconfig/arch/mips/lib/memset.S
@@ -261,9 +261,11 @@
nop
.Lsmall_fixup\@:
+ .set reorder
PTR_SUBU a2, t1, a0
+ PTR_ADDIU a2, 1
jr ra
- PTR_ADDIU a2, 1
+ .set noreorder
.endm
The patch below does not apply to the 4.14-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 bc276ecba132caccb1fda5863a652c15def2b8c6 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Mon, 27 Aug 2018 13:03:01 +1000
Subject: [PATCH] powerpc/64s/hash: Do not use PPC_INVALIDATE_ERAT on CPUs
before POWER9
PPC_INVALIDATE_ERAT is slbia IH=7 which is a new variant introduced
with POWER9, and the result is undefined on earlier CPUs.
Commits 7b9f71f974 ("powerpc/64s: POWER9 machine check handler") and
d4748276ae ("powerpc/64s: Improve local TLB flush for boot and MCE on
POWER9") caused POWER7/8 code to use this instruction. Remove it. An
ERAT flush can be made by invalidatig the SLB, but before POWER9 that
requires a flush and rebolt.
Fixes: 7b9f71f974 ("powerpc/64s: POWER9 machine check handler")
Fixes: d4748276ae ("powerpc/64s: Improve local TLB flush for boot and MCE on POWER9")
Cc: stable(a)vger.kernel.org # v4.11+
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index 2016b58d564f..6b800eec31f2 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -89,6 +89,13 @@ void flush_and_reload_slb(void)
static void flush_erat(void)
{
+#ifdef CONFIG_PPC_BOOK3S_64
+ if (!early_cpu_has_feature(CPU_FTR_ARCH_300)) {
+ flush_and_reload_slb();
+ return;
+ }
+#endif
+ /* PPC_INVALIDATE_ERAT can only be used on ISA v3 and newer */
asm volatile(PPC_INVALIDATE_ERAT : : :"memory");
}
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 729f02df8290..aaa28fd918fe 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -115,6 +115,8 @@ static void tlbiel_all_isa300(unsigned int num_sets, unsigned int is)
tlbiel_hash_set_isa300(0, is, 0, 2, 1);
asm volatile("ptesync": : :"memory");
+
+ asm volatile(PPC_INVALIDATE_ERAT "; isync" : : :"memory");
}
void hash__tlbiel_all(unsigned int action)
@@ -140,8 +142,6 @@ void hash__tlbiel_all(unsigned int action)
tlbiel_all_isa206(POWER7_TLB_SETS, is);
else
WARN(1, "%s called on pre-POWER7 CPU\n", __func__);
-
- asm volatile(PPC_INVALIDATE_ERAT "; isync" : : :"memory");
}
static inline unsigned long ___tlbie(unsigned long vpn, int psize,
The patch below does not apply to the 4.18-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 59fe7eaf3598a89cbcd72e645b1d08afd76f7b29 Mon Sep 17 00:00:00 2001
From: "Naveen N. Rao" <naveen.n.rao(a)linux.vnet.ibm.com>
Date: Tue, 29 May 2018 12:21:00 +0530
Subject: [PATCH] powerpc64/module elfv1: Set opd addresses after module
relocation
module_frob_arch_sections() is called before the module is moved to its
final location. The function descriptor section addresses we are setting
here are thus invalid. Fix this by processing opd section during
module_finalize()
Fixes: 5633e85b2c313 ("powerpc64: Add .opd based function descriptor dereference")
Cc: stable(a)vger.kernel.org # v4.16
Signed-off-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index 77371c9ef3d8..2d861a36662e 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -74,6 +74,14 @@ int module_finalize(const Elf_Ehdr *hdr,
(void *)sect->sh_addr + sect->sh_size);
#endif /* CONFIG_PPC64 */
+#ifdef PPC64_ELF_ABI_v1
+ sect = find_section(hdr, sechdrs, ".opd");
+ if (sect != NULL) {
+ me->arch.start_opd = sect->sh_addr;
+ me->arch.end_opd = sect->sh_addr + sect->sh_size;
+ }
+#endif /* PPC64_ELF_ABI_v1 */
+
#ifdef CONFIG_PPC_BARRIER_NOSPEC
sect = find_section(hdr, sechdrs, "__spec_barrier_fixup");
if (sect != NULL)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index b8d61e019d06..2c53de9f3b6a 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -360,11 +360,6 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
else if (strcmp(secstrings+sechdrs[i].sh_name,"__versions")==0)
dedotify_versions((void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size);
- else if (!strcmp(secstrings + sechdrs[i].sh_name, ".opd")) {
- me->arch.start_opd = sechdrs[i].sh_addr;
- me->arch.end_opd = sechdrs[i].sh_addr +
- sechdrs[i].sh_size;
- }
/* We don't handle .init for the moment: rename to _init */
while ((p = strstr(secstrings + sechdrs[i].sh_name, ".init")))
The patch below does not apply to the 4.14-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 786fa584eda86d6598db3b87c61dc81f68808d11 Mon Sep 17 00:00:00 2001
From: Lubomir Rintel <lkundrak(a)v3.sk>
Date: Thu, 4 Oct 2018 17:29:03 -0400
Subject: [PATCH] media: ov7670: make "xclk" clock optional
When the "xclk" clock was added, it was made mandatory. This broke the
driver on an OLPC plaform which doesn't know such clock. Make it
optional.
Tested on a OLPC XO-1 laptop.
Fixes: 0a024d634cee ("[media] ov7670: get xclk")
Cc: stable(a)vger.kernel.org # 4.11+
Signed-off-by: Lubomir Rintel <lkundrak(a)v3.sk>
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 92f59ae1b624..bc68a3a5b4ec 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1808,17 +1808,24 @@ static int ov7670_probe(struct i2c_client *client,
info->pclk_hb_disable = true;
}
- info->clk = devm_clk_get(&client->dev, "xclk");
- if (IS_ERR(info->clk))
- return PTR_ERR(info->clk);
- ret = clk_prepare_enable(info->clk);
- if (ret)
- return ret;
+ info->clk = devm_clk_get(&client->dev, "xclk"); /* optional */
+ if (IS_ERR(info->clk)) {
+ ret = PTR_ERR(info->clk);
+ if (ret == -ENOENT)
+ info->clk = NULL;
+ else
+ return ret;
+ }
+ if (info->clk) {
+ ret = clk_prepare_enable(info->clk);
+ if (ret)
+ return ret;
- info->clock_speed = clk_get_rate(info->clk) / 1000000;
- if (info->clock_speed < 10 || info->clock_speed > 48) {
- ret = -EINVAL;
- goto clk_disable;
+ info->clock_speed = clk_get_rate(info->clk) / 1000000;
+ if (info->clock_speed < 10 || info->clock_speed > 48) {
+ ret = -EINVAL;
+ goto clk_disable;
+ }
}
ret = ov7670_init_gpio(client, info);
The patch below does not apply to the 4.14-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 84b59f6487d82d3ab4247a099aba66d4d17e8b08 Mon Sep 17 00:00:00 2001
From: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Date: Mon, 3 Sep 2018 04:01:26 +0300
Subject: [PATCH] tpm: fix response size validation in tpm_get_random()
When checking whether the response is large enough to be able to contain
the received random bytes in tpm_get_random() and tpm2_get_random(),
they fail to take account the header size, which should be added to the
minimum size. This commit fixes this issue.
Cc: stable(a)vger.kernel.org
Fixes: c659af78eb7b ("tpm: Check size of response before accessing data")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1a803b0cf980..318a7078b2ba 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1321,7 +1321,8 @@ int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
}
rlength = be32_to_cpu(tpm_cmd.header.out.length);
- if (rlength < offsetof(struct tpm_getrandom_out, rng_data) +
+ if (rlength < TPM_HEADER_SIZE +
+ offsetof(struct tpm_getrandom_out, rng_data) +
recd) {
total = -EFAULT;
break;
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index c31b490bd41d..3acf4fd4e5a5 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -329,7 +329,9 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
&buf.data[TPM_HEADER_SIZE];
recd = min_t(u32, be16_to_cpu(out->size), num_bytes);
if (tpm_buf_length(&buf) <
- offsetof(struct tpm2_get_random_out, buffer) + recd) {
+ TPM_HEADER_SIZE +
+ offsetof(struct tpm2_get_random_out, buffer) +
+ recd) {
err = -EFAULT;
goto out;
}
The patch below does not apply to the 4.18-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 84b59f6487d82d3ab4247a099aba66d4d17e8b08 Mon Sep 17 00:00:00 2001
From: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Date: Mon, 3 Sep 2018 04:01:26 +0300
Subject: [PATCH] tpm: fix response size validation in tpm_get_random()
When checking whether the response is large enough to be able to contain
the received random bytes in tpm_get_random() and tpm2_get_random(),
they fail to take account the header size, which should be added to the
minimum size. This commit fixes this issue.
Cc: stable(a)vger.kernel.org
Fixes: c659af78eb7b ("tpm: Check size of response before accessing data")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1a803b0cf980..318a7078b2ba 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1321,7 +1321,8 @@ int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
}
rlength = be32_to_cpu(tpm_cmd.header.out.length);
- if (rlength < offsetof(struct tpm_getrandom_out, rng_data) +
+ if (rlength < TPM_HEADER_SIZE +
+ offsetof(struct tpm_getrandom_out, rng_data) +
recd) {
total = -EFAULT;
break;
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index c31b490bd41d..3acf4fd4e5a5 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -329,7 +329,9 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
&buf.data[TPM_HEADER_SIZE];
recd = min_t(u32, be16_to_cpu(out->size), num_bytes);
if (tpm_buf_length(&buf) <
- offsetof(struct tpm2_get_random_out, buffer) + recd) {
+ TPM_HEADER_SIZE +
+ offsetof(struct tpm2_get_random_out, buffer) +
+ recd) {
err = -EFAULT;
goto out;
}
On Tue, Jan 2, 2018 at 12:48 PM, kernelci.org bot <bot(a)kernelci.org> wrote:
Hi Ben,
almost a clean build with kernelci!
> Errors summary:
> 1 drivers/scsi/mpt2sas/mpt2sas_base.c:3550:1: internal compiler error: in extract_constrain_insn, at recog.c:2190
> 1 drivers/scsi/mpt2sas/mpt2sas_base.c:3550:1: error: insn does not satisfy its constraints:
See earlier discussion https://www.spinics.net/lists/stable/msg195996.html
> Warnings summary:
> 54 include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
This comes from an incorrect backport of commit
49e67dd17649 ("of: fdt: add missing allocation-failure check")
It's harmless, and stable/linux-3.18.y has the correct version:
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -380,6 +380,6 @@ static void __unflatten_device_tree(void *blob,
/* Allocate memory for the expanded device tree */
mem = dt_alloc(size + 4, __alignof__(struct device_node));
if (!mem)
- return NULL;
+ return;
memset(mem, 0, size);
> 2 ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
This code was last touched in 3.16 by the backport of commit
5864a2fd3088 ("ipc/sem.c: fix complex_count vs. simple op race")
The warning is in "smp_load_acquire(&sma->complex_mode))", and I suspect
that commit 27d7be1801a4 ("ipc/sem.c: avoid using spin_unlock_wait()")
avoided the warning upstream by removing the smp_mb() before it.
The code is way too complex for a fly-by analysis, so I'm adding Manfred
to Cc here. It may be worth comparing the full list of backports that
went into ipc/sem.c in 3.16.y with those in 3.18.y and 4.1.y that don't
have the warning. Here is what I see in the git history:
$ git log --oneline v3.16..stable/linux-3.16.y ipc/sem.c
accb9f16adba ipc/sem.c: fix complex_count vs. simple op race
5b11c133308b ipc: remove use of seq_printf return value
08397b1a5cd4 sysv, ipc: fix security-layer leaking
35cfc2b3a9da ipc/sem.c: fully initialize sem_array before making it visible
69a9a86b645f ipc/sem.c: update/correct memory barriers
30f995ba77ca ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
76ce4fe19d6b ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
$ git log --oneline v3.16..stable/linux-3.18.y ipc/sem.c
7dd90826dfba sysv, ipc: fix security-layer leaking
ff12efa03da1 ipc/sem.c: update/correct memory barriers
38b50c47c25e ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible
$ git log --oneline v3.16..stable/linux-4.1.y ipc/sem.c
e2b438fdfa4d sysv, ipc: fix security-layer leaking
b6805da60f01 ipc/sem.c: update/correct memory barriers
7be83cf01024 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible
$ git log --oneline v3.16..stable/linux-4.4.y ipc/sem.c
f6031d95320d ipc/sem.c: fix complex_count vs. simple op race
62659f0b9ed7 sysv, ipc: fix security-layer leaking
3ed1f8a99d70 ipc/sem.c: update/correct memory barriers
a97955844807 ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
602b8593d2b4 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
55b7ae50167e ipc: rename ipc_obtain_object
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible
$ git log --oneline v3.16..stable/linux-4.9.y ipc/sem.c
2a1613a586de ipc/sem.c: add cond_resched in exit_sme
5864a2fd3088 ipc/sem.c: fix complex_count vs. simple op race
9b24fef9f041 sysv, ipc: fix security-layer leaking
be3e78449803 locking/spinlock: Update spin_unlock_wait() users
33ac279677dc locking/barriers: Introduce smp_acquire__after_ctrl_dep()
a5f4db877177 ipc/sem: make semctl setting sempid consistent
1d5cfdb07628 tree wide: use kvfree() than conditional kfree()/vfree()
3ed1f8a99d70 ipc/sem.c: update/correct memory barriers
a97955844807 ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
602b8593d2b4 ipc,sem: fix use after free on IPC_RMID after a task
using same semaphore set exits
55b7ae50167e ipc: rename ipc_obtain_object
7f032d6ef615 ipc: remove use of seq_printf return value
52644c9ab3fa ipc,sem: use current->state helpers
2e094abfd1f2 ipc/sem.c: change memory barrier in sem_lock() to smp_rmb()
e8577d1f0329 ipc/sem.c: fully initialize sem_array before making it visible
> 1 arch/arm/kernel/head-nommu.S:167: Warning: Use of r13 as a source register is deprecated when r15 is the destination register.
Fixed by backporting:
970d96f9a81b ("ARM: 8383/1: nommu: avoid deprecated source register on mov")
Arnd
The patch below does not apply to the 4.19-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 32a1fb36f6e50183871c2c1fcf5493c633e84732 Mon Sep 17 00:00:00 2001
From: Ronnie Sahlberg <lsahlber(a)redhat.com>
Date: Wed, 24 Oct 2018 11:50:33 +1000
Subject: [PATCH] cifs: allow calling SMB2_xxx_free(NULL)
Change these free functions to allow passing NULL as the argument and
treat it as a no-op just like free(NULL) would.
Or, if rqst->rq_iov is NULL.
The second scenario could happen for smb2_queryfs() if the call
to SMB2_query_info_init() fails and we go to qfs_exit to clean up
and free all resources.
In that case we have not yet assigned rqst[2].rq_iov and thus
the rq_iov dereference in SMB2_close_free() will cause a NULL pointer
dereference.
Fixes: 1eb9fb52040f ("cifs: create SMB2_open_init()/SMB2_open_free() helpers")
Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com>
Signed-off-by: Steve French <stfrench(a)microsoft.com>
Reviewed-by: Aurelien Aptel <aaptel(a)suse.com>
CC: Stable <stable(a)vger.kernel.org>
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 5a08c8f6a322..7d7b016fe8bb 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -2243,10 +2243,12 @@ SMB2_open_free(struct smb_rqst *rqst)
{
int i;
- cifs_small_buf_release(rqst->rq_iov[0].iov_base);
- for (i = 1; i < rqst->rq_nvec; i++)
- if (rqst->rq_iov[i].iov_base != smb2_padding)
- kfree(rqst->rq_iov[i].iov_base);
+ if (rqst && rqst->rq_iov) {
+ cifs_small_buf_release(rqst->rq_iov[0].iov_base);
+ for (i = 1; i < rqst->rq_nvec; i++)
+ if (rqst->rq_iov[i].iov_base != smb2_padding)
+ kfree(rqst->rq_iov[i].iov_base);
+ }
}
int
@@ -2536,7 +2538,8 @@ SMB2_close_init(struct cifs_tcon *tcon, struct smb_rqst *rqst,
void
SMB2_close_free(struct smb_rqst *rqst)
{
- cifs_small_buf_release(rqst->rq_iov[0].iov_base); /* request */
+ if (rqst && rqst->rq_iov)
+ cifs_small_buf_release(rqst->rq_iov[0].iov_base); /* request */
}
int
@@ -2689,7 +2692,8 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct smb_rqst *rqst,
void
SMB2_query_info_free(struct smb_rqst *rqst)
{
- cifs_small_buf_release(rqst->rq_iov[0].iov_base); /* request */
+ if (rqst && rqst->rq_iov)
+ cifs_small_buf_release(rqst->rq_iov[0].iov_base); /* request */
}
static int
@@ -3803,7 +3807,8 @@ SMB2_set_info_init(struct cifs_tcon *tcon, struct smb_rqst *rqst,
void
SMB2_set_info_free(struct smb_rqst *rqst)
{
- cifs_buf_release(rqst->rq_iov[0].iov_base); /* request */
+ if (rqst && rqst->rq_iov)
+ cifs_buf_release(rqst->rq_iov[0].iov_base); /* request */
}
static int
The patch below does not apply to the 4.9-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 da5a3ce66b8bb51b0ea8a89f42aac153903f90fb Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Wed, 17 Oct 2018 17:42:10 +0100
Subject: [PATCH] KVM: arm64: Fix caching of host MDCR_EL2 value
At boot time, KVM stashes the host MDCR_EL2 value, but only does this
when the kernel is not running in hyp mode (i.e. is non-VHE). In these
cases, the stashed value of MDCR_EL2.HPMN happens to be zero, which can
lead to CONSTRAINED UNPREDICTABLE behaviour.
Since we use this value to derive the MDCR_EL2 value when switching
to/from a guest, after a guest have been run, the performance counters
do not behave as expected. This has been observed to result in accesses
via PMXEVTYPER_EL0 and PMXEVCNTR_EL0 not affecting the relevant
counters, resulting in events not being counted. In these cases, only
the fixed-purpose cycle counter appears to work as expected.
Fix this by always stashing the host MDCR_EL2 value, regardless of VHE.
Cc: Christopher Dall <christoffer.dall(a)arm.com>
Cc: James Morse <james.morse(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: stable(a)vger.kernel.org
Fixes: 1e947bad0b63b351 ("arm64: KVM: Skip HYP setup when already running in HYP")
Tested-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 4ce99bb223bc..4c5ff06b18f9 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1296,8 +1296,6 @@ static void cpu_init_hyp_mode(void *dummy)
__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
__cpu_init_stage2();
-
- kvm_arm_init_debug();
}
static void cpu_hyp_reset(void)
@@ -1315,6 +1313,8 @@ static void cpu_hyp_reinit(void)
else
cpu_init_hyp_mode(NULL);
+ kvm_arm_init_debug();
+
if (vgic_present)
kvm_vgic_init_cpu_hardware();
}
On Fri, Feb 16, 2018 at 7:21 PM, kbuild test robot
<fengguang.wu(a)intel.com> wrote:
> Hi Andrey,
>
> It's probably a bug fix that unveils the link errors.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.16.y
> head: 0b9f4cdd4d75131d8886b919bbf6e0c98906d36e
> commit: 3cb0dc19883f0c69225311d4f76aa8128d3681a4 [2872/3488] module: fix types of device tables aliases
> config: x86_64-allmodconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout 3cb0dc19883f0c69225311d4f76aa8128d3681a4
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
> arch/x86/kernel/head64.o: In function `_GLOBAL__sub_D_00100_1_early_pmd_flags':
>>> head64.c:(.text.exit+0x5): undefined reference to `__gcov_exit'
> arch/x86/kernel/head.o: In function `_GLOBAL__sub_D_00100_1_reserve_ebda_region':
> head.c:(.text.exit+0x5): undefined reference to `__gcov_exit'
> init/built-in.o: In function `_GLOBAL__sub_D_00100_1___ksymtab_system_state':
> main.c:(.text.exit+0x5): undefined reference to `__gcov_exit'
> init/built-in.o: In function `_GLOBAL__sub_D_00100_1_root_mountflags':
> do_mounts.c:(.text.exit+0x10): undefined reference to `__gcov_exit'
> init/built-in.o: In function `_GLOBAL__sub_D_00100_1_initrd_load':
> do_mounts_initrd.c:(.text.exit+0x1b): undefined reference to `__gcov_exit'
> init/built-in.o:initramfs.c:(.text.exit+0x26): more undefined references to `__gcov_exit' follow
I think this is a result of using a too new compiler with the old 3.16
kernel. In order
to build with gcc-7.3, you need to backport
05384213436a ("gcov: support GCC 7.1")
It's already part of stable-3.18 and later, but not 3.2 and 3.16.
Arnd
The patch below does not apply to the 4.18-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 7d867a1b765e2b70815fec4964d7822a976ed349 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Fri, 5 Oct 2018 08:00:21 -0400
Subject: [PATCH] media: cec: fix the Signal Free Time calculation
The calculation of the Signal Free Time in the framework was not
correct. If a message was received, then the next transmit should be
considered a New Initiator and use a shorter SFT value.
This was not done with the result that if both sides where continually
sending messages, they both could use the same SFT value and one side
could deny the other side access to the bus.
Note that this fix does not take the corner case into account where
a receive is in progress when you call adap_transmit.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: <stable(a)vger.kernel.org> # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index e6e82b504e56..0c0d9107383e 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -526,9 +526,11 @@ int cec_thread_func(void *_adap)
if (data->attempts) {
/* should be >= 3 data bit periods for a retry */
signal_free_time = CEC_SIGNAL_FREE_TIME_RETRY;
- } else if (data->new_initiator) {
+ } else if (adap->last_initiator !=
+ cec_msg_initiator(&data->msg)) {
/* should be >= 5 data bit periods for new initiator */
signal_free_time = CEC_SIGNAL_FREE_TIME_NEW_INITIATOR;
+ adap->last_initiator = cec_msg_initiator(&data->msg);
} else {
/*
* should be >= 7 data bit periods for sending another
@@ -713,7 +715,6 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
struct cec_fh *fh, bool block)
{
struct cec_data *data;
- u8 last_initiator = 0xff;
msg->rx_ts = 0;
msg->tx_ts = 0;
@@ -823,23 +824,6 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
data->adap = adap;
data->blocking = block;
- /*
- * Determine if this message follows a message from the same
- * initiator. Needed to determine the free signal time later on.
- */
- if (msg->len > 1) {
- if (!(list_empty(&adap->transmit_queue))) {
- const struct cec_data *last;
-
- last = list_last_entry(&adap->transmit_queue,
- const struct cec_data, list);
- last_initiator = cec_msg_initiator(&last->msg);
- } else if (adap->transmitting) {
- last_initiator =
- cec_msg_initiator(&adap->transmitting->msg);
- }
- }
- data->new_initiator = last_initiator != cec_msg_initiator(msg);
init_completion(&data->c);
INIT_DELAYED_WORK(&data->work, cec_wait_timeout);
@@ -1027,6 +1011,8 @@ void cec_received_msg_ts(struct cec_adapter *adap,
mutex_lock(&adap->lock);
dprintk(2, "%s: %*ph\n", __func__, msg->len, msg->msg);
+ adap->last_initiator = 0xff;
+
/* Check if this message was for us (directed or broadcast). */
if (!cec_msg_is_broadcast(msg))
valid_la = cec_has_log_addr(adap, msg_dest);
@@ -1489,6 +1475,8 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
}
mutex_lock(&adap->devnode.lock);
+ adap->last_initiator = 0xff;
+
if ((adap->needs_hpd || list_empty(&adap->devnode.fhs)) &&
adap->ops->adap_enable(adap, true)) {
mutex_unlock(&adap->devnode.lock);
diff --git a/include/media/cec.h b/include/media/cec.h
index 9f382f0c2970..254a610b9aa5 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -63,7 +63,6 @@ struct cec_data {
struct delayed_work work;
struct completion c;
u8 attempts;
- bool new_initiator;
bool blocking;
bool completed;
};
@@ -174,6 +173,7 @@ struct cec_adapter {
bool is_configuring;
bool is_configured;
bool cec_pin_is_high;
+ u8 last_initiator;
u32 monitor_all_cnt;
u32 monitor_pin_cnt;
u32 follower_cnt;
The patch below does not apply to the 4.19-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 7d867a1b765e2b70815fec4964d7822a976ed349 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Fri, 5 Oct 2018 08:00:21 -0400
Subject: [PATCH] media: cec: fix the Signal Free Time calculation
The calculation of the Signal Free Time in the framework was not
correct. If a message was received, then the next transmit should be
considered a New Initiator and use a shorter SFT value.
This was not done with the result that if both sides where continually
sending messages, they both could use the same SFT value and one side
could deny the other side access to the bus.
Note that this fix does not take the corner case into account where
a receive is in progress when you call adap_transmit.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: <stable(a)vger.kernel.org> # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index e6e82b504e56..0c0d9107383e 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -526,9 +526,11 @@ int cec_thread_func(void *_adap)
if (data->attempts) {
/* should be >= 3 data bit periods for a retry */
signal_free_time = CEC_SIGNAL_FREE_TIME_RETRY;
- } else if (data->new_initiator) {
+ } else if (adap->last_initiator !=
+ cec_msg_initiator(&data->msg)) {
/* should be >= 5 data bit periods for new initiator */
signal_free_time = CEC_SIGNAL_FREE_TIME_NEW_INITIATOR;
+ adap->last_initiator = cec_msg_initiator(&data->msg);
} else {
/*
* should be >= 7 data bit periods for sending another
@@ -713,7 +715,6 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
struct cec_fh *fh, bool block)
{
struct cec_data *data;
- u8 last_initiator = 0xff;
msg->rx_ts = 0;
msg->tx_ts = 0;
@@ -823,23 +824,6 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
data->adap = adap;
data->blocking = block;
- /*
- * Determine if this message follows a message from the same
- * initiator. Needed to determine the free signal time later on.
- */
- if (msg->len > 1) {
- if (!(list_empty(&adap->transmit_queue))) {
- const struct cec_data *last;
-
- last = list_last_entry(&adap->transmit_queue,
- const struct cec_data, list);
- last_initiator = cec_msg_initiator(&last->msg);
- } else if (adap->transmitting) {
- last_initiator =
- cec_msg_initiator(&adap->transmitting->msg);
- }
- }
- data->new_initiator = last_initiator != cec_msg_initiator(msg);
init_completion(&data->c);
INIT_DELAYED_WORK(&data->work, cec_wait_timeout);
@@ -1027,6 +1011,8 @@ void cec_received_msg_ts(struct cec_adapter *adap,
mutex_lock(&adap->lock);
dprintk(2, "%s: %*ph\n", __func__, msg->len, msg->msg);
+ adap->last_initiator = 0xff;
+
/* Check if this message was for us (directed or broadcast). */
if (!cec_msg_is_broadcast(msg))
valid_la = cec_has_log_addr(adap, msg_dest);
@@ -1489,6 +1475,8 @@ void __cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, bool block)
}
mutex_lock(&adap->devnode.lock);
+ adap->last_initiator = 0xff;
+
if ((adap->needs_hpd || list_empty(&adap->devnode.fhs)) &&
adap->ops->adap_enable(adap, true)) {
mutex_unlock(&adap->devnode.lock);
diff --git a/include/media/cec.h b/include/media/cec.h
index 9f382f0c2970..254a610b9aa5 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -63,7 +63,6 @@ struct cec_data {
struct delayed_work work;
struct completion c;
u8 attempts;
- bool new_initiator;
bool blocking;
bool completed;
};
@@ -174,6 +173,7 @@ struct cec_adapter {
bool is_configuring;
bool is_configured;
bool cec_pin_is_high;
+ u8 last_initiator;
u32 monitor_all_cnt;
u32 monitor_pin_cnt;
u32 follower_cnt;
Please apply the follow patch from kernel 4.18 to kernel 4.14
Commit: a7f58b9ecfd3c0f63703ec10f4a592cc38dbd1b8
This patch fixes a performance issue with some devices being accessed using
the Volume Management Device (vmd). I have included an updated copy of the
patch because the parent directory of the file has changed between the 4.14
and 4.18 releases
4.14: drivers/pci/host/vmd.c
4.18: drivers/pci/controller/vmd.c
Thank you,
Kenneth Heitke <Kenneth.heitke(a)intel.com>
---
From: Keith Busch <keith.busch(a)intel.com>
Date: Tue, 8 May 2018 10:00:22 -0600
Subject: [PATCH] PCI: vmd: White list for fast interrupt handlers
Devices with slow interrupt handlers are significantly harming
performance when their interrupt vector is shared with a fast device.
Create a class code white list for devices with known fast interrupt
handlers and let all other devices share a single vector so that they
don't interfere with performance.
At the moment, only the NVM Express class code is on the list, but more
may be added if VMD users desire to use other low-latency devices in
these domains.
Signed-off-by: Keith Busch <keith.busch(a)intel.com>
[lorenzo.pieralisi(a)arm.com: changelog]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Acked-by: Jon Derrick: <jonathan.derrick(a)intel.com>
---
drivers/pci/host/vmd.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/vmd.c b/drivers/pci/host/vmd.c
index 509893b..2537b02 100644
--- a/drivers/pci/host/vmd.c
+++ b/drivers/pci/host/vmd.c
@@ -183,9 +183,20 @@ static struct vmd_irq_list *vmd_next_irq(struct vmd_dev *vmd, struct msi_desc *d
int i, best = 1;
unsigned long flags;
- if (pci_is_bridge(msi_desc_to_pci_dev(desc)) || vmd->msix_count == 1)
+ if (vmd->msix_count == 1)
return &vmd->irqs[0];
+ /*
+ * White list for fast-interrupt handlers. All others will share the
+ * "slow" interrupt vector.
+ */
+ switch (msi_desc_to_pci_dev(desc)->class) {
+ case PCI_CLASS_STORAGE_EXPRESS:
+ break;
+ default:
+ return &vmd->irqs[0];
+ }
+
raw_spin_lock_irqsave(&list_lock, flags);
for (i = 1; i < vmd->msix_count; i++)
if (vmd->irqs[i].count < vmd->irqs[best].count)
--
2.7.4
In September last year, Ben Hutchings submitted commit [9547837bdccb]
for 3.16.48-rc1 and I informed him that it would be useless without
[3f3752705dbd] (and that maybe [c3883fe06488] would be useful as well).
Ben dropped the patch but suggested I email this list with the
information of the other two patches but I never quite got around to it.
Now I see Sasha Levin is submitting [3f3752705dbd] and [c3883fe06488]
for 4.9, 4.4 and 3.18 it would now make sense to include [9547837bdccb].
This patch fixes a minor problem where a certain USB adapter for Sega
Genesis controllers appears as one input device when it has two ports
for two controllers. I imagine some users of emulator distributions
might use stable kernels and might benefit from this fix.
I'm actually not entirely sure that patch is something suitable for
stable but since it was already submitted once then I don't think it
hurts to bring it up again (despite it breaking stable-kernel-rules as
far as I understand it).
Commits mentioned:
[9547837bdccb]: HID: usbhid: add quirk for innomedia INNEX GENESIS/ATARI adapter
[3f3752705dbd]: HID: reject input outside logical range only if null state is set
[c3883fe06488]: HID: clamp input to logical range if no null state
If the patch [9547837bdccb] is not relevant then feel free to ignore
this email.
Thanks,
--
Tomasz Kramkowski
The patch below does not apply to the 3.18-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 aeae4f3e5c38d47bdaef50446dc0ec857307df68 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Tue, 4 Sep 2018 12:34:18 -0500
Subject: [PATCH] PCI/ASPM: Fix link_state teardown on device removal
Upon removal of the last device on a bus, the link_state of the bridge
leading to that bus is sought to be torn down by having pci_stop_dev()
call pcie_aspm_exit_link_state().
When ASPM was originally introduced by commit 7d715a6c1ae5 ("PCI: add
PCI Express ASPM support"), it determined whether the device being
removed is the last one by calling list_empty() on the bridge's
subordinate devices list. That didn't work because the device is only
removed from the list slightly later in pci_destroy_dev().
Commit 3419c75e15f8 ("PCI: properly clean up ASPM link state on device
remove") attempted to fix it by calling list_is_last(), but that's not
correct either because it checks whether the device is at the *end* of
the list, not whether it's the last one *left* in the list. If the user
removes the device which happens to be at the end of the list via sysfs
but other devices are preceding the device in the list, the link_state
is torn down prematurely.
The real fix is to move the invocation of pcie_aspm_exit_link_state() to
pci_destroy_dev() and reinstate the call to list_empty(). Remove a
duplicate check for dev->bus->self because pcie_aspm_exit_link_state()
already contains an identical check.
Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Shaohua Li <shaohua.li(a)intel.com>
Cc: stable(a)vger.kernel.org # v2.6.26
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 5326916715d2..f78860ce884b 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -991,7 +991,7 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
* All PCIe functions are in one slot, remove one function will remove
* the whole slot, so just wait until we are the last function left.
*/
- if (!list_is_last(&pdev->bus_list, &parent->subordinate->devices))
+ if (!list_empty(&parent->subordinate->devices))
goto out;
link = parent->link_state;
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 461e7fd2756f..e9c6b120cf45 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -25,9 +25,6 @@ static void pci_stop_dev(struct pci_dev *dev)
pci_dev_assign_added(dev, false);
}
-
- if (dev->bus->self)
- pcie_aspm_exit_link_state(dev);
}
static void pci_destroy_dev(struct pci_dev *dev)
@@ -41,6 +38,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
list_del(&dev->bus_list);
up_write(&pci_bus_sem);
+ pcie_aspm_exit_link_state(dev);
pci_bridge_d3_update(dev);
pci_free_resources(dev);
put_device(&dev->dev);
The patch below does not apply to the 4.4-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 aeae4f3e5c38d47bdaef50446dc0ec857307df68 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Tue, 4 Sep 2018 12:34:18 -0500
Subject: [PATCH] PCI/ASPM: Fix link_state teardown on device removal
Upon removal of the last device on a bus, the link_state of the bridge
leading to that bus is sought to be torn down by having pci_stop_dev()
call pcie_aspm_exit_link_state().
When ASPM was originally introduced by commit 7d715a6c1ae5 ("PCI: add
PCI Express ASPM support"), it determined whether the device being
removed is the last one by calling list_empty() on the bridge's
subordinate devices list. That didn't work because the device is only
removed from the list slightly later in pci_destroy_dev().
Commit 3419c75e15f8 ("PCI: properly clean up ASPM link state on device
remove") attempted to fix it by calling list_is_last(), but that's not
correct either because it checks whether the device is at the *end* of
the list, not whether it's the last one *left* in the list. If the user
removes the device which happens to be at the end of the list via sysfs
but other devices are preceding the device in the list, the link_state
is torn down prematurely.
The real fix is to move the invocation of pcie_aspm_exit_link_state() to
pci_destroy_dev() and reinstate the call to list_empty(). Remove a
duplicate check for dev->bus->self because pcie_aspm_exit_link_state()
already contains an identical check.
Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Shaohua Li <shaohua.li(a)intel.com>
Cc: stable(a)vger.kernel.org # v2.6.26
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 5326916715d2..f78860ce884b 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -991,7 +991,7 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
* All PCIe functions are in one slot, remove one function will remove
* the whole slot, so just wait until we are the last function left.
*/
- if (!list_is_last(&pdev->bus_list, &parent->subordinate->devices))
+ if (!list_empty(&parent->subordinate->devices))
goto out;
link = parent->link_state;
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 461e7fd2756f..e9c6b120cf45 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -25,9 +25,6 @@ static void pci_stop_dev(struct pci_dev *dev)
pci_dev_assign_added(dev, false);
}
-
- if (dev->bus->self)
- pcie_aspm_exit_link_state(dev);
}
static void pci_destroy_dev(struct pci_dev *dev)
@@ -41,6 +38,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
list_del(&dev->bus_list);
up_write(&pci_bus_sem);
+ pcie_aspm_exit_link_state(dev);
pci_bridge_d3_update(dev);
pci_free_resources(dev);
put_device(&dev->dev);
The patch below does not apply to the 4.9-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 aeae4f3e5c38d47bdaef50446dc0ec857307df68 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Tue, 4 Sep 2018 12:34:18 -0500
Subject: [PATCH] PCI/ASPM: Fix link_state teardown on device removal
Upon removal of the last device on a bus, the link_state of the bridge
leading to that bus is sought to be torn down by having pci_stop_dev()
call pcie_aspm_exit_link_state().
When ASPM was originally introduced by commit 7d715a6c1ae5 ("PCI: add
PCI Express ASPM support"), it determined whether the device being
removed is the last one by calling list_empty() on the bridge's
subordinate devices list. That didn't work because the device is only
removed from the list slightly later in pci_destroy_dev().
Commit 3419c75e15f8 ("PCI: properly clean up ASPM link state on device
remove") attempted to fix it by calling list_is_last(), but that's not
correct either because it checks whether the device is at the *end* of
the list, not whether it's the last one *left* in the list. If the user
removes the device which happens to be at the end of the list via sysfs
but other devices are preceding the device in the list, the link_state
is torn down prematurely.
The real fix is to move the invocation of pcie_aspm_exit_link_state() to
pci_destroy_dev() and reinstate the call to list_empty(). Remove a
duplicate check for dev->bus->self because pcie_aspm_exit_link_state()
already contains an identical check.
Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Shaohua Li <shaohua.li(a)intel.com>
Cc: stable(a)vger.kernel.org # v2.6.26
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 5326916715d2..f78860ce884b 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -991,7 +991,7 @@ void pcie_aspm_exit_link_state(struct pci_dev *pdev)
* All PCIe functions are in one slot, remove one function will remove
* the whole slot, so just wait until we are the last function left.
*/
- if (!list_is_last(&pdev->bus_list, &parent->subordinate->devices))
+ if (!list_empty(&parent->subordinate->devices))
goto out;
link = parent->link_state;
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 461e7fd2756f..e9c6b120cf45 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -25,9 +25,6 @@ static void pci_stop_dev(struct pci_dev *dev)
pci_dev_assign_added(dev, false);
}
-
- if (dev->bus->self)
- pcie_aspm_exit_link_state(dev);
}
static void pci_destroy_dev(struct pci_dev *dev)
@@ -41,6 +38,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
list_del(&dev->bus_list);
up_write(&pci_bus_sem);
+ pcie_aspm_exit_link_state(dev);
pci_bridge_d3_update(dev);
pci_free_resources(dev);
put_device(&dev->dev);
The patch below does not apply to the 4.9-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 9a59739bd01f77db6fbe2955a4fce165f0f43568 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg(a)mellanox.com>
Date: Tue, 14 Aug 2018 15:33:02 -0700
Subject: [PATCH] IB/rxe: Revise the ib_wr_opcode enum
This enum has become part of the uABI, as both RXE and the
ib_uverbs_post_send() command expect userspace to supply values from this
enum. So it should be properly placed in include/uapi/rdma.
In userspace this enum is called 'enum ibv_wr_opcode' as part of
libibverbs.h. That enum defines different values for IB_WR_LOCAL_INV,
IB_WR_SEND_WITH_INV, and IB_WR_LSO. These were introduced (incorrectly, it
turns out) into libiberbs in 2015.
The kernel has changed its mind on the numbering for several of the IB_WC
values over the years, but has remained stable on IB_WR_LOCAL_INV and
below.
Based on this we can conclude that there is no real user space user of the
values beyond IB_WR_ATOMIC_FETCH_AND_ADD, as they have never worked via
rdma-core. This is confirmed by inspection, only rxe uses the kernel enum
and implements the latter operations. rxe has clearly never worked with
these attributes from userspace. Other drivers that support these opcodes
implement the functionality without calling out to the kernel.
To make IB_WR_SEND_WITH_INV and related work for RXE in userspace we
choose to renumber the IB_WR enum in the kernel to match the uABI that
userspace has bee using since before Soft RoCE was merged. This is an
overall simpler configuration for the whole software stack, and obviously
can't break anything existing.
Reported-by: Seth Howell <seth.howell(a)intel.com>
Tested-by: Seth Howell <seth.howell(a)intel.com>
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 6076c9b72ab9..e463d3007a35 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1281,21 +1281,27 @@ struct ib_qp_attr {
};
enum ib_wr_opcode {
- IB_WR_RDMA_WRITE,
- IB_WR_RDMA_WRITE_WITH_IMM,
- IB_WR_SEND,
- IB_WR_SEND_WITH_IMM,
- IB_WR_RDMA_READ,
- IB_WR_ATOMIC_CMP_AND_SWP,
- IB_WR_ATOMIC_FETCH_AND_ADD,
- IB_WR_LSO,
- IB_WR_SEND_WITH_INV,
- IB_WR_RDMA_READ_WITH_INV,
- IB_WR_LOCAL_INV,
- IB_WR_REG_MR,
- IB_WR_MASKED_ATOMIC_CMP_AND_SWP,
- IB_WR_MASKED_ATOMIC_FETCH_AND_ADD,
+ /* These are shared with userspace */
+ IB_WR_RDMA_WRITE = IB_UVERBS_WR_RDMA_WRITE,
+ IB_WR_RDMA_WRITE_WITH_IMM = IB_UVERBS_WR_RDMA_WRITE_WITH_IMM,
+ IB_WR_SEND = IB_UVERBS_WR_SEND,
+ IB_WR_SEND_WITH_IMM = IB_UVERBS_WR_SEND_WITH_IMM,
+ IB_WR_RDMA_READ = IB_UVERBS_WR_RDMA_READ,
+ IB_WR_ATOMIC_CMP_AND_SWP = IB_UVERBS_WR_ATOMIC_CMP_AND_SWP,
+ IB_WR_ATOMIC_FETCH_AND_ADD = IB_UVERBS_WR_ATOMIC_FETCH_AND_ADD,
+ IB_WR_LSO = IB_UVERBS_WR_TSO,
+ IB_WR_SEND_WITH_INV = IB_UVERBS_WR_SEND_WITH_INV,
+ IB_WR_RDMA_READ_WITH_INV = IB_UVERBS_WR_RDMA_READ_WITH_INV,
+ IB_WR_LOCAL_INV = IB_UVERBS_WR_LOCAL_INV,
+ IB_WR_MASKED_ATOMIC_CMP_AND_SWP =
+ IB_UVERBS_WR_MASKED_ATOMIC_CMP_AND_SWP,
+ IB_WR_MASKED_ATOMIC_FETCH_AND_ADD =
+ IB_UVERBS_WR_MASKED_ATOMIC_FETCH_AND_ADD,
+
+ /* These are kernel only and can not be issued by userspace */
+ IB_WR_REG_MR = 0x20,
IB_WR_REG_SIG_MR,
+
/* reserve values for low level drivers' internal use.
* These values will not be used at all in the ib core layer.
*/
diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h
index 25a16760de2a..1254b51a551a 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -763,10 +763,28 @@ struct ib_uverbs_sge {
__u32 lkey;
};
+enum ib_uverbs_wr_opcode {
+ IB_UVERBS_WR_RDMA_WRITE = 0,
+ IB_UVERBS_WR_RDMA_WRITE_WITH_IMM = 1,
+ IB_UVERBS_WR_SEND = 2,
+ IB_UVERBS_WR_SEND_WITH_IMM = 3,
+ IB_UVERBS_WR_RDMA_READ = 4,
+ IB_UVERBS_WR_ATOMIC_CMP_AND_SWP = 5,
+ IB_UVERBS_WR_ATOMIC_FETCH_AND_ADD = 6,
+ IB_UVERBS_WR_LOCAL_INV = 7,
+ IB_UVERBS_WR_BIND_MW = 8,
+ IB_UVERBS_WR_SEND_WITH_INV = 9,
+ IB_UVERBS_WR_TSO = 10,
+ IB_UVERBS_WR_RDMA_READ_WITH_INV = 11,
+ IB_UVERBS_WR_MASKED_ATOMIC_CMP_AND_SWP = 12,
+ IB_UVERBS_WR_MASKED_ATOMIC_FETCH_AND_ADD = 13,
+ /* Review enum ib_wr_opcode before modifying this */
+};
+
struct ib_uverbs_send_wr {
__aligned_u64 wr_id;
__u32 num_sge;
- __u32 opcode;
+ __u32 opcode; /* see enum ib_uverbs_wr_opcode */
__u32 send_flags;
union {
__be32 imm_data;
The patch below does not apply to the 4.14-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 9a59739bd01f77db6fbe2955a4fce165f0f43568 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg(a)mellanox.com>
Date: Tue, 14 Aug 2018 15:33:02 -0700
Subject: [PATCH] IB/rxe: Revise the ib_wr_opcode enum
This enum has become part of the uABI, as both RXE and the
ib_uverbs_post_send() command expect userspace to supply values from this
enum. So it should be properly placed in include/uapi/rdma.
In userspace this enum is called 'enum ibv_wr_opcode' as part of
libibverbs.h. That enum defines different values for IB_WR_LOCAL_INV,
IB_WR_SEND_WITH_INV, and IB_WR_LSO. These were introduced (incorrectly, it
turns out) into libiberbs in 2015.
The kernel has changed its mind on the numbering for several of the IB_WC
values over the years, but has remained stable on IB_WR_LOCAL_INV and
below.
Based on this we can conclude that there is no real user space user of the
values beyond IB_WR_ATOMIC_FETCH_AND_ADD, as they have never worked via
rdma-core. This is confirmed by inspection, only rxe uses the kernel enum
and implements the latter operations. rxe has clearly never worked with
these attributes from userspace. Other drivers that support these opcodes
implement the functionality without calling out to the kernel.
To make IB_WR_SEND_WITH_INV and related work for RXE in userspace we
choose to renumber the IB_WR enum in the kernel to match the uABI that
userspace has bee using since before Soft RoCE was merged. This is an
overall simpler configuration for the whole software stack, and obviously
can't break anything existing.
Reported-by: Seth Howell <seth.howell(a)intel.com>
Tested-by: Seth Howell <seth.howell(a)intel.com>
Fixes: 8700e3e7c485 ("Soft RoCE driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 6076c9b72ab9..e463d3007a35 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -1281,21 +1281,27 @@ struct ib_qp_attr {
};
enum ib_wr_opcode {
- IB_WR_RDMA_WRITE,
- IB_WR_RDMA_WRITE_WITH_IMM,
- IB_WR_SEND,
- IB_WR_SEND_WITH_IMM,
- IB_WR_RDMA_READ,
- IB_WR_ATOMIC_CMP_AND_SWP,
- IB_WR_ATOMIC_FETCH_AND_ADD,
- IB_WR_LSO,
- IB_WR_SEND_WITH_INV,
- IB_WR_RDMA_READ_WITH_INV,
- IB_WR_LOCAL_INV,
- IB_WR_REG_MR,
- IB_WR_MASKED_ATOMIC_CMP_AND_SWP,
- IB_WR_MASKED_ATOMIC_FETCH_AND_ADD,
+ /* These are shared with userspace */
+ IB_WR_RDMA_WRITE = IB_UVERBS_WR_RDMA_WRITE,
+ IB_WR_RDMA_WRITE_WITH_IMM = IB_UVERBS_WR_RDMA_WRITE_WITH_IMM,
+ IB_WR_SEND = IB_UVERBS_WR_SEND,
+ IB_WR_SEND_WITH_IMM = IB_UVERBS_WR_SEND_WITH_IMM,
+ IB_WR_RDMA_READ = IB_UVERBS_WR_RDMA_READ,
+ IB_WR_ATOMIC_CMP_AND_SWP = IB_UVERBS_WR_ATOMIC_CMP_AND_SWP,
+ IB_WR_ATOMIC_FETCH_AND_ADD = IB_UVERBS_WR_ATOMIC_FETCH_AND_ADD,
+ IB_WR_LSO = IB_UVERBS_WR_TSO,
+ IB_WR_SEND_WITH_INV = IB_UVERBS_WR_SEND_WITH_INV,
+ IB_WR_RDMA_READ_WITH_INV = IB_UVERBS_WR_RDMA_READ_WITH_INV,
+ IB_WR_LOCAL_INV = IB_UVERBS_WR_LOCAL_INV,
+ IB_WR_MASKED_ATOMIC_CMP_AND_SWP =
+ IB_UVERBS_WR_MASKED_ATOMIC_CMP_AND_SWP,
+ IB_WR_MASKED_ATOMIC_FETCH_AND_ADD =
+ IB_UVERBS_WR_MASKED_ATOMIC_FETCH_AND_ADD,
+
+ /* These are kernel only and can not be issued by userspace */
+ IB_WR_REG_MR = 0x20,
IB_WR_REG_SIG_MR,
+
/* reserve values for low level drivers' internal use.
* These values will not be used at all in the ib core layer.
*/
diff --git a/include/uapi/rdma/ib_user_verbs.h b/include/uapi/rdma/ib_user_verbs.h
index 25a16760de2a..1254b51a551a 100644
--- a/include/uapi/rdma/ib_user_verbs.h
+++ b/include/uapi/rdma/ib_user_verbs.h
@@ -763,10 +763,28 @@ struct ib_uverbs_sge {
__u32 lkey;
};
+enum ib_uverbs_wr_opcode {
+ IB_UVERBS_WR_RDMA_WRITE = 0,
+ IB_UVERBS_WR_RDMA_WRITE_WITH_IMM = 1,
+ IB_UVERBS_WR_SEND = 2,
+ IB_UVERBS_WR_SEND_WITH_IMM = 3,
+ IB_UVERBS_WR_RDMA_READ = 4,
+ IB_UVERBS_WR_ATOMIC_CMP_AND_SWP = 5,
+ IB_UVERBS_WR_ATOMIC_FETCH_AND_ADD = 6,
+ IB_UVERBS_WR_LOCAL_INV = 7,
+ IB_UVERBS_WR_BIND_MW = 8,
+ IB_UVERBS_WR_SEND_WITH_INV = 9,
+ IB_UVERBS_WR_TSO = 10,
+ IB_UVERBS_WR_RDMA_READ_WITH_INV = 11,
+ IB_UVERBS_WR_MASKED_ATOMIC_CMP_AND_SWP = 12,
+ IB_UVERBS_WR_MASKED_ATOMIC_FETCH_AND_ADD = 13,
+ /* Review enum ib_wr_opcode before modifying this */
+};
+
struct ib_uverbs_send_wr {
__aligned_u64 wr_id;
__u32 num_sge;
- __u32 opcode;
+ __u32 opcode; /* see enum ib_uverbs_wr_opcode */
__u32 send_flags;
union {
__be32 imm_data;
This is backport of the upstream patch
41c73a49df31151f4ff868f28fe4f129f113fa2c. It should be backported to
stable kernels because this performance problem was seen on the android
4.4 kernel.
commit 41c73a49df31151f4ff868f28fe4f129f113fa2c
Author: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Wed Nov 23 17:04:00 2016 -0500
dm bufio: drop the lock when doing GFP_NOIO allocation
If the first allocation attempt using GFP_NOWAIT fails, drop the lock
and retry using GFP_NOIO allocation (lock is dropped because the
allocation can take some time).
Note that we won't do GFP_NOIO allocation when we loop for the second
time, because the lock shouldn't be dropped between __wait_for_free_buffer
and __get_unclaimed_buffer.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index 9ef88f0e2382..1c2e1dd7ca16 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -822,6 +822,7 @@ enum new_flag {
static struct dm_buffer *__alloc_buffer_wait_no_callback(struct dm_bufio_client *c, enum new_flag nf)
{
struct dm_buffer *b;
+ bool tried_noio_alloc = false;
/*
* dm-bufio is resistant to allocation failures (it just keeps
@@ -846,6 +847,15 @@ static struct dm_buffer *__alloc_buffer_wait_no_callback(struct dm_bufio_client
if (nf == NF_PREFETCH)
return NULL;
+ if (dm_bufio_cache_size_latch != 1 && !tried_noio_alloc) {
+ dm_bufio_unlock(c);
+ b = alloc_buffer(c, GFP_NOIO | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN);
+ dm_bufio_lock(c);
+ if (b)
+ return b;
+ tried_noio_alloc = true;
+ }
+
if (!list_empty(&c->reserved_buffers)) {
b = list_entry(c->reserved_buffers.next,
struct dm_buffer, lru_list);
This is backport of the upstream patch
9ea61cac0b1ad0c09022f39fd97e9b99a2cfc2dc. It should be backported to
stable kernels because this performance problem was seen on the android
4.4 kernel.
commit 9ea61cac0b1ad0c09022f39fd97e9b99a2cfc2dc
Author: Douglas Anderson <dianders(a)chromium.org>
Date: Thu Nov 17 11:24:20 2016 -0800
dm bufio: avoid sleeping while holding the dm_bufio lock
We've seen in-field reports showing _lots_ (18 in one case, 41 in
another) of tasks all sitting there blocked on:
mutex_lock+0x4c/0x68
dm_bufio_shrink_count+0x38/0x78
shrink_slab.part.54.constprop.65+0x100/0x464
shrink_zone+0xa8/0x198
In the two cases analyzed, we see one task that looks like this:
Workqueue: kverityd verity_prefetch_io
__switch_to+0x9c/0xa8
__schedule+0x440/0x6d8
schedule+0x94/0xb4
schedule_timeout+0x204/0x27c
schedule_timeout_uninterruptible+0x44/0x50
wait_iff_congested+0x9c/0x1f0
shrink_inactive_list+0x3a0/0x4cc
shrink_lruvec+0x418/0x5cc
shrink_zone+0x88/0x198
try_to_free_pages+0x51c/0x588
__alloc_pages_nodemask+0x648/0xa88
__get_free_pages+0x34/0x7c
alloc_buffer+0xa4/0x144
__bufio_new+0x84/0x278
dm_bufio_prefetch+0x9c/0x154
verity_prefetch_io+0xe8/0x10c
process_one_work+0x240/0x424
worker_thread+0x2fc/0x424
kthread+0x10c/0x114
...and that looks to be the one holding the mutex.
The problem has been reproduced on fairly easily:
0. Be running Chrome OS w/ verity enabled on the root filesystem
1. Pick test patch: http://crosreview.com/412360
2. Install launchBalloons.sh and balloon.arm from
http://crbug.com/468342
...that's just a memory stress test app.
3. On a 4GB rk3399 machine, run
nice ./launchBalloons.sh 4 900 100000
...that tries to eat 4 * 900 MB of memory and keep accessing.
4. Login to the Chrome web browser and restore many tabs
With that, I've seen printouts like:
DOUG: long bufio 90758 ms
...and stack trace always show's we're in dm_bufio_prefetch().
The problem is that we try to allocate memory with GFP_NOIO while
we're holding the dm_bufio lock. Instead we should be using
GFP_NOWAIT. Using GFP_NOIO can cause us to sleep while holding the
lock and that causes the above problems.
The current behavior explained by David Rientjes:
It will still try reclaim initially because __GFP_WAIT (or
__GFP_KSWAPD_RECLAIM) is set by GFP_NOIO. This is the cause of
contention on dm_bufio_lock() that the thread holds. You want to
pass GFP_NOWAIT instead of GFP_NOIO to alloc_buffer() when holding a
mutex that can be contended by a concurrent slab shrinker (if
count_objects didn't use a trylock, this pattern would trivially
deadlock).
This change significantly increases responsiveness of the system while
in this state. It makes a real difference because it unblocks kswapd.
In the bug report analyzed, kswapd was hung:
kswapd0 D ffffffc000204fd8 0 72 2 0x00000000
Call trace:
[<ffffffc000204fd8>] __switch_to+0x9c/0xa8
[<ffffffc00090b794>] __schedule+0x440/0x6d8
[<ffffffc00090bac0>] schedule+0x94/0xb4
[<ffffffc00090be44>] schedule_preempt_disabled+0x28/0x44
[<ffffffc00090d900>] __mutex_lock_slowpath+0x120/0x1ac
[<ffffffc00090d9d8>] mutex_lock+0x4c/0x68
[<ffffffc000708e7c>] dm_bufio_shrink_count+0x38/0x78
[<ffffffc00030b268>] shrink_slab.part.54.constprop.65+0x100/0x464
[<ffffffc00030dbd8>] shrink_zone+0xa8/0x198
[<ffffffc00030e578>] balance_pgdat+0x328/0x508
[<ffffffc00030eb7c>] kswapd+0x424/0x51c
[<ffffffc00023f06c>] kthread+0x10c/0x114
[<ffffffc000203dd0>] ret_from_fork+0x10/0x40
By unblocking kswapd memory pressure should be reduced.
Suggested-by: David Rientjes <rientjes(a)google.com>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Douglas Anderson <dianders(a)chromium.org>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index 125aedc3875f..b5d3428d109e 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -827,7 +827,8 @@ static struct dm_buffer *__alloc_buffer_wait_no_callback(struct dm_bufio_client
* dm-bufio is resistant to allocation failures (it just keeps
* one buffer reserved in cases all the allocations fail).
* So set flags to not try too hard:
- * GFP_NOIO: don't recurse into the I/O layer
+ * GFP_NOWAIT: don't wait; if we need to sleep we'll release our
+ * mutex and wait ourselves.
* __GFP_NORETRY: don't retry and rather return failure
* __GFP_NOMEMALLOC: don't use emergency reserves
* __GFP_NOWARN: don't print a warning in case of failure
@@ -837,7 +838,7 @@ static struct dm_buffer *__alloc_buffer_wait_no_callback(struct dm_bufio_client
*/
while (1) {
if (dm_bufio_cache_size_latch != 1) {
- b = alloc_buffer(c, GFP_NOIO | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN);
+ b = alloc_buffer(c, GFP_NOWAIT | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN);
if (b)
return b;
}
On a powerpc 8xx, 'btc' fails as follows:
Entering kdb (current=0x(ptrval), pid 282) due to Keyboard Entry
kdb> btc
btc: cpu status: Currently on cpu 0
Available cpus: 0
kdb_getarea: Bad address 0x0
when booting the kernel with 'debug_boot_weak_hash', it fails as well
Entering kdb (current=0xba99ad80, pid 284) due to Keyboard Entry
kdb> btc
btc: cpu status: Currently on cpu 0
Available cpus: 0
kdb_getarea: Bad address 0xba99ad80
On other platforms, Oopses have been observed too, see
https://github.com/linuxppc/linux/issues/139
This is due to btc calling 'btt' with %p pointer as an argument.
This patch replaces %p by %px to get the real pointer value as
expected by 'btt'
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Cc: <stable(a)vger.kernel.org> # 4.15+
---
kernel/debug/kdb/kdb_bt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c
index 6ad4a9fcbd6f..7921ae4fca8d 100644
--- a/kernel/debug/kdb/kdb_bt.c
+++ b/kernel/debug/kdb/kdb_bt.c
@@ -179,14 +179,14 @@ kdb_bt(int argc, const char **argv)
kdb_printf("no process for cpu %ld\n", cpu);
return 0;
}
- sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu));
+ sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu));
kdb_parse(buf);
return 0;
}
kdb_printf("btc: cpu status: ");
kdb_parse("cpu\n");
for_each_online_cpu(cpu) {
- sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu));
+ sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu));
kdb_parse(buf);
touch_nmi_watchdog();
}
--
2.13.3
On Fri, Oct 12, 2018 at 7:31 PM, Alexei Starovoitov
<alexei.starovoitov(a)gmail.com> wrote:
> On Fri, Oct 12, 2018 at 03:54:27AM -0700, Daniel Colascione wrote:
>> The map-in-map frequently serves as a mechanism for atomic
>> snapshotting of state that a BPF program might record. The current
>> implementation is dangerous to use in this way, however, since
>> userspace has no way of knowing when all programs that might have
>> retrieved the "old" value of the map may have completed.
>>
>> This change ensures that map update operations on map-in-map map types
>> always wait for all references to the old map to drop before returning
>> to userspace.
>>
>> Signed-off-by: Daniel Colascione <dancol(a)google.com>
>> ---
>> kernel/bpf/syscall.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index 8339d81cba1d..d7c16ae1e85a 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -741,6 +741,18 @@ static int map_lookup_elem(union bpf_attr *attr)
>> return err;
>> }
>>
>> +static void maybe_wait_bpf_programs(struct bpf_map *map)
>> +{
>> + /* Wait for any running BPF programs to complete so that
>> + * userspace, when we return to it, knows that all programs
>> + * that could be running use the new map value.
>> + */
>> + if (map->map_type == BPF_MAP_TYPE_HASH_OF_MAPS ||
>> + map->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS) {
>> + synchronize_rcu();
>> + }
>
> extra {} were not necessary. I removed them while applying to bpf-next.
> Please run checkpatch.pl next time.
> Thanks
Thanks Alexei for taking it. Me and Lorenzo were discussing that not
having this causes incorrect behavior for apps using map-in-map for
this. So I CC'd stable as well.
-Joel
The patch below does not apply to the 4.4-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 f5e758b8358f6c27e8a351ddf0b441a64cdabb94 Mon Sep 17 00:00:00 2001
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
Date: Wed, 5 Sep 2018 12:02:15 +0200
Subject: [PATCH] ARM: dts: exynos: Disable pull control for MAX8997 interrupts
on Origen
PMIC_IRQB and PMIC_KEYINB lines on Exynos4210-based Origen board have
external pull-up resistors, so disable any pull control for those lines
in respective pin controller node. This fixes support for MAX8997
interrupts and enables operation of wakeup from MAX8997 RTC alarm.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Fixes: 17419726aaa1 ("ARM: dts: add max8997 device node for exynos4210-origen board")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
index 2ab99f9f3d0a..dd9ec05eb0f7 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -151,6 +151,8 @@
reg = <0x66>;
interrupt-parent = <&gpx0>;
interrupts = <4 IRQ_TYPE_NONE>, <3 IRQ_TYPE_NONE>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&max8997_irq>;
max8997,pmic-buck1-dvs-voltage = <1350000>;
max8997,pmic-buck2-dvs-voltage = <1100000>;
@@ -288,6 +290,13 @@
};
};
+&pinctrl_1 {
+ max8997_irq: max8997-irq {
+ samsung,pins = "gpx0-3", "gpx0-4";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+};
+
&sdhci_0 {
bus-width = <4>;
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_cd>;
The patch below does not apply to the 4.9-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 f5e758b8358f6c27e8a351ddf0b441a64cdabb94 Mon Sep 17 00:00:00 2001
From: Marek Szyprowski <m.szyprowski(a)samsung.com>
Date: Wed, 5 Sep 2018 12:02:15 +0200
Subject: [PATCH] ARM: dts: exynos: Disable pull control for MAX8997 interrupts
on Origen
PMIC_IRQB and PMIC_KEYINB lines on Exynos4210-based Origen board have
external pull-up resistors, so disable any pull control for those lines
in respective pin controller node. This fixes support for MAX8997
interrupts and enables operation of wakeup from MAX8997 RTC alarm.
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
Fixes: 17419726aaa1 ("ARM: dts: add max8997 device node for exynos4210-origen board")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
index 2ab99f9f3d0a..dd9ec05eb0f7 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -151,6 +151,8 @@
reg = <0x66>;
interrupt-parent = <&gpx0>;
interrupts = <4 IRQ_TYPE_NONE>, <3 IRQ_TYPE_NONE>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&max8997_irq>;
max8997,pmic-buck1-dvs-voltage = <1350000>;
max8997,pmic-buck2-dvs-voltage = <1100000>;
@@ -288,6 +290,13 @@
};
};
+&pinctrl_1 {
+ max8997_irq: max8997-irq {
+ samsung,pins = "gpx0-3", "gpx0-4";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+};
+
&sdhci_0 {
bus-width = <4>;
pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_cd>;
From: Daniel Wagner <daniel.wagner(a)siemens.com>
Sebastian writes:
"""
We reproducibly observe cache line starvation on a Core2Duo E6850 (2
cores), a i5-6400 SKL (4 cores) and on a NXP LS2044A ARM Cortex-A72 (4
cores).
The problem can be triggered with a v4.9-RT kernel by starting
cyclictest -S -p98 -m -i2000 -b 200
and as "load"
stress-ng --ptrace 4
The reported maximal latency is usually less than 60us. If the problem
triggers then values around 400us, 800us or even more are reported. The
upperlimit is the -i parameter.
Reproduction with 4.9-RT is almost immediate on Core2Duo, ARM64 and SKL,
but it took 7.5 hours to trigger on v4.14-RT on the Core2Duo.
Instrumentation show always the picture:
CPU0 CPU1
=> do_syscall_64 => do_syscall_64
=> SyS_ptrace => syscall_slow_exit_work
=> ptrace_check_attach => ptrace_do_notify / rt_read_unlock
=> wait_task_inactive rt_spin_lock_slowunlock()
-> while task_running() __rt_mutex_unlock_common()
/ check_task_state() mark_wakeup_next_waiter()
| raw_spin_lock_irq(&p->pi_lock); raw_spin_lock(¤t->pi_lock);
| . .
| raw_spin_unlock_irq(&p->pi_lock); .
\ cpu_relax() .
- .
*IRQ* <lock acquired>
In the error case we observe that the while() loop is repeated more than
5000 times which indicates that the pi_lock can be acquired. CPU1 on the
other side does not make progress waiting for the same lock with interrupts
disabled.
This continues until an IRQ hits CPU0. Once CPU0 starts processing the IRQ
the other CPU is able to acquire pi_lock and the situation relaxes.
"""
This matches with the observeration for v4.4-rt on a Core2Duo E6850:
CPU 0:
- no progress for a very long time in rt_mutex_dequeue_pi):
stress-n-1931 0d..11 5060.891219: function: __try_to_take_rt_mutex
stress-n-1931 0d..11 5060.891219: function: rt_mutex_dequeue
stress-n-1931 0d..21 5060.891220: function: rt_mutex_enqueue_pi
stress-n-1931 0....2 5060.891220: signal_generate: sig=17 errno=0 code=262148 comm=stress-ng-ptrac pid=1928 grp=1 res=1
stress-n-1931 0d..21 5060.894114: function: rt_mutex_dequeue_pi
stress-n-1931 0d.h11 5060.894115: local_timer_entry: vector=239
CPU 1:
- IRQ at 5060.894114 on CPU 1 followed by the IRQ on CPU 0
stress-n-1928 1....0 5060.891215: sys_enter: NR 101 (18, 78b, 0, 0, 17, 788)
stress-n-1928 1d..11 5060.891216: function: __try_to_take_rt_mutex
stress-n-1928 1d..21 5060.891216: function: rt_mutex_enqueue_pi
stress-n-1928 1d..21 5060.891217: function: rt_mutex_dequeue_pi
stress-n-1928 1....1 5060.891217: function: rt_mutex_adjust_prio
stress-n-1928 1d..11 5060.891218: function: __rt_mutex_adjust_prio
stress-n-1928 1d.h10 5060.894114: local_timer_entry: vector=239
Thomas writes:
"""
This has nothing to do with RT. RT is merily exposing the
problem in an observable way. The same issue happens with upstream, it's
harder to trigger and it's harder to observe for obvious reasons.
If you read through the discussions [see the links below] then you
really see that there is an upstream issue with the x86 qrlock
implementation and Peter has posted fixes which resolve it, both at
the practical and the theoretical level.
"""
Backporting all qspinlock related patches is very likely to introduce
regressions on v4.4. Therefore, the recommended solution by Peter and
Thomas is to drop back to ticket spinlocks for v4.4.
Link :https://lkml.kernel.org/r/20180921120226.6xjgr4oiho22ex75@linutronix.de
Link: https://lkml.kernel.org/r/20180926110117.405325143@infradead.org
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Daniel Wagner <daniel.wagner(a)siemens.com>
---
Thomas suggest following plan for fixing the issues on the varous
stable trees:
4.4: Trivial by switching back to ticket locks.
4.9: Decide whether bringing back ticket locks or backporting all qrlock
fixes. Sebastian has done the latter already and it's probably the
right solution
4.14:
4.18: Backporting the qrlock fixes
4.19: Either the fix ends up in 4.19 final or it needs to be backported
arch/x86/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6df130a37d41..f00cab581e2d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -42,7 +42,6 @@ config X86
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF if X86_64
select ARCH_USE_QUEUED_RWLOCKS
- select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_FRAME_POINTERS
--
2.14.4
The patch below does not apply to the 4.9-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 a7c42bb6da6b1b54b2e7bd567636d72d87b10a79 Mon Sep 17 00:00:00 2001
From: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Date: Tue, 16 Oct 2018 18:50:06 +0200
Subject: [PATCH] x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit
vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and
MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any
order. Values match, however, kvm_lapic_enable_pv_eoi() uses different
length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM
native case it is 8. In case we restore KVM-native MSR last cache will
be reinitialized with len=8 so trying to access VP assist page beyond
8 bytes with kvm_read_guest_cached() will fail.
Check if we re-initializing cache for the same address and preserve length
in case it was greater.
Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 79358fd6a71c..3cd227ff807f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2647,14 +2647,22 @@ int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)
int kvm_lapic_enable_pv_eoi(struct kvm_vcpu *vcpu, u64 data, unsigned long len)
{
u64 addr = data & ~KVM_MSR_ENABLED;
+ struct gfn_to_hva_cache *ghc = &vcpu->arch.pv_eoi.data;
+ unsigned long new_len;
+
if (!IS_ALIGNED(addr, 4))
return 1;
vcpu->arch.pv_eoi.msr_val = data;
if (!pv_eoi_enabled(vcpu))
return 0;
- return kvm_gfn_to_hva_cache_init(vcpu->kvm, &vcpu->arch.pv_eoi.data,
- addr, len);
+
+ if (addr == ghc->gpa && len <= ghc->len)
+ new_len = ghc->len;
+ else
+ new_len = len;
+
+ return kvm_gfn_to_hva_cache_init(vcpu->kvm, ghc, addr, new_len);
}
void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
The patch below does not apply to the 4.14-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 a7c42bb6da6b1b54b2e7bd567636d72d87b10a79 Mon Sep 17 00:00:00 2001
From: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Date: Tue, 16 Oct 2018 18:50:06 +0200
Subject: [PATCH] x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit
vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and
MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any
order. Values match, however, kvm_lapic_enable_pv_eoi() uses different
length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM
native case it is 8. In case we restore KVM-native MSR last cache will
be reinitialized with len=8 so trying to access VP assist page beyond
8 bytes with kvm_read_guest_cached() will fail.
Check if we re-initializing cache for the same address and preserve length
in case it was greater.
Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 79358fd6a71c..3cd227ff807f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2647,14 +2647,22 @@ int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)
int kvm_lapic_enable_pv_eoi(struct kvm_vcpu *vcpu, u64 data, unsigned long len)
{
u64 addr = data & ~KVM_MSR_ENABLED;
+ struct gfn_to_hva_cache *ghc = &vcpu->arch.pv_eoi.data;
+ unsigned long new_len;
+
if (!IS_ALIGNED(addr, 4))
return 1;
vcpu->arch.pv_eoi.msr_val = data;
if (!pv_eoi_enabled(vcpu))
return 0;
- return kvm_gfn_to_hva_cache_init(vcpu->kvm, &vcpu->arch.pv_eoi.data,
- addr, len);
+
+ if (addr == ghc->gpa && len <= ghc->len)
+ new_len = ghc->len;
+ else
+ new_len = len;
+
+ return kvm_gfn_to_hva_cache_init(vcpu->kvm, ghc, addr, new_len);
}
void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
The patch below does not apply to the 4.18-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 a7c42bb6da6b1b54b2e7bd567636d72d87b10a79 Mon Sep 17 00:00:00 2001
From: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Date: Tue, 16 Oct 2018 18:50:06 +0200
Subject: [PATCH] x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit
vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and
MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any
order. Values match, however, kvm_lapic_enable_pv_eoi() uses different
length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM
native case it is 8. In case we restore KVM-native MSR last cache will
be reinitialized with len=8 so trying to access VP assist page beyond
8 bytes with kvm_read_guest_cached() will fail.
Check if we re-initializing cache for the same address and preserve length
in case it was greater.
Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 79358fd6a71c..3cd227ff807f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2647,14 +2647,22 @@ int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)
int kvm_lapic_enable_pv_eoi(struct kvm_vcpu *vcpu, u64 data, unsigned long len)
{
u64 addr = data & ~KVM_MSR_ENABLED;
+ struct gfn_to_hva_cache *ghc = &vcpu->arch.pv_eoi.data;
+ unsigned long new_len;
+
if (!IS_ALIGNED(addr, 4))
return 1;
vcpu->arch.pv_eoi.msr_val = data;
if (!pv_eoi_enabled(vcpu))
return 0;
- return kvm_gfn_to_hva_cache_init(vcpu->kvm, &vcpu->arch.pv_eoi.data,
- addr, len);
+
+ if (addr == ghc->gpa && len <= ghc->len)
+ new_len = ghc->len;
+ else
+ new_len = len;
+
+ return kvm_gfn_to_hva_cache_init(vcpu->kvm, ghc, addr, new_len);
}
void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
The patch below does not apply to the 4.19-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 a7c42bb6da6b1b54b2e7bd567636d72d87b10a79 Mon Sep 17 00:00:00 2001
From: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Date: Tue, 16 Oct 2018 18:50:06 +0200
Subject: [PATCH] x86/kvm/lapic: preserve gfn_to_hva_cache len on cache reinit
vcpu->arch.pv_eoi is accessible through both HV_X64_MSR_VP_ASSIST_PAGE and
MSR_KVM_PV_EOI_EN so on migration userspace may try to restore them in any
order. Values match, however, kvm_lapic_enable_pv_eoi() uses different
length: for Hyper-V case it's the whole struct hv_vp_assist_page, for KVM
native case it is 8. In case we restore KVM-native MSR last cache will
be reinitialized with len=8 so trying to access VP assist page beyond
8 bytes with kvm_read_guest_cached() will fail.
Check if we re-initializing cache for the same address and preserve length
in case it was greater.
Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 79358fd6a71c..3cd227ff807f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2647,14 +2647,22 @@ int kvm_hv_vapic_msr_read(struct kvm_vcpu *vcpu, u32 reg, u64 *data)
int kvm_lapic_enable_pv_eoi(struct kvm_vcpu *vcpu, u64 data, unsigned long len)
{
u64 addr = data & ~KVM_MSR_ENABLED;
+ struct gfn_to_hva_cache *ghc = &vcpu->arch.pv_eoi.data;
+ unsigned long new_len;
+
if (!IS_ALIGNED(addr, 4))
return 1;
vcpu->arch.pv_eoi.msr_val = data;
if (!pv_eoi_enabled(vcpu))
return 0;
- return kvm_gfn_to_hva_cache_init(vcpu->kvm, &vcpu->arch.pv_eoi.data,
- addr, len);
+
+ if (addr == ghc->gpa && len <= ghc->len)
+ new_len = ghc->len;
+ else
+ new_len = len;
+
+ return kvm_gfn_to_hva_cache_init(vcpu->kvm, ghc, addr, new_len);
}
void kvm_apic_accept_events(struct kvm_vcpu *vcpu)
The patch below does not apply to the 4.18-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 d3abaf43bab8d5b0a3c6b982100d9e2be96de4ad Mon Sep 17 00:00:00 2001
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Sat, 13 Oct 2018 20:32:17 -0700
Subject: [PATCH] acpi, nfit: Fix Address Range Scrub completion tracking
The Address Range Scrub implementation tried to skip running scrubs
against ranges that were already scrubbed by the BIOS. Unfortunately
that support also resulted in early scrub completions as evidenced by
this debug output from nfit_test:
nd_region region9: ARS: range 1 short complete
nd_region region3: ARS: range 1 short complete
nd_region region4: ARS: range 2 ARS start (0)
nd_region region4: ARS: range 2 short complete
...i.e. completions without any indications that the scrub was started.
This state of affairs was hard to see in the code due to the
proliferation of state bits and mistakenly trying to track done state
per-range when the completion is a global property of the bus.
So, kill the four ARS state bits (ARS_REQ, ARS_REQ_REDO, ARS_DONE, and
ARS_SHORT), and replace them with just 2 request flags ARS_REQ_SHORT and
ARS_REQ_LONG. The implementation will still complete and reap the
results of BIOS initiated ARS, but it will not attempt to use that
information to affect the completion status of scrubbing the ranges from
a Linux perspective.
Instead, try to synchronously run a short ARS per range at init time and
schedule a long scrub in the background. If ARS is busy with an ARS
request, schedule both a short and a long scrub for when ARS returns to
idle. This logic also satisfies the intent of what ARS_REQ_REDO was
trying to achieve. The new rule is that the REQ flag stays set until the
next successful ars_start() for that range.
With the new policy that the REQ flags are not cleared until the next
start, the implementation no longer loses requests as can be seen from
the following log:
nd_region region3: ARS: range 1 ARS start short (0)
nd_region region9: ARS: range 1 ARS start short (0)
nd_region region3: ARS: range 1 complete
nd_region region4: ARS: range 2 ARS start short (0)
nd_region region9: ARS: range 1 complete
nd_region region9: ARS: range 1 ARS start long (0)
nd_region region4: ARS: range 2 complete
nd_region region3: ARS: range 1 ARS start long (0)
nd_region region9: ARS: range 1 complete
nd_region region3: ARS: range 1 complete
nd_region region4: ARS: range 2 ARS start long (0)
nd_region region4: ARS: range 2 complete
...note that the nfit_test emulated driver provides 2 buses, that is why
some of the range indices are duplicated. Notice that each range
now successfully completes a short and long scrub.
Cc: <stable(a)vger.kernel.org>
Fixes: 14c73f997a5e ("nfit, address-range-scrub: introduce nfit_spa->ars_state")
Fixes: cc3d3458d46f ("acpi/nfit: queue issuing of ars when an uc error...")
Reported-by: Jacek Zloch <jacek.zloch(a)intel.com>
Reported-by: Krzysztof Rusocki <krzysztof.rusocki(a)intel.com>
Reviewed-by: Dave Jiang <dave.jiang(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index ec8fb578fa36..b24cd3e5b99f 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2549,7 +2549,8 @@ static int ars_get_cap(struct acpi_nfit_desc *acpi_desc,
return cmd_rc;
}
-static int ars_start(struct acpi_nfit_desc *acpi_desc, struct nfit_spa *nfit_spa)
+static int ars_start(struct acpi_nfit_desc *acpi_desc,
+ struct nfit_spa *nfit_spa, enum nfit_ars_state req_type)
{
int rc;
int cmd_rc;
@@ -2560,7 +2561,7 @@ static int ars_start(struct acpi_nfit_desc *acpi_desc, struct nfit_spa *nfit_spa
memset(&ars_start, 0, sizeof(ars_start));
ars_start.address = spa->address;
ars_start.length = spa->length;
- if (test_bit(ARS_SHORT, &nfit_spa->ars_state))
+ if (req_type == ARS_REQ_SHORT)
ars_start.flags = ND_ARS_RETURN_PREV_DATA;
if (nfit_spa_type(spa) == NFIT_SPA_PM)
ars_start.type = ND_ARS_PERSISTENT;
@@ -2617,6 +2618,15 @@ static void ars_complete(struct acpi_nfit_desc *acpi_desc,
struct nd_region *nd_region = nfit_spa->nd_region;
struct device *dev;
+ lockdep_assert_held(&acpi_desc->init_mutex);
+ /*
+ * Only advance the ARS state for ARS runs initiated by the
+ * kernel, ignore ARS results from BIOS initiated runs for scrub
+ * completion tracking.
+ */
+ if (acpi_desc->scrub_spa != nfit_spa)
+ return;
+
if ((ars_status->address >= spa->address && ars_status->address
< spa->address + spa->length)
|| (ars_status->address < spa->address)) {
@@ -2636,28 +2646,13 @@ static void ars_complete(struct acpi_nfit_desc *acpi_desc,
} else
return;
- if (test_bit(ARS_DONE, &nfit_spa->ars_state))
- return;
-
- if (!test_and_clear_bit(ARS_REQ, &nfit_spa->ars_state))
- return;
-
+ acpi_desc->scrub_spa = NULL;
if (nd_region) {
dev = nd_region_dev(nd_region);
nvdimm_region_notify(nd_region, NVDIMM_REVALIDATE_POISON);
} else
dev = acpi_desc->dev;
-
- dev_dbg(dev, "ARS: range %d %s complete\n", spa->range_index,
- test_bit(ARS_SHORT, &nfit_spa->ars_state)
- ? "short" : "long");
- clear_bit(ARS_SHORT, &nfit_spa->ars_state);
- if (test_and_clear_bit(ARS_REQ_REDO, &nfit_spa->ars_state)) {
- set_bit(ARS_SHORT, &nfit_spa->ars_state);
- set_bit(ARS_REQ, &nfit_spa->ars_state);
- dev_dbg(dev, "ARS: processing scrub request received while in progress\n");
- } else
- set_bit(ARS_DONE, &nfit_spa->ars_state);
+ dev_dbg(dev, "ARS: range %d complete\n", spa->range_index);
}
static int ars_status_process_records(struct acpi_nfit_desc *acpi_desc)
@@ -2938,46 +2933,55 @@ static int acpi_nfit_query_poison(struct acpi_nfit_desc *acpi_desc)
return 0;
}
-static int ars_register(struct acpi_nfit_desc *acpi_desc, struct nfit_spa *nfit_spa,
- int *query_rc)
+static int ars_register(struct acpi_nfit_desc *acpi_desc,
+ struct nfit_spa *nfit_spa)
{
- int rc = *query_rc;
+ int rc;
- if (no_init_ars)
+ if (no_init_ars || test_bit(ARS_FAILED, &nfit_spa->ars_state))
return acpi_nfit_register_region(acpi_desc, nfit_spa);
- set_bit(ARS_REQ, &nfit_spa->ars_state);
- set_bit(ARS_SHORT, &nfit_spa->ars_state);
+ set_bit(ARS_REQ_SHORT, &nfit_spa->ars_state);
+ set_bit(ARS_REQ_LONG, &nfit_spa->ars_state);
- switch (rc) {
+ switch (acpi_nfit_query_poison(acpi_desc)) {
case 0:
case -EAGAIN:
- rc = ars_start(acpi_desc, nfit_spa);
- if (rc == -EBUSY) {
- *query_rc = rc;
+ rc = ars_start(acpi_desc, nfit_spa, ARS_REQ_SHORT);
+ /* shouldn't happen, try again later */
+ if (rc == -EBUSY)
break;
- } else if (rc == 0) {
- rc = acpi_nfit_query_poison(acpi_desc);
- } else {
+ if (rc) {
set_bit(ARS_FAILED, &nfit_spa->ars_state);
break;
}
- if (rc == -EAGAIN)
- clear_bit(ARS_SHORT, &nfit_spa->ars_state);
- else if (rc == 0)
- ars_complete(acpi_desc, nfit_spa);
+ clear_bit(ARS_REQ_SHORT, &nfit_spa->ars_state);
+ rc = acpi_nfit_query_poison(acpi_desc);
+ if (rc)
+ break;
+ acpi_desc->scrub_spa = nfit_spa;
+ ars_complete(acpi_desc, nfit_spa);
+ /*
+ * If ars_complete() says we didn't complete the
+ * short scrub, we'll try again with a long
+ * request.
+ */
+ acpi_desc->scrub_spa = NULL;
break;
case -EBUSY:
+ case -ENOMEM:
case -ENOSPC:
+ /*
+ * BIOS was using ARS, wait for it to complete (or
+ * resources to become available) and then perform our
+ * own scrubs.
+ */
break;
default:
set_bit(ARS_FAILED, &nfit_spa->ars_state);
break;
}
- if (test_and_clear_bit(ARS_DONE, &nfit_spa->ars_state))
- set_bit(ARS_REQ, &nfit_spa->ars_state);
-
return acpi_nfit_register_region(acpi_desc, nfit_spa);
}
@@ -2999,6 +3003,8 @@ static unsigned int __acpi_nfit_scrub(struct acpi_nfit_desc *acpi_desc,
struct device *dev = acpi_desc->dev;
struct nfit_spa *nfit_spa;
+ lockdep_assert_held(&acpi_desc->init_mutex);
+
if (acpi_desc->cancel)
return 0;
@@ -3022,21 +3028,49 @@ static unsigned int __acpi_nfit_scrub(struct acpi_nfit_desc *acpi_desc,
ars_complete_all(acpi_desc);
list_for_each_entry(nfit_spa, &acpi_desc->spas, list) {
+ enum nfit_ars_state req_type;
+ int rc;
+
if (test_bit(ARS_FAILED, &nfit_spa->ars_state))
continue;
- if (test_bit(ARS_REQ, &nfit_spa->ars_state)) {
- int rc = ars_start(acpi_desc, nfit_spa);
-
- clear_bit(ARS_DONE, &nfit_spa->ars_state);
- dev = nd_region_dev(nfit_spa->nd_region);
- dev_dbg(dev, "ARS: range %d ARS start (%d)\n",
- nfit_spa->spa->range_index, rc);
- if (rc == 0 || rc == -EBUSY)
- return 1;
- dev_err(dev, "ARS: range %d ARS failed (%d)\n",
- nfit_spa->spa->range_index, rc);
- set_bit(ARS_FAILED, &nfit_spa->ars_state);
+
+ /* prefer short ARS requests first */
+ if (test_bit(ARS_REQ_SHORT, &nfit_spa->ars_state))
+ req_type = ARS_REQ_SHORT;
+ else if (test_bit(ARS_REQ_LONG, &nfit_spa->ars_state))
+ req_type = ARS_REQ_LONG;
+ else
+ continue;
+ rc = ars_start(acpi_desc, nfit_spa, req_type);
+
+ dev = nd_region_dev(nfit_spa->nd_region);
+ dev_dbg(dev, "ARS: range %d ARS start %s (%d)\n",
+ nfit_spa->spa->range_index,
+ req_type == ARS_REQ_SHORT ? "short" : "long",
+ rc);
+ /*
+ * Hmm, we raced someone else starting ARS? Try again in
+ * a bit.
+ */
+ if (rc == -EBUSY)
+ return 1;
+ if (rc == 0) {
+ dev_WARN_ONCE(dev, acpi_desc->scrub_spa,
+ "scrub start while range %d active\n",
+ acpi_desc->scrub_spa->spa->range_index);
+ clear_bit(req_type, &nfit_spa->ars_state);
+ acpi_desc->scrub_spa = nfit_spa;
+ /*
+ * Consider this spa last for future scrub
+ * requests
+ */
+ list_move_tail(&nfit_spa->list, &acpi_desc->spas);
+ return 1;
}
+
+ dev_err(dev, "ARS: range %d ARS failed (%d)\n",
+ nfit_spa->spa->range_index, rc);
+ set_bit(ARS_FAILED, &nfit_spa->ars_state);
}
return 0;
}
@@ -3092,6 +3126,7 @@ static void acpi_nfit_init_ars(struct acpi_nfit_desc *acpi_desc,
struct nd_cmd_ars_cap ars_cap;
int rc;
+ set_bit(ARS_FAILED, &nfit_spa->ars_state);
memset(&ars_cap, 0, sizeof(ars_cap));
rc = ars_get_cap(acpi_desc, &ars_cap, nfit_spa);
if (rc < 0)
@@ -3108,16 +3143,14 @@ static void acpi_nfit_init_ars(struct acpi_nfit_desc *acpi_desc,
nfit_spa->clear_err_unit = ars_cap.clear_err_unit;
acpi_desc->max_ars = max(nfit_spa->max_ars, acpi_desc->max_ars);
clear_bit(ARS_FAILED, &nfit_spa->ars_state);
- set_bit(ARS_REQ, &nfit_spa->ars_state);
}
static int acpi_nfit_register_regions(struct acpi_nfit_desc *acpi_desc)
{
struct nfit_spa *nfit_spa;
- int rc, query_rc;
+ int rc;
list_for_each_entry(nfit_spa, &acpi_desc->spas, list) {
- set_bit(ARS_FAILED, &nfit_spa->ars_state);
switch (nfit_spa_type(nfit_spa->spa)) {
case NFIT_SPA_VOLATILE:
case NFIT_SPA_PM:
@@ -3126,20 +3159,12 @@ static int acpi_nfit_register_regions(struct acpi_nfit_desc *acpi_desc)
}
}
- /*
- * Reap any results that might be pending before starting new
- * short requests.
- */
- query_rc = acpi_nfit_query_poison(acpi_desc);
- if (query_rc == 0)
- ars_complete_all(acpi_desc);
-
list_for_each_entry(nfit_spa, &acpi_desc->spas, list)
switch (nfit_spa_type(nfit_spa->spa)) {
case NFIT_SPA_VOLATILE:
case NFIT_SPA_PM:
/* register regions and kick off initial ARS run */
- rc = ars_register(acpi_desc, nfit_spa, &query_rc);
+ rc = ars_register(acpi_desc, nfit_spa);
if (rc)
return rc;
break;
@@ -3334,7 +3359,8 @@ static int acpi_nfit_clear_to_send(struct nvdimm_bus_descriptor *nd_desc,
return 0;
}
-int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc, unsigned long flags)
+int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc,
+ enum nfit_ars_state req_type)
{
struct device *dev = acpi_desc->dev;
int scheduled = 0, busy = 0;
@@ -3354,14 +3380,10 @@ int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc, unsigned long flags)
if (test_bit(ARS_FAILED, &nfit_spa->ars_state))
continue;
- if (test_and_set_bit(ARS_REQ, &nfit_spa->ars_state)) {
+ if (test_and_set_bit(req_type, &nfit_spa->ars_state))
busy++;
- set_bit(ARS_REQ_REDO, &nfit_spa->ars_state);
- } else {
- if (test_bit(ARS_SHORT, &flags))
- set_bit(ARS_SHORT, &nfit_spa->ars_state);
+ else
scheduled++;
- }
}
if (scheduled) {
sched_ars(acpi_desc);
@@ -3547,10 +3569,11 @@ static void acpi_nfit_update_notify(struct device *dev, acpi_handle handle)
static void acpi_nfit_uc_error_notify(struct device *dev, acpi_handle handle)
{
struct acpi_nfit_desc *acpi_desc = dev_get_drvdata(dev);
- unsigned long flags = (acpi_desc->scrub_mode == HW_ERROR_SCRUB_ON) ?
- 0 : 1 << ARS_SHORT;
- acpi_nfit_ars_rescan(acpi_desc, flags);
+ if (acpi_desc->scrub_mode == HW_ERROR_SCRUB_ON)
+ acpi_nfit_ars_rescan(acpi_desc, ARS_REQ_LONG);
+ else
+ acpi_nfit_ars_rescan(acpi_desc, ARS_REQ_SHORT);
}
void __acpi_nfit_notify(struct device *dev, acpi_handle handle, u32 event)
diff --git a/drivers/acpi/nfit/nfit.h b/drivers/acpi/nfit/nfit.h
index af73aec547f2..df0f6b8407e7 100644
--- a/drivers/acpi/nfit/nfit.h
+++ b/drivers/acpi/nfit/nfit.h
@@ -118,10 +118,8 @@ enum nfit_dimm_notifiers {
};
enum nfit_ars_state {
- ARS_REQ,
- ARS_REQ_REDO,
- ARS_DONE,
- ARS_SHORT,
+ ARS_REQ_SHORT,
+ ARS_REQ_LONG,
ARS_FAILED,
};
@@ -205,6 +203,7 @@ struct acpi_nfit_desc {
struct device *dev;
u8 ars_start_flags;
struct nd_cmd_ars_status *ars_status;
+ struct nfit_spa *scrub_spa;
struct delayed_work dwork;
struct list_head list;
struct kernfs_node *scrub_count_state;
@@ -259,7 +258,8 @@ struct nfit_blk {
extern struct list_head acpi_descs;
extern struct mutex acpi_desc_lock;
-int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc, unsigned long flags);
+int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc,
+ enum nfit_ars_state req_type);
#ifdef CONFIG_X86_MCE
void nfit_mce_register(void);
The patch below does not apply to the 4.4-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 34ffec60b27aa81d04e274e71e4c6ef740f75fc7 Mon Sep 17 00:00:00 2001
From: Ming Lei <ming.lei(a)redhat.com>
Date: Mon, 29 Oct 2018 20:57:19 +0800
Subject: [PATCH] block: make sure writesame bio is aligned with logical block
size
Obviously the created writesame bio has to be aligned with logical block
size, and use bio_allowed_max_sectors() to retrieve this number.
Cc: stable(a)vger.kernel.org
Cc: Mike Snitzer <snitzer(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Xiao Ni <xni(a)redhat.com>
Cc: Mariusz Dabrowski <mariusz.dabrowski(a)intel.com>
Fixes: b49a0871be31a745b2ef ("block: remove split code in blkdev_issue_{discard,write_same}")
Tested-by: Rui Salvaterra <rsalvaterra(a)gmail.com>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/block/blk-lib.c b/block/blk-lib.c
index d58d5d87dd88..e8b3bb9bf375 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -149,7 +149,7 @@ static int __blkdev_issue_write_same(struct block_device *bdev, sector_t sector,
return -EOPNOTSUPP;
/* Ensure that max_write_same_sectors doesn't overflow bi_size */
- max_write_same_sectors = UINT_MAX >> 9;
+ max_write_same_sectors = bio_allowed_max_sectors(q);
while (nr_sects) {
bio = blk_next_bio(bio, 1, gfp_mask);
The patch below does not apply to the 4.9-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 34ffec60b27aa81d04e274e71e4c6ef740f75fc7 Mon Sep 17 00:00:00 2001
From: Ming Lei <ming.lei(a)redhat.com>
Date: Mon, 29 Oct 2018 20:57:19 +0800
Subject: [PATCH] block: make sure writesame bio is aligned with logical block
size
Obviously the created writesame bio has to be aligned with logical block
size, and use bio_allowed_max_sectors() to retrieve this number.
Cc: stable(a)vger.kernel.org
Cc: Mike Snitzer <snitzer(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Xiao Ni <xni(a)redhat.com>
Cc: Mariusz Dabrowski <mariusz.dabrowski(a)intel.com>
Fixes: b49a0871be31a745b2ef ("block: remove split code in blkdev_issue_{discard,write_same}")
Tested-by: Rui Salvaterra <rsalvaterra(a)gmail.com>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/block/blk-lib.c b/block/blk-lib.c
index d58d5d87dd88..e8b3bb9bf375 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -149,7 +149,7 @@ static int __blkdev_issue_write_same(struct block_device *bdev, sector_t sector,
return -EOPNOTSUPP;
/* Ensure that max_write_same_sectors doesn't overflow bi_size */
- max_write_same_sectors = UINT_MAX >> 9;
+ max_write_same_sectors = bio_allowed_max_sectors(q);
while (nr_sects) {
bio = blk_next_bio(bio, 1, gfp_mask);
The patch below does not apply to the 4.14-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 34ffec60b27aa81d04e274e71e4c6ef740f75fc7 Mon Sep 17 00:00:00 2001
From: Ming Lei <ming.lei(a)redhat.com>
Date: Mon, 29 Oct 2018 20:57:19 +0800
Subject: [PATCH] block: make sure writesame bio is aligned with logical block
size
Obviously the created writesame bio has to be aligned with logical block
size, and use bio_allowed_max_sectors() to retrieve this number.
Cc: stable(a)vger.kernel.org
Cc: Mike Snitzer <snitzer(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Xiao Ni <xni(a)redhat.com>
Cc: Mariusz Dabrowski <mariusz.dabrowski(a)intel.com>
Fixes: b49a0871be31a745b2ef ("block: remove split code in blkdev_issue_{discard,write_same}")
Tested-by: Rui Salvaterra <rsalvaterra(a)gmail.com>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/block/blk-lib.c b/block/blk-lib.c
index d58d5d87dd88..e8b3bb9bf375 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -149,7 +149,7 @@ static int __blkdev_issue_write_same(struct block_device *bdev, sector_t sector,
return -EOPNOTSUPP;
/* Ensure that max_write_same_sectors doesn't overflow bi_size */
- max_write_same_sectors = UINT_MAX >> 9;
+ max_write_same_sectors = bio_allowed_max_sectors(q);
while (nr_sects) {
bio = blk_next_bio(bio, 1, gfp_mask);
stable-rc/linux-3.18.y build: 183 builds: 0 failed, 183 passed, 291 warnings (v3.18.125)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.125/
Tree: stable-rc
Branch: linux-3.18.y
Git Describe: v3.18.125
Git Commit: 78e0897dd8b321ba1b4a2137778ab7ae7d400af5
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 4 unique architectures
Warnings Detected:
arm64: gcc version 7.3.0 (Debian 7.3.0-28)
allnoconfig: 2 warnings
defconfig: 2 warnings
tinyconfig: 2 warnings
arm: gcc version 7.3.0 (Debian 7.3.0-28)
acs5k_defconfig: 2 warnings
acs5k_tiny_defconfig: 2 warnings
allnoconfig: 2 warnings
am200epdkit_defconfig: 2 warnings
ape6evm_defconfig: 2 warnings
armadillo800eva_defconfig: 2 warnings
assabet_defconfig: 2 warnings
at91_dt_defconfig: 2 warnings
at91rm9200_defconfig: 2 warnings
at91sam9260_9g20_defconfig: 2 warnings
at91sam9261_9g10_defconfig: 2 warnings
at91sam9263_defconfig: 2 warnings
at91sam9g45_defconfig: 2 warnings
at91sam9rl_defconfig: 2 warnings
at91x40_defconfig: 2 warnings
axm55xx_defconfig: 2 warnings
badge4_defconfig: 2 warnings
bcm2835_defconfig: 2 warnings
bcm_defconfig: 2 warnings
bockw_defconfig: 2 warnings
cerfcube_defconfig: 2 warnings
clps711x_defconfig: 2 warnings
cm_x2xx_defconfig: 2 warnings
cm_x300_defconfig: 2 warnings
cns3420vb_defconfig: 2 warnings
colibri_pxa270_defconfig: 2 warnings
colibri_pxa300_defconfig: 2 warnings
collie_defconfig: 2 warnings
corgi_defconfig: 2 warnings
davinci_all_defconfig: 2 warnings
dove_defconfig: 2 warnings
ebsa110_defconfig: 2 warnings
efm32_defconfig: 2 warnings
em_x270_defconfig: 2 warnings
ep93xx_defconfig: 2 warnings
eseries_pxa_defconfig: 2 warnings
exynos_defconfig: 2 warnings
ezx_defconfig: 2 warnings
footbridge_defconfig: 2 warnings
h3600_defconfig: 2 warnings
h5000_defconfig: 2 warnings
hackkit_defconfig: 2 warnings
hisi_defconfig: 2 warnings
imote2_defconfig: 2 warnings
imx_v4_v5_defconfig: 2 warnings
imx_v6_v7_defconfig: 2 warnings
integrator_defconfig: 2 warnings
iop13xx_defconfig: 2 warnings
iop32x_defconfig: 2 warnings
iop33x_defconfig: 2 warnings
ixp4xx_defconfig: 2 warnings
jornada720_defconfig: 2 warnings
keystone_defconfig: 2 warnings
koelsch_defconfig: 2 warnings
ks8695_defconfig: 2 warnings
kzm9g_defconfig: 2 warnings
lager_defconfig: 2 warnings
lart_defconfig: 2 warnings
lpc32xx_defconfig: 2 warnings
lpd270_defconfig: 2 warnings
lubbock_defconfig: 2 warnings
mackerel_defconfig: 2 warnings
magician_defconfig: 2 warnings
mainstone_defconfig: 2 warnings
marzen_defconfig: 2 warnings
mini2440_defconfig: 2 warnings
mmp2_defconfig: 2 warnings
moxart_defconfig: 2 warnings
msm_defconfig: 2 warnings
multi_v5_defconfig: 2 warnings
multi_v7_defconfig: 2 warnings
mv78xx0_defconfig: 2 warnings
mvebu_v5_defconfig: 2 warnings
mvebu_v7_defconfig: 2 warnings
mxs_defconfig: 2 warnings
neponset_defconfig: 2 warnings
netwinder_defconfig: 2 warnings
netx_defconfig: 2 warnings
nhk8815_defconfig: 2 warnings
nuc910_defconfig: 2 warnings
nuc950_defconfig: 2 warnings
nuc960_defconfig: 2 warnings
omap1_defconfig: 2 warnings
omap2plus_defconfig: 2 warnings
orion5x_defconfig: 2 warnings
palmz72_defconfig: 2 warnings
pcm027_defconfig: 2 warnings
pleb_defconfig: 2 warnings
prima2_defconfig: 2 warnings
pxa168_defconfig: 2 warnings
pxa255-idp_defconfig: 2 warnings
pxa3xx_defconfig: 2 warnings
pxa910_defconfig: 2 warnings
qcom_defconfig: 2 warnings
raumfeld_defconfig: 2 warnings
realview-smp_defconfig: 2 warnings
realview_defconfig: 2 warnings
rpc_defconfig: 2 warnings
s3c2410_defconfig: 2 warnings
s3c6400_defconfig: 2 warnings
s5pv210_defconfig: 2 warnings
sama5_defconfig: 2 warnings
shannon_defconfig: 2 warnings
shmobile_defconfig: 2 warnings
simpad_defconfig: 2 warnings
socfpga_defconfig: 2 warnings
spear13xx_defconfig: 2 warnings
spear3xx_defconfig: 2 warnings
spear6xx_defconfig: 2 warnings
spitz_defconfig: 2 warnings
sunxi_defconfig: 2 warnings
tct_hammer_defconfig: 2 warnings
tegra_defconfig: 2 warnings
tinyconfig: 2 warnings
trizeps4_defconfig: 2 warnings
u300_defconfig: 2 warnings
u8500_defconfig: 2 warnings
versatile_defconfig: 2 warnings
vexpress_defconfig: 2 warnings
viper_defconfig: 2 warnings
vt8500_v6_v7_defconfig: 2 warnings
xcep_defconfig: 2 warnings
zeus_defconfig: 2 warnings
x86: gcc version 7.3.0 (Debian 7.3.0-29)
allnoconfig: 3 warnings
i386_defconfig: 3 warnings
tinyconfig: 3 warnings
x86_64_defconfig: 30 warnings
Warnings summary:
126 scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
126 scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
3 arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
2 include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
1 net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
1 lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
1 kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
1 drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
1 block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
1 block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
allnoconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ape6evm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
armadillo800eva_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
assabet_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91_dt_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91rm9200_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9260_9g20_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9261_9g10_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9263_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9g45_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9rl_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91x40_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ath79_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
badge4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm2835_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bigsur_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bockw_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
capcella_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
clps711x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cns3420vb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cobalt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
collie_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
corgi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
davinci_all_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
db1xxx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
dove_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
e55_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
efm32_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
em_x270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ep93xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
exynos_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ezx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
footbridge_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
h5000_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hackkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hisi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
i386_defconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
imote2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
integrator_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop32x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop33x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ip22_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
jazz_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
keystone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
koelsch_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ks8695_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
kzm9g_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lager_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lasat_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lpd270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ls1b_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mackerel_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
magician_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mainstone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
malta_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
marzen_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mini2440_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
moxart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mpc30x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
msp71xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mv78xx0_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mxs_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
neponset_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netwinder_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nhk8815_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc950_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc960_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap1_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap2plus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
orion5x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
palmz72_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pcm027_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pleb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa168_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qcom_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rb532_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview-smp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
realview_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rpc_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rt305x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s3c6400_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s5pv210_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sama5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3micro_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
shmobile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
simpad_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
socfpga_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear6xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spitz_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sunxi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tb0219_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tegra_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
tinyconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u8500_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
versatile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vexpress_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
viper_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
workpad_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86) — PASS, 0 errors, 30 warnings, 0 section mismatches
Warnings:
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
--------------------------------------------------------------------------------
xcep_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
xway_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
---
For more info write to <info(a)kernelci.org>
The patch below does not apply to the 4.9-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 da5e79bc70b84971d2b3a55fb252e34e51d81d48 Mon Sep 17 00:00:00 2001
From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
Date: Mon, 15 Oct 2018 23:21:05 +0200
Subject: [PATCH] cpufreq: conservative: Take limits changes into account
properly
If the policy limits change between invocations of cs_dbs_update(),
the requested frequency value stored in dbs_info may not be updated
and the function may use a stale value of it next time. Moreover, if
idle periods are takem into account by cs_dbs_update(), the requested
frequency value stored in dbs_info may be below the min policy limit,
which is incorrect.
To fix these problems, always update the requested frequency value
in dbs_info along with the local copy of it when the previous
requested frequency is beyond the policy limits and avoid decreasing
the requested frequency below the min policy limit when taking
idle periods into account.
Fixes: abb6627910a1 (cpufreq: conservative: Fix next frequency selection)
Fixes: 00bfe05889e9 (cpufreq: conservative: Decrease frequency faster for deferred updates)
Reported-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz(a)intel.com>
Cc: All applicable <stable(a)vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Acked-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz(a)intel.com>
Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org>
diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index f20f20a77d4d..4268f87e99fc 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -80,8 +80,10 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
* changed in the meantime, so fall back to current frequency in that
* case.
*/
- if (requested_freq > policy->max || requested_freq < policy->min)
+ if (requested_freq > policy->max || requested_freq < policy->min) {
requested_freq = policy->cur;
+ dbs_info->requested_freq = requested_freq;
+ }
freq_step = get_freq_step(cs_tuners, policy);
@@ -92,7 +94,7 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
if (policy_dbs->idle_periods < UINT_MAX) {
unsigned int freq_steps = policy_dbs->idle_periods * freq_step;
- if (requested_freq > freq_steps)
+ if (requested_freq > policy->min + freq_steps)
requested_freq -= freq_steps;
else
requested_freq = policy->min;
The patch below does not apply to the 4.18-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 dd0c91793b7c2658ea32c6b3a2247a8ceca45dc0 Mon Sep 17 00:00:00 2001
From: Tang Junhui <tang.junhui.linux(a)gmail.com>
Date: Mon, 8 Oct 2018 20:41:10 +0800
Subject: [PATCH] bcache: fix ioctl in flash device
When doing ioctl in flash device, it will call ioctl_dev() in super.c,
then we should not to get cached device since flash only device has
no backend device. This patch just move the jugement dc->io_disable
to cached_dev_ioctl() to make ioctl in flash device correctly.
Fixes: 0f0709e6bfc3c ("bcache: stop bcache device when backing device is offline")
Signed-off-by: Tang Junhui <tang.junhui.linux(a)gmail.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Coly Li <colyli(a)suse.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index ee15fb039fd0..3bf35914bb57 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -1218,6 +1218,9 @@ static int cached_dev_ioctl(struct bcache_device *d, fmode_t mode,
{
struct cached_dev *dc = container_of(d, struct cached_dev, disk);
+ if (dc->io_disable)
+ return -EIO;
+
return __blkdev_driver_ioctl(dc->bdev, mode, cmd, arg);
}
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 5fd1466b34e4..9de6695195bf 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -648,10 +648,6 @@ static int ioctl_dev(struct block_device *b, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct bcache_device *d = b->bd_disk->private_data;
- struct cached_dev *dc = container_of(d, struct cached_dev, disk);
-
- if (dc->io_disable)
- return -EIO;
return d->ioctl(d, mode, cmd, arg);
}
The patch below does not apply to the 4.4-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 000412276370a9bcfec73b3752ceefd9a927f1db Mon Sep 17 00:00:00 2001
From: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Date: Fri, 21 Sep 2018 11:32:53 +0200
Subject: [PATCH] mtd: spi-nor: fsl-quadspi: Don't let -EINVAL on the bus
fsl_qspi_get_seqid() may return -EINVAL, but fsl_qspi_init_ahb_read()
doesn't check for error codes with the result that -EINVAL could find
itself signalled over the bus.
In conjunction with the LS1046A SoC's A-009283 errata
("Illegal accesses to SPI flash memory can result in a system hang")
this illegal access to SPI flash memory results in a system hang
if userspace attempts reading later on.
Avoid this by always checking fsl_qspi_get_seqid()'s return value
and bail out otherwise.
Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 7d9620c7ff6c..d1ace310e7c1 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -543,6 +543,9 @@ fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int addr, int len)
/* trigger the LUT now */
seqid = fsl_qspi_get_seqid(q, cmd);
+ if (seqid < 0)
+ return seqid;
+
qspi_writel(q, (seqid << QUADSPI_IPCR_SEQID_SHIFT) | len,
base + QUADSPI_IPCR);
@@ -671,7 +674,7 @@ static void fsl_qspi_set_map_addr(struct fsl_qspi *q)
* causes the controller to clear the buffer, and use the sequence pointed
* by the QUADSPI_BFGENCR[SEQID] to initiate a read from the flash.
*/
-static void fsl_qspi_init_ahb_read(struct fsl_qspi *q)
+static int fsl_qspi_init_ahb_read(struct fsl_qspi *q)
{
void __iomem *base = q->iobase;
int seqid;
@@ -696,8 +699,13 @@ static void fsl_qspi_init_ahb_read(struct fsl_qspi *q)
/* Set the default lut sequence for AHB Read. */
seqid = fsl_qspi_get_seqid(q, q->nor[0].read_opcode);
+ if (seqid < 0)
+ return seqid;
+
qspi_writel(q, seqid << QUADSPI_BFGENCR_SEQID_SHIFT,
q->iobase + QUADSPI_BFGENCR);
+
+ return 0;
}
/* This function was used to prepare and enable QSPI clock */
@@ -805,9 +813,7 @@ static int fsl_qspi_nor_setup_last(struct fsl_qspi *q)
fsl_qspi_init_lut(q);
/* Init for AHB read */
- fsl_qspi_init_ahb_read(q);
-
- return 0;
+ return fsl_qspi_init_ahb_read(q);
}
static const struct of_device_id fsl_qspi_dt_ids[] = {
The patch below does not apply to the 4.9-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 000412276370a9bcfec73b3752ceefd9a927f1db Mon Sep 17 00:00:00 2001
From: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Date: Fri, 21 Sep 2018 11:32:53 +0200
Subject: [PATCH] mtd: spi-nor: fsl-quadspi: Don't let -EINVAL on the bus
fsl_qspi_get_seqid() may return -EINVAL, but fsl_qspi_init_ahb_read()
doesn't check for error codes with the result that -EINVAL could find
itself signalled over the bus.
In conjunction with the LS1046A SoC's A-009283 errata
("Illegal accesses to SPI flash memory can result in a system hang")
this illegal access to SPI flash memory results in a system hang
if userspace attempts reading later on.
Avoid this by always checking fsl_qspi_get_seqid()'s return value
and bail out otherwise.
Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 7d9620c7ff6c..d1ace310e7c1 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -543,6 +543,9 @@ fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int addr, int len)
/* trigger the LUT now */
seqid = fsl_qspi_get_seqid(q, cmd);
+ if (seqid < 0)
+ return seqid;
+
qspi_writel(q, (seqid << QUADSPI_IPCR_SEQID_SHIFT) | len,
base + QUADSPI_IPCR);
@@ -671,7 +674,7 @@ static void fsl_qspi_set_map_addr(struct fsl_qspi *q)
* causes the controller to clear the buffer, and use the sequence pointed
* by the QUADSPI_BFGENCR[SEQID] to initiate a read from the flash.
*/
-static void fsl_qspi_init_ahb_read(struct fsl_qspi *q)
+static int fsl_qspi_init_ahb_read(struct fsl_qspi *q)
{
void __iomem *base = q->iobase;
int seqid;
@@ -696,8 +699,13 @@ static void fsl_qspi_init_ahb_read(struct fsl_qspi *q)
/* Set the default lut sequence for AHB Read. */
seqid = fsl_qspi_get_seqid(q, q->nor[0].read_opcode);
+ if (seqid < 0)
+ return seqid;
+
qspi_writel(q, seqid << QUADSPI_BFGENCR_SEQID_SHIFT,
q->iobase + QUADSPI_BFGENCR);
+
+ return 0;
}
/* This function was used to prepare and enable QSPI clock */
@@ -805,9 +813,7 @@ static int fsl_qspi_nor_setup_last(struct fsl_qspi *q)
fsl_qspi_init_lut(q);
/* Init for AHB read */
- fsl_qspi_init_ahb_read(q);
-
- return 0;
+ return fsl_qspi_init_ahb_read(q);
}
static const struct of_device_id fsl_qspi_dt_ids[] = {
The patch below does not apply to the 4.14-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 000412276370a9bcfec73b3752ceefd9a927f1db Mon Sep 17 00:00:00 2001
From: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Date: Fri, 21 Sep 2018 11:32:53 +0200
Subject: [PATCH] mtd: spi-nor: fsl-quadspi: Don't let -EINVAL on the bus
fsl_qspi_get_seqid() may return -EINVAL, but fsl_qspi_init_ahb_read()
doesn't check for error codes with the result that -EINVAL could find
itself signalled over the bus.
In conjunction with the LS1046A SoC's A-009283 errata
("Illegal accesses to SPI flash memory can result in a system hang")
this illegal access to SPI flash memory results in a system hang
if userspace attempts reading later on.
Avoid this by always checking fsl_qspi_get_seqid()'s return value
and bail out otherwise.
Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Ahmad Fatoum <a.fatoum(a)pengutronix.de>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 7d9620c7ff6c..d1ace310e7c1 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -543,6 +543,9 @@ fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int addr, int len)
/* trigger the LUT now */
seqid = fsl_qspi_get_seqid(q, cmd);
+ if (seqid < 0)
+ return seqid;
+
qspi_writel(q, (seqid << QUADSPI_IPCR_SEQID_SHIFT) | len,
base + QUADSPI_IPCR);
@@ -671,7 +674,7 @@ static void fsl_qspi_set_map_addr(struct fsl_qspi *q)
* causes the controller to clear the buffer, and use the sequence pointed
* by the QUADSPI_BFGENCR[SEQID] to initiate a read from the flash.
*/
-static void fsl_qspi_init_ahb_read(struct fsl_qspi *q)
+static int fsl_qspi_init_ahb_read(struct fsl_qspi *q)
{
void __iomem *base = q->iobase;
int seqid;
@@ -696,8 +699,13 @@ static void fsl_qspi_init_ahb_read(struct fsl_qspi *q)
/* Set the default lut sequence for AHB Read. */
seqid = fsl_qspi_get_seqid(q, q->nor[0].read_opcode);
+ if (seqid < 0)
+ return seqid;
+
qspi_writel(q, seqid << QUADSPI_BFGENCR_SEQID_SHIFT,
q->iobase + QUADSPI_BFGENCR);
+
+ return 0;
}
/* This function was used to prepare and enable QSPI clock */
@@ -805,9 +813,7 @@ static int fsl_qspi_nor_setup_last(struct fsl_qspi *q)
fsl_qspi_init_lut(q);
/* Init for AHB read */
- fsl_qspi_init_ahb_read(q);
-
- return 0;
+ return fsl_qspi_init_ahb_read(q);
}
static const struct of_device_id fsl_qspi_dt_ids[] = {
The patch below does not apply to the 3.18-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 41fe242979e463d6ad251077ded01b825a330b7e Mon Sep 17 00:00:00 2001
From: Liu Xiang <liu.xiang6(a)zte.com.cn>
Date: Tue, 28 Aug 2018 22:32:57 +0800
Subject: [PATCH] mtd: spi-nor: fsl-quadspi: fix read error for flash size
larger than 16MB
If the size of spi-nor flash is larger than 16MB, the read_opcode
is set to SPINOR_OP_READ_1_1_4_4B, and fsl_qspi_get_seqid() will
return -EINVAL when cmd is SPINOR_OP_READ_1_1_4_4B. This can
cause read operation fail.
Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Liu Xiang <liu.xiang6(a)zte.com.cn>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index d1ace310e7c1..1ff3430f82c8 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -478,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
case SPINOR_OP_READ_1_1_4:
+ case SPINOR_OP_READ_1_1_4_4B:
return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
The patch below does not apply to the 4.4-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 41fe242979e463d6ad251077ded01b825a330b7e Mon Sep 17 00:00:00 2001
From: Liu Xiang <liu.xiang6(a)zte.com.cn>
Date: Tue, 28 Aug 2018 22:32:57 +0800
Subject: [PATCH] mtd: spi-nor: fsl-quadspi: fix read error for flash size
larger than 16MB
If the size of spi-nor flash is larger than 16MB, the read_opcode
is set to SPINOR_OP_READ_1_1_4_4B, and fsl_qspi_get_seqid() will
return -EINVAL when cmd is SPINOR_OP_READ_1_1_4_4B. This can
cause read operation fail.
Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Liu Xiang <liu.xiang6(a)zte.com.cn>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index d1ace310e7c1..1ff3430f82c8 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -478,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
case SPINOR_OP_READ_1_1_4:
+ case SPINOR_OP_READ_1_1_4_4B:
return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
The patch below does not apply to the 4.9-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 41fe242979e463d6ad251077ded01b825a330b7e Mon Sep 17 00:00:00 2001
From: Liu Xiang <liu.xiang6(a)zte.com.cn>
Date: Tue, 28 Aug 2018 22:32:57 +0800
Subject: [PATCH] mtd: spi-nor: fsl-quadspi: fix read error for flash size
larger than 16MB
If the size of spi-nor flash is larger than 16MB, the read_opcode
is set to SPINOR_OP_READ_1_1_4_4B, and fsl_qspi_get_seqid() will
return -EINVAL when cmd is SPINOR_OP_READ_1_1_4_4B. This can
cause read operation fail.
Fixes: e46ecda764dc ("mtd: spi-nor: Add Freescale QuadSPI driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Liu Xiang <liu.xiang6(a)zte.com.cn>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index d1ace310e7c1..1ff3430f82c8 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -478,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
{
switch (cmd) {
case SPINOR_OP_READ_1_1_4:
+ case SPINOR_OP_READ_1_1_4_4B:
return SEQID_READ;
case SPINOR_OP_WREN:
return SEQID_WREN;
The patch below does not apply to the 4.4-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 6c925b333368cda4e1b0513b07f72316c0e7edd7 Mon Sep 17 00:00:00 2001
From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Date: Thu, 4 Oct 2018 15:01:04 +0200
Subject: [PATCH] mtd: maps: gpio-addr-flash: Fix ioremapped size
We should only iomap the area of the chip that is memory mapped.
Otherwise we could be mapping devices beyond the memory space or that
belong to other devices.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Fixes: ebd71e3a4861 ("mtd: maps: gpio-addr-flash: fix warnings and make more portable")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/maps/gpio-addr-flash.c b/drivers/mtd/maps/gpio-addr-flash.c
index 17be47f72973..6de16e81994c 100644
--- a/drivers/mtd/maps/gpio-addr-flash.c
+++ b/drivers/mtd/maps/gpio-addr-flash.c
@@ -234,7 +234,7 @@ static int gpio_flash_probe(struct platform_device *pdev)
state->map.copy_to = gf_copy_to;
state->map.bankwidth = pdata->width;
state->map.size = state->win_size * (1 << state->gpio_count);
- state->map.virt = ioremap_nocache(memory->start, state->map.size);
+ state->map.virt = ioremap_nocache(memory->start, state->win_size);
if (!state->map.virt)
return -ENOMEM;
The patch below does not apply to the 4.9-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 6c925b333368cda4e1b0513b07f72316c0e7edd7 Mon Sep 17 00:00:00 2001
From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Date: Thu, 4 Oct 2018 15:01:04 +0200
Subject: [PATCH] mtd: maps: gpio-addr-flash: Fix ioremapped size
We should only iomap the area of the chip that is memory mapped.
Otherwise we could be mapping devices beyond the memory space or that
belong to other devices.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Fixes: ebd71e3a4861 ("mtd: maps: gpio-addr-flash: fix warnings and make more portable")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/maps/gpio-addr-flash.c b/drivers/mtd/maps/gpio-addr-flash.c
index 17be47f72973..6de16e81994c 100644
--- a/drivers/mtd/maps/gpio-addr-flash.c
+++ b/drivers/mtd/maps/gpio-addr-flash.c
@@ -234,7 +234,7 @@ static int gpio_flash_probe(struct platform_device *pdev)
state->map.copy_to = gf_copy_to;
state->map.bankwidth = pdata->width;
state->map.size = state->win_size * (1 << state->gpio_count);
- state->map.virt = ioremap_nocache(memory->start, state->map.size);
+ state->map.virt = ioremap_nocache(memory->start, state->win_size);
if (!state->map.virt)
return -ENOMEM;
The patch below does not apply to the 4.14-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 6c925b333368cda4e1b0513b07f72316c0e7edd7 Mon Sep 17 00:00:00 2001
From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Date: Thu, 4 Oct 2018 15:01:04 +0200
Subject: [PATCH] mtd: maps: gpio-addr-flash: Fix ioremapped size
We should only iomap the area of the chip that is memory mapped.
Otherwise we could be mapping devices beyond the memory space or that
belong to other devices.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Fixes: ebd71e3a4861 ("mtd: maps: gpio-addr-flash: fix warnings and make more portable")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/maps/gpio-addr-flash.c b/drivers/mtd/maps/gpio-addr-flash.c
index 17be47f72973..6de16e81994c 100644
--- a/drivers/mtd/maps/gpio-addr-flash.c
+++ b/drivers/mtd/maps/gpio-addr-flash.c
@@ -234,7 +234,7 @@ static int gpio_flash_probe(struct platform_device *pdev)
state->map.copy_to = gf_copy_to;
state->map.bankwidth = pdata->width;
state->map.size = state->win_size * (1 << state->gpio_count);
- state->map.virt = ioremap_nocache(memory->start, state->map.size);
+ state->map.virt = ioremap_nocache(memory->start, state->win_size);
if (!state->map.virt)
return -ENOMEM;
The patch below does not apply to the 4.18-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 6c925b333368cda4e1b0513b07f72316c0e7edd7 Mon Sep 17 00:00:00 2001
From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Date: Thu, 4 Oct 2018 15:01:04 +0200
Subject: [PATCH] mtd: maps: gpio-addr-flash: Fix ioremapped size
We should only iomap the area of the chip that is memory mapped.
Otherwise we could be mapping devices beyond the memory space or that
belong to other devices.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Fixes: ebd71e3a4861 ("mtd: maps: gpio-addr-flash: fix warnings and make more portable")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
diff --git a/drivers/mtd/maps/gpio-addr-flash.c b/drivers/mtd/maps/gpio-addr-flash.c
index 17be47f72973..6de16e81994c 100644
--- a/drivers/mtd/maps/gpio-addr-flash.c
+++ b/drivers/mtd/maps/gpio-addr-flash.c
@@ -234,7 +234,7 @@ static int gpio_flash_probe(struct platform_device *pdev)
state->map.copy_to = gf_copy_to;
state->map.bankwidth = pdata->width;
state->map.size = state->win_size * (1 << state->gpio_count);
- state->map.virt = ioremap_nocache(memory->start, state->map.size);
+ state->map.virt = ioremap_nocache(memory->start, state->win_size);
if (!state->map.virt)
return -ENOMEM;
I'm announcing the release of the 4.18.18 kernel.
All users of the 4.18 kernel series must upgrade.
The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.18.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
arch/x86/include/asm/fpu/internal.h | 2
arch/x86/include/asm/percpu.h | 8 +-
arch/x86/kernel/pci-swiotlb.c | 2
arch/x86/kernel/setup.c | 2
arch/x86/kernel/time.c | 2
arch/x86/kernel/tsc.c | 6 -
drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 10 ++
drivers/gpio/gpio-mxs.c | 4 -
drivers/gpu/drm/drm_edid.c | 5 +
drivers/gpu/drm/drm_fb_helper.c | 91 +++++++------------------
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 12 +++
drivers/infiniband/core/ucm.c | 3
drivers/infiniband/core/ucma.c | 3
drivers/input/mouse/elan_i2c_core.c | 1
drivers/misc/eeprom/at24.c | 17 ++++
drivers/ptp/ptp_chardev.c | 4 +
drivers/usb/class/cdc-acm.c | 16 ++--
drivers/usb/core/devio.c | 4 -
drivers/usb/gadget/function/f_mass_storage.c | 3
drivers/usb/host/xhci-pci.c | 6 +
drivers/usb/roles/intel-xhci-usb-role-switch.c | 2
drivers/usb/usbip/vhci_hcd.c | 57 +++++++++++----
fs/cachefiles/namei.c | 2
fs/fscache/cookie.c | 31 ++------
fs/fscache/internal.h | 1
fs/fscache/main.c | 4 -
fs/ioctl.c | 2
fs/nfsd/vfs.c | 3
fs/overlayfs/copy_up.c | 2
fs/read_write.c | 17 ++++
include/drm/drm_edid.h | 6 -
include/linux/bpf_verifier.h | 3
include/linux/fs.h | 17 ----
kernel/bpf/verifier.c | 10 +-
kernel/sched/fair.c | 22 +++++-
kernel/sched/sched.h | 2
kernel/trace/trace_events_hist.c | 32 ++++++--
38 files changed, 243 insertions(+), 173 deletions(-)
Al Viro (1):
cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)
Alan Chiang (1):
eeprom: at24: Add support for address-width property
Alan Stern (1):
USB: fix the usbfs flag sanitization for control transfers
Amir Goldstein (1):
vfs: swap names of {do,vfs}_clone_file_range()
Boris Brezillon (1):
drm/sun4i: Fix an ulong overflow in the dotclock driver
Chen-Yu Tsai (1):
clk: sunxi-ng: sun4i: Set VCO and PLL bias current to lowest setting
Christoph Hellwig (1):
x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
Clint Taylor (1):
drm/edid: VSDB yCBCr420 Deep Color mode bit definitions
Daniel Borkmann (1):
bpf: fix partial copy of map_ptr when dst is scalar
David Howells (1):
fscache: Fix incomplete initialisation of inline key space
Eric Sandeen (1):
fscache: Fix out of bound read in long cookie keys
Eugeniy Paltsev (1):
drm: fb-helper: Reject all pixel format changing requests
Greg Kroah-Hartman (1):
Linux 4.18.18
Gustavo A. R. Silva (4):
ptp: fix Spectre v1 vulnerability
RDMA/ucma: Fix Spectre v1 vulnerability
IB/ucm: Fix Spectre v1 vulnerability
usb: gadget: storage: Fix Spectre v1 vulnerability
Heikki Krogerus (1):
usb: xhci: pci: Enable Intel USB role mux on Apollo Lake platforms
Kai-Heng Feng (1):
drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
Linus Walleij (1):
gpio: mxs: Get rid of external API call
Masami Hiramatsu (2):
tracing: Fix synthetic event to accept unsigned modifier
tracing: Fix synthetic event to allow semicolon at end
Mikhail Nikiforov (1):
Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM
Nathan Chancellor (1):
x86/time: Correct the attribute on jiffies' definition
Oliver Neukum (1):
cdc-acm: fix race between reset and control messaging
Peter Zijlstra (2):
x86/tsc: Force inlining of cyc2ns bits
x86/percpu: Fix this_cpu_read()
Phil Auld (1):
sched/fair: Fix throttle_list starvation with low CFS quota
Sebastian Andrzej Siewior (1):
x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU
Shuah Khan (Samsung OSG) (1):
usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()
Tobias Herzog (2):
cdc-acm: do not reset notification buffer index upon urb unlinking
cdc-acm: correct counting of UART states in serial state notification
Wan Ahmad Zainie (1):
usb: roles: intel_xhci: Fix Unbalanced pm_runtime_enable
Zhimin Gu (1):
x86, hibernate: Fix nosave_regions setup for hibernation
This is the start of the stable review cycle for the 4.18.18 release.
There are 34 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 Sat Nov 10 21:51:21 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.18.18-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.18.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.18.18-rc1
Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU
Christoph Hellwig <hch(a)lst.de>
x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels
Nathan Chancellor <natechancellor(a)gmail.com>
x86/time: Correct the attribute on jiffies' definition
Peter Zijlstra <peterz(a)infradead.org>
x86/percpu: Fix this_cpu_read()
Zhimin Gu <kookoo.gu(a)intel.com>
x86, hibernate: Fix nosave_regions setup for hibernation
Peter Zijlstra <peterz(a)infradead.org>
x86/tsc: Force inlining of cyc2ns bits
Phil Auld <pauld(a)redhat.com>
sched/fair: Fix throttle_list starvation with low CFS quota
Boris Brezillon <boris.brezillon(a)bootlin.com>
drm/sun4i: Fix an ulong overflow in the dotclock driver
Mikhail Nikiforov <jackxviichaos(a)gmail.com>
Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM
Masami Hiramatsu <mhiramat(a)kernel.org>
tracing: Fix synthetic event to allow semicolon at end
Masami Hiramatsu <mhiramat(a)kernel.org>
tracing: Fix synthetic event to accept unsigned modifier
Ming Lei <ming.lei(a)redhat.com>
block: don't deal with discard limit in blkdev_issue_discard()
Alan Stern <stern(a)rowland.harvard.edu>
USB: fix the usbfs flag sanitization for control transfers
Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
usb: xhci: pci: Enable Intel USB role mux on Apollo Lake platforms
Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad(a)intel.com>
usb: roles: intel_xhci: Fix Unbalanced pm_runtime_enable
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
usb: gadget: storage: Fix Spectre v1 vulnerability
Shuah Khan (Samsung OSG) <shuah(a)kernel.org>
usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()
Oliver Neukum <oneukum(a)suse.com>
cdc-acm: fix race between reset and control messaging
Tobias Herzog <t-herzog(a)gmx.de>
cdc-acm: correct counting of UART states in serial state notification
Tobias Herzog <t-herzog(a)gmx.de>
cdc-acm: do not reset notification buffer index upon urb unlinking
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
IB/ucm: Fix Spectre v1 vulnerability
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
RDMA/ucma: Fix Spectre v1 vulnerability
Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com>
drm: fb-helper: Reject all pixel format changing requests
Clint Taylor <clinton.a.taylor(a)intel.com>
drm/edid: VSDB yCBCr420 Deep Color mode bit definitions
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
ptp: fix Spectre v1 vulnerability
Eric Sandeen <sandeen(a)redhat.com>
fscache: Fix out of bound read in long cookie keys
Al Viro <viro(a)zeniv.linux.org.uk>
cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)
David Howells <dhowells(a)redhat.com>
fscache: Fix incomplete initialisation of inline key space
Chen-Yu Tsai <wens(a)csie.org>
clk: sunxi-ng: sun4i: Set VCO and PLL bias current to lowest setting
Linus Walleij <linus.walleij(a)linaro.org>
gpio: mxs: Get rid of external API call
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: fix partial copy of map_ptr when dst is scalar
Amir Goldstein <amir73il(a)gmail.com>
vfs: swap names of {do,vfs}_clone_file_range()
Alan Chiang <alanx.chiang(a)intel.com>
eeprom: at24: Add support for address-width property
-------------
Diffstat:
Makefile | 4 +-
arch/x86/include/asm/fpu/internal.h | 2 +-
arch/x86/include/asm/percpu.h | 8 +--
arch/x86/kernel/pci-swiotlb.c | 2 -
arch/x86/kernel/setup.c | 2 +-
arch/x86/kernel/time.c | 2 +-
arch/x86/kernel/tsc.c | 6 +-
block/blk-lib.c | 28 +-------
drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 10 ++-
drivers/gpio/gpio-mxs.c | 4 +-
drivers/gpu/drm/drm_edid.c | 5 +-
drivers/gpu/drm/drm_fb_helper.c | 91 ++++++++------------------
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 12 +++-
drivers/infiniband/core/ucm.c | 3 +
drivers/infiniband/core/ucma.c | 3 +
drivers/input/mouse/elan_i2c_core.c | 1 +
drivers/misc/eeprom/at24.c | 17 +++++
drivers/ptp/ptp_chardev.c | 4 ++
drivers/usb/class/cdc-acm.c | 16 ++---
drivers/usb/core/devio.c | 4 +-
drivers/usb/gadget/function/f_mass_storage.c | 3 +
drivers/usb/host/xhci-pci.c | 6 +-
drivers/usb/roles/intel-xhci-usb-role-switch.c | 2 +
drivers/usb/usbip/vhci_hcd.c | 57 +++++++++++-----
fs/cachefiles/namei.c | 2 +-
fs/fscache/cookie.c | 31 +++------
fs/fscache/internal.h | 1 -
fs/fscache/main.c | 4 +-
fs/ioctl.c | 2 +-
fs/nfsd/vfs.c | 3 +-
fs/overlayfs/copy_up.c | 2 +-
fs/read_write.c | 17 ++++-
include/drm/drm_edid.h | 6 +-
include/linux/bpf_verifier.h | 3 +
include/linux/fs.h | 17 +----
kernel/bpf/verifier.c | 10 +--
kernel/sched/fair.c | 22 ++++++-
kernel/sched/sched.h | 2 +
kernel/trace/trace_events_hist.c | 32 +++++++--
39 files changed, 246 insertions(+), 200 deletions(-)
This is the start of the stable review cycle for the 4.14.80 release.
There are 31 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 Sat Nov 10 21:51: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.80-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.80-rc1
Christophe Leroy <christophe.leroy(a)c-s.fr>
net: fs_enet: do not call phy_stop() in interrupts
Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU
Nathan Chancellor <natechancellor(a)gmail.com>
x86/time: Correct the attribute on jiffies' definition
Peter Zijlstra <peterz(a)infradead.org>
x86/percpu: Fix this_cpu_read()
Zhimin Gu <kookoo.gu(a)intel.com>
x86, hibernate: Fix nosave_regions setup for hibernation
Peter Zijlstra <peterz(a)infradead.org>
x86/tsc: Force inlining of cyc2ns bits
Phil Auld <pauld(a)redhat.com>
sched/fair: Fix throttle_list starvation with low CFS quota
Mikhail Nikiforov <jackxviichaos(a)gmail.com>
Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM
Alan Stern <stern(a)rowland.harvard.edu>
USB: fix the usbfs flag sanitization for control transfers
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
usb: gadget: storage: Fix Spectre v1 vulnerability
Shuah Khan (Samsung OSG) <shuah(a)kernel.org>
usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()
Oliver Neukum <oneukum(a)suse.com>
cdc-acm: fix race between reset and control messaging
Tobias Herzog <t-herzog(a)gmx.de>
cdc-acm: correct counting of UART states in serial state notification
Tobias Herzog <t-herzog(a)gmx.de>
cdc-acm: do not reset notification buffer index upon urb unlinking
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
IB/ucm: Fix Spectre v1 vulnerability
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
RDMA/ucma: Fix Spectre v1 vulnerability
Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com>
drm: fb-helper: Reject all pixel format changing requests
Clint Taylor <clinton.a.taylor(a)intel.com>
drm/edid: VSDB yCBCr420 Deep Color mode bit definitions
Kai-Heng Feng <kai.heng.feng(a)canonical.com>
drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
ptp: fix Spectre v1 vulnerability
Al Viro <viro(a)zeniv.linux.org.uk>
cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)
Brian Foster <bfoster(a)redhat.com>
xfs: truncate transaction does not modify the inobt
Linus Walleij <linus.walleij(a)linaro.org>
gpio: mxs: Get rid of external API call
Amir Goldstein <amir73il(a)gmail.com>
fsnotify: fix ignore mask logic in fsnotify()
Dmitry Osipenko <digetx(a)gmail.com>
clk: tegra: Add quirk for getting CDEV1/2 clocks on Tegra20
Sasha Levin <sashal(a)kernel.org>
Revert "ARM: tegra: Fix ULPI regression on Tegra20"
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: fix partial copy of map_ptr when dst is scalar
Johan Hovold <johan(a)kernel.org>
USB: serial: option: add two-endpoints device-id flag
Kristian Evensen <kristian.evensen(a)gmail.com>
USB: serial: option: improve Quectel EP06 detection
Amir Goldstein <amir73il(a)gmail.com>
vfs: swap names of {do,vfs}_clone_file_range()
Alan Chiang <alanx.chiang(a)intel.com>
eeprom: at24: Add support for address-width property
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/tegra20.dtsi | 2 +-
arch/x86/include/asm/fpu/internal.h | 2 +-
arch/x86/include/asm/percpu.h | 8 +-
arch/x86/kernel/setup.c | 2 +-
arch/x86/kernel/time.c | 2 +-
arch/x86/kernel/tsc.c | 6 +-
drivers/clk/tegra/clk-tegra114.c | 2 +-
drivers/clk/tegra/clk-tegra124.c | 2 +-
drivers/clk/tegra/clk-tegra20.c | 32 +++++++-
drivers/clk/tegra/clk-tegra210.c | 2 +-
drivers/clk/tegra/clk-tegra30.c | 2 +-
drivers/clk/tegra/clk.c | 5 +-
drivers/clk/tegra/clk.h | 2 +-
drivers/gpio/gpio-mxs.c | 4 +-
drivers/gpu/drm/drm_edid.c | 5 +-
drivers/gpu/drm/drm_fb_helper.c | 91 +++++++---------------
drivers/infiniband/core/ucm.c | 3 +
drivers/infiniband/core/ucma.c | 3 +
drivers/input/mouse/elan_i2c_core.c | 1 +
drivers/misc/eeprom/at24.c | 17 ++++
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 16 +++-
drivers/net/ethernet/freescale/fs_enet/fs_enet.h | 1 +
drivers/ptp/ptp_chardev.c | 4 +
drivers/usb/class/cdc-acm.c | 16 ++--
drivers/usb/core/devio.c | 4 +-
drivers/usb/gadget/function/f_mass_storage.c | 3 +
drivers/usb/serial/option.c | 15 +++-
drivers/usb/usbip/vhci_hcd.c | 57 ++++++++++----
fs/cachefiles/namei.c | 2 +-
fs/ioctl.c | 2 +-
fs/nfsd/vfs.c | 3 +-
fs/notify/fsnotify.c | 14 ++--
fs/overlayfs/copy_up.c | 2 +-
fs/read_write.c | 17 +++-
fs/xfs/libxfs/xfs_trans_resv.c | 9 +--
include/drm/drm_edid.h | 6 +-
include/linux/bpf_verifier.h | 3 +
include/linux/fs.h | 17 +---
kernel/bpf/verifier.c | 10 ++-
kernel/sched/fair.c | 22 +++++-
kernel/sched/sched.h | 2 +
42 files changed, 255 insertions(+), 167 deletions(-)
From: Changwei Ge <ge.changwei(a)h3c.com>
Somehow, file system metadata was corrupted, which causes
ocfs2_check_dir_entry() to fail in function ocfs2_dir_foreach_blk_el().
According to the original design intention, if above happens we should
skip the problematic block and continue to retrieve dir entry. But there
is obviouse misuse of brelse around related code.
After failure of ocfs2_check_dir_entry(), currunt code just moves to next
position and uses the problematic buffer head again and again during
which the problematic buffer head is released for multiple times. I
suppose, this a serious issue which is long-lived in ocfs2. This may
cause other file systems which is also used in a the same host insane.
So we should also consider about bakcporting this patch into
linux -stable.
Suggested-by: Changkuo Shi <shi.changkuo(a)h3c.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Changwei Ge <ge.changwei(a)h3c.com>
---
fs/ocfs2/dir.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index b048d4f..c121abb 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -1897,8 +1897,7 @@ static int ocfs2_dir_foreach_blk_el(struct inode *inode,
/* On error, skip the f_pos to the
next block. */
ctx->pos = (ctx->pos | (sb->s_blocksize - 1)) + 1;
- brelse(bh);
- continue;
+ break;
}
if (le64_to_cpu(de->inode)) {
unsigned char d_type = DT_UNKNOWN;
--
2.7.4
Dear friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
Thanks and waiting to hear from you
Abel.
This is a note to let you know that I've just added the patch titled
serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeout
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-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 641a41dbba217ee5bd26abe6be77f8cead9cd00e Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Tue, 30 Oct 2018 15:13:35 +0900
Subject: serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeout
This patch fixes an issue that the sci_remove() could not remove
dev_attr_rx_fifo_timeout because uart_remove_one_port() set
the port->port.type to PORT_UNKNOWN.
Reported-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Reviewed-by: Ulrich Hecht <uli+renesas(a)fpond.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index e19bfbba8a01..effba6ce0caa 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3102,6 +3102,7 @@ static struct uart_driver sci_uart_driver = {
static int sci_remove(struct platform_device *dev)
{
struct sci_port *port = platform_get_drvdata(dev);
+ unsigned int type = port->port.type; /* uart_remove_... clears it */
sci_ports_in_use &= ~BIT(port->port.line);
uart_remove_one_port(&sci_uart_driver, &port->port);
@@ -3112,8 +3113,7 @@ static int sci_remove(struct platform_device *dev)
sysfs_remove_file(&dev->dev.kobj,
&dev_attr_rx_fifo_trigger.attr);
}
- if (port->port.type == PORT_SCIFA || port->port.type == PORT_SCIFB ||
- port->port.type == PORT_HSCIF) {
+ if (type == PORT_SCIFA || type == PORT_SCIFB || type == PORT_HSCIF) {
sysfs_remove_file(&dev->dev.kobj,
&dev_attr_rx_fifo_timeout.attr);
}
--
2.19.1
Unfortunately drm_dp_get_mst_branch_device which is called from both
drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely
on that mgr->mst_primary is not NULL, which seem to be wrong as it can be
cleared with simultaneous mode set, if probing fails or in other case.
mgr->lock mutex doesn't protect against that as it might just get
assigned to NULL right before, not simultaneously.
There are currently bugs 107738, 108616 bugs which crash in
drm_dp_get_mst_branch_device, caused by this issue.
v2: Refactored the code, as it was nicely noticed.
Fixed Bugzilla bug numbers(second was 108616, but not 108816)
and added links.
Reviewed-by: Lyude Paul <lyude(a)redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108616
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107738
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy(a)intel.com>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5ff1d79b86c4..0e0df398222d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1275,6 +1275,9 @@ static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device(struct drm_dp_mst_
mutex_lock(&mgr->lock);
mstb = mgr->mst_primary;
+ if (!mstb)
+ goto out;
+
for (i = 0; i < lct - 1; i++) {
int shift = (i % 2) ? 0 : 4;
int port_num = (rad[i / 2] >> shift) & 0xf;
--
2.17.1
This is a note to let you know that I've just added the patch titled
xhci: Add check for invalid byte size error when UAS devices are
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-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 d9193efba84fe4c4aa22a569fade5e6ca971f8af Mon Sep 17 00:00:00 2001
From: Sandeep Singh <sandeep.singh(a)amd.com>
Date: Fri, 9 Nov 2018 17:21:19 +0200
Subject: xhci: Add check for invalid byte size error when UAS devices are
connected.
Observed "TRB completion code (27)" error which corresponds to Stopped -
Length Invalid error(xhci spec section 4.17.4) while connecting USB to
SATA bridge.
Looks like this case was not considered when the following patch[1] was
committed. Hence adding this new check which can prevent
the invalid byte size error.
[1] ade2e3a xhci: handle transfer events without TRB pointer
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Sandeep Singh <sandeep.singh(a)amd.com>
cc: Nehal Shah <Nehal-bakulchandra.Shah(a)amd.com>
cc: Shyam Sundar S K <Shyam-sundar.S-k(a)amd.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 80d464ea5a9a..730a6ecd85fc 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2273,6 +2273,7 @@ static int handle_tx_event(struct xhci_hcd *xhci,
goto cleanup;
case COMP_RING_UNDERRUN:
case COMP_RING_OVERRUN:
+ case COMP_STOPPED_LENGTH_INVALID:
goto cleanup;
default:
xhci_err(xhci, "ERROR Transfer event for unknown stream ring slot %u ep %u\n",
--
2.19.1