From: Greg Kroah-Hartman Date: Mon, 16 Apr 2018 10:27:05 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.16.3~34 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e45e7beda2d41a4becafdb3597f50ad51ca65781;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: parisc-fix-out-of-array-access-in-match_pci_device.patch perf-intel-pt-fix-error-recovery-from-missing-tip-packet.patch perf-intel-pt-fix-overlap-detection-to-identify-consecutive-buffers-correctly.patch perf-intel-pt-fix-sync_switch.patch perf-intel-pt-fix-timestamp-following-overflow.patch radeon-hide-pointless-warning-when-compile-testing.patch x86-apic-fix-restoring-boot-irq-mode-in-reboot-and-kexec-kdump.patch --- diff --git a/queue-4.4/parisc-fix-out-of-array-access-in-match_pci_device.patch b/queue-4.4/parisc-fix-out-of-array-access-in-match_pci_device.patch new file mode 100644 index 00000000000..28111e3b701 --- /dev/null +++ b/queue-4.4/parisc-fix-out-of-array-access-in-match_pci_device.patch @@ -0,0 +1,49 @@ +From 615b2665fd20c327b631ff1e79426775de748094 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Sun, 25 Mar 2018 23:53:22 +0200 +Subject: parisc: Fix out of array access in match_pci_device() + +From: Helge Deller + +commit 615b2665fd20c327b631ff1e79426775de748094 upstream. + +As found by the ubsan checker, the value of the 'index' variable can be +out of range for the bc[] array: + +UBSAN: Undefined behaviour in arch/parisc/kernel/drivers.c:655:21 +index 6 is out of range for type 'char [6]' +Backtrace: + [<104fa850>] __ubsan_handle_out_of_bounds+0x68/0x80 + [<1019d83c>] check_parent+0xc0/0x170 + [<1019d91c>] descend_children+0x30/0x6c + [<1059e164>] device_for_each_child+0x60/0x98 + [<1019cd54>] parse_tree_node+0x40/0x54 + [<1019d86c>] check_parent+0xf0/0x170 + [<1019d91c>] descend_children+0x30/0x6c + [<1059e164>] device_for_each_child+0x60/0x98 + [<1019d938>] descend_children+0x4c/0x6c + [<1059e164>] device_for_each_child+0x60/0x98 + [<1019cd54>] parse_tree_node+0x40/0x54 + [<1019cffc>] hwpath_to_device+0xa4/0xc4 + +Signed-off-by: Helge Deller +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/parisc/kernel/drivers.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/parisc/kernel/drivers.c ++++ b/arch/parisc/kernel/drivers.c +@@ -648,6 +648,10 @@ static int match_pci_device(struct devic + (modpath->mod == PCI_FUNC(devfn))); + } + ++ /* index might be out of bounds for bc[] */ ++ if (index >= 6) ++ return 0; ++ + id = PCI_SLOT(pdev->devfn) | (PCI_FUNC(pdev->devfn) << 5); + return (modpath->bc[index] == id); + } diff --git a/queue-4.4/perf-intel-pt-fix-error-recovery-from-missing-tip-packet.patch b/queue-4.4/perf-intel-pt-fix-error-recovery-from-missing-tip-packet.patch new file mode 100644 index 00000000000..863b7cd278c --- /dev/null +++ b/queue-4.4/perf-intel-pt-fix-error-recovery-from-missing-tip-packet.patch @@ -0,0 +1,36 @@ +From 1c196a6c771c47a2faa63d38d913e03284f73a16 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 7 Mar 2018 16:02:23 +0200 +Subject: perf intel-pt: Fix error recovery from missing TIP packet + +From: Adrian Hunter + +commit 1c196a6c771c47a2faa63d38d913e03284f73a16 upstream. + +When a TIP packet is expected but there is a different packet, it is an +error. However the unexpected packet might be something important like a +TSC packet, so after the error, it is necessary to continue from there, +rather than the next packet. That is achieved by setting pkt_step to +zero. + +Signed-off-by: Adrian Hunter +Cc: Jiri Olsa +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/1520431349-30689-4-git-send-email-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c ++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c +@@ -1492,6 +1492,7 @@ static int intel_pt_walk_fup_tip(struct + case INTEL_PT_PSBEND: + intel_pt_log("ERROR: Missing TIP after FUP\n"); + decoder->pkt_state = INTEL_PT_STATE_ERR3; ++ decoder->pkt_step = 0; + return -ENOENT; + + case INTEL_PT_OVF: diff --git a/queue-4.4/perf-intel-pt-fix-overlap-detection-to-identify-consecutive-buffers-correctly.patch b/queue-4.4/perf-intel-pt-fix-overlap-detection-to-identify-consecutive-buffers-correctly.patch new file mode 100644 index 00000000000..f84751f520c --- /dev/null +++ b/queue-4.4/perf-intel-pt-fix-overlap-detection-to-identify-consecutive-buffers-correctly.patch @@ -0,0 +1,220 @@ +From 117db4b27bf08dba412faf3924ba55fe970c57b8 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 7 Mar 2018 16:02:21 +0200 +Subject: perf intel-pt: Fix overlap detection to identify consecutive buffers correctly + +From: Adrian Hunter + +commit 117db4b27bf08dba412faf3924ba55fe970c57b8 upstream. + +Overlap detection was not not updating the buffer's 'consecutive' flag. +Marking buffers consecutive has the advantage that decoding begins from +the start of the buffer instead of the first PSB. Fix overlap detection +to identify consecutive buffers correctly. + +Signed-off-by: Adrian Hunter +Cc: Jiri Olsa +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/1520431349-30689-2-git-send-email-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 62 +++++++++----------- + tools/perf/util/intel-pt-decoder/intel-pt-decoder.h | 2 + tools/perf/util/intel-pt.c | 5 + + 3 files changed, 34 insertions(+), 35 deletions(-) + +--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c ++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c +@@ -2152,14 +2152,6 @@ const struct intel_pt_state *intel_pt_de + return &decoder->state; + } + +-static bool intel_pt_at_psb(unsigned char *buf, size_t len) +-{ +- if (len < INTEL_PT_PSB_LEN) +- return false; +- return memmem(buf, INTEL_PT_PSB_LEN, INTEL_PT_PSB_STR, +- INTEL_PT_PSB_LEN); +-} +- + /** + * intel_pt_next_psb - move buffer pointer to the start of the next PSB packet. + * @buf: pointer to buffer pointer +@@ -2248,6 +2240,7 @@ static unsigned char *intel_pt_last_psb( + * @buf: buffer + * @len: size of buffer + * @tsc: TSC value returned ++ * @rem: returns remaining size when TSC is found + * + * Find a TSC packet in @buf and return the TSC value. This function assumes + * that @buf starts at a PSB and that PSB+ will contain TSC and so stops if a +@@ -2255,7 +2248,8 @@ static unsigned char *intel_pt_last_psb( + * + * Return: %true if TSC is found, false otherwise. + */ +-static bool intel_pt_next_tsc(unsigned char *buf, size_t len, uint64_t *tsc) ++static bool intel_pt_next_tsc(unsigned char *buf, size_t len, uint64_t *tsc, ++ size_t *rem) + { + struct intel_pt_pkt packet; + int ret; +@@ -2266,6 +2260,7 @@ static bool intel_pt_next_tsc(unsigned c + return false; + if (packet.type == INTEL_PT_TSC) { + *tsc = packet.payload; ++ *rem = len; + return true; + } + if (packet.type == INTEL_PT_PSBEND) +@@ -2316,6 +2311,8 @@ static int intel_pt_tsc_cmp(uint64_t tsc + * @len_a: size of first buffer + * @buf_b: second buffer + * @len_b: size of second buffer ++ * @consecutive: returns true if there is data in buf_b that is consecutive ++ * to buf_a + * + * If the trace contains TSC we can look at the last TSC of @buf_a and the + * first TSC of @buf_b in order to determine if the buffers overlap, and then +@@ -2328,33 +2325,41 @@ static int intel_pt_tsc_cmp(uint64_t tsc + static unsigned char *intel_pt_find_overlap_tsc(unsigned char *buf_a, + size_t len_a, + unsigned char *buf_b, +- size_t len_b) ++ size_t len_b, bool *consecutive) + { + uint64_t tsc_a, tsc_b; + unsigned char *p; +- size_t len; ++ size_t len, rem_a, rem_b; + + p = intel_pt_last_psb(buf_a, len_a); + if (!p) + return buf_b; /* No PSB in buf_a => no overlap */ + + len = len_a - (p - buf_a); +- if (!intel_pt_next_tsc(p, len, &tsc_a)) { ++ if (!intel_pt_next_tsc(p, len, &tsc_a, &rem_a)) { + /* The last PSB+ in buf_a is incomplete, so go back one more */ + len_a -= len; + p = intel_pt_last_psb(buf_a, len_a); + if (!p) + return buf_b; /* No full PSB+ => assume no overlap */ + len = len_a - (p - buf_a); +- if (!intel_pt_next_tsc(p, len, &tsc_a)) ++ if (!intel_pt_next_tsc(p, len, &tsc_a, &rem_a)) + return buf_b; /* No TSC in buf_a => assume no overlap */ + } + + while (1) { + /* Ignore PSB+ with no TSC */ +- if (intel_pt_next_tsc(buf_b, len_b, &tsc_b) && +- intel_pt_tsc_cmp(tsc_a, tsc_b) < 0) +- return buf_b; /* tsc_a < tsc_b => no overlap */ ++ if (intel_pt_next_tsc(buf_b, len_b, &tsc_b, &rem_b)) { ++ int cmp = intel_pt_tsc_cmp(tsc_a, tsc_b); ++ ++ /* Same TSC, so buffers are consecutive */ ++ if (!cmp && rem_b >= rem_a) { ++ *consecutive = true; ++ return buf_b + len_b - (rem_b - rem_a); ++ } ++ if (cmp < 0) ++ return buf_b; /* tsc_a < tsc_b => no overlap */ ++ } + + if (!intel_pt_step_psb(&buf_b, &len_b)) + return buf_b + len_b; /* No PSB in buf_b => no data */ +@@ -2368,6 +2373,8 @@ static unsigned char *intel_pt_find_over + * @buf_b: second buffer + * @len_b: size of second buffer + * @have_tsc: can use TSC packets to detect overlap ++ * @consecutive: returns true if there is data in buf_b that is consecutive ++ * to buf_a + * + * When trace samples or snapshots are recorded there is the possibility that + * the data overlaps. Note that, for the purposes of decoding, data is only +@@ -2378,7 +2385,7 @@ static unsigned char *intel_pt_find_over + */ + unsigned char *intel_pt_find_overlap(unsigned char *buf_a, size_t len_a, + unsigned char *buf_b, size_t len_b, +- bool have_tsc) ++ bool have_tsc, bool *consecutive) + { + unsigned char *found; + +@@ -2390,7 +2397,8 @@ unsigned char *intel_pt_find_overlap(uns + return buf_b; /* No overlap */ + + if (have_tsc) { +- found = intel_pt_find_overlap_tsc(buf_a, len_a, buf_b, len_b); ++ found = intel_pt_find_overlap_tsc(buf_a, len_a, buf_b, len_b, ++ consecutive); + if (found) + return found; + } +@@ -2405,28 +2413,16 @@ unsigned char *intel_pt_find_overlap(uns + } + + /* Now len_b >= len_a */ +- if (len_b > len_a) { +- /* The leftover buffer 'b' must start at a PSB */ +- while (!intel_pt_at_psb(buf_b + len_a, len_b - len_a)) { +- if (!intel_pt_step_psb(&buf_a, &len_a)) +- return buf_b; /* No overlap */ +- } +- } +- + while (1) { + /* Potential overlap so check the bytes */ + found = memmem(buf_a, len_a, buf_b, len_a); +- if (found) ++ if (found) { ++ *consecutive = true; + return buf_b + len_a; ++ } + + /* Try again at next PSB in buffer 'a' */ + if (!intel_pt_step_psb(&buf_a, &len_a)) + return buf_b; /* No overlap */ +- +- /* The leftover buffer 'b' must start at a PSB */ +- while (!intel_pt_at_psb(buf_b + len_a, len_b - len_a)) { +- if (!intel_pt_step_psb(&buf_a, &len_a)) +- return buf_b; /* No overlap */ +- } + } + } +--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h ++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h +@@ -102,7 +102,7 @@ const struct intel_pt_state *intel_pt_de + + unsigned char *intel_pt_find_overlap(unsigned char *buf_a, size_t len_a, + unsigned char *buf_b, size_t len_b, +- bool have_tsc); ++ bool have_tsc, bool *consecutive); + + int intel_pt__strerror(int code, char *buf, size_t buflen); + +--- a/tools/perf/util/intel-pt.c ++++ b/tools/perf/util/intel-pt.c +@@ -188,14 +188,17 @@ static void intel_pt_dump_event(struct i + static int intel_pt_do_fix_overlap(struct intel_pt *pt, struct auxtrace_buffer *a, + struct auxtrace_buffer *b) + { ++ bool consecutive = false; + void *start; + + start = intel_pt_find_overlap(a->data, a->size, b->data, b->size, +- pt->have_tsc); ++ pt->have_tsc, &consecutive); + if (!start) + return -EINVAL; + b->use_size = b->data + b->size - start; + b->use_data = start; ++ if (b->use_size && consecutive) ++ b->consecutive = true; + return 0; + } + diff --git a/queue-4.4/perf-intel-pt-fix-sync_switch.patch b/queue-4.4/perf-intel-pt-fix-sync_switch.patch new file mode 100644 index 00000000000..e8d22cc1ea5 --- /dev/null +++ b/queue-4.4/perf-intel-pt-fix-sync_switch.patch @@ -0,0 +1,127 @@ +From 63d8e38f6ae6c36dd5b5ba0e8c112e8861532ea2 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 7 Mar 2018 16:02:22 +0200 +Subject: perf intel-pt: Fix sync_switch + +From: Adrian Hunter + +commit 63d8e38f6ae6c36dd5b5ba0e8c112e8861532ea2 upstream. + +sync_switch is a facility to synchronize decoding more closely with the +point in the kernel when the context actually switched. + +The flag when sync_switch is enabled was global to the decoding, whereas +it is really specific to the CPU. + +The trace data for different CPUs is put on different queues, so add +sync_switch to the intel_pt_queue structure and use that in preference +to the global setting in the intel_pt structure. + +That fixes problems decoding one CPU's trace because sync_switch was +disabled on a different CPU's queue. + +Signed-off-by: Adrian Hunter +Cc: Jiri Olsa +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/1520431349-30689-3-git-send-email-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/intel-pt.c | 32 +++++++++++++++++++++++++------- + 1 file changed, 25 insertions(+), 7 deletions(-) + +--- a/tools/perf/util/intel-pt.c ++++ b/tools/perf/util/intel-pt.c +@@ -125,6 +125,7 @@ struct intel_pt_queue { + bool stop; + bool step_through_buffers; + bool use_buffer_pid_tid; ++ bool sync_switch; + pid_t pid, tid; + int cpu; + int switch_state; +@@ -852,10 +853,12 @@ static int intel_pt_setup_queue(struct i + if (pt->timeless_decoding || !pt->have_sched_switch) + ptq->use_buffer_pid_tid = true; + } ++ ++ ptq->sync_switch = pt->sync_switch; + } + + if (!ptq->on_heap && +- (!pt->sync_switch || ++ (!ptq->sync_switch || + ptq->switch_state != INTEL_PT_SS_EXPECTING_SWITCH_EVENT)) { + const struct intel_pt_state *state; + int ret; +@@ -1238,7 +1241,7 @@ static int intel_pt_sample(struct intel_ + if (pt->synth_opts.last_branch) + intel_pt_update_last_branch_rb(ptq); + +- if (!pt->sync_switch) ++ if (!ptq->sync_switch) + return 0; + + if (intel_pt_is_switch_ip(ptq, state->to_ip)) { +@@ -1319,6 +1322,21 @@ static u64 intel_pt_switch_ip(struct int + return switch_ip; + } + ++static void intel_pt_enable_sync_switch(struct intel_pt *pt) ++{ ++ unsigned int i; ++ ++ pt->sync_switch = true; ++ ++ for (i = 0; i < pt->queues.nr_queues; i++) { ++ struct auxtrace_queue *queue = &pt->queues.queue_array[i]; ++ struct intel_pt_queue *ptq = queue->priv; ++ ++ if (ptq) ++ ptq->sync_switch = true; ++ } ++} ++ + static int intel_pt_run_decoder(struct intel_pt_queue *ptq, u64 *timestamp) + { + const struct intel_pt_state *state = ptq->state; +@@ -1335,7 +1353,7 @@ static int intel_pt_run_decoder(struct i + if (pt->switch_ip) { + intel_pt_log("switch_ip: %"PRIx64" ptss_ip: %"PRIx64"\n", + pt->switch_ip, pt->ptss_ip); +- pt->sync_switch = true; ++ intel_pt_enable_sync_switch(pt); + } + } + } +@@ -1351,9 +1369,9 @@ static int intel_pt_run_decoder(struct i + if (state->err) { + if (state->err == INTEL_PT_ERR_NODATA) + return 1; +- if (pt->sync_switch && ++ if (ptq->sync_switch && + state->from_ip >= pt->kernel_start) { +- pt->sync_switch = false; ++ ptq->sync_switch = false; + intel_pt_next_tid(pt, ptq); + } + if (pt->synth_opts.errors) { +@@ -1379,7 +1397,7 @@ static int intel_pt_run_decoder(struct i + state->timestamp, state->est_timestamp); + ptq->timestamp = state->est_timestamp; + /* Use estimated TSC in unknown switch state */ +- } else if (pt->sync_switch && ++ } else if (ptq->sync_switch && + ptq->switch_state == INTEL_PT_SS_UNKNOWN && + intel_pt_is_switch_ip(ptq, state->to_ip) && + ptq->next_tid == -1) { +@@ -1526,7 +1544,7 @@ static int intel_pt_sync_switch(struct i + return 1; + + ptq = intel_pt_cpu_to_ptq(pt, cpu); +- if (!ptq) ++ if (!ptq || !ptq->sync_switch) + return 1; + + switch (ptq->switch_state) { diff --git a/queue-4.4/perf-intel-pt-fix-timestamp-following-overflow.patch b/queue-4.4/perf-intel-pt-fix-timestamp-following-overflow.patch new file mode 100644 index 00000000000..42b37ad5f0a --- /dev/null +++ b/queue-4.4/perf-intel-pt-fix-timestamp-following-overflow.patch @@ -0,0 +1,41 @@ +From 91d29b288aed3406caf7c454bf2b898c96cfd177 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 7 Mar 2018 16:02:24 +0200 +Subject: perf intel-pt: Fix timestamp following overflow + +From: Adrian Hunter + +commit 91d29b288aed3406caf7c454bf2b898c96cfd177 upstream. + +timestamp_insn_cnt is used to estimate the timestamp based on the number of +instructions since the last known timestamp. + +If the estimate is not accurate enough decoding might not be correctly +synchronized with side-band events causing more trace errors. + +However there are always timestamps following an overflow, so the +estimate is not needed and can indeed result in more errors. + +Suppress the estimate by setting timestamp_insn_cnt to zero. + +Signed-off-by: Adrian Hunter +Cc: Jiri Olsa +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/1520431349-30689-5-git-send-email-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c ++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c +@@ -1270,6 +1270,7 @@ static int intel_pt_overflow(struct inte + intel_pt_clear_tx_flags(decoder); + decoder->have_tma = false; + decoder->cbr = 0; ++ decoder->timestamp_insn_cnt = 0; + decoder->pkt_state = INTEL_PT_STATE_ERR_RESYNC; + decoder->overflow = true; + return -EOVERFLOW; diff --git a/queue-4.4/radeon-hide-pointless-warning-when-compile-testing.patch b/queue-4.4/radeon-hide-pointless-warning-when-compile-testing.patch new file mode 100644 index 00000000000..00f477df2ff --- /dev/null +++ b/queue-4.4/radeon-hide-pointless-warning-when-compile-testing.patch @@ -0,0 +1,53 @@ +From c02216acf4177c4411d33735c81cad687790fa59 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 16 Feb 2018 16:26:57 +0100 +Subject: radeon: hide pointless #warning when compile testing +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Arnd Bergmann + +commit c02216acf4177c4411d33735c81cad687790fa59 upstream. + +In randconfig testing, we sometimes get this warning: + +drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create': +drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp] + #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \ + +This is rather annoying since almost all other code produces no build-time +output unless we have found a real bug. We already fixed this in the +amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for +compile testing") by adding a CONFIG_COMPILE_TEST check last year and +agreed to do the same here, but both Michel and I then forgot about it +until I came across the issue again now. + +For stable kernels, as this is one of very few remaining randconfig +warnings in 4.14. + +Cc: stable@vger.kernel.org +Link: https://patchwork.kernel.org/patch/9550009/ +Signed-off-by: Arnd Bergmann +Signed-off-by: Michel Dänzer +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_object.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/radeon/radeon_object.c ++++ b/drivers/gpu/drm/radeon/radeon_object.c +@@ -238,9 +238,10 @@ int radeon_bo_create(struct radeon_devic + * may be slow + * See https://bugs.freedesktop.org/show_bug.cgi?id=88758 + */ +- ++#ifndef CONFIG_COMPILE_TEST + #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \ + thanks to write-combining ++#endif + + if (bo->flags & RADEON_GEM_GTT_WC) + DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for " diff --git a/queue-4.4/series b/queue-4.4/series index 7029bc23c1c..da1f8b04fda 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -1 +1,8 @@ media-v4l2-compat-ioctl32-don-t-oops-on-overlay.patch +parisc-fix-out-of-array-access-in-match_pci_device.patch +perf-intel-pt-fix-overlap-detection-to-identify-consecutive-buffers-correctly.patch +perf-intel-pt-fix-sync_switch.patch +perf-intel-pt-fix-error-recovery-from-missing-tip-packet.patch +perf-intel-pt-fix-timestamp-following-overflow.patch +radeon-hide-pointless-warning-when-compile-testing.patch +x86-apic-fix-restoring-boot-irq-mode-in-reboot-and-kexec-kdump.patch diff --git a/queue-4.4/x86-apic-fix-restoring-boot-irq-mode-in-reboot-and-kexec-kdump.patch b/queue-4.4/x86-apic-fix-restoring-boot-irq-mode-in-reboot-and-kexec-kdump.patch new file mode 100644 index 00000000000..0437bcb2b8e --- /dev/null +++ b/queue-4.4/x86-apic-fix-restoring-boot-irq-mode-in-reboot-and-kexec-kdump.patch @@ -0,0 +1,95 @@ +From 339b2ae0cd5d4a58f9efe06e4ee36adbeca59228 Mon Sep 17 00:00:00 2001 +From: Baoquan He +Date: Wed, 14 Feb 2018 13:46:53 +0800 +Subject: x86/apic: Fix restoring boot IRQ mode in reboot and kexec/kdump + +From: Baoquan He + +commit 339b2ae0cd5d4a58f9efe06e4ee36adbeca59228 upstream. + +This is a regression fix. + +Before, to fix erratum AVR31, the following commit: + + 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC") + +... moved the lapic_shutdown() call to after disable_IO_APIC() in the reboot +and kexec/kdump code paths. + +This introduced the following regression: disable_IO_APIC() not only clears +the IO-APIC, but it also restores boot IRQ mode by setting the +LAPIC/APIC/IMCR, calling lapic_shutdown() after disable_IO_APIC() will +disable LAPIC and ruin the possible virtual wire mode setting which +the code has been trying to do all along. + +The consequence is that a KVM guest kernel always prints the warning below +during kexec/kdump as the kernel boots up: + + [ 0.001000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1467 setup_local_APIC+0x228/0x330 + [ ........] + [ 0.001000] Call Trace: + [ 0.001000] apic_bsp_setup+0x56/0x74 + [ 0.001000] x86_late_time_init+0x11/0x16 + [ 0.001000] start_kernel+0x3c9/0x486 + [ 0.001000] secondary_startup_64+0xa5/0xb0 + [ ........] + [ 0.001000] masked ExtINT on CPU#0 + +To fix this, just call clear_IO_APIC() to stop the IO-APIC where +disable_IO_APIC() was called, and call restore_boot_irq_mode() to +restore boot IRQ mode before a reboot or a kexec/kdump jump. + +Signed-off-by: Baoquan He +Reviewed-by: Eric W. Biederman +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: douly.fnst@cn.fujitsu.com +Cc: joro@8bytes.org +Cc: prarit@redhat.com +Cc: stable@vger.kernel.org +Cc: uobergfe@redhat.com +Fixes: commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local APIC") +Link: http://lkml.kernel.org/r/20180214054656.3780-4-bhe@redhat.com +[ Rewrote the changelog. ] +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/crash.c | 3 ++- + arch/x86/kernel/reboot.c | 3 ++- + 2 files changed, 4 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/crash.c ++++ b/arch/x86/kernel/crash.c +@@ -172,9 +172,10 @@ void native_machine_crash_shutdown(struc + #ifdef CONFIG_X86_IO_APIC + /* Prevent crash_kexec() from deadlocking on ioapic_lock. */ + ioapic_zap_locks(); +- disable_IO_APIC(); ++ clear_IO_APIC(); + #endif + lapic_shutdown(); ++ restore_boot_irq_mode(); + #ifdef CONFIG_HPET_TIMER + hpet_disable(); + #endif +--- a/arch/x86/kernel/reboot.c ++++ b/arch/x86/kernel/reboot.c +@@ -619,7 +619,7 @@ void native_machine_shutdown(void) + * Even without the erratum, it still makes sense to quiet IO APIC + * before disabling Local APIC. + */ +- disable_IO_APIC(); ++ clear_IO_APIC(); + #endif + + #ifdef CONFIG_SMP +@@ -633,6 +633,7 @@ void native_machine_shutdown(void) + #endif + + lapic_shutdown(); ++ restore_boot_irq_mode(); + + #ifdef CONFIG_HPET_TIMER + hpet_disable();