Re: [PATCH] x86/pci: fix intel_mid_pci.c build error when ACPI is not enabled

/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration] acpi_noirq_set(); Signed-off-by: Randy Dunlap Cc: Jacob Pan Cc: Len Brown Cc: Bjorn Helgaas Cc: Jesse Barnes Cc: Arjan van de Ven Cc: linux

Re: [PATCH v11 2/3] x86,/proc/pid/status: Add AVX-512 usage elapsed time

On 2/20/2019 7:35 AM, David Laight wrote: From: Sent: 16 February 2019 12:56 To: Li, Aubrey ... The above experiment just confirms what I said: The numbers are inaccurate and potentially misleading to a large extent when the AVX using task is not scheduled out for a longer time. Not only

Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations

On 1/14/2019 5:06 AM, Jiri Kosina wrote: On Mon, 14 Jan 2019, Pavel Machek wrote: Frankly I'd not call it Meltdown, as it works only on data in the cache, so the defense is completely different. Seems more like a l1tf :-). Meltdown on x86 also seems to work only for data in L1D, but the

Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations

On 12/31/2018 8:22 AM, Ben Greear wrote: On 12/21/2018 05:17 PM, Tim Chen wrote: On 12/21/18 1:59 PM, Ben Greear wrote: On 12/21/18 9:44 AM, Tim Chen wrote: Thomas, Andi and I have made an update to our draft of the Spectre admin guide. We may be out on Christmas vacation for a while.  But

Re: WARNING in __rcu_read_unlock

On 12/17/2018 3:29 AM, Paul E. McKenney wrote: As does this sort of report on a line that contains simple integer arithmetic and boolean operations.;-) Any chance of a bisection? btw this looks like something caused a stack overflow and thus all the weirdness that then happens

Re: [PATCH v4 1/2] x86/fpu: track AVX-512 usage of tasks

On 12/11/2018 3:46 PM, Li, Aubrey wrote: On 2018/12/12 1:18, Dave Hansen wrote: On 12/10/18 4:24 PM, Aubrey Li wrote: The tracking turns on the usage flag at the next context switch of the task, but requires 3 consecutive context switches with no usage to clear it. This decay is required

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

On processors with enhanced IBRS support, we recommend setting IBRS to 1 and left set. Then why doesn't CPU with EIBRS support acutally *default* to '1', with opt-out possibility for OS? (slightly longer answer) you can pretty much assume that on these CPUs, IBRS doesn't actually do anything

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

On processors with enhanced IBRS support, we recommend setting IBRS to 1 and left set. Then why doesn't CPU with EIBRS support acutally *default* to '1', with opt-out possibility for OS? (slightly longer answer) you can pretty much assume that on these CPUs, IBRS doesn't actually do anything

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

On processors with enhanced IBRS support, we recommend setting IBRS to 1 and left set. Then why doesn't CPU with EIBRS support acutally *default* to '1', with opt-out possibility for OS? the BIOSes could indeed get this set up this way. do you want to trust the bios to get it right?

Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

On processors with enhanced IBRS support, we recommend setting IBRS to 1 and left set. Then why doesn't CPU with EIBRS support acutally *default* to '1', with opt-out possibility for OS? the BIOSes could indeed get this set up this way. do you want to trust the bios to get it right?

Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment

On 11/21/2018 2:53 PM, Borislav Petkov wrote: On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: Btw, I really do not like the app2app wording. I'd rather go for usr2usr, but that's kinda horrible as well. But then, all of this is horrible. Any better ideas? It needs to have

Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment

On 11/21/2018 2:53 PM, Borislav Petkov wrote: On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: Btw, I really do not like the app2app wording. I'd rather go for usr2usr, but that's kinda horrible as well. But then, all of this is horrible. Any better ideas? It needs to have

Re: STIBP by default.. Revert?

On 11/20/2018 11:27 PM, Jiri Kosina wrote: On Mon, 19 Nov 2018, Arjan van de Ven wrote: In the documentation, AMD officially recommends against this by default, and I can speak for Intel that our position is that as well: this really must not be on by default. Thanks for pointing to the AMD

Re: STIBP by default.. Revert?

On 11/20/2018 11:27 PM, Jiri Kosina wrote: On Mon, 19 Nov 2018, Arjan van de Ven wrote: In the documentation, AMD officially recommends against this by default, and I can speak for Intel that our position is that as well: this really must not be on by default. Thanks for pointing to the AMD

Re: Re: STIBP by default.. Revert?

On 11/19/2018 6:00 AM, Linus Torvalds wrote: On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote: So why do that STIBP slow-down by default when the people who *really* care already disabled SMT? BTW for them, there is no impact at all. Right. People who really care about security and are

Re: Re: STIBP by default.. Revert?

On 11/19/2018 6:00 AM, Linus Torvalds wrote: On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote: So why do that STIBP slow-down by default when the people who *really* care already disabled SMT? BTW for them, there is no impact at all. Right. People who really care about security and are

Re: [RFC PATCH v1 2/2] proc: add /proc//thread_state

I'd prefer the kernel to do such clustering... I think that is a next step. Also, while the kernel can do this at a best effort basis, it cannot take into account things the kernel doesn't know about, like high priority job peak load etc.., things a job scheduler would know. Then again, a

Re: [RFC PATCH v1 2/2] proc: add /proc//thread_state

I'd prefer the kernel to do such clustering... I think that is a next step. Also, while the kernel can do this at a best effort basis, it cannot take into account things the kernel doesn't know about, like high priority job peak load etc.., things a job scheduler would know. Then again, a

Re: [RFC] x86, tsc: Add kcmdline args for skipping tsc calibration sequences

On 7/13/2018 12:19 PM, patrickg wrote: This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration methods should the user desire to. The current ordering in ML x86 tsc is to calibrate in the order listed above; returning whenever there's a successful calibration. However

Re: [RFC] x86, tsc: Add kcmdline args for skipping tsc calibration sequences

On 7/13/2018 12:19 PM, patrickg wrote: This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration methods should the user desire to. The current ordering in ML x86 tsc is to calibrate in the order listed above; returning whenever there's a successful calibration. However

Re: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

On 2/16/2018 11:43 AM, Linus Torvalds wrote: On Fri, Feb 16, 2018 at 11:38 AM, Linus Torvalds wrote: Of course, your patch still doesn't allow for "we claim to be skylake for various other independent reasons, but the RSB issue is fixed". .. maybe nobody ever

Re: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow

On 2/16/2018 11:43 AM, Linus Torvalds wrote: On Fri, Feb 16, 2018 at 11:38 AM, Linus Torvalds wrote: Of course, your patch still doesn't allow for "we claim to be skylake for various other independent reasons, but the RSB issue is fixed". .. maybe nobody ever has a reason to do that,

Re: [PATCH] platform/x86: intel_turbo_max_3: Remove restriction for HWP platforms

On 2/14/2018 11:29 AM, Andy Shevchenko wrote: On Mon, Feb 12, 2018 at 9:50 PM, Srinivas Pandruvada wrote: On systems supporting HWP (Hardware P-States) mode, we expected to enumerate core priority via ACPI-CPPC tables. Unfortunately deployment of TURBO 3.0

Re: [PATCH] platform/x86: intel_turbo_max_3: Remove restriction for HWP platforms

On 2/14/2018 11:29 AM, Andy Shevchenko wrote: On Mon, Feb 12, 2018 at 9:50 PM, Srinivas Pandruvada wrote: On systems supporting HWP (Hardware P-States) mode, we expected to enumerate core priority via ACPI-CPPC tables. Unfortunately deployment of TURBO 3.0 didn't use this method to show core

Re: [PATCH 4.9 43/92] x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown

So, any hints on what you think should be the correct fix here? the patch sure looks correct to me, it now has a nice table for CPU IDs including all of AMD (and soon hopefully the existing Intel ones that are not exposed to meltdown)

Re: [PATCH 4.9 43/92] x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown

So, any hints on what you think should be the correct fix here? the patch sure looks correct to me, it now has a nice table for CPU IDs including all of AMD (and soon hopefully the existing Intel ones that are not exposed to meltdown)

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/31/2018 2:15 AM, Thomas Gleixner wrote: Good luck with making all that work. on the Intel side we're checking what we can do that works and doesn't break things right now; hopefully we just end up with a bit in the arch capabilities MSR for "you should do RSB stuffing" and then the HV's

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/31/2018 2:15 AM, Thomas Gleixner wrote: Good luck with making all that work. on the Intel side we're checking what we can do that works and doesn't break things right now; hopefully we just end up with a bit in the arch capabilities MSR for "you should do RSB stuffing" and then the HV's

Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

On 1/30/2018 5:11 AM, Borislav Petkov wrote: On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote: So much for the theory. That's not going to work. If the boot cpu has the feature then the alternatives will have been applied. So even if the flag mismatch can be observed when a

Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

On 1/30/2018 5:11 AM, Borislav Petkov wrote: On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote: So much for the theory. That's not going to work. If the boot cpu has the feature then the alternatives will have been applied. So even if the flag mismatch can be observed when a

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/29/2018 7:32 PM, Linus Torvalds wrote: On Mon, Jan 29, 2018 at 5:32 PM, Arjan van de Ven <ar...@linux.intel.com> wrote: the most simple solution is that we set the internal feature bit in Linux to turn on the "stuff the RSB" workaround is we're on a SKL *or* as

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/29/2018 7:32 PM, Linus Torvalds wrote: On Mon, Jan 29, 2018 at 5:32 PM, Arjan van de Ven wrote: the most simple solution is that we set the internal feature bit in Linux to turn on the "stuff the RSB" workaround is we're on a SKL *or* as a guest in a VM. That sounds

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/29/2018 4:23 PM, Linus Torvalds wrote: Why do you even _care_ about the guest, and how it acts wrt Skylake? What you should care about is not so much the guests (which do their own thing) but protect guests from each other, no? the most simple solution is that we set the internal feature

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/29/2018 4:23 PM, Linus Torvalds wrote: Why do you even _care_ about the guest, and how it acts wrt Skylake? What you should care about is not so much the guests (which do their own thing) but protect guests from each other, no? the most simple solution is that we set the internal feature

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/29/2018 12:42 PM, Eduardo Habkost wrote: The question is how the hypervisor could tell that to the guest. If Intel doesn't give us a CPUID bit that can be used to tell that retpolines are enough, maybe we should use a hypervisor CPUID bit for that? the objective is to have retpoline be

Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/29/2018 12:42 PM, Eduardo Habkost wrote: The question is how the hypervisor could tell that to the guest. If Intel doesn't give us a CPUID bit that can be used to tell that retpolines are enough, maybe we should use a hypervisor CPUID bit for that? the objective is to have retpoline be

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On 1/26/2018 10:11 AM, David Woodhouse wrote: I am *actively* ignoring Skylake right now. This is about per-SKL userspace even with SMEP, because we think Intel's document lies to us. if you think we lie to you then I think we're done with the conversation? Please tell us then what you

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On 1/26/2018 10:11 AM, David Woodhouse wrote: I am *actively* ignoring Skylake right now. This is about per-SKL userspace even with SMEP, because we think Intel's document lies to us. if you think we lie to you then I think we're done with the conversation? Please tell us then what you

Re: [PATCH v3 5/6] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown

On 1/26/2018 7:27 AM, Dave Hansen wrote: On 01/26/2018 04:14 AM, Yves-Alexis Perez wrote: I know we'll still be able to manually enable PTI with a command line option, but it's also a hardening feature which has the nice side effect of emulating SMEP on CPU which don't support it (e.g the Atom

Re: [PATCH v3 5/6] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown

On 1/26/2018 7:27 AM, Dave Hansen wrote: On 01/26/2018 04:14 AM, Yves-Alexis Perez wrote: I know we'll still be able to manually enable PTI with a command line option, but it's also a hardening feature which has the nice side effect of emulating SMEP on CPU which don't support it (e.g the Atom

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This patch tries to address the case when we do switch to init_mm and back. Do you still have objections to the approach in this patch to save the last active mm before switching to init_mm? how do you know the last active mm did not go away and started a new process with new content? (other

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This patch tries to address the case when we do switch to init_mm and back. Do you still have objections to the approach in this patch to save the last active mm before switching to init_mm? how do you know the last active mm did not go away and started a new process with new content? (other

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

The idea is simple, do what we do for virt. Don't send IPI's to CPUs that don't need them (in virt's case because the vCPU isn't running, in our case because we're not in fact running a user process), but mark the CPU as having needed a TLB flush. I am really uncomfortable with that idea. You

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

The idea is simple, do what we do for virt. Don't send IPI's to CPUs that don't need them (in virt's case because the vCPU isn't running, in our case because we're not in fact running a user process), but mark the CPU as having needed a TLB flush. I am really uncomfortable with that idea. You

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 1/25/2018 5:50 AM, Peter Zijlstra wrote: On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IP

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

On 1/25/2018 5:50 AM, Peter Zijlstra wrote: On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote: This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IP

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IPI CPUs in deep sleep states for a tlb flush. (trust me, that you really want, sequentially IPI's a pile of cores in a

Re: [RFC PATCH 1/2] x86/ibpb: Skip IBPB when we switch back to same user process

This means that 'A -> idle -> A' should never pass through switch_mm to begin with. Please clarify how you think it does. the idle code does leave_mm() to avoid having to IPI CPUs in deep sleep states for a tlb flush. (trust me, that you really want, sequentially IPI's a pile of cores in a

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/24/2018 1:10 AM, Greg Kroah-Hartman wrote: That means the whitelist ends up basically empty right now. Should I add a command line parameter to override it? Otherwise we end up having to rebuild the kernel every time there's a microcode release which covers a new CPU SKU (which is why I

Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

On 1/24/2018 1:10 AM, Greg Kroah-Hartman wrote: That means the whitelist ends up basically empty right now. Should I add a command line parameter to override it? Otherwise we end up having to rebuild the kernel every time there's a microcode release which covers a new CPU SKU (which is why I

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

On 1/21/2018 8:21 AM, Ingo Molnar wrote: So if it's only about the scheduler barrier, what cycle cost are we talking about here? in the order of 5000 to 1 cycles. (depends a bit on the cpu generation but this range is a reasonable approximation) Because putting something like this

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

On 1/21/2018 8:21 AM, Ingo Molnar wrote: So if it's only about the scheduler barrier, what cycle cost are we talking about here? in the order of 5000 to 1 cycles. (depends a bit on the cpu generation but this range is a reasonable approximation) Because putting something like this

Re: kexec reboot fails with extra wbinvd introduced for AME SME

Does anybody have any other ideas? the only other weird case that comes to mind; what happens if there's a line dirty in the caches, but the memory is now mapped uncached. (Which could happen if kexec does muck with MTRRs, CR0 or other similar things in weird ways)... not sure what happens

Re: kexec reboot fails with extra wbinvd introduced for AME SME

Does anybody have any other ideas? the only other weird case that comes to mind; what happens if there's a line dirty in the caches, but the memory is now mapped uncached. (Which could happen if kexec does muck with MTRRs, CR0 or other similar things in weird ways)... not sure what happens

Re: kexec reboot fails with extra wbinvd introduced for AME SME

Does anybody have any other ideas? wbinvd is thankfully not common, but also not rare (MTRR setup and a bunch of other cases) and in some other operating systems it happens even more than on Linux.. it's generally not totally broken like this. I can only imagine a machine check case where a

Re: kexec reboot fails with extra wbinvd introduced for AME SME

Does anybody have any other ideas? wbinvd is thankfully not common, but also not rare (MTRR setup and a bunch of other cases) and in some other operating systems it happens even more than on Linux.. it's generally not totally broken like this. I can only imagine a machine check case where a

Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs

This would means that userspace would see return predictions based on the values the kernel 'stuffed' into the RSB to fill it. Potentially this leaks a kernel address to userspace. KASLR pretty much died in May this year to be honest with the KAISER paper (if not before then) also with KPTI

Re: [tip:x86/pti] x86/retpoline: Fill RSB on context switch for affected CPUs

This would means that userspace would see return predictions based on the values the kernel 'stuffed' into the RSB to fill it. Potentially this leaks a kernel address to userspace. KASLR pretty much died in May this year to be honest with the KAISER paper (if not before then) also with KPTI

Re: [PATCH 3/8] kvm: vmx: pass MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD down to the guest

On 1/10/2018 5:20 AM, Paolo Bonzini wrote: * a simple specification that does "IBRS=1 blocks indirect branch prediction altogether" would actually satisfy the specification just as well, and it would be nice to know if that's what the processor actually does. it doesn't exactly, not for all.

Re: [PATCH 3/8] kvm: vmx: pass MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD down to the guest

On 1/10/2018 5:20 AM, Paolo Bonzini wrote: * a simple specification that does "IBRS=1 blocks indirect branch prediction altogether" would actually satisfy the specification just as well, and it would be nice to know if that's what the processor actually does. it doesn't exactly, not for all.

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 1/9/2018 8:17 AM, Paolo Bonzini wrote: On 09/01/2018 16:19, Arjan van de Ven wrote: On 1/9/2018 7:00 AM, Liran Alon wrote: - ar...@linux.intel.com wrote: On 1/9/2018 3:41 AM, Paolo Bonzini wrote: The above ("IBRS simply disables the indirect branch predictor") was my

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 1/9/2018 8:17 AM, Paolo Bonzini wrote: On 09/01/2018 16:19, Arjan van de Ven wrote: On 1/9/2018 7:00 AM, Liran Alon wrote: - ar...@linux.intel.com wrote: On 1/9/2018 3:41 AM, Paolo Bonzini wrote: The above ("IBRS simply disables the indirect branch predictor") was my

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

I'm sorry I'm not familiar with your L0/L1/L2 terminology (maybe it's before coffee has had time to permeate the brain) These are standard terminology for guest levels: L0 == hypervisor that runs on bare-metal L1 == hypervisor that runs as L0 guest. L2 == software that runs as L1 guest. (We

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

I'm sorry I'm not familiar with your L0/L1/L2 terminology (maybe it's before coffee has had time to permeate the brain) These are standard terminology for guest levels: L0 == hypervisor that runs on bare-metal L1 == hypervisor that runs as L0 guest. L2 == software that runs as L1 guest. (We

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 1/9/2018 7:00 AM, Liran Alon wrote: - ar...@linux.intel.com wrote: On 1/9/2018 3:41 AM, Paolo Bonzini wrote: The above ("IBRS simply disables the indirect branch predictor") was my take-away message from private discussion with Intel. My guess is that the vendors are just

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 1/9/2018 7:00 AM, Liran Alon wrote: - ar...@linux.intel.com wrote: On 1/9/2018 3:41 AM, Paolo Bonzini wrote: The above ("IBRS simply disables the indirect branch predictor") was my take-away message from private discussion with Intel. My guess is that the vendors are just

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 1/9/2018 3:41 AM, Paolo Bonzini wrote: The above ("IBRS simply disables the indirect branch predictor") was my take-away message from private discussion with Intel. My guess is that the vendors are just handwaving a spec that doesn't match what they have implemented, because honestly a

Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU

On 1/9/2018 3:41 AM, Paolo Bonzini wrote: The above ("IBRS simply disables the indirect branch predictor") was my take-away message from private discussion with Intel. My guess is that the vendors are just handwaving a spec that doesn't match what they have implemented, because honestly a

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

It sounds like Coverity was used to produce these patches? If so, is there a plan to have smatch (hey Dan) or other open source static analysis tool be possibly enhanced to do a similar type of work? I'd love for that to happen; the tricky part is being able to have even a sort of sensible

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

It sounds like Coverity was used to produce these patches? If so, is there a plan to have smatch (hey Dan) or other open source static analysis tool be possibly enhanced to do a similar type of work? I'd love for that to happen; the tricky part is being able to have even a sort of sensible

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/20/2017 1:11 AM, Thomas Gleixner wrote: On Thu, 20 Jul 2017, Li, Aubrey wrote: Don't get me wrong, even if a fast path is acceptable, we still need to figure out if the coming idle is short and when to switch. I'm just worried about if irq timings is not an ideal statistics, we have to

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/20/2017 1:11 AM, Thomas Gleixner wrote: On Thu, 20 Jul 2017, Li, Aubrey wrote: Don't get me wrong, even if a fast path is acceptable, we still need to figure out if the coming idle is short and when to switch. I'm just worried about if irq timings is not an ideal statistics, we have to

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/20/2017 5:50 AM, Paul E. McKenney wrote: To make this work reasonably, you would also need some way to check for the case where the prediction idle time is short but the real idle time is very long. so the case where you predict very short but is actually "indefinite", the real solution

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/20/2017 5:50 AM, Paul E. McKenney wrote: To make this work reasonably, you would also need some way to check for the case where the prediction idle time is short but the real idle time is very long. so the case where you predict very short but is actually "indefinite", the real solution

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/18/2017 9:36 AM, Peter Zijlstra wrote: On Tue, Jul 18, 2017 at 08:29:40AM -0700, Arjan van de Ven wrote: the most obvious way to do this (for me, maybe I'm naive) is to add another C state, lets call it "C1-lite" with its own thresholds and power levels etc, and just let that

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/18/2017 9:36 AM, Peter Zijlstra wrote: On Tue, Jul 18, 2017 at 08:29:40AM -0700, Arjan van de Ven wrote: the most obvious way to do this (for me, maybe I'm naive) is to add another C state, lets call it "C1-lite" with its own thresholds and power levels etc, and just let that

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/18/2017 8:20 AM, Paul E. McKenney wrote: 3.2) how to determine if the idle is short or long. My current proposal is to use a tunable value via /sys, while Peter prefers an auto-adjust mechanism. I didn't get the details of an auto-adjust mechanism yet the most obvious way to do this (for

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/18/2017 8:20 AM, Paul E. McKenney wrote: 3.2) how to determine if the idle is short or long. My current proposal is to use a tunable value via /sys, while Peter prefers an auto-adjust mechanism. I didn't get the details of an auto-adjust mechanism yet the most obvious way to do this (for

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:53 PM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Arjan van de Ven wrote: On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Of course, this all assumes a Gaussian distribution to begin with, if we get bimodal (or worse) distributions we can still get it wrong. To fix that, we'd

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:53 PM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Arjan van de Ven wrote: On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Of course, this all assumes a Gaussian distribution to begin with, if we get bimodal (or worse) distributions we can still get it wrong. To fix that, we'd

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:46 PM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Arjan van de Ven wrote: On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Now I think the problem is that the current predictor goes for an average idle duration. This means that we, on average, get it wrong 50% of the time

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:46 PM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Arjan van de Ven wrote: On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Now I think the problem is that the current predictor goes for an average idle duration. This means that we, on average, get it wrong 50% of the time

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Of course, this all assumes a Gaussian distribution to begin with, if we get bimodal (or worse) distributions we can still get it wrong. To fix that, we'd need to do something better than what we currently have. fwiw some time ago I made a chart

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Of course, this all assumes a Gaussian distribution to begin with, if we get bimodal (or worse) distributions we can still get it wrong. To fix that, we'd need to do something better than what we currently have. fwiw some time ago I made a chart

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Now I think the problem is that the current predictor goes for an average idle duration. This means that we, on average, get it wrong 50% of the time. For performance that's bad. that's not really what it does; it looks at next tick and then

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/17/2017 12:23 PM, Peter Zijlstra wrote: Now I think the problem is that the current predictor goes for an average idle duration. This means that we, on average, get it wrong 50% of the time. For performance that's bad. that's not really what it does; it looks at next tick and then

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/14/2017 8:38 AM, Peter Zijlstra wrote: No, that's wrong. We want to fix the normal C state selection process to pick the right C state. The fast-idle criteria could cut off a whole bunch of available C states. We need to understand why our current C state pick is wrong and amend the

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On 7/14/2017 8:38 AM, Peter Zijlstra wrote: No, that's wrong. We want to fix the normal C state selection process to pick the right C state. The fast-idle criteria could cut off a whole bunch of available C states. We need to understand why our current C state pick is wrong and amend the

Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c

On 5/27/2017 9:56 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 9:00 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 6:31 AM, kernel test robot wrote: FYI, we noticed the following commit: commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf

Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c

On 5/27/2017 9:56 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 9:00 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 6:31 AM, kernel test robot wrote: FYI, we noticed the following commit: commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf ("x86/mm: Rework lazy TLB to track the

Re: [patch 12/18] async: Adjust system_state checks

On 5/14/2017 11:27 AM, Thomas Gleixner wrote: looks good .. ack

Re: [patch 12/18] async: Adjust system_state checks

On 5/14/2017 11:27 AM, Thomas Gleixner wrote: looks good .. ack

Re: [PATCH] use get_random_long for the per-task stack canary

On 5/4/2017 6:32 AM, Daniel Micay wrote: The stack canary is an unsigned long and should be fully initialized to random data rather than only 32 bits of random data. that makes sense to me... ack

Re: [PATCH] use get_random_long for the per-task stack canary

On 5/4/2017 6:32 AM, Daniel Micay wrote: The stack canary is an unsigned long and should be fully initialized to random data rather than only 32 bits of random data. that makes sense to me... ack

Re: [PATCH 5/6] notifiers: Use CHECK_DATA_CORRUPTION() on checks

On 3/22/2017 12:29 PM, Kees Cook wrote: When performing notifier function pointer sanity checking, allow CONFIG_BUG_ON_DATA_CORRUPTION to upgrade from a WARN to a BUG. Additionally enables CONFIG_DEBUG_NOTIFIERS when selecting CONFIG_BUG_ON_DATA_CORRUPTION. Any feedback on this change? By

Re: [PATCH 5/6] notifiers: Use CHECK_DATA_CORRUPTION() on checks

On 3/22/2017 12:29 PM, Kees Cook wrote: When performing notifier function pointer sanity checking, allow CONFIG_BUG_ON_DATA_CORRUPTION to upgrade from a WARN to a BUG. Additionally enables CONFIG_DEBUG_NOTIFIERS when selecting CONFIG_BUG_ON_DATA_CORRUPTION. Any feedback on this change? By

Re: [PATCH 1/5] x86: Implement __WARN using UD0

On 3/21/2017 8:14 AM, Peter Zijlstra wrote: For self-documentation purposes, maybe use a define for the length of the ud0 instruction? #define TWO 2 ;-) some things make sense as a define, others don't (adding a comment, maybe)

Re: [PATCH 1/5] x86: Implement __WARN using UD0

On 3/21/2017 8:14 AM, Peter Zijlstra wrote: For self-documentation purposes, maybe use a define for the length of the ud0 instruction? #define TWO 2 ;-) some things make sense as a define, others don't (adding a comment, maybe)

Re: [PATCH] x86/dmi: Switch dmi_remap to ioremap_cache

On 3/9/2017 9:48 AM, Julian Brost wrote: I'm note entirely sure whether it's actually the kernel or HP to blame, but for now, hp-health is completely broken on 4.9 (probably on everything starting from 4.6), so this patch should be reviewed again. it looks like another kernel driver is doing

Re: [PATCH] x86/dmi: Switch dmi_remap to ioremap_cache

On 3/9/2017 9:48 AM, Julian Brost wrote: I'm note entirely sure whether it's actually the kernel or HP to blame, but for now, hp-health is completely broken on 4.9 (probably on everything starting from 4.6), so this patch should be reviewed again. it looks like another kernel driver is doing

  1   2   3   4   5   6   7   8   9   10   >