[patch V2 09/10] x86/mm/cpa: Do the range check early

2018-09-14 Thread Thomas Gleixner
: 541 2M pages sameprot: 466 2M pages preserved: 47 4K pages checked: 514 4K pages set-checked: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 27 +++ 1 file changed, 23

[patch V2 04/10] x86/mm/cpa: Add debug mechanism

2018-09-14 Thread Thomas Gleixner
except for developers, so limit the output hard to the protection fixups. Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 60 + 1 file changed, 51 insertions(+), 9 deletions(-) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c

[patch V2 07/10] x86/mm/cpa: Add sanity check for existing mappings

2018-09-14 Thread Thomas Gleixner
the static protections for the PTE entries to fix up the incorrectness. For 1G pages this can't be done easily because that would require to either find the offending 2M areas before the split or afterwards. For now just warn about that case and revisit it when reported. Signed-off-by: Thomas

[patch V2 01/10] x86/mm/cpa: Split, rename and clean up try_preserve_large_page()

2018-09-14 Thread Thomas Gleixner
damage while at it. No functional change. Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 121 - 1 file changed, 60 insertions(+), 61 deletions(-) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -421,18 +421,18 @@ pte_t

[patch V2 08/10] x86/mm/cpa: Optimize same protection check

2018-09-14 Thread Thomas Gleixner
: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 14 ++ 1 file changed, 14 insertions(+) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -836,6 +836,20 @@ static int __should_split_large_page(pte } /* +* Optimization

[patch V2 03/10] x86/mm/cpa: Allow range check for static protections

2018-09-14 Thread Thomas Gleixner
Checking static protections only page by page is slow especially for huge pages. To allow quick checks over a complete range, add the ability to do that. Make the checks inclusive so the ranges can be directly used for debug output later. No functional change. Signed-off-by: Thomas Gleixner

[patch V2 10/10] x86/mm/cpa: Avoid the 4k pages check completely

2018-09-14 Thread Thomas Gleixner
sameprot: 466 2M pages preserved: 47 4K pages set-checked: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 66 - 1 file changed, 17 insertions(+), 49 deletions(-) --- a/arch/x86/mm

Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

2018-09-14 Thread Thomas Gleixner
On Fri, 14 Sep 2018, Rafael J. Wysocki wrote: > On Fri, Sep 14, 2018 at 11:53 AM Mika Penttilä > > >> But doesn't injecting sleep time here make monotonic clock too large > > >> by the amount of sleeptime? tick_freeze() / tick_unfreeze() already > > >> injects the sleeptime (otherwise delta

Re: [PATCH v8 1/2] x86/mm: add .bss..decrypted section to hold shared variables

2018-09-14 Thread Thomas Gleixner
On Fri, 14 Sep 2018, Brijesh Singh wrote: > On 9/14/18 2:10 AM, Borislav Petkov wrote: > >>/* > >> + * Clear the memory encryption mask from the .bss..decrypted section. > >> + * The bss section will be memset to zero later in the initialization so > >> + * there is no need to zero it

RE: [PATCH v6 1/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

2018-09-14 Thread Thomas Gleixner
On Fri, 14 Sep 2018, Jiri Kosina wrote: > On Thu, 13 Sep 2018, Schaufler, Casey wrote: > > > > - return security_ptrace_access_check(task, mode); > > > + if (!(mode & PTRACE_MODE_NOACCESS_CHK)) > > > + return security_ptrace_access_check(task, mode); > > > + return 0; > > > > Because

Re: [PATCH v1 2/3] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

2018-09-14 Thread Thomas Gleixner
On Fri, 14 Sep 2018, Yi Sun wrote: > > > +static void hv_notify_long_spin_wait(void) > > > +{ > > > + u64 input = spin_wait_info | 0x; > > > > What? The result is always 0x . > > > Oh, sorry for such error. > > > > + spin_wait_info++; > > > +

Re: Multi-parent IRQ domains

2018-09-14 Thread Thomas Gleixner
On Thu, 13 Sep 2018, Thierry Reding wrote: > I've been trying to implement a feature on recent Tegra chips that's > called "wake events". These wake events are implemented as part of the > power management controller (PMC) and they control which events can be > used to wake the system from

Re: [PATCH v8 2/2] x86/kvm: use __bss_decrypted attribute in shared variables

2018-09-13 Thread Thomas Gleixner
On Thu, 13 Sep 2018, Brijesh Singh wrote: > > +static void __init kvmclock_init_mem(void) > +{ > + unsigned int ncpus = num_possible_cpus() - HVC_BOOT_ARRAY_SIZE; > + unsigned int order = get_order(ncpus * sizeof(*hvclock_mem)); > + struct page *p; > + int r; > + > + p =

Re: [PATCH v8 1/2] x86/mm: add .bss..decrypted section to hold shared variables

2018-09-13 Thread Thomas Gleixner
On Thu, 13 Sep 2018, Brijesh Singh wrote: > > +void __weak mem_encrypt_free_decrypted_mem(void) { } > + > void __ref free_initmem(void) > { > e820__reallocate_tables(); > > + mem_encrypt_free_decrypted_mem(); > + > free_kernel_image_pages(&__init_begin, &__init_end); > } >

Re: [PATCH v7 0/5] x86: Fix SEV guest regression

2018-09-13 Thread Thomas Gleixner
On Thu, 13 Sep 2018, Brijesh Singh wrote: > On 09/13/2018 11:22 AM, Thomas Gleixner wrote: > > I really have to ask why this whole change to sme_encrypt_kernel() is > > required at all. > > The main reason behind making the changes in sme_encrypt_kernel() was > to pervers

Re: [PATCH v7 0/5] x86: Fix SEV guest regression

2018-09-13 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Brijesh Singh wrote: > x86/kvmclock: Remove memblock dependency > introduced SEV guest regression. > > The guest physical address holding the wall_clock and hv_clock_boot > are shared with the hypervisor must be mapped with C=0 when SEV > is active. To clear the C-bit we use

Re: [PATCH v1 2/3] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

2018-09-13 Thread Thomas Gleixner
On Thu, 13 Sep 2018, Yi Sun wrote: > +++ b/arch/x86/hyperv/hv_spinlock.c > @@ -0,0 +1,99 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +/* > + * Hyper-V specific spinlock code. > + * > + * Copyright (C) 2018, Intel, Inc. > + * > + * Author : Yi Sun > + * > + * This program is free software; you

Re: [PATCH v1 2/3] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

2018-09-13 Thread Thomas Gleixner
On Thu, 13 Sep 2018, Yi Sun wrote: > +#include > > /* representing HT siblings of each logical CPU */ > DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_map); > @@ -1335,6 +1336,7 @@ void __init native_smp_prepare_boot_cpu(void) > /* already set me in cpu_online_mask in

Re: [RFC PATCH] irq/affinity: Mark the pre/post vectors as regular interrupts

2018-09-13 Thread Thomas Gleixner
On Thu, 13 Sep 2018, Dou Liyang wrote: > So, clear these affinity mask and check it in alloc_desc() to leave them > as regular interrupts which can be affinity controlled and also can move > freely on hotplug. This is the wrong direction as it does not allow to do initial affinity assignement for

Re: [PATCH 2/4][v2] PM / hibernate: Check the success of generating md5 digest before hibernation

2018-09-13 Thread Thomas Gleixner
On Wed, 12 Sep 2018, Chen Yu wrote: > static bool hibernation_e820_mismatch(void *buf) > @@ -306,6 +307,7 @@ static bool hibernation_e820_mismatch(void *buf) > int arch_hibernation_header_save(void *addr, unsigned int max_size) > { > struct restore_data_record *rdr = addr; > + int ret

Re: linux-next: build warning after merge of the tip tree

2018-09-12 Thread Thomas Gleixner
On Tue, 11 Sep 2018, Stephen Rothwell wrote: > After merging the tip tree, today's linux-next build (x86_64 allnoconfig) > produced this warning: > > arch/x86/kernel/cpu/common.c: In function 'syscall_init': > arch/x86/kernel/cpu/common.c:1534:6: warning: unused variable 'cpu' >

Re: [PATCH v6 2/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-12 Thread Thomas Gleixner
On Wed, 12 Sep 2018, Jiri Kosina wrote: > case X86_BUG_SPECTRE_V2: > - return sprintf(buf, "%s%s%s%s\n", > spectre_v2_strings[spectre_v2_enabled], > + mutex_lock(_ctrl_mutex); > + ret = sprintf(buf, "%s%s%s%s%s\n", >

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

2018-09-12 Thread Thomas Gleixner
On Wed, 12 Sep 2018, Florian Weimer wrote: > On 09/12/2018 04:17 PM, Thomas Gleixner wrote: > > On Wed, 12 Sep 2018, Florian Weimer wrote: > > > Does this mean glibc can keep using a single vDSO entrypoint, the one we > > > have today? > > > > We have no

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

2018-09-12 Thread Thomas Gleixner
On Wed, 12 Sep 2018, Florian Weimer wrote: > On 09/09/2018 10:05 PM, Thomas Gleixner wrote: > > See the patch below. It's integrating TAI without slowing down everything > > and it definitely does not result in indirect calls. > > > > On a HSW it slows down clock_gett

[PATCH stable] x86/tsc: Prevent result truncation on 32 bit

2018-09-12 Thread Thomas Gleixner
: dd759d93f4dd ("x86/timers: Add simple udelay calibration") Signed-off-by: Chuanhua Lei Signed-off-by: Thomas Gleixner Cc: yixin@linux.intel.com Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: Len Brown Cc: Pavel Tatashin Cc: Rajvi Jingar Cc: Dou Liyang Cc: Ville S

RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

2018-09-12 Thread Thomas Gleixner
On Tue, 11 Sep 2018, Schaufler, Casey wrote: > How about this? Take Jiri's patch as written. You get everything except checks > on the security blobs and any "magic" that my safesidechannel module did. I > will propose a follow on patch that fixes the SELinux code to eliminate the > locking >

Re: [PATCH v5 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-11 Thread Thomas Gleixner
On Tue, 11 Sep 2018, Thomas Gleixner wrote: > On Tue, 11 Sep 2018, Tim Chen wrote: > > On 09/10/2018 04:46 AM, Jiri Kosina wrote: > > > Nah, IBPB is actuall there, sorry. So I'll add reporting of STIBP + fixup > > > the missing reporting of RSB_CTXSW for v6. &

Re: [PATCH v5 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-11 Thread Thomas Gleixner
On Tue, 11 Sep 2018, Tim Chen wrote: > On 09/10/2018 04:46 AM, Jiri Kosina wrote: > > Nah, IBPB is actuall there, sorry. So I'll add reporting of STIBP + fixup > > the missing reporting of RSB_CTXSW for v6. > > > > I anticipate that STIBP could affect workloads with a lot of indirect > branches

RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

2018-09-11 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Schaufler, Casey wrote: > > -Original Message- > > From: Jiri Kosina [mailto:ji...@kernel.org] > > Sent: Monday, September 10, 2018 1:42 PM > > To: Schaufler, Casey > > Cc: Thomas Gleixner ; Ingo Molnar ; > > Peter Zijlstra ; J

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

2018-09-11 Thread Thomas Gleixner
On Tue, 11 Sep 2018, Ville Syrjälä wrote: > On Mon, Sep 10, 2018 at 06:53:54PM +0200, Thomas Gleixner wrote: > > On Mon, 10 Sep 2018, Ville Syrjälä wrote: > > > > Good: 1718674.70 BogoMIPS (lpj=2863311530) > > Bad: 859455.59 BogoMIPS (lpj=1431852151) > &

Re: x86/apic: MSI address malformed for "flat" driver

2018-09-11 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Cyril Novikov wrote: > On 9/7/2018 12:11 PM, Thomas Gleixner wrote: > > On Thu, 6 Sep 2018, Philipp Eppelt wrote: > > > > > > The "flat" driver defines the MSI addressing scheme to be used as > > > logical addressing

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Anup Patel wrote: > On Mon, Sep 10, 2018 at 10:09 PM, Christoph Hellwig > wrote: > > On Mon, Sep 10, 2018 at 10:05:42PM +0530, Anup Patel wrote: > >> I am quite sure RISC-V spec does not restrict the use of other > >> local interrupts. Different CPU implementations can have

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Ville Syrjälä wrote: > On Mon, Sep 10, 2018 at 06:23:49PM +0200, Thomas Gleixner wrote: > > 1) My workflow makes things tagged as BUG and REGRESSION urgent > >automatically while [PATCH] just is queued to the normal pile of > >backlog, i.e. at th

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Ville Syrjälä wrote: Good: 1718674.70 BogoMIPS (lpj=2863311530) Bad: 859455.59 BogoMIPS (lpj=1431852151) while both kernels agree on the CPU frequency of 996MHz. This pretty much smells like the 32bit LPJ conversion bug which got fixed in rc3. Does the problem persist with

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Ville Syrjälä wrote: > On Mon, Sep 10, 2018 at 02:48:45PM +0200, Thomas Gleixner wrote: > > On Mon, 10 Sep 2018, Ville Syrjala wrote: > > I asked for that before and I really do not understand why you do not even > > make an attempt to report an

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Anup Patel wrote: > On Mon, Sep 10, 2018 at 7:19 PM, Christoph Hellwig wrote: > > On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote: > >> > He has an irqchip that is called from the RISC-V exception handler > >> > when th

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Christoph Hellwig wrote: > On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote: > > > > Just a few weeks ago you said the contrary: > > > > > > > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html >

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Thomas Gleixner wrote: > On Mon, 10 Sep 2018, Christoph Hellwig wrote: > > On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote: > > > On Thu, 6 Sep 2018, Christoph Hellwig wrote: > > > > > > > Just as before: NAK to entire

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Christoph Hellwig wrote: > On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote: > > On Thu, 6 Sep 2018, Christoph Hellwig wrote: > > > > > Just as before: NAK to entirely pointless abstractions. Please stop > > > beating th

Re: [PATCH v6 4/5] x86/kvm: use __decrypted attribute in shared variables

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Sean Christopherson wrote: > On Mon, 2018-09-10 at 14:04 +0200, Borislav Petkov wrote: > > On Fri, Sep 07, 2018 at 12:57:29PM -0500, Brijesh Singh wrote: > > > > > > Commit: 368a540e0232 (x86/kvmclock: Remove memblock dependency) > > > caused SEV guest regression. > > When

Re: next-20180910: boots on thinkpad x60 (32bit machine) but has problems during suspend

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Pavel Machek wrote: > > Next -0910 seems to boot ok... but when I hit the power button to > suspend the machine... Full dmesg is in the attachment. Is this a next only issue or is this happening on Linus tree as well? Thanks, tglx

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

2018-09-10 Thread Thomas Gleixner
Ville, On Mon, 10 Sep 2018, Ville Syrjala wrote: > From: Ville Syrjälä > > This reverts commit 608008a45798fe9e2aee04f99b5270ea57c1376f. > > It breaks wifi on my pentium 3 Fujitsu-Siemens Lifebook S6010 > laptop. Scanning for APs doesn't seem to work most of the time, > and, even when it

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

2018-09-10 Thread Thomas Gleixner
On Sun, 9 Sep 2018, Thomas Gleixner wrote: > #ifdef BUILD_VDSO32_64 > typedef u64 gtod_long_t; > #else > typedef unsigned long gtod_long_t; > #endif > + > +struct vgtod_ts { > + gtod_long_t sec; and actually this wants to become u64 unconditionally as we

Re: [PATCH v5 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Jiri Kosina wrote: > +static void update_stibp_msr(void *info) > +{ > + wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base); > +} > + > +void arch_smt_update(void) > +{ > + if (stibp_needed()) { if (!stib_needed()) return; spares you an indentation

Re: [PATCH] x86, mm: Reserver some memory for bootmem allocator for NO_BOOTMEM

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Feng Tang wrote: > On Fri, Sep 07, 2018 at 12:52:17PM +0200, Thomas Gleixner wrote: > > You really want to add a proper sanity check for this. The static stuff has > > to cover the fixmap. Just making it work for this particular case is sloppy > > at be

Re: [patch 01/10] x86/mm/cpa: Split, rename and clean up try_preserve_large_page()

2018-09-10 Thread Thomas Gleixner
On Mon, 10 Sep 2018, Yang, Bin wrote: Can you please trim your replies? It's a pain in the neck to find the single line of information within a large pile of useless quoted text. > On Fri, 2018-09-07 at 17:01 +0200, Thomas Gleixner wrote: > > /* > > -* We need to check

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

2018-09-09 Thread Thomas Gleixner
On Fri, 31 Aug 2018, Andy Lutomirski wrote: > (Hi, Florian!) > > On Fri, Aug 31, 2018 at 6:59 PM, Matt Rickard wrote: > > Process clock_gettime(CLOCK_TAI) in vDSO. > > This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC: > > > > nanoseconds > > before after clockname > >

[GIT pull] x86 fixes for 4.19

2018-09-09 Thread Thomas Gleixner
c.h warnings Thomas Gleixner (1): x86/apic/vector: Make error return value negative arch/x86/include/asm/atomic.h | 12 ++-- arch/x86/include/asm/atomic64_32.h| 8 arch/x86/include/asm/atomic64_64.h| 12 ++-- arch/x86/include/asm/kdebug.h |

[GIT pull] timekeeping fixes for 4.19

2018-09-09 Thread Thomas Gleixner
Linus, please pull the latest timers-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-for-linus Two fixes for timekeeping: - Revert to the previous kthread based update, which is unfortunately required due to lock ordering issues.

[GIT pull] smp/hotplug fixes for 4.19

2018-09-09 Thread Thomas Gleixner
smb() in cpuhp_thread_fun() Thomas Gleixner (1): cpu/hotplug: Prevent state corruption on error rollback kernel/cpu.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/cpu.c b/kernel/cpu.c index aa7fe85ad62e..0097acec1c71 100644 --- a/kernel/cpu.c +++ b/ker

[GIT pull] irq fix for 4.19

2018-09-09 Thread Thomas Gleixner
Linus, please pull the latest irq-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-for-linus A single fix to prevent allocating excessive memory in the GIC/ITS driver. While the subject of the patch might suggest otherwise this is a real

Re: [PATCH] irqchip: Convert to using %pOFn instead of device_node.name

2018-09-08 Thread Thomas Gleixner
On Mon, 27 Aug 2018, Rob Herring wrote: > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: linux-arm-ker...@lists.infra

Re: [PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

2018-09-08 Thread Thomas Gleixner
On Wed, 29 Aug 2018, Baoquan He wrote: > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the > initial size of the direct mapping region. This is right in the > old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS, > 46bit, and only 4-level mode was supported. > >

Re: [PATCH] x86/intel_rdt: Show missing resctrl mount options

2018-09-08 Thread Thomas Gleixner
On Tue, 4 Sep 2018, Fenghua Yu wrote: > > Signed-off-by: Xiaochen Shen > Signed-off-by: Fenghua Yu Sigh. Am I supposed to assume that this patch is authored by Xiaochen? Come on, you are around long enough to do it proper. Thanks, tglx

Re: [PATCH 00/10] Removing SEND_SIG_FORCED

2018-09-08 Thread Thomas Gleixner
it carefuly and could not spot anything. Great work! Reviewed-by: Thomas Gleixner

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

2018-09-08 Thread Thomas Gleixner
On Thu, 6 Sep 2018, Christoph Hellwig wrote: > Just as before: NAK to entirely pointless abstractions. Please stop > beating the dead horse. I disagree. These interrupts very well fit into the percpu interupt mechanics and that allows them to be handled by all the generic mechanisms as any

Re: 32-bit PTI with THP = userspace corruption

2018-09-08 Thread Thomas Gleixner
On Fri, 31 Aug 2018, Joerg Roedel wrote: > On Fri, Aug 31, 2018 at 07:12:44AM +0300, Meelis Roos wrote: > > > Thanks for the report! I'll try to reproduce the problem tomorrow and > > > investigate it. Can you please check if any of the kernel configurations > > > that show the bug has

Re: [PATCH] lib/sg_pool: remove unnecessary null check when free the object

2018-09-08 Thread Thomas Gleixner
On Sat, 8 Sep 2018, zhong jiang wrote: > On 2018/9/8 17:46, Thomas Gleixner wrote: > > On Sat, 8 Sep 2018, zhong jiang wrote: > >> Hi, Thomas > >> > >> Can you pick up the patch? > > I'm not picking up patches for lib/sg_pool. Why would I? > > &

Re: [PATCH v2 2/2] irq/matrix: Spread managed interrupts on allocation

2018-09-08 Thread Thomas Gleixner
On Sat, 8 Sep 2018, Dou Liyang wrote: > Spread managed interrupt on allocation as well. > > Fixes: a0c9259dc4e1("irq/matrix: Spread interrupts on allocation") No. This is an enhancement and not a fix. > - cpumask_and(vector_searchmask, vector_searchmask, affmsk); > - cpu =

Re: [PATCH v2 1/2] irq/matrix: Split out the CPU finding code into a helper

2018-09-08 Thread Thomas Gleixner
On Sat, 8 Sep 2018, Dou Liyang wrote: > +/* Find the best CPU which has the lowest vector allocation count */ > +static int matrix_find_best_cpu(struct irq_matrix *m, > + const struct cpumask *msk, int *best_cpu) > +{ > + unsigned int cpu, maxavl = 0; > + struct

Re: [PATCH] lib/sg_pool: remove unnecessary null check when free the object

2018-09-08 Thread Thomas Gleixner
On Sat, 8 Sep 2018, zhong jiang wrote: > Hi, Thomas > > Can you pick up the patch? I'm not picking up patches for lib/sg_pool. Why would I?

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Thomas Gleixner
On Sat, 8 Sep 2018, Thomas Gleixner wrote: > On Fri, 7 Sep 2018, Jiri Kosina wrote: > > So I will go through the whole codepath again, but I fear your suggestion > > would not work -- see the check for cpu_smt_control in stibp_needed(). We > > need to see the o

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Jiri Kosina wrote: > On Fri, 7 Sep 2018, Thomas Gleixner wrote: > > > > + * The read-modify-write of the MSR doesn't need any race protection > > > here, > > > + * as we're running in atomic context. > > > + */ > > > +static

Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Andy Lutomirski wrote: > On Fri, Sep 7, 2018 at 5:04 PM, Linus Torvalds > wrote: > > Virtual mapping tricks may be cool, but in the end, not having to use > > them is better still, I think. > > > > If (and this is a *big* if) all the percpu data is within 2GB of the > entry

Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-08 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Linus Torvalds wrote: > On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner wrote: > > > > > - We execute from an extra page and read from another extra page > > > during the syscall. (The latter is because we need to use a relative > > >

Re: [PATCH v4 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

2018-09-07 Thread Thomas Gleixner
On Thu, 6 Sep 2018, Jiri Kosina wrote: > +/* > + * The read-modify-write of the MSR doesn't need any race protection here, > + * as we're running in atomic context. > + */ > +static void enable_stibp(void *info) > +{ > + u64 mask; > + rdmsrl(MSR_IA32_SPEC_CTRL, mask); > + mask |=

Re: [PATCH V4 3/3] x86/efi: Introduce EFI_PAGE_FAULT_HANDLER

2018-09-07 Thread Thomas Gleixner
On Sat, 8 Sep 2018, Bhupesh Sharma wrote: > On Sat, Sep 8, 2018 at 12:52 AM, Thomas Gleixner wrote: > > If the distro patched their kernel to deal with buggy firmware, then: > > > > 1) why did they not upstream it ? > > Because some of the kernel fixes are (for such

Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline

2018-09-07 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Andy Lutomirski wrote: > On Tue, Sep 4, 2018 at 12:04 AM, Peter Zijlstra wrote: > > Can we have a few words on why this solution and not this alternative? I > > mean, you raise the possibility, but then surely you chose not to > > implement that. Might as well share that with

Re: x86/apic: MSI address malformed for "flat" driver

2018-09-07 Thread Thomas Gleixner
On Thu, 6 Sep 2018, Philipp Eppelt wrote: > > The "flat" driver defines the MSI addressing scheme to be used as > logical addressing in flat mode. The MSI msg address is composed > accordingly, but sets MSI_ADDR_REDIRECTION_CPU which is a zero at bit[3]. Correct. That's what it means: * When

[patch 00/10] x86/mm/cpa: Improve large page preservation handling

2018-09-07 Thread Thomas Gleixner
Bin reported that try_preserve_large_page() in the page attribute code consumes an large amount of CPU time. His initial attempts of addressing this made me look deeper into the code. The logic in this code is not really intelligent. It requires to check a large page in 4k steps for conflicts.

[patch 06/10] x86/mm/cpa: Avoid static protection checks on unmap

2018-09-07 Thread Thomas Gleixner
2M pages sameprot: 466 2M pages preserved: 47 4K pages checked: 800709 4K pages set-checked: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c |7 +++ 1 file changed, 7 insertions(+) --- a/arch/x86/mm/pageattr.c

[patch 07/10] x86/mm/cpa: Add sanity check for existing mappings

2018-09-07 Thread Thomas Gleixner
the static protections for the PTE entries to fix up the incorrectness. For 1G pages this can't be done easily because that would require to either find the offending 2M areas before the split or afterwards. For now just warn about that case and revisit it when reported. Signed-off-by: Thomas

[patch 05/10] x86/mm/cpa: Add large page preservation statistics

2018-09-07 Thread Thomas Gleixner
: 0 2M pages checked: 540 2M pages sameprot: 466 2M pages preserved: 47 4K pages checked: 800770 4K pages set-checked: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/Kconfig |8 +++ arch/x86/mm

[patch 01/10] x86/mm/cpa: Split, rename and clean up try_preserve_large_page()

2018-09-07 Thread Thomas Gleixner
damage while at it. No functional change. Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 121 - 1 file changed, 60 insertions(+), 61 deletions(-) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -421,18 +421,18 @@ pte_t

[patch 08/10] x86/mm/cpa: Optimize same protection check

2018-09-07 Thread Thomas Gleixner
: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 14 ++ 1 file changed, 14 insertions(+) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -836,6 +836,20 @@ static int __should_split_large_page(pte } /* +* Optimization

[patch 02/10] x86/mm/cpa: Rework static_protections()

2018-09-07 Thread Thomas Gleixner
static_protections() is pretty unreadable. Split it up into separate checks for each protection area. Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 159 + 1 file changed, 95 insertions(+), 64 deletions(-) --- a/arch/x86/mm

[patch 03/10] x86/mm/cpa: Allow range check for static protections

2018-09-07 Thread Thomas Gleixner
Checking static protections only page by page is slow especially for huge pages. To allow quick checks over a complete range, add the ability to do that. Make the checks inclusive so the ranges can be directly used for debug output later. No functional change. Signed-off-by: Thomas Gleixner

[patch 10/10] x86/mm/cpa: Avoid the 4k pages check completely

2018-09-07 Thread Thomas Gleixner
sameprot: 466 2M pages preserved: 47 4K pages set-checked: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 66 - 1 file changed, 17 insertions(+), 49 deletions(-) --- a/arch/x86/mm

[patch 04/10] x86/mm/cpa: Add debug mechanism

2018-09-07 Thread Thomas Gleixner
except for developers, so limit the output hard to the protection fixups. Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 60 + 1 file changed, 51 insertions(+), 9 deletions(-) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c

[patch 09/10] x86/mm/cpa: Do the range check early

2018-09-07 Thread Thomas Gleixner
: 541 2M pages sameprot: 466 2M pages preserved: 47 4K pages checked: 514 4K pages set-checked: 7668 Signed-off-by: Thomas Gleixner --- arch/x86/mm/pageattr.c | 27 +++ 1 file changed, 23

Re: [PATCH 2/2] irq/matrix: Spread managed interrupts on allocation

2018-09-07 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Dou Liyang wrote: > -int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu) > +int irq_matrix_alloc_managed(struct irq_matrix *m, const struct cpumask *msk, > + unsigned int *mapped_cpu) > { > - struct cpumap *cm =

Re: [PATCH] x86, mm: Reserver some memory for bootmem allocator for NO_BOOTMEM

2018-09-07 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Feng Tang wrote: > On Fri, Aug 31, 2018 at 09:36:59PM +0800, Feng Tang wrote: > > Any sugestion? I can only have patch like this: > > Could you review this patch, as at this time window there is no usable memory > block or other memory allocators that I know, so I follow the

Re: [PATCH v3 4/5] x86/mm: optimize static_protection() by using overlap()

2018-09-07 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Yang, Bin wrote: > On Fri, 2018-09-07 at 09:49 +0200, Thomas Gleixner wrote: > > On Fri, 7 Sep 2018, Yang, Bin wrote: > > > On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote: > > > > > > I just write a test.c to compare the result

Re: [PATCH v3 4/5] x86/mm: optimize static_protection() by using overlap()

2018-09-07 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Yang, Bin wrote: > On Tue, 2018-09-04 at 14:22 +0200, Thomas Gleixner wrote: > > I just write a test.c to compare the result between overlap() and > original within(). You are right. Your version of doing the overlap exclusive works. I misread the conditions. I

Re: linux-next: Signed-off-by missing for commit in the tip tree

2018-09-06 Thread Thomas Gleixner
On Fri, 7 Sep 2018, Stephen Rothwell wrote: > Commit > > 760902b24960 ("clocksource: Revert "Remove kthread"") > > is missing a Signed-off-by from its committer. Reverts are commits, too. Duh. Fixed. Thanks for spotting! tglx

Re: Ensuring wall_to_monotonic is not positive breaks use case

2018-09-06 Thread Thomas Gleixner
Rick, On Wed, 5 Sep 2018, Rick Ratzel wrote: > We're looking for suggestions on how best to proceed with a new change > that ideally both supports the use case described above, as well as > addresses the symptoms brought up in the initial commit (negative boot > time causes get_expiry() to

Re: [RFC PATCH 00/20] x86/intel_rdt: Start abstraction for a second arch

2018-09-06 Thread Thomas Gleixner
On Fri, 31 Aug 2018, James Morse wrote: > You want to see it all at once (great!). I'm not quite ready with all this > yet, > so it will be a while. I assumed 'all at once' would be to much to ask from > reviewers, hence this attempt to break it into small chunks and post it over a > longer

[tip:smp/urgent] cpu/hotplug: Prevent state corruption on error rollback

2018-09-06 Thread tip-bot for Thomas Gleixner
Commit-ID: 69fa6eb7d6a64801ea261025cce9723d9442d773 Gitweb: https://git.kernel.org/tip/69fa6eb7d6a64801ea261025cce9723d9442d773 Author: Thomas Gleixner AuthorDate: Thu, 6 Sep 2018 15:21:38 +0200 Committer: Thomas Gleixner CommitDate: Thu, 6 Sep 2018 15:21:38 +0200 cpu/hotplug: Prevent

Re: [PATCH V3 10/26] csky: IRQ handling

2018-09-06 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Guo Ren wrote: > +static void (*handle_arch_irq)(struct pt_regs *regs) = NULL; > + > +void __init set_handle_irq(void (*handle_irq)(struct pt_regs *)) > +{ > + if (handle_arch_irq) > + return; > + > + handle_arch_irq = handle_irq; > +} Please don't

Re: [PATCH] x86/fault: Decode page fault OOPSes better

2018-09-06 Thread Thomas Gleixner
On Fri, 31 Aug 2018, Andy Lutomirski wrote: > @@ -671,6 +705,48 @@ show_fault_oops(struct pt_regs *regs, unsigned long > error_code, >address < PAGE_SIZE ? "NULL pointer dereference" : "paging > request", >(void *)address); > > + errcode[0] = 0; error_code

Re: [PATCH] x86/process: don't mix user/kernel regs in 64bit __show_regs

2018-09-06 Thread Thomas Gleixner
On Thu, 6 Sep 2018, Jann Horn wrote: > On Fri, Aug 31, 2018 at 10:12 PM Andy Lutomirski wrote: > > > > On Fri, Aug 31, 2018 at 12:41 PM, Jann Horn wrote: > > > When the kernel.print-fatal-signals sysctl has been enabled (I don't know > > > whether anyone actually enables it), a simple userspace

Re: [PATCH] cpu/hotplug: Fix rollback during error-out in takedown_cpu()

2018-09-06 Thread Thomas Gleixner
On Thu, 6 Sep 2018, Neeraj Upadhyay wrote: > On 09/05/2018 06:47 PM, Thomas Gleixner wrote: > > On Wed, 5 Sep 2018, Neeraj Upadhyay wrote: > > > On 09/05/2018 05:53 PM, Thomas Gleixner wrote: > > > > And looking closer this is a general issue. Just that the TEARDOWN

Re: [PATCH 16/21] x86: DT: use for_each_of_cpu_node iterator

2018-09-06 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Rob Herring wrote: > Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This > has the side effect of defaulting to iterating using "cpu" node names in > preference to the deprecated (for FDT) device_type == "cpu". > > Cc:

Re: [PATCH] kernel: cpu: Handle hotplug failure for state CPUHP_AP_IDLE_DEAD

2018-09-06 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Prakruthi Deepak Heragu wrote: > Once the tear down hotplug handler is run, cpu is dead and enters > into CPUHP_AP_IDLE_DEAD state. Any callbacks that fail in the state > machine with state < CPUHP_AP_IDLE must be treated as fatal as this > could result into timer not beig

Re: [PATCH] genirq: Avoid race between cpu hot plug and irq_desc() allocation paths

2018-09-06 Thread Thomas Gleixner
On Wed, 5 Sep 2018, pher...@codeaurora.org wrote: > On 2018-09-05 11:23, Thomas Gleixner wrote: > > On Wed, 5 Sep 2018, Prakruthi Deepak Heragu wrote: > > > > > One of the cores might have just allocated irq_desc() and other core > > > might be doing i

Re: Plumbers 2018 - Performance and Scalability Microconference

2018-09-05 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Laurent Dufour wrote: > On 05/09/2018 17:10, Christopher Lameter wrote: > > Large page sizes also reduce contention there. > > That's true for the page fault path, but for process's actions manipulating > the > memory process's layout (mmap,munmap,madvise,mprotect) the impact

Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks

2018-09-05 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Andi Kleen wrote: > > So, after giving it a bit more thought, I still believe "I want spectre V2 > > protection" vs. "I do not care about spectre V2 on my system > > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4 > > of my patchset, including the

Re: [PATCH] genirq: Avoid race between cpu hot plug and irq_desc() allocation paths

2018-09-05 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Prakruthi Deepak Heragu wrote: > One of the cores might have just allocated irq_desc() and other core > might be doing irq migration in the hot plug path. In the hot plug path > during the IRQ migration, for_each_active_irq macro is trying to get > irqs whose bits are set in

Re: [PATCH] cpu/hotplug: Fix rollback during error-out in takedown_cpu()

2018-09-05 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Neeraj Upadhyay wrote: > On 09/05/2018 05:53 PM, Thomas Gleixner wrote: > > > > And looking closer this is a general issue. Just that the TEARDOWN state > > makes it simple to observe. It's universaly broken, when the first teardown > > callback fails

Re: [PATCH] cpu/hotplug: Fix rollback during error-out in takedown_cpu()

2018-09-05 Thread Thomas Gleixner
On Wed, 5 Sep 2018, Mukesh Ojha wrote: > On 9/5/2018 5:03 PM, Thomas Gleixner wrote: > > > + st->rollback = true; > > > + st->target = prev_state; > > > + st->bringup = !st->bringup; > > No, this is just papering over the

<    1   2   3   4   5   6   7   8   9   10   >