Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi Peter,
Good news is that I got our opengl test running on your x86/mm branch.
The commit a2b4306c50b5de2ca955cd73ac57c2ac6426ee15 (current tip of
x86/mm) is good. For sanity I jumped back and found this commit
a2aa52ab16efbee40ad118ebac4a5e438f5b43ee doesn't work.
Thanks,
Tom
On 2018-12-03 2:26 p.m., Tom St Denis wrote:
> Hi Peter,
>
> After updating my UMDs (mesa/etc) over the weekend I cannot reproduce
> the bug to begin with. I'll try jumping directly to the intersection
> and see if I can reproduce the fault there otherwise I'll have to
> rollback my umds.
>
> Hopefully I can test this tomorrow.
>
> Tom
>
> On 2018-12-03 10:41 a.m., Peter Zijlstra wrote:
>> On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
>>> NAK I get a failure in TTM on init with your x86/mm branch (see attached
>>> dmesg).
>>
>> So the good news is that with some additional self-tests I can trivially
>> reproduce this. The bad news is that an otherwise straight forward
>> cleanup seems to make CPA horribly mad at me.
>>
>> And since we're somewhat late in the release cycle, I suppose we should
>> do the simple thing first, and then I can try and figure out this CPA
>> mess later.
>>
>> So how about this relatively simple partial revert to sort the problem.
>>
>> ---
>> Subject: x86/mm/cpa: Fix cpa_flush_array() TLB invalidation
>>
>> In commit:
>>
>> a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>>
>> I misread the cpa array code and incorrectly used
>> tlb_flush_kernel_range(), resulting in missing TLB flushes and
>> consequent failures.
>>
>> Instead do a full invalidate in this case -- for now.
>>
>> Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>> Reported-by: "StDenis, Tom"
>> Signed-off-by: Peter Zijlstra (Intel)
>> ---
>> arch/x86/mm/pageattr.c | 24
>> 1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
>> index bac35001d896..61bc7d1800d7 100644
>> --- a/arch/x86/mm/pageattr.c
>> +++ b/arch/x86/mm/pageattr.c
>> @@ -285,20 +285,16 @@ static void cpa_flush_all(unsigned long cache)
>> on_each_cpu(__cpa_flush_all, (void *) cache, 1);
>> }
>> -static bool __cpa_flush_range(unsigned long start, int numpages, int
>> cache)
>> +static bool __inv_flush_all(int cache)
>> {
>> BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
>> - WARN_ON(PAGE_ALIGN(start) != start);
>> -
>> if (cache && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
>> cpa_flush_all(cache);
>> return true;
>> }
>> - flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
>> -
>> - return !cache;
>> + return false;
>> }
>> static void cpa_flush_range(unsigned long start, int numpages, int
>> cache)
>> @@ -306,7 +302,14 @@ static void cpa_flush_range(unsigned long start,
>> int numpages, int cache)
>> unsigned int i, level;
>> unsigned long addr;
>> - if (__cpa_flush_range(start, numpages, cache))
>> + WARN_ON(PAGE_ALIGN(start) != start);
>> +
>> + if (__inv_flush_all(cache))
>> + return;
>> +
>> + flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
>> +
>> + if (!cache)
>> return;
>> /*
>> @@ -332,7 +335,12 @@ static void cpa_flush_array(unsigned long baddr,
>> unsigned long *start,
>> {
>> unsigned int i, level;
>> - if (__cpa_flush_range(baddr, numpages, cache))
>> + if (__inv_flush_all(cache))
>> + return;
>> +
>> + flush_tlb_all();
>> +
>> + if (!cache)
>> return;
>> /*
>>
>
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi Peter,
Good news is that I got our opengl test running on your x86/mm branch.
The commit a2b4306c50b5de2ca955cd73ac57c2ac6426ee15 (current tip of
x86/mm) is good. For sanity I jumped back and found this commit
a2aa52ab16efbee40ad118ebac4a5e438f5b43ee doesn't work.
Thanks,
Tom
On 2018-12-03 2:26 p.m., Tom St Denis wrote:
> Hi Peter,
>
> After updating my UMDs (mesa/etc) over the weekend I cannot reproduce
> the bug to begin with. I'll try jumping directly to the intersection
> and see if I can reproduce the fault there otherwise I'll have to
> rollback my umds.
>
> Hopefully I can test this tomorrow.
>
> Tom
>
> On 2018-12-03 10:41 a.m., Peter Zijlstra wrote:
>> On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
>>> NAK I get a failure in TTM on init with your x86/mm branch (see attached
>>> dmesg).
>>
>> So the good news is that with some additional self-tests I can trivially
>> reproduce this. The bad news is that an otherwise straight forward
>> cleanup seems to make CPA horribly mad at me.
>>
>> And since we're somewhat late in the release cycle, I suppose we should
>> do the simple thing first, and then I can try and figure out this CPA
>> mess later.
>>
>> So how about this relatively simple partial revert to sort the problem.
>>
>> ---
>> Subject: x86/mm/cpa: Fix cpa_flush_array() TLB invalidation
>>
>> In commit:
>>
>> a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>>
>> I misread the cpa array code and incorrectly used
>> tlb_flush_kernel_range(), resulting in missing TLB flushes and
>> consequent failures.
>>
>> Instead do a full invalidate in this case -- for now.
>>
>> Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>> Reported-by: "StDenis, Tom"
>> Signed-off-by: Peter Zijlstra (Intel)
>> ---
>> arch/x86/mm/pageattr.c | 24
>> 1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
>> index bac35001d896..61bc7d1800d7 100644
>> --- a/arch/x86/mm/pageattr.c
>> +++ b/arch/x86/mm/pageattr.c
>> @@ -285,20 +285,16 @@ static void cpa_flush_all(unsigned long cache)
>> on_each_cpu(__cpa_flush_all, (void *) cache, 1);
>> }
>> -static bool __cpa_flush_range(unsigned long start, int numpages, int
>> cache)
>> +static bool __inv_flush_all(int cache)
>> {
>> BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
>> - WARN_ON(PAGE_ALIGN(start) != start);
>> -
>> if (cache && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
>> cpa_flush_all(cache);
>> return true;
>> }
>> - flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
>> -
>> - return !cache;
>> + return false;
>> }
>> static void cpa_flush_range(unsigned long start, int numpages, int
>> cache)
>> @@ -306,7 +302,14 @@ static void cpa_flush_range(unsigned long start,
>> int numpages, int cache)
>> unsigned int i, level;
>> unsigned long addr;
>> - if (__cpa_flush_range(start, numpages, cache))
>> + WARN_ON(PAGE_ALIGN(start) != start);
>> +
>> + if (__inv_flush_all(cache))
>> + return;
>> +
>> + flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
>> +
>> + if (!cache)
>> return;
>> /*
>> @@ -332,7 +335,12 @@ static void cpa_flush_array(unsigned long baddr,
>> unsigned long *start,
>> {
>> unsigned int i, level;
>> - if (__cpa_flush_range(baddr, numpages, cache))
>> + if (__inv_flush_all(cache))
>> + return;
>> +
>> + flush_tlb_all();
>> +
>> + if (!cache)
>> return;
>> /*
>>
>
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi Peter,
After updating my UMDs (mesa/etc) over the weekend I cannot reproduce
the bug to begin with. I'll try jumping directly to the intersection
and see if I can reproduce the fault there otherwise I'll have to
rollback my umds.
Hopefully I can test this tomorrow.
Tom
On 2018-12-03 10:41 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
>> NAK I get a failure in TTM on init with your x86/mm branch (see attached
>> dmesg).
>
> So the good news is that with some additional self-tests I can trivially
> reproduce this. The bad news is that an otherwise straight forward
> cleanup seems to make CPA horribly mad at me.
>
> And since we're somewhat late in the release cycle, I suppose we should
> do the simple thing first, and then I can try and figure out this CPA
> mess later.
>
> So how about this relatively simple partial revert to sort the problem.
>
> ---
> Subject: x86/mm/cpa: Fix cpa_flush_array() TLB invalidation
>
> In commit:
>
>a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>
> I misread the cpa array code and incorrectly used
> tlb_flush_kernel_range(), resulting in missing TLB flushes and
> consequent failures.
>
> Instead do a full invalidate in this case -- for now.
>
> Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
> Reported-by: "StDenis, Tom"
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/mm/pageattr.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index bac35001d896..61bc7d1800d7 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -285,20 +285,16 @@ static void cpa_flush_all(unsigned long cache)
> on_each_cpu(__cpa_flush_all, (void *) cache, 1);
> }
>
> -static bool __cpa_flush_range(unsigned long start, int numpages, int cache)
> +static bool __inv_flush_all(int cache)
> {
> BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
>
> - WARN_ON(PAGE_ALIGN(start) != start);
> -
> if (cache && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
> cpa_flush_all(cache);
> return true;
> }
>
> - flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
> -
> - return !cache;
> + return false;
> }
>
> static void cpa_flush_range(unsigned long start, int numpages, int cache)
> @@ -306,7 +302,14 @@ static void cpa_flush_range(unsigned long start, int
> numpages, int cache)
> unsigned int i, level;
> unsigned long addr;
>
> - if (__cpa_flush_range(start, numpages, cache))
> + WARN_ON(PAGE_ALIGN(start) != start);
> +
> + if (__inv_flush_all(cache))
> + return;
> +
> + flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
> +
> + if (!cache)
> return;
>
> /*
> @@ -332,7 +335,12 @@ static void cpa_flush_array(unsigned long baddr,
> unsigned long *start,
> {
> unsigned int i, level;
>
> - if (__cpa_flush_range(baddr, numpages, cache))
> + if (__inv_flush_all(cache))
> + return;
> +
> + flush_tlb_all();
> +
> + if (!cache)
> return;
>
> /*
>
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi Peter,
After updating my UMDs (mesa/etc) over the weekend I cannot reproduce
the bug to begin with. I'll try jumping directly to the intersection
and see if I can reproduce the fault there otherwise I'll have to
rollback my umds.
Hopefully I can test this tomorrow.
Tom
On 2018-12-03 10:41 a.m., Peter Zijlstra wrote:
> On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
>> NAK I get a failure in TTM on init with your x86/mm branch (see attached
>> dmesg).
>
> So the good news is that with some additional self-tests I can trivially
> reproduce this. The bad news is that an otherwise straight forward
> cleanup seems to make CPA horribly mad at me.
>
> And since we're somewhat late in the release cycle, I suppose we should
> do the simple thing first, and then I can try and figure out this CPA
> mess later.
>
> So how about this relatively simple partial revert to sort the problem.
>
> ---
> Subject: x86/mm/cpa: Fix cpa_flush_array() TLB invalidation
>
> In commit:
>
>a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>
> I misread the cpa array code and incorrectly used
> tlb_flush_kernel_range(), resulting in missing TLB flushes and
> consequent failures.
>
> Instead do a full invalidate in this case -- for now.
>
> Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
> Reported-by: "StDenis, Tom"
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/mm/pageattr.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index bac35001d896..61bc7d1800d7 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -285,20 +285,16 @@ static void cpa_flush_all(unsigned long cache)
> on_each_cpu(__cpa_flush_all, (void *) cache, 1);
> }
>
> -static bool __cpa_flush_range(unsigned long start, int numpages, int cache)
> +static bool __inv_flush_all(int cache)
> {
> BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
>
> - WARN_ON(PAGE_ALIGN(start) != start);
> -
> if (cache && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
> cpa_flush_all(cache);
> return true;
> }
>
> - flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
> -
> - return !cache;
> + return false;
> }
>
> static void cpa_flush_range(unsigned long start, int numpages, int cache)
> @@ -306,7 +302,14 @@ static void cpa_flush_range(unsigned long start, int
> numpages, int cache)
> unsigned int i, level;
> unsigned long addr;
>
> - if (__cpa_flush_range(start, numpages, cache))
> + WARN_ON(PAGE_ALIGN(start) != start);
> +
> + if (__inv_flush_all(cache))
> + return;
> +
> + flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
> +
> + if (!cache)
> return;
>
> /*
> @@ -332,7 +335,12 @@ static void cpa_flush_array(unsigned long baddr,
> unsigned long *start,
> {
> unsigned int i, level;
>
> - if (__cpa_flush_range(baddr, numpages, cache))
> + if (__inv_flush_all(cache))
> + return;
> +
> + flush_tlb_all();
> +
> + if (!cache)
> return;
>
> /*
>
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
> NAK I get a failure in TTM on init with your x86/mm branch (see attached
> dmesg).
So the good news is that with some additional self-tests I can trivially
reproduce this. The bad news is that an otherwise straight forward
cleanup seems to make CPA horribly mad at me.
And since we're somewhat late in the release cycle, I suppose we should
do the simple thing first, and then I can try and figure out this CPA
mess later.
So how about this relatively simple partial revert to sort the problem.
---
Subject: x86/mm/cpa: Fix cpa_flush_array() TLB invalidation
In commit:
a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
I misread the cpa array code and incorrectly used
tlb_flush_kernel_range(), resulting in missing TLB flushes and
consequent failures.
Instead do a full invalidate in this case -- for now.
Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
Reported-by: "StDenis, Tom"
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/mm/pageattr.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index bac35001d896..61bc7d1800d7 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -285,20 +285,16 @@ static void cpa_flush_all(unsigned long cache)
on_each_cpu(__cpa_flush_all, (void *) cache, 1);
}
-static bool __cpa_flush_range(unsigned long start, int numpages, int cache)
+static bool __inv_flush_all(int cache)
{
BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
- WARN_ON(PAGE_ALIGN(start) != start);
-
if (cache && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
cpa_flush_all(cache);
return true;
}
- flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
-
- return !cache;
+ return false;
}
static void cpa_flush_range(unsigned long start, int numpages, int cache)
@@ -306,7 +302,14 @@ static void cpa_flush_range(unsigned long start, int
numpages, int cache)
unsigned int i, level;
unsigned long addr;
- if (__cpa_flush_range(start, numpages, cache))
+ WARN_ON(PAGE_ALIGN(start) != start);
+
+ if (__inv_flush_all(cache))
+ return;
+
+ flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
+
+ if (!cache)
return;
/*
@@ -332,7 +335,12 @@ static void cpa_flush_array(unsigned long baddr, unsigned
long *start,
{
unsigned int i, level;
- if (__cpa_flush_range(baddr, numpages, cache))
+ if (__inv_flush_all(cache))
+ return;
+
+ flush_tlb_all();
+
+ if (!cache)
return;
/*
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
> NAK I get a failure in TTM on init with your x86/mm branch (see attached
> dmesg).
So the good news is that with some additional self-tests I can trivially
reproduce this. The bad news is that an otherwise straight forward
cleanup seems to make CPA horribly mad at me.
And since we're somewhat late in the release cycle, I suppose we should
do the simple thing first, and then I can try and figure out this CPA
mess later.
So how about this relatively simple partial revert to sort the problem.
---
Subject: x86/mm/cpa: Fix cpa_flush_array() TLB invalidation
In commit:
a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
I misread the cpa array code and incorrectly used
tlb_flush_kernel_range(), resulting in missing TLB flushes and
consequent failures.
Instead do a full invalidate in this case -- for now.
Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
Reported-by: "StDenis, Tom"
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/mm/pageattr.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index bac35001d896..61bc7d1800d7 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -285,20 +285,16 @@ static void cpa_flush_all(unsigned long cache)
on_each_cpu(__cpa_flush_all, (void *) cache, 1);
}
-static bool __cpa_flush_range(unsigned long start, int numpages, int cache)
+static bool __inv_flush_all(int cache)
{
BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
- WARN_ON(PAGE_ALIGN(start) != start);
-
if (cache && !static_cpu_has(X86_FEATURE_CLFLUSH)) {
cpa_flush_all(cache);
return true;
}
- flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
-
- return !cache;
+ return false;
}
static void cpa_flush_range(unsigned long start, int numpages, int cache)
@@ -306,7 +302,14 @@ static void cpa_flush_range(unsigned long start, int
numpages, int cache)
unsigned int i, level;
unsigned long addr;
- if (__cpa_flush_range(start, numpages, cache))
+ WARN_ON(PAGE_ALIGN(start) != start);
+
+ if (__inv_flush_all(cache))
+ return;
+
+ flush_tlb_kernel_range(start, start + PAGE_SIZE * numpages);
+
+ if (!cache)
return;
/*
@@ -332,7 +335,12 @@ static void cpa_flush_array(unsigned long baddr, unsigned
long *start,
{
unsigned int i, level;
- if (__cpa_flush_range(baddr, numpages, cache))
+ if (__inv_flush_all(cache))
+ return;
+
+ flush_tlb_all();
+
+ if (!cache)
return;
/*
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 05:49:34PM +, StDenis, Tom wrote: > On 2018-11-30 12:48 p.m., Peter Zijlstra wrote: > > On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: > >> On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > > > >>> I pushed them out to: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm > >>> > >>> I hope that works; I'm out for a few hours, but should check on email > >>> again tonight. > >>> > >> > >> NAK I get a failure in TTM on init with your x86/mm branch (see attached > >> dmesg). > > > > *sigh*, it's been one of those days. Ok, I'll go write some cpa > > selftests or something so that I have code that uses this stuff. > > > > Well the ttm crash could be completely unrelated the problem is your > x86/mm branch is not up to date with master and doesn't include drm fixes. Well, it crashes right in the middle of the CPA code, and I'm having a horrible day, so I'm thinking I screwed up rather than anything else. Also, some level of selftests would be good to have in any case I figure.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 05:49:34PM +, StDenis, Tom wrote: > On 2018-11-30 12:48 p.m., Peter Zijlstra wrote: > > On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: > >> On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > > > >>> I pushed them out to: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm > >>> > >>> I hope that works; I'm out for a few hours, but should check on email > >>> again tonight. > >>> > >> > >> NAK I get a failure in TTM on init with your x86/mm branch (see attached > >> dmesg). > > > > *sigh*, it's been one of those days. Ok, I'll go write some cpa > > selftests or something so that I have code that uses this stuff. > > > > Well the ttm crash could be completely unrelated the problem is your > x86/mm branch is not up to date with master and doesn't include drm fixes. Well, it crashes right in the middle of the CPA code, and I'm having a horrible day, so I'm thinking I screwed up rather than anything else. Also, some level of selftests would be good to have in any case I figure.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 03:27:02PM +, StDenis, Tom wrote: > I can apply the patch you attached but the inline patches just don't > apply. Could be my imap client (thunderbird) mangled them but I've > applied patches this way before. could you attach them instead please? That's arguably a bug in Thunderbird; but there's already upstream quilt changes (that I used to have before Debian helpfully updated my quilt package) that should remedy this as well. It seems some MUA's get horribly confused about the "Content-Disposition: inline; filename=$patch" header quilt-mail adds. I've once again removed that from my local copy; hopefully the next time Debian updates that package it will actually be with a new enough version to also include those changes :/
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 03:27:02PM +, StDenis, Tom wrote: > I can apply the patch you attached but the inline patches just don't > apply. Could be my imap client (thunderbird) mangled them but I've > applied patches this way before. could you attach them instead please? That's arguably a bug in Thunderbird; but there's already upstream quilt changes (that I used to have before Debian helpfully updated my quilt package) that should remedy this as well. It seems some MUA's get horribly confused about the "Content-Disposition: inline; filename=$patch" header quilt-mail adds. I've once again removed that from my local copy; hopefully the next time Debian updates that package it will actually be with a new enough version to also include those changes :/
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 12:48 p.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: >> On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > >>> I pushed them out to: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm >>> >>> I hope that works; I'm out for a few hours, but should check on email >>> again tonight. >>> >> >> NAK I get a failure in TTM on init with your x86/mm branch (see attached >> dmesg). > > *sigh*, it's been one of those days. Ok, I'll go write some cpa > selftests or something so that I have code that uses this stuff. > Well the ttm crash could be completely unrelated the problem is your x86/mm branch is not up to date with master and doesn't include drm fixes. Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 12:48 p.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: >> On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > >>> I pushed them out to: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm >>> >>> I hope that works; I'm out for a few hours, but should check on email >>> again tonight. >>> >> >> NAK I get a failure in TTM on init with your x86/mm branch (see attached >> dmesg). > > *sigh*, it's been one of those days. Ok, I'll go write some cpa > selftests or something so that I have code that uses this stuff. > Well the ttm crash could be completely unrelated the problem is your x86/mm branch is not up to date with master and doesn't include drm fixes. Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: > On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > > I pushed them out to: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm > > > > I hope that works; I'm out for a few hours, but should check on email > > again tonight. > > > > NAK I get a failure in TTM on init with your x86/mm branch (see attached > dmesg). *sigh*, it's been one of those days. Ok, I'll go write some cpa selftests or something so that I have code that uses this stuff.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: > On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > > I pushed them out to: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm > > > > I hope that works; I'm out for a few hours, but should check on email > > again tonight. > > > > NAK I get a failure in TTM on init with your x86/mm branch (see attached > dmesg). *sigh*, it's been one of those days. Ok, I'll go write some cpa selftests or something so that I have code that uses this stuff.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 04:23:47PM +0100, Peter Zijlstra wrote: > >> Hurm.. no. They apply cleanly to Linus' tree here. >> >> linux-2.6$ git describe >> v4.20-rc4-156-g94f371cb7394 >> linux-2.6$ quilt push 4 >> Applying patch patches/peterz-cpa-addr.patch >> patching file arch/x86/mm/pageattr.c >> Applying patch patches/peterz-cpa-fix-flush_array.patch >> patching file arch/x86/mm/mm_internal.h >> patching file arch/x86/mm/pageattr.c >> patching file arch/x86/mm/tlb.c >> Applying patch patches/peterz-cpa-fold-cpa_flush.patch >> patching file arch/x86/mm/pageattr.c >> Applying patch patches/peterz-cpa-clflush_opt.patch >> patching file arch/x86/mm/pageattr.c >> Now at patch patches/peterz-cpa-clflush_opt.patch >> >> Weird. > > I pushed them out to: > >git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm > > I hope that works; I'm out for a few hours, but should check on email > again tonight. > NAK I get a failure in TTM on init with your x86/mm branch (see attached dmesg). This builds an RC2 kernel btw whereas we were building an RC3 kernel which is about 974 commits behind the tip of our drm-next and about 850 commits behind the last drm-next merge from Dave. Tom [0.00] Linux version 4.20.0-rc2+ (root@carrizo) (gcc version 8.2.1 20181105 (Red Hat 8.2.1-5) (GCC)) #1 SMP Fri Nov 30 10:44:38 EST 2018 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.20.0-rc2+ root=UUID=d7f3aad3-6017-4563-9cec-9b3c99467214 ro rhgb quiet LANG=en_CA.UTF-8 rdblacklist=amdgpu,radeon [0.00] [Firmware Info]: CPU: Re-enabling disabled Topology Extensions Support. [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xd46cefff] usable [0.00] BIOS-e820: [mem 0xd46cf000-0xd46e8fff] ACPI data [0.00] BIOS-e820: [mem 0xd46e9000-0xda5c0fff] usable [0.00] BIOS-e820: [mem 0xda5c1000-0xda6fcfff] reserved [0.00] BIOS-e820: [mem 0xda6fd000-0xda712fff] ACPI data [0.00] BIOS-e820: [mem 0xda713000-0xda80bfff] usable [0.00] BIOS-e820: [mem 0xda80c000-0xdabbdfff] ACPI NVS [0.00] BIOS-e820: [mem 0xdabbe000-0xdb53] reserved [0.00] BIOS-e820: [mem 0xdb54-0xddff] usable [0.00] BIOS-e820: [mem 0xde00-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfe50-0xfe5f] reserved [0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved [0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfedc-0xfedc0fff] reserved [0.00] BIOS-e820: [mem 0xfedc2000-0xfedc8fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001feff] usable [0.00] BIOS-e820: [mem 0x0001ff00-0x00021eff] reserved [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x9f205018-0x9f214e57] usable ==> usable [0.00] e820: update [mem 0x9f205018-0x9f214e57] usable ==> usable [0.00] e820: update [mem 0x9f1f6018-0x9f204057] usable ==> usable [0.00] e820: update [mem 0x9f1f6018-0x9f204057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0009] usable [0.00] reserve setup_data: [mem 0x000a-0x000f] reserved [0.00] reserve setup_data: [mem 0x0010-0x9f1f6017] usable [0.00] reserve setup_data: [mem 0x9f1f6018-0x9f204057] usable [0.00]
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 04:23:47PM +0100, Peter Zijlstra wrote: > >> Hurm.. no. They apply cleanly to Linus' tree here. >> >> linux-2.6$ git describe >> v4.20-rc4-156-g94f371cb7394 >> linux-2.6$ quilt push 4 >> Applying patch patches/peterz-cpa-addr.patch >> patching file arch/x86/mm/pageattr.c >> Applying patch patches/peterz-cpa-fix-flush_array.patch >> patching file arch/x86/mm/mm_internal.h >> patching file arch/x86/mm/pageattr.c >> patching file arch/x86/mm/tlb.c >> Applying patch patches/peterz-cpa-fold-cpa_flush.patch >> patching file arch/x86/mm/pageattr.c >> Applying patch patches/peterz-cpa-clflush_opt.patch >> patching file arch/x86/mm/pageattr.c >> Now at patch patches/peterz-cpa-clflush_opt.patch >> >> Weird. > > I pushed them out to: > >git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm > > I hope that works; I'm out for a few hours, but should check on email > again tonight. > NAK I get a failure in TTM on init with your x86/mm branch (see attached dmesg). This builds an RC2 kernel btw whereas we were building an RC3 kernel which is about 974 commits behind the tip of our drm-next and about 850 commits behind the last drm-next merge from Dave. Tom [0.00] Linux version 4.20.0-rc2+ (root@carrizo) (gcc version 8.2.1 20181105 (Red Hat 8.2.1-5) (GCC)) #1 SMP Fri Nov 30 10:44:38 EST 2018 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.20.0-rc2+ root=UUID=d7f3aad3-6017-4563-9cec-9b3c99467214 ro rhgb quiet LANG=en_CA.UTF-8 rdblacklist=amdgpu,radeon [0.00] [Firmware Info]: CPU: Re-enabling disabled Topology Extensions Support. [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x000a-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xd46cefff] usable [0.00] BIOS-e820: [mem 0xd46cf000-0xd46e8fff] ACPI data [0.00] BIOS-e820: [mem 0xd46e9000-0xda5c0fff] usable [0.00] BIOS-e820: [mem 0xda5c1000-0xda6fcfff] reserved [0.00] BIOS-e820: [mem 0xda6fd000-0xda712fff] ACPI data [0.00] BIOS-e820: [mem 0xda713000-0xda80bfff] usable [0.00] BIOS-e820: [mem 0xda80c000-0xdabbdfff] ACPI NVS [0.00] BIOS-e820: [mem 0xdabbe000-0xdb53] reserved [0.00] BIOS-e820: [mem 0xdb54-0xddff] usable [0.00] BIOS-e820: [mem 0xde00-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfe50-0xfe5f] reserved [0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved [0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfedc-0xfedc0fff] reserved [0.00] BIOS-e820: [mem 0xfedc2000-0xfedc8fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001feff] usable [0.00] BIOS-e820: [mem 0x0001ff00-0x00021eff] reserved [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x9f205018-0x9f214e57] usable ==> usable [0.00] e820: update [mem 0x9f205018-0x9f214e57] usable ==> usable [0.00] e820: update [mem 0x9f1f6018-0x9f204057] usable ==> usable [0.00] e820: update [mem 0x9f1f6018-0x9f204057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0009] usable [0.00] reserve setup_data: [mem 0x000a-0x000f] reserved [0.00] reserve setup_data: [mem 0x0010-0x9f1f6017] usable [0.00] reserve setup_data: [mem 0x9f1f6018-0x9f204057] usable [0.00]
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 04:23:47PM +0100, Peter Zijlstra wrote: > Hurm.. no. They apply cleanly to Linus' tree here. > > linux-2.6$ git describe > v4.20-rc4-156-g94f371cb7394 > linux-2.6$ quilt push 4 > Applying patch patches/peterz-cpa-addr.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-fix-flush_array.patch > patching file arch/x86/mm/mm_internal.h > patching file arch/x86/mm/pageattr.c > patching file arch/x86/mm/tlb.c > Applying patch patches/peterz-cpa-fold-cpa_flush.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-clflush_opt.patch > patching file arch/x86/mm/pageattr.c > Now at patch patches/peterz-cpa-clflush_opt.patch > > Weird. I pushed them out to: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm I hope that works; I'm out for a few hours, but should check on email again tonight.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 04:23:47PM +0100, Peter Zijlstra wrote: > Hurm.. no. They apply cleanly to Linus' tree here. > > linux-2.6$ git describe > v4.20-rc4-156-g94f371cb7394 > linux-2.6$ quilt push 4 > Applying patch patches/peterz-cpa-addr.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-fix-flush_array.patch > patching file arch/x86/mm/mm_internal.h > patching file arch/x86/mm/pageattr.c > patching file arch/x86/mm/tlb.c > Applying patch patches/peterz-cpa-fold-cpa_flush.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-clflush_opt.patch > patching file arch/x86/mm/pageattr.c > Now at patch patches/peterz-cpa-clflush_opt.patch > > Weird. I pushed them out to: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm I hope that works; I'm out for a few hours, but should check on email again tonight.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:23 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote: >> On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: >>> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: Hi Peter, Unfortunately I can't apply this on top of our drm-next the first patch fails. >>> >>> Against what tree would you like the patches? rebasing should not be >>> hard I think. >>> >> >> Actually I just tried applying against the tip of master and got the >> same errors... >> >> [root@carrizo linux]# git apply \[PATCH\ 1_4\]\ x86_mm_cpa\:\ Add\ >> __cpa_addr\(\)\ helper\ -\ Peter\ Zijlstra\ \\ -\ >> 2018-11-30\ 0844.eml >> error: patch failed: arch/x86/mm/pageattr.c:228 >> error: arch/x86/mm/pageattr.c: patch does not apply >> >> >> Any ideas? > > Hurm.. no. They apply cleanly to Linus' tree here. > > linux-2.6$ git describe > v4.20-rc4-156-g94f371cb7394 > linux-2.6$ quilt push 4 > Applying patch patches/peterz-cpa-addr.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-fix-flush_array.patch > patching file arch/x86/mm/mm_internal.h > patching file arch/x86/mm/pageattr.c > patching file arch/x86/mm/tlb.c > Applying patch patches/peterz-cpa-fold-cpa_flush.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-clflush_opt.patch > patching file arch/x86/mm/pageattr.c > Now at patch patches/peterz-cpa-clflush_opt.patch > > Weird. > I can apply the patch you attached but the inline patches just don't apply. Could be my imap client (thunderbird) mangled them but I've applied patches this way before. could you attach them instead please? Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:23 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote: >> On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: >>> On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: Hi Peter, Unfortunately I can't apply this on top of our drm-next the first patch fails. >>> >>> Against what tree would you like the patches? rebasing should not be >>> hard I think. >>> >> >> Actually I just tried applying against the tip of master and got the >> same errors... >> >> [root@carrizo linux]# git apply \[PATCH\ 1_4\]\ x86_mm_cpa\:\ Add\ >> __cpa_addr\(\)\ helper\ -\ Peter\ Zijlstra\ \\ -\ >> 2018-11-30\ 0844.eml >> error: patch failed: arch/x86/mm/pageattr.c:228 >> error: arch/x86/mm/pageattr.c: patch does not apply >> >> >> Any ideas? > > Hurm.. no. They apply cleanly to Linus' tree here. > > linux-2.6$ git describe > v4.20-rc4-156-g94f371cb7394 > linux-2.6$ quilt push 4 > Applying patch patches/peterz-cpa-addr.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-fix-flush_array.patch > patching file arch/x86/mm/mm_internal.h > patching file arch/x86/mm/pageattr.c > patching file arch/x86/mm/tlb.c > Applying patch patches/peterz-cpa-fold-cpa_flush.patch > patching file arch/x86/mm/pageattr.c > Applying patch patches/peterz-cpa-clflush_opt.patch > patching file arch/x86/mm/pageattr.c > Now at patch patches/peterz-cpa-clflush_opt.patch > > Weird. > I can apply the patch you attached but the inline patches just don't apply. Could be my imap client (thunderbird) mangled them but I've applied patches this way before. could you attach them instead please? Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote: > On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: > > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: > >> Hi Peter, > >> > >> Unfortunately I can't apply this on top of our drm-next the first patch > >> fails. > > > > Against what tree would you like the patches? rebasing should not be > > hard I think. > > > > Actually I just tried applying against the tip of master and got the > same errors... > > [root@carrizo linux]# git apply \[PATCH\ 1_4\]\ x86_mm_cpa\:\ Add\ > __cpa_addr\(\)\ helper\ -\ Peter\ Zijlstra\ \\ -\ > 2018-11-30\ 0844.eml > error: patch failed: arch/x86/mm/pageattr.c:228 > error: arch/x86/mm/pageattr.c: patch does not apply > > > Any ideas? Hurm.. no. They apply cleanly to Linus' tree here. linux-2.6$ git describe v4.20-rc4-156-g94f371cb7394 linux-2.6$ quilt push 4 Applying patch patches/peterz-cpa-addr.patch patching file arch/x86/mm/pageattr.c Applying patch patches/peterz-cpa-fix-flush_array.patch patching file arch/x86/mm/mm_internal.h patching file arch/x86/mm/pageattr.c patching file arch/x86/mm/tlb.c Applying patch patches/peterz-cpa-fold-cpa_flush.patch patching file arch/x86/mm/pageattr.c Applying patch patches/peterz-cpa-clflush_opt.patch patching file arch/x86/mm/pageattr.c Now at patch patches/peterz-cpa-clflush_opt.patch Weird.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote: > On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: > > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: > >> Hi Peter, > >> > >> Unfortunately I can't apply this on top of our drm-next the first patch > >> fails. > > > > Against what tree would you like the patches? rebasing should not be > > hard I think. > > > > Actually I just tried applying against the tip of master and got the > same errors... > > [root@carrizo linux]# git apply \[PATCH\ 1_4\]\ x86_mm_cpa\:\ Add\ > __cpa_addr\(\)\ helper\ -\ Peter\ Zijlstra\ \\ -\ > 2018-11-30\ 0844.eml > error: patch failed: arch/x86/mm/pageattr.c:228 > error: arch/x86/mm/pageattr.c: patch does not apply > > > Any ideas? Hurm.. no. They apply cleanly to Linus' tree here. linux-2.6$ git describe v4.20-rc4-156-g94f371cb7394 linux-2.6$ quilt push 4 Applying patch patches/peterz-cpa-addr.patch patching file arch/x86/mm/pageattr.c Applying patch patches/peterz-cpa-fix-flush_array.patch patching file arch/x86/mm/mm_internal.h patching file arch/x86/mm/pageattr.c patching file arch/x86/mm/tlb.c Applying patch patches/peterz-cpa-fold-cpa_flush.patch patching file arch/x86/mm/pageattr.c Applying patch patches/peterz-cpa-clflush_opt.patch patching file arch/x86/mm/pageattr.c Now at patch patches/peterz-cpa-clflush_opt.patch Weird.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: >> Hi Peter, >> >> Unfortunately I can't apply this on top of our drm-next the first patch >> fails. > > Against what tree would you like the patches? rebasing should not be > hard I think. > Actually I just tried applying against the tip of master and got the same errors... [root@carrizo linux]# git apply \[PATCH\ 1_4\]\ x86_mm_cpa\:\ Add\ __cpa_addr\(\)\ helper\ -\ Peter\ Zijlstra\ \\ -\ 2018-11-30\ 0844.eml error: patch failed: arch/x86/mm/pageattr.c:228 error: arch/x86/mm/pageattr.c: patch does not apply Any ideas? Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: >> Hi Peter, >> >> Unfortunately I can't apply this on top of our drm-next the first patch >> fails. > > Against what tree would you like the patches? rebasing should not be > hard I think. > Actually I just tried applying against the tip of master and got the same errors... [root@carrizo linux]# git apply \[PATCH\ 1_4\]\ x86_mm_cpa\:\ Add\ __cpa_addr\(\)\ helper\ -\ Peter\ Zijlstra\ \\ -\ 2018-11-30\ 0844.eml error: patch failed: arch/x86/mm/pageattr.c:228 error: arch/x86/mm/pageattr.c: patch does not apply Any ideas? Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: >> Hi Peter, >> >> Unfortunately I can't apply this on top of our drm-next the first patch >> fails. > > Against what tree would you like the patches? rebasing should not be > hard I think. > Actually never mind the AMDGPU patches I need are actually upstream I was mistaken :-) I'll try it out shortly. Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: >> Hi Peter, >> >> Unfortunately I can't apply this on top of our drm-next the first patch >> fails. > > Against what tree would you like the patches? rebasing should not be > hard I think. > Actually never mind the AMDGPU patches I need are actually upstream I was mistaken :-) I'll try it out shortly. Tom
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: > Hi Peter, > > Unfortunately I can't apply this on top of our drm-next the first patch > fails. Against what tree would you like the patches? rebasing should not be hard I think.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: > Hi Peter, > > Unfortunately I can't apply this on top of our drm-next the first patch > fails. Against what tree would you like the patches? rebasing should not be hard I think.
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:07 a.m., Deucher, Alexander wrote:
> Sure, but it might be week or so. For now can you test against Linus
> master? It should be close enough.
I need the bulk move from the our drm-next merge (which isn't yet
upstream) to trigger the bug though.
I can try to cherry pick it on top of master.
Tom
>
>
> Alex
>
>
> *From:* StDenis, Tom
> *Sent:* Friday, November 30, 2018 9:52:26 AM
> *To:* Peter Zijlstra; dave.han...@intel.com; l...@kernel.org
> *Cc:* x...@kernel.org; linux-kernel@vger.kernel.org; Deucher, Alexander
> *Subject:* Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
> Hi Peter,
>
> Unfortunately I can't apply this on top of our drm-next the first patch
> fails.
>
> Alex: could we rebase again at some point?
>
> Tom
>
> On 2018-11-30 8:44 a.m., Peter Zijlstra wrote:
>> Hi,
>>
>> Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
>>
>> It turns out that with commit:
>>
>> a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>>
>> I misread the cpa array code and messed up the TLB invalidations for it.
>> These
>> patches (hopefully) fix the issue while also shrinking the CPA code again.
>>
>> Tom, would you be so kind as to test again? These patches are significantly
>> different from what I send you yesterday.
>>
>> ---
>> arch/x86/mm/mm_internal.h | 2 +
>> arch/x86/mm/pageattr.c | 167
>> --
>> arch/x86/mm/tlb.c | 4 +-
>> 3 files changed, 79 insertions(+), 94 deletions(-)
>>
>
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
On 2018-11-30 10:07 a.m., Deucher, Alexander wrote:
> Sure, but it might be week or so. For now can you test against Linus
> master? It should be close enough.
I need the bulk move from the our drm-next merge (which isn't yet
upstream) to trigger the bug though.
I can try to cherry pick it on top of master.
Tom
>
>
> Alex
>
>
> *From:* StDenis, Tom
> *Sent:* Friday, November 30, 2018 9:52:26 AM
> *To:* Peter Zijlstra; dave.han...@intel.com; l...@kernel.org
> *Cc:* x...@kernel.org; linux-kernel@vger.kernel.org; Deucher, Alexander
> *Subject:* Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
> Hi Peter,
>
> Unfortunately I can't apply this on top of our drm-next the first patch
> fails.
>
> Alex: could we rebase again at some point?
>
> Tom
>
> On 2018-11-30 8:44 a.m., Peter Zijlstra wrote:
>> Hi,
>>
>> Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
>>
>> It turns out that with commit:
>>
>> a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>>
>> I misread the cpa array code and messed up the TLB invalidations for it.
>> These
>> patches (hopefully) fix the issue while also shrinking the CPA code again.
>>
>> Tom, would you be so kind as to test again? These patches are significantly
>> different from what I send you yesterday.
>>
>> ---
>> arch/x86/mm/mm_internal.h | 2 +
>> arch/x86/mm/pageattr.c | 167
>> --
>> arch/x86/mm/tlb.c | 4 +-
>> 3 files changed, 79 insertions(+), 94 deletions(-)
>>
>
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi Peter,
Unfortunately I can't apply this on top of our drm-next the first patch
fails.
Alex: could we rebase again at some point?
Tom
On 2018-11-30 8:44 a.m., Peter Zijlstra wrote:
> Hi,
>
> Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
>
> It turns out that with commit:
>
>a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>
> I misread the cpa array code and messed up the TLB invalidations for it. These
> patches (hopefully) fix the issue while also shrinking the CPA code again.
>
> Tom, would you be so kind as to test again? These patches are significantly
> different from what I send you yesterday.
>
> ---
> arch/x86/mm/mm_internal.h | 2 +
> arch/x86/mm/pageattr.c| 167 --
> arch/x86/mm/tlb.c | 4 +-
> 3 files changed, 79 insertions(+), 94 deletions(-)
>
Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi Peter,
Unfortunately I can't apply this on top of our drm-next the first patch
fails.
Alex: could we rebase again at some point?
Tom
On 2018-11-30 8:44 a.m., Peter Zijlstra wrote:
> Hi,
>
> Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
>
> It turns out that with commit:
>
>a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
>
> I misread the cpa array code and messed up the TLB invalidations for it. These
> patches (hopefully) fix the issue while also shrinking the CPA code again.
>
> Tom, would you be so kind as to test again? These patches are significantly
> different from what I send you yesterday.
>
> ---
> arch/x86/mm/mm_internal.h | 2 +
> arch/x86/mm/pageattr.c| 167 --
> arch/x86/mm/tlb.c | 4 +-
> 3 files changed, 79 insertions(+), 94 deletions(-)
>
[PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi,
Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
It turns out that with commit:
a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
I misread the cpa array code and messed up the TLB invalidations for it. These
patches (hopefully) fix the issue while also shrinking the CPA code again.
Tom, would you be so kind as to test again? These patches are significantly
different from what I send you yesterday.
---
arch/x86/mm/mm_internal.h | 2 +
arch/x86/mm/pageattr.c| 167 --
arch/x86/mm/tlb.c | 4 +-
3 files changed, 79 insertions(+), 94 deletions(-)
[PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation
Hi,
Yesterday Tom reported a CPA bug triggered by the AMDGPU team.
It turns out that with commit:
a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()")
I misread the cpa array code and messed up the TLB invalidations for it. These
patches (hopefully) fix the issue while also shrinking the CPA code again.
Tom, would you be so kind as to test again? These patches are significantly
different from what I send you yesterday.
---
arch/x86/mm/mm_internal.h | 2 +
arch/x86/mm/pageattr.c| 167 --
arch/x86/mm/tlb.c | 4 +-
3 files changed, 79 insertions(+), 94 deletions(-)
