From: Nadav Amit [mailto:nadav.a...@gmail.com]
Sent: Tuesday, June 14, 2016 8:38 PM
>> +pte_t pte = ptep_get_and_clear(mm, addr, ptep);
>> +
>> +if (boot_cpu_has_bug(X86_BUG_PTE_LEAK))
>> +fix_pte_leak(mm, addr, ptep);
>> +return pte;
>> }
>
> I missed it on the previous i
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Tuesday, June 14, 2016 8:10 PM
>> +if (boot_cpu_has_bug(X86_BUG_PTE_LEAK))
>
> static_cpu_has_bug()
>> +if (c->x86_model == 87) {
>
> That should be INTEL_FAM6_XEON_PHI_KNL, AFAICT.
>> +static bool printed;
>> +
>> +
From: Dave Hansen [mailto:dave.han...@linux.intel.com]
Sent: Tuesday, June 14, 2016 7:20 PM
>> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
...
>> +extern void fix_pte_leak(struct mm_struct *mm, unsigned long addr,
>> + pte_t *ptep);
> Doesn't
From: Nadav Amit [mailto:nadav.a...@gmail.com]
Sent: Tuesday, June 14, 2016 6:48 PM
> Lukasz Anaczkowski wrote:
>> From: Andi Kleen
>> +void fix_pte_leak(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
>> +{
> Here there should be a call to smp_mb__after_atomic() to synchronize with
> s
-Original Message-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Wednesday, December 2, 2015 8:28 PM
To: Chrzaniuk, Hubert
Cc: Anaczkowski, Lukasz ;
mche...@osg.samsung.com; dougthomp...@xmission.com; linux-e...@vger.kernel.org;
linux-kernel@vger.kernel.org; Snow, Jim M
Subject
From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
Sent: Thursday, September 17, 2015 7:05 PM
> Please *always* send PM-related patches to linux...@vger.kernel.org (CCed
> now).
Ok, thanks for noticing.
I've addressed my patch based on output of ./scripts/get_maintainer.pl
and gave me output l
-Original Message-
From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
Sent: Wednesday, September 9, 2015 3:56 PM
> On Wed, Sep 09, 2015 at 10:30:18AM +0100, Lukasz Anaczkowski wrote:
> > () it's hard to predict how cores and threads are enumerated
> So ? Why would the logical cpu
From: Marc Zyngier [mailto:marc.zyng...@arm.com]
Sent: Tuesday, September 8, 2015 6:28 PM
> In my view, this makes the change a lot more palatable, and it can fit in
> exactly two patches:
>
> 1) add the acpi_subtable_proc stuff with the compatibility helpers
> 2) change arch/x86/kernel/acpi/boo
From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org]
Sent: Tuesday, September 1, 2015 3:37 PM
> On 01.09.2015 14:07, Anaczkowski, Lukasz wrote:
>> From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org]
>> Sent: Tuesday, September 1, 2015 10:03 AM
>>>
>>>>
From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org]
Sent: Tuesday, September 1, 2015 10:03 AM
>> To fix this, each LAPIC/X2APIC entry from MADT table needs to be
>> handled at the same time when processing it, thus adding
>> acpi_subtable_proc structure which stores
>> () ACPI table id
>> (
On Monday, August 3, 2015 8:26 PM
Lukasz Anaczkowski wrote:
> v2: Fixed ARM64 syntax error
Hi Marc,
Does this patch look ok now?
Thanks,
Lukasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
> I have some concerns here about "maxcpus" and "nox2apic" kernel parameters.
> Say "maxcpus=72 nox2apic" is specified, user may get less than 72 CPUs with
> you patch applied. Original code will try to only all xapic CPUs before
> trying x2apic CPUs, so "maxcpus" doesn't conflict with "nox2apic
> From: Aristeu Rozanski [mailto:a...@redhat.com]
> the only reason these exist is for when there's a difference between memory
> controllers:
> > pvt->info.get_memory_type = get_memory_type;
> > pvt->info.get_memory_type = get_memory_type;
> > pvt->info.get_m
13 matches
Mail list logo
