From: Greg Kroah-Hartman Date: Mon, 11 Feb 2019 16:55:00 +0000 (+0100) Subject: drop tracing patch from all queues X-Git-Tag: v4.9.156~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=953342ad468dacb764f85155950c66ac23b759e1;p=thirdparty%2Fkernel%2Fstable-queue.git drop tracing patch from all queues --- diff --git a/queue-4.14/series b/queue-4.14/series index 92b2ef4fc9f..607accbf62a 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -74,7 +74,6 @@ arm-dts-fix-omap4430-sdp-ethernet-startup.patch 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 diff --git a/queue-4.14/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch b/queue-4.14/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch deleted file mode 100644 index 01630d95bc4..00000000000 --- a/queue-4.14/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch +++ /dev/null @@ -1,65 +0,0 @@ -From ad41aeaf4dd5895c7f0ab6b438373ee778dfb151 Mon Sep 17 00:00:00 2001 -From: Dan Carpenter -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 -Signed-off-by: Steven Rostedt (VMware) -Signed-off-by: Sasha Levin ---- - 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 - diff --git a/queue-4.19/series b/queue-4.19/series index 74e7bcf20a8..90a5351b57f 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -113,7 +113,6 @@ arm-dts-fix-omap4430-sdp-ethernet-startup.patch 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 diff --git a/queue-4.19/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch b/queue-4.19/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch deleted file mode 100644 index 5e73013b11b..00000000000 --- a/queue-4.19/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch +++ /dev/null @@ -1,65 +0,0 @@ -From af4dc639e26f2f315eeb3bb2e9f593871d7d1f8c Mon Sep 17 00:00:00 2001 -From: Dan Carpenter -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 -Signed-off-by: Steven Rostedt (VMware) -Signed-off-by: Sasha Levin ---- - 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 - diff --git a/queue-4.20/series b/queue-4.20/series index 2199f56a2d7..1caee502595 100644 --- a/queue-4.20/series +++ b/queue-4.20/series @@ -135,7 +135,6 @@ mips-bpf-fix-encoding-bug-for-mm_srlv32_op.patch 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 diff --git a/queue-4.20/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch b/queue-4.20/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch deleted file mode 100644 index 80893e8ebb5..00000000000 --- a/queue-4.20/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch +++ /dev/null @@ -1,65 +0,0 @@ -From 165423a2a8ad0c5ffc0155bce8c52d791c29f6b5 Mon Sep 17 00:00:00 2001 -From: Dan Carpenter -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 -Signed-off-by: Steven Rostedt (VMware) -Signed-off-by: Sasha Levin ---- - 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 - diff --git a/queue-4.4/series b/queue-4.4/series index ec524a32601..a3f549be18e 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -29,7 +29,6 @@ usb-hub-delay-hub-autosuspend-if-usb3-port-is-still-.patch 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 diff --git a/queue-4.4/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch b/queue-4.4/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch deleted file mode 100644 index 98588a1b5ed..00000000000 --- a/queue-4.4/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch +++ /dev/null @@ -1,65 +0,0 @@ -From eded309e14001f5caf6e5cbe7e3b3734458518e9 Mon Sep 17 00:00:00 2001 -From: Dan Carpenter -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 -Signed-off-by: Steven Rostedt (VMware) -Signed-off-by: Sasha Levin ---- - 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 - diff --git a/queue-4.9/series b/queue-4.9/series index 9fd0ec36c50..0c86fd1f4fd 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -41,7 +41,6 @@ clk-sunxi-ng-a33-set-clk_set_rate_parent-for-all-aud.patch 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 diff --git a/queue-4.9/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch b/queue-4.9/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch deleted file mode 100644 index acb97894a02..00000000000 --- a/queue-4.9/tracing-have-trace_stack-nr_entries-compare-not-be-s.patch +++ /dev/null @@ -1,65 +0,0 @@ -From 524d1667c8df34808d91ea4fb2d1a8235d86fc4d Mon Sep 17 00:00:00 2001 -From: Dan Carpenter -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 -Signed-off-by: Steven Rostedt (VMware) -Signed-off-by: Sasha Levin ---- - 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 -