- Linux-stable-mirror - lists.linaro.org

Patch "perf/x86/intel/uncore: Fix Skylake UPI event format" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf/x86/intel/uncore: Fix Skylake UPI event format to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-x86-intel-uncore-fix-skylake-upi-event-format.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 317660940fd9dddd3201c2f92e25c27902c753fa Mon Sep 17 00:00:00 2001 From: Kan Liang <kan.liang(a)linux.intel.com> Date: Fri, 2 Mar 2018 07:22:30 -0800 Subject: perf/x86/intel/uncore: Fix Skylake UPI event format From: Kan Liang <kan.liang(a)linux.intel.com> commit 317660940fd9dddd3201c2f92e25c27902c753fa upstream. There is no event extension (bit 21) for SKX UPI, so use 'event' instead of 'event_ext'. Reported-by: Stephane Eranian <eranian(a)google.com> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Vince Weaver <vincent.weaver(a)maine.edu> Fixes: cd34cd97b7b4 ("perf/x86/intel/uncore: Add Skylake server uncore support") Link: http://lkml.kernel.org/r/1520004150-4855-1-git-send-email-kan.liang@linux.i… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/events/intel/uncore_snbep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -3598,7 +3598,7 @@ static struct intel_uncore_type skx_unco }; static struct attribute *skx_upi_uncore_formats_attr[] = { - &format_attr_event_ext.attr, + &format_attr_event.attr, &format_attr_umask_ext.attr, &format_attr_edge.attr, &format_attr_inv.attr, Patches currently in stable-queue which might be from kan.liang(a)linux.intel.com are queue-4.14/perf-x86-intel-uncore-fix-skylake-upi-event-format.patch queue-4.14/perf-x86-intel-uncore-fix-multi-domain-pci-cha-enumeration-bug-on-skylake-servers.patch queue-4.14/perf-x86-intel-don-t-accidentally-clear-high-bits-in-bdw_limit_period.patch

7 years, 5 months

1
0
0 0

Patch "perf/x86/intel/uncore: Fix multi-domain PCI CHA enumeration bug on Skylake servers" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf/x86/intel/uncore: Fix multi-domain PCI CHA enumeration bug on Skylake servers to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-x86-intel-uncore-fix-multi-domain-pci-cha-enumeration-bug-on-skylake-servers.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 320b0651f32b830add6497fcdcfdcb6ae8c7b8a0 Mon Sep 17 00:00:00 2001 From: Kan Liang <kan.liang(a)linux.intel.com> Date: Tue, 13 Mar 2018 11:51:34 -0700 Subject: perf/x86/intel/uncore: Fix multi-domain PCI CHA enumeration bug on Skylake servers From: Kan Liang <kan.liang(a)linux.intel.com> commit 320b0651f32b830add6497fcdcfdcb6ae8c7b8a0 upstream. The number of CHAs is miscalculated on multi-domain PCI Skylake server systems, resulting in an uncore driver initialization error. Gary Kroening explains: "For systems with a single PCI segment, it is sufficient to look for the bus number to change in order to determine that all of the CHa's have been counted for a single socket. However, for multi PCI segment systems, each socket is given a new segment and the bus number does NOT change. So looking only for the bus number to change ends up counting all of the CHa's on all sockets in the system. This leads to writing CPU MSRs beyond a valid range and causes an error in ivbep_uncore_msr_init_box()." To fix this bug, query the number of CHAs from the CAPID6 register: it should read bits 27:0 in the CAPID6 register located at Device 30, Function 3, Offset 0x9C. These 28 bits form a bit vector of available LLC slices and the CHAs that manage those slices. Reported-by: Kroening, Gary <gary.kroening(a)hpe.com> Tested-by: Kroening, Gary <gary.kroening(a)hpe.com> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Vince Weaver <vincent.weaver(a)maine.edu> Cc: abanman(a)hpe.com Cc: dimitri.sivanich(a)hpe.com Cc: hpa(a)zytor.com Cc: mike.travis(a)hpe.com Cc: russ.anderson(a)hpe.com Fixes: cd34cd97b7b4 ("perf/x86/intel/uncore: Add Skylake server uncore support") Link: http://lkml.kernel.org/r/1520967094-13219-1-git-send-email-kan.liang@linux.… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/events/intel/uncore_snbep.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -3554,24 +3554,27 @@ static struct intel_uncore_type *skx_msr NULL, }; +/* + * To determine the number of CHAs, it should read bits 27:0 in the CAPID6 + * register which located at Device 30, Function 3, Offset 0x9C. PCI ID 0x2083. + */ +#define SKX_CAPID6 0x9c +#define SKX_CHA_BIT_MASK GENMASK(27, 0) + static int skx_count_chabox(void) { - struct pci_dev *chabox_dev = NULL; - int bus, count = 0; + struct pci_dev *dev = NULL; + u32 val = 0; - while (1) { - chabox_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x208d, chabox_dev); - if (!chabox_dev) - break; - if (count == 0) - bus = chabox_dev->bus->number; - if (bus != chabox_dev->bus->number) - break; - count++; - } + dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x2083, dev); + if (!dev) + goto out; - pci_dev_put(chabox_dev); - return count; + pci_read_config_dword(dev, SKX_CAPID6, &val); + val &= SKX_CHA_BIT_MASK; +out: + pci_dev_put(dev); + return hweight32(val); } void skx_uncore_cpu_init(void) Patches currently in stable-queue which might be from kan.liang(a)linux.intel.com are queue-4.14/perf-x86-intel-uncore-fix-skylake-upi-event-format.patch queue-4.14/perf-x86-intel-uncore-fix-multi-domain-pci-cha-enumeration-bug-on-skylake-servers.patch queue-4.14/perf-x86-intel-don-t-accidentally-clear-high-bits-in-bdw_limit_period.patch

7 years, 5 months

1
0
0 0

Patch "perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-x86-intel-don-t-accidentally-clear-high-bits-in-bdw_limit_period.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e5ea9b54a055619160bbfe527ebb7d7191823d66 Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Sat, 17 Mar 2018 14:52:16 +0300 Subject: perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period() From: Dan Carpenter <dan.carpenter(a)oracle.com> commit e5ea9b54a055619160bbfe527ebb7d7191823d66 upstream. We intended to clear the lowest 6 bits but because of a type bug we clear the high 32 bits as well. Andi says that periods are rarely more than U32_MAX so this bug probably doesn't have a huge runtime impact. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Kan Liang <kan.liang(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Vince Weaver <vincent.weaver(a)maine.edu> Fixes: 294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds") Link: http://lkml.kernel.org/r/20180317115216.GB4035@mwanda Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/events/intel/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -3194,7 +3194,7 @@ static unsigned bdw_limit_period(struct X86_CONFIG(.event=0xc0, .umask=0x01)) { if (left < 128) left = 128; - left &= ~0x3fu; + left &= ~0x3fULL; } return left; } Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.14/perf-x86-intel-don-t-accidentally-clear-high-bits-in-bdw_limit_period.patch queue-4.14/staging-ncpfs-memory-corruption-in-ncp_read_kernel.patch queue-4.14/iio-adc-meson-saradc-unlock-on-error-in-meson_sar_adc_lock.patch

7 years, 5 months

1
0
0 0

Patch "perf stat: Fix CVS output format for non-supported counters" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf stat: Fix CVS output format for non-supported counters to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-stat-fix-cvs-output-format-for-non-supported-counters.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 40c21898ba5372c14ef71717040529794a91ccc2 Mon Sep 17 00:00:00 2001 From: Ilya Pronin <ipronin(a)twitter.com> Date: Mon, 5 Mar 2018 22:43:53 -0800 Subject: perf stat: Fix CVS output format for non-supported counters From: Ilya Pronin <ipronin(a)twitter.com> commit 40c21898ba5372c14ef71717040529794a91ccc2 upstream. When printing stats in CSV mode, 'perf stat' appends extra separators when a counter is not supported: <not supported>,,L1-dcache-store-misses,mesos/bd442f34-2b4a-47df-b966-9b281f9f56fc,0,100.00,,,, Which causes a failure when parsing fields. The numbers of separators should be the same for each line, no matter if the counter is or not supported. Signed-off-by: Ilya Pronin <ipronin(a)twitter.com> Acked-by: Jiri Olsa <jolsa(a)redhat.com> Cc: Andi Kleen <ak(a)linux.intel.com> Link: http://lkml.kernel.org/r/20180306064353.31930-1-xiyou.wangcong@gmail.com Fixes: 92a61f6412d3 ("perf stat: Implement CSV metrics output") Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/builtin-stat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/builtin-stat.c +++ b/tools/perf/builtin-stat.c @@ -922,7 +922,7 @@ static void print_metric_csv(void *ctx, char buf[64], *vals, *ends; if (unit == NULL || fmt == NULL) { - fprintf(out, "%s%s%s%s", csv_sep, csv_sep, csv_sep, csv_sep); + fprintf(out, "%s%s", csv_sep, csv_sep); return; } snprintf(buf, sizeof(buf), fmt, val); Patches currently in stable-queue which might be from ipronin(a)twitter.com are queue-4.14/perf-stat-fix-cvs-output-format-for-non-supported-counters.patch

7 years, 5 months

1
0
0 0

Patch "perf/core: Fix ctx_event_type in ctx_resched()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf/core: Fix ctx_event_type in ctx_resched() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-core-fix-ctx_event_type-in-ctx_resched.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bd903afeb504db5655a45bb4cf86f38be5b1bf62 Mon Sep 17 00:00:00 2001 From: Song Liu <songliubraving(a)fb.com> Date: Mon, 5 Mar 2018 21:55:04 -0800 Subject: perf/core: Fix ctx_event_type in ctx_resched() From: Song Liu <songliubraving(a)fb.com> commit bd903afeb504db5655a45bb4cf86f38be5b1bf62 upstream. In ctx_resched(), EVENT_FLEXIBLE should be sched_out when EVENT_PINNED is added. However, ctx_resched() calculates ctx_event_type before checking this condition. As a result, pinned events will NOT get higher priority than flexible events. The following shows this issue on an Intel CPU (where ref-cycles can only use one hardware counter). 1. First start: perf stat -C 0 -e ref-cycles -I 1000 2. Then, in the second console, run: perf stat -C 0 -e ref-cycles:D -I 1000 The second perf uses pinned events, which is expected to have higher priority. However, because it failed in ctx_resched(). It is never run. This patch fixes this by calculating ctx_event_type after re-evaluating event_type. Reported-by: Ephraim Park <ephiepark(a)fb.com> Signed-off-by: Song Liu <songliubraving(a)fb.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: <jolsa(a)redhat.com> Cc: <kernel-team(a)fb.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Vince Weaver <vincent.weaver(a)maine.edu> Fixes: 487f05e18aa4 ("perf/core: Optimize event rescheduling on active contexts") Link: http://lkml.kernel.org/r/20180306055504.3283731-1-songliubraving@fb.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/events/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -2322,7 +2322,7 @@ static void ctx_resched(struct perf_cpu_ struct perf_event_context *task_ctx, enum event_type_t event_type) { - enum event_type_t ctx_event_type = event_type & EVENT_ALL; + enum event_type_t ctx_event_type; bool cpu_event = !!(event_type & EVENT_CPU); /* @@ -2332,6 +2332,8 @@ static void ctx_resched(struct perf_cpu_ if (event_type & EVENT_PINNED) event_type |= EVENT_FLEXIBLE; + ctx_event_type = event_type & EVENT_ALL; + perf_pmu_disable(cpuctx->ctx.pmu); if (task_ctx) task_ctx_sched_out(cpuctx, task_ctx, event_type); Patches currently in stable-queue which might be from songliubraving(a)fb.com are queue-4.14/perf-core-fix-ctx_event_type-in-ctx_resched.patch

7 years, 5 months

1
0
0 0

Patch "x86/entry/64: Don't use IST entry for #BP stack" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/entry/64: Don't use IST entry for #BP stack to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-entry-64-don-t-use-ist-entry-for-bp-stack.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Thu, 23 Jul 2015 15:37:48 -0700 Subject: x86/entry/64: Don't use IST entry for #BP stack From: Andy Lutomirski <luto(a)kernel.org> commit d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9 upstream. There's nothing IST-worthy about #BP/int3. We don't allow kprobes in the small handful of places in the kernel that run at CPL0 with an invalid stack, and 32-bit kernels have used normal interrupt gates for #BP forever. Furthermore, we don't allow kprobes in places that have usergs while in kernel mode, so "paranoid" is also unnecessary. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/entry/entry_64.S | 2 +- arch/x86/kernel/traps.c | 24 +++++++++++------------- 2 files changed, 12 insertions(+), 14 deletions(-) --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -943,7 +943,7 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTO #endif /* CONFIG_HYPERV */ idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK -idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK +idtentry int3 do_int3 has_error_code=0 idtentry stack_segment do_stack_segment has_error_code=1 #ifdef CONFIG_XEN --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -526,7 +526,6 @@ do_general_protection(struct pt_regs *re } NOKPROBE_SYMBOL(do_general_protection); -/* May run on IST stack. */ dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code) { #ifdef CONFIG_DYNAMIC_FTRACE @@ -541,7 +540,15 @@ dotraplinkage void notrace do_int3(struc if (poke_int3_handler(regs)) return; + /* + * Use ist_enter despite the fact that we don't use an IST stack. + * We can be called from a kprobe in non-CONTEXT_KERNEL kernel + * mode or even during context tracking state changes. + * + * This means that we can't schedule. That's okay. + */ ist_enter(regs); + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); #ifdef CONFIG_KGDB_LOW_LEVEL_TRAP if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP, @@ -558,17 +565,11 @@ dotraplinkage void notrace do_int3(struc SIGTRAP) == NOTIFY_STOP) goto exit; - /* - * Let others (NMI) know that the debug stack is in use - * as we may switch to the interrupt stack. - */ - debug_stack_usage_inc(); preempt_disable(); cond_local_irq_enable(regs); do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL); cond_local_irq_disable(regs); preempt_enable_no_resched(); - debug_stack_usage_dec(); exit: ist_exit(regs); } @@ -989,19 +990,16 @@ void __init trap_init(void) cpu_init(); /* - * X86_TRAP_DB and X86_TRAP_BP have been set - * in early_trap_init(). However, ITS works only after - * cpu_init() loads TSS. See comments in early_trap_init(). + * X86_TRAP_DB was installed in early_trap_init(). However, + * IST works only after cpu_init() loads TSS. See comments + * in early_trap_init(). */ set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK); - /* int3 can be called from all */ - set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK); x86_init.irqs.trap_init(); #ifdef CONFIG_X86_64 memcpy(&debug_idt_table, &idt_table, IDT_ENTRIES * 16); set_nmi_gate(X86_TRAP_DB, &debug); - set_nmi_gate(X86_TRAP_BP, &int3); #endif } Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/x86-entry-64-don-t-use-ist-entry-for-bp-stack.patch queue-4.9/selftests-x86-ptrace_syscall-fix-for-yet-more-glibc-interference.patch queue-4.9/kvm-x86-fix-icebp-instruction-handling.patch

7 years, 5 months

1
0
0 0

Patch "x86/entry/64: Don't use IST entry for #BP stack" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/entry/64: Don't use IST entry for #BP stack to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-entry-64-don-t-use-ist-entry-for-bp-stack.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Thu, 23 Jul 2015 15:37:48 -0700 Subject: x86/entry/64: Don't use IST entry for #BP stack From: Andy Lutomirski <luto(a)kernel.org> commit d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9 upstream. There's nothing IST-worthy about #BP/int3. We don't allow kprobes in the small handful of places in the kernel that run at CPL0 with an invalid stack, and 32-bit kernels have used normal interrupt gates for #BP forever. Furthermore, we don't allow kprobes in places that have usergs while in kernel mode, so "paranoid" is also unnecessary. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/entry/entry_64.S | 2 +- arch/x86/kernel/traps.c | 24 +++++++++++------------- 2 files changed, 12 insertions(+), 14 deletions(-) --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1018,7 +1018,7 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTO #endif /* CONFIG_HYPERV */ idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK -idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK +idtentry int3 do_int3 has_error_code=0 idtentry stack_segment do_stack_segment has_error_code=1 #ifdef CONFIG_XEN --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -480,7 +480,6 @@ do_general_protection(struct pt_regs *re } NOKPROBE_SYMBOL(do_general_protection); -/* May run on IST stack. */ dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code) { #ifdef CONFIG_DYNAMIC_FTRACE @@ -495,7 +494,15 @@ dotraplinkage void notrace do_int3(struc if (poke_int3_handler(regs)) return; + /* + * Use ist_enter despite the fact that we don't use an IST stack. + * We can be called from a kprobe in non-CONTEXT_KERNEL kernel + * mode or even during context tracking state changes. + * + * This means that we can't schedule. That's okay. + */ ist_enter(regs); + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); #ifdef CONFIG_KGDB_LOW_LEVEL_TRAP if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP, @@ -512,15 +519,9 @@ dotraplinkage void notrace do_int3(struc SIGTRAP) == NOTIFY_STOP) goto exit; - /* - * Let others (NMI) know that the debug stack is in use - * as we may switch to the interrupt stack. - */ - debug_stack_usage_inc(); preempt_conditional_sti(regs); do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL); preempt_conditional_cli(regs); - debug_stack_usage_dec(); exit: ist_exit(regs); } @@ -886,19 +887,16 @@ void __init trap_init(void) cpu_init(); /* - * X86_TRAP_DB and X86_TRAP_BP have been set - * in early_trap_init(). However, ITS works only after - * cpu_init() loads TSS. See comments in early_trap_init(). + * X86_TRAP_DB was installed in early_trap_init(). However, + * IST works only after cpu_init() loads TSS. See comments + * in early_trap_init(). */ set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK); - /* int3 can be called from all */ - set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK); x86_init.irqs.trap_init(); #ifdef CONFIG_X86_64 memcpy(&debug_idt_table, &idt_table, IDT_ENTRIES * 16); set_nmi_gate(X86_TRAP_DB, &debug); - set_nmi_gate(X86_TRAP_BP, &int3); #endif } Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.4/x86-entry-64-don-t-use-ist-entry-for-bp-stack.patch queue-4.4/kvm-x86-fix-icebp-instruction-handling.patch

7 years, 5 months

1
0
0 0

Patch "hwmon: (k10temp) Only apply temperature offset if result is positive" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (k10temp) Only apply temperature offset if result is positive to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hwmon-k10temp-only-apply-temperature-offset-if-result-is-positive.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From aef17ca1271948ee57cc39b2493d31110cc42625 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux(a)roeck-us.net> Date: Wed, 7 Feb 2018 17:49:39 -0800 Subject: hwmon: (k10temp) Only apply temperature offset if result is positive MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Guenter Roeck <linux(a)roeck-us.net> commit aef17ca1271948ee57cc39b2493d31110cc42625 upstream. A user reports a really bad temperature on Ryzen 1950X. k10temp-pci-00cb Adapter: PCI adapter temp1: +4294948.3°C (high = +70.0°C) This will happen if the temperature reported by the chip is lower than the offset temperature. This has been seen in the field if "Sense MI Skew" and/or "Sense MI Offset" BIOS parameters were set to unexpected values. Let's report a temperature of 0 degrees C in that case. Fixes: 1b50b776355f ("hwmon: (k10temp) Add support for temperature offsets") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/k10temp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/hwmon/k10temp.c +++ b/drivers/hwmon/k10temp.c @@ -128,7 +128,10 @@ static ssize_t temp1_input_show(struct d data->read_tempreg(data->pdev, &regval); temp = (regval >> 21) * 125; - temp -= data->temp_offset; + if (temp > data->temp_offset) + temp -= data->temp_offset; + else + temp = 0; return sprintf(buf, "%u\n", temp); } Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.15/hwmon-k10temp-add-temperature-offset-for-ryzen-1900x.patch queue-4.15/hwmon-k10temp-only-apply-temperature-offset-if-result-is-positive.patch queue-4.15/acpi-watchdog-fix-off-by-one-error-at-resource-assignment.patch

7 years, 5 months

1
0
0 0

Patch "hwmon: (k10temp) Add temperature offset for Ryzen 1900X" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled hwmon: (k10temp) Add temperature offset for Ryzen 1900X to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hwmon-k10temp-add-temperature-offset-for-ryzen-1900x.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6509614fdd2d05c6926d50901a45d5dfb852b715 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux(a)roeck-us.net> Date: Fri, 19 Jan 2018 06:38:03 -0800 Subject: hwmon: (k10temp) Add temperature offset for Ryzen 1900X From: Guenter Roeck <linux(a)roeck-us.net> commit 6509614fdd2d05c6926d50901a45d5dfb852b715 upstream. Like the other CPUs from the same series, the 1900X has a temperature offset of 27 degrees C. Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwmon/k10temp.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/hwmon/k10temp.c +++ b/drivers/hwmon/k10temp.c @@ -86,6 +86,7 @@ static const struct tctl_offset tctl_off { 0x17, "AMD Ryzen 7 1800X", 20000 }, { 0x17, "AMD Ryzen Threadripper 1950X", 27000 }, { 0x17, "AMD Ryzen Threadripper 1920X", 27000 }, + { 0x17, "AMD Ryzen Threadripper 1900X", 27000 }, { 0x17, "AMD Ryzen Threadripper 1950", 10000 }, { 0x17, "AMD Ryzen Threadripper 1920", 10000 }, { 0x17, "AMD Ryzen Threadripper 1910", 10000 }, Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.15/hwmon-k10temp-add-temperature-offset-for-ryzen-1900x.patch queue-4.15/hwmon-k10temp-only-apply-temperature-offset-if-result-is-positive.patch queue-4.15/acpi-watchdog-fix-off-by-one-error-at-resource-assignment.patch

7 years, 5 months

1
0
0 0

Patch "drm/syncobj: Stop reusing the same struct file for all syncobj -> fd" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/syncobj: Stop reusing the same struct file for all syncobj -> fd to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-syncobj-stop-reusing-the-same-struct-file-for-all-syncobj-fd.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Tue, 19 Dec 2017 12:07:00 +0000 Subject: drm/syncobj: Stop reusing the same struct file for all syncobj -> fd From: Chris Wilson <chris(a)chris-wilson.co.uk> commit e7cdf5c82f1773c3386b93bbcf13b9bfff29fa31 upstream. The vk cts test: dEQP-VK.api.external.semaphore.opaque_fd.export_multiple_times_temporary triggers a lot of VFS: Close: file count is 0 Dave pointed out that clearing the syncobj->file from drm_syncobj_file_release() was sufficient to silence the test, but that opens a can of worm since we assumed that the syncobj->file was never unset. Stop trying to reuse the same struct file for every fd pointing to the drm_syncobj, and allocate one file for each fd instead. v2: Fixup return handling of drm_syncobj_fd_to_handle v2.1: [airlied: fix possible syncobj ref race] v2.2: [jekstrand: back-port to 4.14] Reported-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Tested-by: Dave Airlie <airlied(a)redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> Tested-by: Clayton Craft <clayton.a.craft(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_syncobj.c | 81 +++++++++++++++--------------------------- include/drm/drm_syncobj.h | 5 -- 2 files changed, 30 insertions(+), 56 deletions(-) --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -328,28 +328,11 @@ static const struct file_operations drm_ .release = drm_syncobj_file_release, }; -static int drm_syncobj_alloc_file(struct drm_syncobj *syncobj) -{ - struct file *file = anon_inode_getfile("syncobj_file", - &drm_syncobj_file_fops, - syncobj, 0); - if (IS_ERR(file)) - return PTR_ERR(file); - - drm_syncobj_get(syncobj); - if (cmpxchg(&syncobj->file, NULL, file)) { - /* lost the race */ - fput(file); - } - - return 0; -} - static int drm_syncobj_handle_to_fd(struct drm_file *file_private, u32 handle, int *p_fd) { struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle); - int ret; + struct file *file; int fd; if (!syncobj) @@ -361,46 +344,40 @@ static int drm_syncobj_handle_to_fd(stru return fd; } - if (!syncobj->file) { - ret = drm_syncobj_alloc_file(syncobj); - if (ret) - goto out_put_fd; + file = anon_inode_getfile("syncobj_file", + &drm_syncobj_file_fops, + syncobj, 0); + if (IS_ERR(file)) { + put_unused_fd(fd); + drm_syncobj_put(syncobj); + return PTR_ERR(file); } - fd_install(fd, syncobj->file); - drm_syncobj_put(syncobj); + + drm_syncobj_get(syncobj); + fd_install(fd, file); + *p_fd = fd; return 0; -out_put_fd: - put_unused_fd(fd); - drm_syncobj_put(syncobj); - return ret; } -static struct drm_syncobj *drm_syncobj_fdget(int fd) -{ - struct file *file = fget(fd); - - if (!file) - return NULL; - if (file->f_op != &drm_syncobj_file_fops) - goto err; - - return file->private_data; -err: - fput(file); - return NULL; -}; - static int drm_syncobj_fd_to_handle(struct drm_file *file_private, int fd, u32 *handle) { - struct drm_syncobj *syncobj = drm_syncobj_fdget(fd); + struct drm_syncobj *syncobj; + struct file *file; int ret; - if (!syncobj) + file = fget(fd); + if (!file) + return -EINVAL; + + if (file->f_op != &drm_syncobj_file_fops) { + fput(file); return -EINVAL; + } /* take a reference to put in the idr */ + syncobj = file->private_data; drm_syncobj_get(syncobj); idr_preload(GFP_KERNEL); @@ -409,12 +386,14 @@ static int drm_syncobj_fd_to_handle(stru spin_unlock(&file_private->syncobj_table_lock); idr_preload_end(); - if (ret < 0) { - fput(syncobj->file); - return ret; - } - *handle = ret; - return 0; + if (ret > 0) { + *handle = ret; + ret = 0; + } else + drm_syncobj_put(syncobj); + + fput(file); + return ret; } int drm_syncobj_import_sync_file_fence(struct drm_file *file_private, --- a/include/drm/drm_syncobj.h +++ b/include/drm/drm_syncobj.h @@ -60,11 +60,6 @@ struct drm_syncobj { * locks cb_list and write-locks fence. */ spinlock_t lock; - /** - * @file: - * a file backing for this syncobj. - */ - struct file *file; }; typedef void (*drm_syncobj_func_t)(struct drm_syncobj *syncobj, Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are queue-4.14/drm-syncobj-stop-reusing-the-same-struct-file-for-all-syncobj-fd.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror