On Sat, May 05, 2018 at 11:47:53AM +0200, Jörg Otte wrote:
> Patch doesn't hurt me. For me it´s ok.
>
> Thanks, Jörg
Good, thanks for testing!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Sat, May 05, 2018 at 11:47:53AM +0200, Jörg Otte wrote:
> Patch doesn't hurt me. For me it´s ok.
>
> Thanks, Jörg
Good, thanks for testing!
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
2018-05-04 18:18 GMT+02:00 Borislav Petkov :
> On Wed, May 02, 2018 at 02:20:52PM +0200, Thomas Gleixner wrote:
>> Thanks for confirming. Still need to find a way which is less fragile, but
>> that's probably too much of churn for rc4
>>
>> At least I know exactly what's
2018-05-04 18:18 GMT+02:00 Borislav Petkov :
> On Wed, May 02, 2018 at 02:20:52PM +0200, Thomas Gleixner wrote:
>> Thanks for confirming. Still need to find a way which is less fragile, but
>> that's probably too much of churn for rc4
>>
>> At least I know exactly what's happening, so I can
On Wed, May 02, 2018 at 02:20:52PM +0200, Thomas Gleixner wrote:
> Thanks for confirming. Still need to find a way which is less fragile, but
> that's probably too much of churn for rc4
>
> At least I know exactly what's happening, so I can write a better changelog.
>
> Thanks for testing!
On Wed, May 02, 2018 at 02:20:52PM +0200, Thomas Gleixner wrote:
> Thanks for confirming. Still need to find a way which is less fragile, but
> that's probably too much of churn for rc4
>
> At least I know exactly what's happening, so I can write a better changelog.
>
> Thanks for testing!
On Wed, 2 May 2018, Jörg Otte wrote:
> 2018-05-02 11:02 GMT+02:00 Thomas Gleixner :
> > Ok, I think I know what's going wrong in that steaming pile of horrors of
> > CPUID detection. I need to analyze it down to the roots, but if you have
> > cycles, can you please test the
On Wed, 2 May 2018, Jörg Otte wrote:
> 2018-05-02 11:02 GMT+02:00 Thomas Gleixner :
> > Ok, I think I know what's going wrong in that steaming pile of horrors of
> > CPUID detection. I need to analyze it down to the roots, but if you have
> > cycles, can you please test the patch below?
> >
> >
2018-05-02 11:02 GMT+02:00 Thomas Gleixner :
> On Wed, 2 May 2018, Jörg Otte wrote:
>> With revert:
>>
>> jojo@fichte:~$ dmesg | grep -i -e spec -e micro -e "Linux version"
>>
>> [0.00] microcode: microcode updated early to revision 0x24,
>> date = 2018-01-21
>> [
2018-05-02 11:02 GMT+02:00 Thomas Gleixner :
> On Wed, 2 May 2018, Jörg Otte wrote:
>> With revert:
>>
>> jojo@fichte:~$ dmesg | grep -i -e spec -e micro -e "Linux version"
>>
>> [0.00] microcode: microcode updated early to revision 0x24,
>> date = 2018-01-21
>> [0.00] Linux
On Wed, 2 May 2018, Jörg Otte wrote:
> With revert:
>
> jojo@fichte:~$ dmesg | grep -i -e spec -e micro -e "Linux version"
>
> [0.00] microcode: microcode updated early to revision 0x24,
> date = 2018-01-21
> [0.00] Linux version 4.17.0-rc3-revert-1-gcb1069f
> (jojo@fichte)
On Wed, 2 May 2018, Jörg Otte wrote:
> With revert:
>
> jojo@fichte:~$ dmesg | grep -i -e spec -e micro -e "Linux version"
>
> [0.00] microcode: microcode updated early to revision 0x24,
> date = 2018-01-21
> [0.00] Linux version 4.17.0-rc3-revert-1-gcb1069f
> (jojo@fichte)
2018-05-01 22:14 GMT+02:00 Linus Torvalds :
> On Tue, May 1, 2018 at 5:59 AM Thomas Gleixner wrote:
>
>> Then I really have no idea how reverting the patch you pointed out would
>> fix it.
>
> So I do think that the original patch is buggy.
>
>
2018-05-01 22:14 GMT+02:00 Linus Torvalds :
> On Tue, May 1, 2018 at 5:59 AM Thomas Gleixner wrote:
>
>> Then I really have no idea how reverting the patch you pointed out would
>> fix it.
>
> So I do think that the original patch is buggy.
>
> What I think *may* be going on is:
>
> - first we
On 05/01/2018 11:27 AM, Thomas Gleixner wrote:
> On Tue, 1 May 2018, Thomas Gleixner wrote:
>> On Tue, 1 May 2018, Jörg Otte wrote:
>>> 2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -848,6
On 05/01/2018 11:27 AM, Thomas Gleixner wrote:
> On Tue, 1 May 2018, Thomas Gleixner wrote:
>> On Tue, 1 May 2018, Jörg Otte wrote:
>>> 2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -848,6 +848,11 @@ void
On Tue, May 1, 2018 at 5:59 AM Thomas Gleixner wrote:
> Then I really have no idea how reverting the patch you pointed out would
> fix it.
So I do think that the original patch is buggy.
What I think *may* be going on is:
- first we do that
On Tue, May 1, 2018 at 5:59 AM Thomas Gleixner wrote:
> Then I really have no idea how reverting the patch you pointed out would
> fix it.
So I do think that the original patch is buggy.
What I think *may* be going on is:
- first we do that
get_cpu_cap(c);
On Tue, 1 May 2018, Thomas Gleixner wrote:
> On Tue, 1 May 2018, Jörg Otte wrote:
> > 2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
> > > --- a/arch/x86/kernel/cpu/common.c
> > > +++ b/arch/x86/kernel/cpu/common.c
> > > @@ -848,6 +848,11 @@ void get_cpu_cap(struct cpuinfo_x86
On Tue, 1 May 2018, Thomas Gleixner wrote:
> On Tue, 1 May 2018, Jörg Otte wrote:
> > 2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
> > > --- a/arch/x86/kernel/cpu/common.c
> > > +++ b/arch/x86/kernel/cpu/common.c
> > > @@ -848,6 +848,11 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> > >
On Tue, 1 May 2018, Jörg Otte wrote:
> 2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -848,6 +848,11 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> > c->x86_power = edx;
> >
On Tue, 1 May 2018, Jörg Otte wrote:
> 2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -848,6 +848,11 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> > c->x86_power = edx;
> > }
> >
> > +
2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
> Jörg,
>
> On Mon, 30 Apr 2018, Jörg Otte wrote:
>
>> In v4.16 I already had support for BPB, IBRS_FW for spectre_v2 mitigation.
>> But this went away in v17-rcx.
>>
>> With 4.16 I have:
>> jojo@fichte:~$ cd
2018-04-30 21:53 GMT+02:00 Thomas Gleixner :
> Jörg,
>
> On Mon, 30 Apr 2018, Jörg Otte wrote:
>
>> In v4.16 I already had support for BPB, IBRS_FW for spectre_v2 mitigation.
>> But this went away in v17-rcx.
>>
>> With 4.16 I have:
>> jojo@fichte:~$ cd /sys/devices/system/cpu/vulnerabilities;
Jörg,
On Mon, 30 Apr 2018, Jörg Otte wrote:
> In v4.16 I already had support for BPB, IBRS_FW for spectre_v2 mitigation.
> But this went away in v17-rcx.
>
> With 4.16 I have:
> jojo@fichte:~$ cd /sys/devices/system/cpu/vulnerabilities; grep ".*" *
> meltdown:Mitigation: PTI
>
Jörg,
On Mon, 30 Apr 2018, Jörg Otte wrote:
> In v4.16 I already had support for BPB, IBRS_FW for spectre_v2 mitigation.
> But this went away in v17-rcx.
>
> With 4.16 I have:
> jojo@fichte:~$ cd /sys/devices/system/cpu/vulnerabilities; grep ".*" *
> meltdown:Mitigation: PTI
>
Hi,
In v4.16 I already had support for BPB, IBRS_FW for spectre_v2 mitigation.
But this went away in v17-rcx.
With 4.16 I have:
jojo@fichte:~$ cd /sys/devices/system/cpu/vulnerabilities; grep ".*" *
meltdown:Mitigation: PTI
spectre_v1:Mitigation: __user pointer sanitization
Hi,
In v4.16 I already had support for BPB, IBRS_FW for spectre_v2 mitigation.
But this went away in v17-rcx.
With 4.16 I have:
jojo@fichte:~$ cd /sys/devices/system/cpu/vulnerabilities; grep ".*" *
meltdown:Mitigation: PTI
spectre_v1:Mitigation: __user pointer sanitization
28 matches
Mail list logo