mips-bpf-fix-encoding-bug-for-mm_srlv32_op.patch
media-coda-fix-h.264-deblocking-filter-controls.patch
arm-dts-fix-up-the-d-link-dir-685-mtd-partition-info.patch
-tracing-have-trace_stack-nr_entries-compare-not-be-s.patch
watchdog-renesas_wdt-don-t-set-divider-while-watchdo.patch
usb-dwc3-gadget-disable-csp-for-stream-out-ep.patch
iommu-arm-smmu-add-support-for-qcom-smmu-v2-variant.patch
+++ /dev/null
-From ad41aeaf4dd5895c7f0ab6b438373ee778dfb151 Mon Sep 17 00:00:00 2001
-From: Dan Carpenter <dan.carpenter@oracle.com>
-Date: Wed, 20 Jun 2018 14:08:00 +0300
-Subject: tracing: Have trace_stack nr_entries compare not be so subtle
-
-[ Upstream commit ca16b0fbb05242f18da9d810c07d3882ffed831c ]
-
-Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
-one bug.
-
- "From reviewing the code, it seems possible for
- stack_trace_max.nr_entries to be set to .max_entries and in that case we
- would be reading one element beyond the end of the stack_dump_trace[]
- array. If it's not set to .max_entries then the bug doesn't affect
- runtime."
-
-Although it looks to be the case, it is not. Because we have:
-
- static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
- { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
-
- struct stack_trace stack_trace_max = {
- .max_entries = STACK_TRACE_ENTRIES - 1,
- .entries = &stack_dump_trace[0],
- };
-
-And:
-
- stack_trace_max.nr_entries = x;
- for (; x < i; x++)
- stack_dump_trace[x] = ULONG_MAX;
-
-Even if nr_entries equals max_entries, indexing with it into the
-stack_dump_trace[] array will not overflow the array. But if it is the case,
-the second part of the conditional that tests stack_dump_trace[nr_entries]
-to ULONG_MAX will always be true.
-
-By applying Dan's patch, it removes the subtle aspect of it and makes the if
-conditional slightly more efficient.
-
-Link: http://lkml.kernel.org/r/20180620110758.crunhd5bfep7zuiz@kili.mountain
-
-Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
-Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- kernel/trace/trace_stack.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
-index 719a52a4064a..ba662010542c 100644
---- a/kernel/trace/trace_stack.c
-+++ b/kernel/trace/trace_stack.c
-@@ -282,7 +282,7 @@ __next(struct seq_file *m, loff_t *pos)
- {
- long n = *pos - 1;
-
-- if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
-+ if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
- return NULL;
-
- m->private = (void *)n;
---
-2.19.1
-
mips-bpf-fix-encoding-bug-for-mm_srlv32_op.patch
media-coda-fix-h.264-deblocking-filter-controls.patch
arm-dts-fix-up-the-d-link-dir-685-mtd-partition-info.patch
-tracing-have-trace_stack-nr_entries-compare-not-be-s.patch
watchdog-renesas_wdt-don-t-set-divider-while-watchdo.patch
arm-dts-imx51-zii-rdu1-do-not-specify-power-gpio-for.patch
usb-dwc3-gadget-disable-csp-for-stream-out-ep.patch
+++ /dev/null
-From af4dc639e26f2f315eeb3bb2e9f593871d7d1f8c Mon Sep 17 00:00:00 2001
-From: Dan Carpenter <dan.carpenter@oracle.com>
-Date: Wed, 20 Jun 2018 14:08:00 +0300
-Subject: tracing: Have trace_stack nr_entries compare not be so subtle
-
-[ Upstream commit ca16b0fbb05242f18da9d810c07d3882ffed831c ]
-
-Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
-one bug.
-
- "From reviewing the code, it seems possible for
- stack_trace_max.nr_entries to be set to .max_entries and in that case we
- would be reading one element beyond the end of the stack_dump_trace[]
- array. If it's not set to .max_entries then the bug doesn't affect
- runtime."
-
-Although it looks to be the case, it is not. Because we have:
-
- static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
- { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
-
- struct stack_trace stack_trace_max = {
- .max_entries = STACK_TRACE_ENTRIES - 1,
- .entries = &stack_dump_trace[0],
- };
-
-And:
-
- stack_trace_max.nr_entries = x;
- for (; x < i; x++)
- stack_dump_trace[x] = ULONG_MAX;
-
-Even if nr_entries equals max_entries, indexing with it into the
-stack_dump_trace[] array will not overflow the array. But if it is the case,
-the second part of the conditional that tests stack_dump_trace[nr_entries]
-to ULONG_MAX will always be true.
-
-By applying Dan's patch, it removes the subtle aspect of it and makes the if
-conditional slightly more efficient.
-
-Link: http://lkml.kernel.org/r/20180620110758.crunhd5bfep7zuiz@kili.mountain
-
-Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
-Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- kernel/trace/trace_stack.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
-index 4237eba4ef20..6e3edd745c68 100644
---- a/kernel/trace/trace_stack.c
-+++ b/kernel/trace/trace_stack.c
-@@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos)
- {
- long n = *pos - 1;
-
-- if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
-+ if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
- return NULL;
-
- m->private = (void *)n;
---
-2.19.1
-
media-coda-fix-h.264-deblocking-filter-controls.patch
arm64-dts-meson-fix-irq-trigger-type-for-macirq.patch
arm-dts-fix-up-the-d-link-dir-685-mtd-partition-info.patch
-tracing-have-trace_stack-nr_entries-compare-not-be-s.patch
watchdog-renesas_wdt-don-t-set-divider-while-watchdo.patch
arm-dts-imx51-zii-rdu1-do-not-specify-power-gpio-for.patch
usb-dwc3-gadget-disable-csp-for-stream-out-ep.patch
+++ /dev/null
-From 165423a2a8ad0c5ffc0155bce8c52d791c29f6b5 Mon Sep 17 00:00:00 2001
-From: Dan Carpenter <dan.carpenter@oracle.com>
-Date: Wed, 20 Jun 2018 14:08:00 +0300
-Subject: tracing: Have trace_stack nr_entries compare not be so subtle
-
-[ Upstream commit ca16b0fbb05242f18da9d810c07d3882ffed831c ]
-
-Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
-one bug.
-
- "From reviewing the code, it seems possible for
- stack_trace_max.nr_entries to be set to .max_entries and in that case we
- would be reading one element beyond the end of the stack_dump_trace[]
- array. If it's not set to .max_entries then the bug doesn't affect
- runtime."
-
-Although it looks to be the case, it is not. Because we have:
-
- static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
- { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
-
- struct stack_trace stack_trace_max = {
- .max_entries = STACK_TRACE_ENTRIES - 1,
- .entries = &stack_dump_trace[0],
- };
-
-And:
-
- stack_trace_max.nr_entries = x;
- for (; x < i; x++)
- stack_dump_trace[x] = ULONG_MAX;
-
-Even if nr_entries equals max_entries, indexing with it into the
-stack_dump_trace[] array will not overflow the array. But if it is the case,
-the second part of the conditional that tests stack_dump_trace[nr_entries]
-to ULONG_MAX will always be true.
-
-By applying Dan's patch, it removes the subtle aspect of it and makes the if
-conditional slightly more efficient.
-
-Link: http://lkml.kernel.org/r/20180620110758.crunhd5bfep7zuiz@kili.mountain
-
-Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
-Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- kernel/trace/trace_stack.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
-index 2b0d1ee3241c..e2a153fc1afc 100644
---- a/kernel/trace/trace_stack.c
-+++ b/kernel/trace/trace_stack.c
-@@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos)
- {
- long n = *pos - 1;
-
-- if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
-+ if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
- return NULL;
-
- m->private = (void *)n;
---
-2.19.1
-
timekeeping-use-proper-seqcount-initializer.patch
arm-dts-fix-omap4430-sdp-ethernet-startup.patch
mips-bpf-fix-encoding-bug-for-mm_srlv32_op.patch
-tracing-have-trace_stack-nr_entries-compare-not-be-s.patch
iommu-arm-smmu-v3-use-explicit-mb-when-moving-cons-p.patch
sata_rcar-fix-deferred-probing.patch
clk-imx6sl-ensure-mmdc-ch0-handshake-is-bypassed.patch
+++ /dev/null
-From eded309e14001f5caf6e5cbe7e3b3734458518e9 Mon Sep 17 00:00:00 2001
-From: Dan Carpenter <dan.carpenter@oracle.com>
-Date: Wed, 20 Jun 2018 14:08:00 +0300
-Subject: tracing: Have trace_stack nr_entries compare not be so subtle
-
-[ Upstream commit ca16b0fbb05242f18da9d810c07d3882ffed831c ]
-
-Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
-one bug.
-
- "From reviewing the code, it seems possible for
- stack_trace_max.nr_entries to be set to .max_entries and in that case we
- would be reading one element beyond the end of the stack_dump_trace[]
- array. If it's not set to .max_entries then the bug doesn't affect
- runtime."
-
-Although it looks to be the case, it is not. Because we have:
-
- static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
- { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
-
- struct stack_trace stack_trace_max = {
- .max_entries = STACK_TRACE_ENTRIES - 1,
- .entries = &stack_dump_trace[0],
- };
-
-And:
-
- stack_trace_max.nr_entries = x;
- for (; x < i; x++)
- stack_dump_trace[x] = ULONG_MAX;
-
-Even if nr_entries equals max_entries, indexing with it into the
-stack_dump_trace[] array will not overflow the array. But if it is the case,
-the second part of the conditional that tests stack_dump_trace[nr_entries]
-to ULONG_MAX will always be true.
-
-By applying Dan's patch, it removes the subtle aspect of it and makes the if
-conditional slightly more efficient.
-
-Link: http://lkml.kernel.org/r/20180620110758.crunhd5bfep7zuiz@kili.mountain
-
-Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
-Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- kernel/trace/trace_stack.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
-index 202df6cffcca..cd97c4cffdbd 100644
---- a/kernel/trace/trace_stack.c
-+++ b/kernel/trace/trace_stack.c
-@@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos)
- {
- long n = *pos - 1;
-
-- if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
-+ if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
- return NULL;
-
- m->private = (void *)n;
---
-2.19.1
-
iommu-amd-fix-amd_iommu-force_isolation.patch
arm-dts-fix-omap4430-sdp-ethernet-startup.patch
mips-bpf-fix-encoding-bug-for-mm_srlv32_op.patch
-tracing-have-trace_stack-nr_entries-compare-not-be-s.patch
iommu-arm-smmu-add-support-for-qcom-smmu-v2-variant.patch
iommu-arm-smmu-v3-use-explicit-mb-when-moving-cons-p.patch
sata_rcar-fix-deferred-probing.patch
+++ /dev/null
-From 524d1667c8df34808d91ea4fb2d1a8235d86fc4d Mon Sep 17 00:00:00 2001
-From: Dan Carpenter <dan.carpenter@oracle.com>
-Date: Wed, 20 Jun 2018 14:08:00 +0300
-Subject: tracing: Have trace_stack nr_entries compare not be so subtle
-
-[ Upstream commit ca16b0fbb05242f18da9d810c07d3882ffed831c ]
-
-Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
-one bug.
-
- "From reviewing the code, it seems possible for
- stack_trace_max.nr_entries to be set to .max_entries and in that case we
- would be reading one element beyond the end of the stack_dump_trace[]
- array. If it's not set to .max_entries then the bug doesn't affect
- runtime."
-
-Although it looks to be the case, it is not. Because we have:
-
- static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
- { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
-
- struct stack_trace stack_trace_max = {
- .max_entries = STACK_TRACE_ENTRIES - 1,
- .entries = &stack_dump_trace[0],
- };
-
-And:
-
- stack_trace_max.nr_entries = x;
- for (; x < i; x++)
- stack_dump_trace[x] = ULONG_MAX;
-
-Even if nr_entries equals max_entries, indexing with it into the
-stack_dump_trace[] array will not overflow the array. But if it is the case,
-the second part of the conditional that tests stack_dump_trace[nr_entries]
-to ULONG_MAX will always be true.
-
-By applying Dan's patch, it removes the subtle aspect of it and makes the if
-conditional slightly more efficient.
-
-Link: http://lkml.kernel.org/r/20180620110758.crunhd5bfep7zuiz@kili.mountain
-
-Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
-Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-Signed-off-by: Sasha Levin <sashal@kernel.org>
----
- kernel/trace/trace_stack.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
-index 2a1abbaca10e..f9255740411e 100644
---- a/kernel/trace/trace_stack.c
-+++ b/kernel/trace/trace_stack.c
-@@ -290,7 +290,7 @@ __next(struct seq_file *m, loff_t *pos)
- {
- long n = *pos - 1;
-
-- if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
-+ if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
- return NULL;
-
- m->private = (void *)n;
---
-2.19.1
-
projects / thirdparty / kernel / stable-queue.git / commitdiff
