> On Jul 11, 2019, at 8:08 AM, Kees Cook wrote:
>
> On Thu, Jul 11, 2019 at 10:01:34AM +0200, Peter Zijlstra wrote:
>> On Thu, Jul 11, 2019 at 07:11:19AM +, Nadav Amit wrote:
On Jul 10, 2019, at 7:22 AM, Jiri Kosina wrote:
On Wed, 10 Jul 2019, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 10:01:34AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 11, 2019 at 07:11:19AM +, Nadav Amit wrote:
> > > On Jul 10, 2019, at 7:22 AM, Jiri Kosina wrote:
> > >
> > > On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> > >
> > >> If we mark the key as RO after init, and then tr
On Thu, Jul 11, 2019 at 07:11:19AM +, Nadav Amit wrote:
> > On Jul 10, 2019, at 7:22 AM, Jiri Kosina wrote:
> >
> > On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> >
> >> If we mark the key as RO after init, and then try and modify the key to
> >> link module usage sites, things might go bang a
On Thu, 11 Jul 2019, Nadav Amit wrote:
> > On Jul 10, 2019, at 7:22 AM, Jiri Kosina wrote:
> >
> > On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> >
> >> If we mark the key as RO after init, and then try and modify the key to
> >> link module usage sites, things might go bang as described.
> >>
>
> On Jul 10, 2019, at 7:22 AM, Jiri Kosina wrote:
>
> On Wed, 10 Jul 2019, Peter Zijlstra wrote:
>
>> If we mark the key as RO after init, and then try and modify the key to
>> link module usage sites, things might go bang as described.
>>
>> Thanks!
>>
>>
>> diff --git a/arch/x86/kernel/cpu/
On Tue, Jul 9, 2019 at 10:15 PM Linus Torvalds
wrote:
>
> I think there is _another_ problem too, and maybe it's the APCI one,
> but this one triggers some issue before the other issue even gets to
> play..
No, the other problem was the keyring ACL support from David Howells,
which seems to have
On 2019-07-10 17:13 +0200, Thomas Gleixner wrote:
> Something like the below. Builds and boots, must be perfect.
>
> Thanks,
>
> tglx
Tested-by: Xi Ruoyao
> 8<
>
> arch/x86/include/asm/processor.h |1
> arch/x86/include/asm/special_insns.h | 41 --
On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> On Wed, Jul 10, 2019 at 04:22:51PM +0200, Jiri Kosina wrote:
> > On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> >
> > > If we mark the key as RO after init, and then try and modify the key to
> > > link module usage sites, things might go bang as describe
On 2019-07-10 16:22 +0200, Jiri Kosina wrote:
> On Wed, 10 Jul 2019, Peter Zijlstra wrote:
>
> > If we mark the key as RO after init, and then try and modify the key to
> > link module usage sites, things might go bang as described.
> >
> > Thanks!
> >
> >
> > diff --git a/arch/x86/kernel/cpu/c
On Wed, Jul 10, 2019 at 04:22:51PM +0200, Jiri Kosina wrote:
> On Wed, 10 Jul 2019, Peter Zijlstra wrote:
>
> > If we mark the key as RO after init, and then try and modify the key to
> > link module usage sites, things might go bang as described.
> >
> > Thanks!
> >
> >
> > diff --git a/arch/x
On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> On Wed, 10 Jul 2019, Peter Zijlstra wrote:
>
> > On Wed, Jul 10, 2019 at 09:25:16PM +0800, Xi Ruoyao wrote:
> > > On 2019-07-10 14:31 +0200, Jiri Kosina wrote:
> > > > Adding Daniel to check whether this couldn't be some fallout of
> > > > jumplabel
On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> If we mark the key as RO after init, and then try and modify the key to
> link module usage sites, things might go bang as described.
>
> Thanks!
>
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 27d7864e7252..5bf
On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> On Wed, Jul 10, 2019 at 09:25:16PM +0800, Xi Ruoyao wrote:
> > On 2019-07-10 14:31 +0200, Jiri Kosina wrote:
> > > Adding Daniel to check whether this couldn't be some fallout of jumplabel
> > > batching.
> >
> > I don't think so. I tried to revert D
On Wed, Jul 10, 2019 at 09:25:16PM +0800, Xi Ruoyao wrote:
> On 2019-07-10 14:31 +0200, Jiri Kosina wrote:
> > Adding Daniel to check whether this couldn't be some fallout of jumplabel
> > batching.
>
> I don't think so. I tried to revert Daniel's jumplabel batching commits and
> the
> issue wa
On 2019-07-10 15:28 +0200, Jiri Kosina wrote:
> On Wed, 10 Jul 2019, Jiri Kosina wrote:
> > > > > BUG: unable to handle page fault for address: 9edc1598
> > > > > #PF: supervisor write access in kernel mode
> > > > > #PF: error_code(0x0003) - permissions violation
> > Hm, and it seems to
On Wed, 10 Jul 2019, Jiri Kosina wrote:
> On Wed, 10 Jul 2019, Peter Zijlstra wrote:
>
> > > > BUG: unable to handle page fault for address: 9edc1598
> > > > #PF: supervisor write access in kernel mode
> > > > #PF: error_code(0x0003) - permissions violation
> > > > PGD 1a20c067 P4D 1a20c0
On Wed, 10 Jul 2019, Peter Zijlstra wrote:
> > > BUG: unable to handle page fault for address: 9edc1598
> > > #PF: supervisor write access in kernel mode
> > > #PF: error_code(0x0003) - permissions violation
> > > PGD 1a20c067 P4D 1a20c067 PUD 1a20d063 PMD 800019e000e1
> > > Oops: 000
On 2019-07-10 14:31 +0200, Jiri Kosina wrote:
> Adding Daniel to check whether this couldn't be some fallout of jumplabel
> batching.
I don't think so. I tried to revert Daniel's jumplabel batching commits and the
issue wasn't solved. But reverting Kees' CR0 and CR4 commits can "fix" it
(appren
On Wed, Jul 10, 2019 at 02:31:29PM +0200, Jiri Kosina wrote:
> On Wed, 10 Jul 2019, Thomas Gleixner wrote:
>
> > From the log:
> >
> > BUG: unable to handle page fault for address: 9edc1598
> > #PF: supervisor write access in kernel mode
> > #PF: error_code(0x0003) - permissions violation
On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> From the log:
>
> BUG: unable to handle page fault for address: 9edc1598
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0003) - permissions violation
> PGD 1a20c067 P4D 1a20c067 PUD 1a20d063 PMD 800019e000e1
> Oops: 000
On Wed, 10 Jul 2019, Xi Ruoyao wrote:
> On 2019-07-10 19:27 +0800, Xi Ruoyao wrote:
> > On 2019-07-09 17:31 -0700, Kees Cook wrote:
> > > On Wed, Jul 10, 2019 at 01:17:11AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> > > > > That still does not explain the cr
On 2019-07-09 17:31 -0700, Kees Cook wrote:
> On Wed, Jul 10, 2019 at 01:17:11AM +0200, Thomas Gleixner wrote:
> > On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> > > That still does not explain the cr4/0 issue you have. Can you send me your
> > > .config please?
> >
> > Does your machine have UMIP
On Wednesday, July 10, 2019 1:00:32 AM CEST Thomas Gleixner wrote:
> On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> > On Tue, 9 Jul 2019, Linus Torvalds wrote:
> > > I also don't have any logs, because the boot never gets far enough. I
> > > assume that there was a problem bringing up a non-boot CPU
On Tue, Jul 09, 2019 at 10:15:21PM -0700, Linus Torvalds wrote:
> On Tue, Jul 9, 2019 at 8:21 PM Linus Torvalds
> wrote:
> >
> > Whee. It looks like it's bisecting to the same thing. Only partway
> > done, but it feels very much like my desktop.
>
> Confirmed.
>
> With that config, I get this
>
On Tue, Jul 9, 2019 at 8:21 PM Linus Torvalds
wrote:
>
> Whee. It looks like it's bisecting to the same thing. Only partway
> done, but it feels very much like my desktop.
Confirmed.
With that config, I get this
c21ac93288f0 (refs/bisect/bad) Merge tag 'v5.2-rc6' into x86/asm, to
refresh the
On Tue, Jul 9, 2019 at 5:59 PM Linus Torvalds
wrote:
>
> On my laptop (which I am at right now), the hang is different, and
> maybe it's similar to your ACPI hang issue. I will try that revert,
> and at least see if that solves the laptop side.
Nope, that wasn't it. Apparently there are three di
On Tue, Jul 9, 2019 at 4:00 PM Thomas Gleixner wrote:
>
> That still does not explain the cr4/0 issue you have. Can you send me your
> .config please?
Gaah. Now I'm off my desktop and won't be at it again until tomorrow.
And that's the one that bisected to the cr0/cr4 bits (and I did all my
bisec
On Wed, Jul 10, 2019 at 01:17:11AM +0200, Thomas Gleixner wrote:
> On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> >
> > That still does not explain the cr4/0 issue you have. Can you send me your
> > .config please?
>
> Does your machine have UMIP support? None of my test boxes has. So that'd
> be
On Wed, 10 Jul 2019, Thomas Gleixner wrote:
>
> That still does not explain the cr4/0 issue you have. Can you send me your
> .config please?
Does your machine have UMIP support? None of my test boxes has. So that'd
be the difference of bits enforced in CR4. Should not matter because it's
User mod
On Wed, 10 Jul 2019, Thomas Gleixner wrote:
> On Tue, 9 Jul 2019, Linus Torvalds wrote:
> > I also don't have any logs, because the boot never gets far enough. I
> > assume that there was a problem bringing up a non-boot CPU, and the
> > eventual hang ends up being due to that.
>
> Hrm. I just bui
On Tue, 9 Jul 2019, Linus Torvalds wrote:
> On Tue, Jul 9, 2019 at 2:45 PM Linus Torvalds
> wrote:
> >
> > and I suspect it's the sensitive bit pinning. But I'll delve all the way.
>
> Confirmed. Bisection says
>
> 873d50d58f67ef15d2777b5e7f7a5268bb1fbae2 is the first bad commit
> commit 873d50
On Tue, Jul 9, 2019 at 3:00 PM Linus Torvalds
wrote:
>
> I haven't confirmed yet whether reverting just that one commit is
> required, or if I need to revert the cr0 one too.
Oh, I can't revert just the cr4 one, because the cr0 one depends on it.
But reverting both gets my desktop back to life.
On Tue, Jul 9, 2019 at 2:45 PM Linus Torvalds
wrote:
>
> and I suspect it's the sensitive bit pinning. But I'll delve all the way.
Confirmed. Bisection says
873d50d58f67ef15d2777b5e7f7a5268bb1fbae2 is the first bad commit
commit 873d50d58f67ef15d2777b5e7f7a5268bb1fbae2
Author: Kees Cook
Date:
On Tue, Jul 9, 2019 at 2:26 PM Linus Torvalds
wrote:
>
> but still bisecting to pinpoint the exact thing.
One of:
c21ac93288f0 (refs/bisect/bad) Merge tag 'v5.2-rc6' into x86/asm, to
refresh the branch
8dbec27a242c x86/asm: Pin sensitive CR0 bits
873d50d58f67 x86/asm: Pin sensitive CR4 bit
On Tue, Jul 9, 2019 at 2:20 PM Linus Torvalds
wrote:
>
> Will keep you updated as bisection narrows it down.
Hmm. Already narrowed down to either of
Pull x86 asm updates from Ingo Molnar:
Pull scheduler updates from Ingo Molnar:
but still bisecting to pinpoint the exact thing.
After doing a lot of build testing and merging, I finally got around
to actually boot-testing the result.
Something in this series has broken booting for me. Or rather, things
*boot*, but then it hangs in user space, with
A start job is running for udev Wait for Complete Device Initialization
The pull request you sent on Mon, 8 Jul 2019 18:27:56 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-topology-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/222a21d29521d144f3dd7a0bc4d4020e448f0126
Thank you!
--
Deet-doot-dot, I
Linus,
Please pull the latest x86-topology-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-topology-for-linus
# HEAD: eb876fbc248e6eb4773a5bc80d205ff7262b1bb5 perf/x86/intel/rapl:
Cosmetic rename internal variables in response to multi-die/pkg suppo
38 matches
Mail list logo
