* Ingo Molnar wrote:
> > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> > index 4ac952080869..ea992ca4e74f 100644
> > --- a/arch/x86/entry/entry_64.S
> > +++ b/arch/x86/entry/entry_64.S
> > @@ -547,6 +547,8 @@ END(irq_entries_start)
> > ud2
> > .Lokay_\@:
> > addq
* Ingo Molnar wrote:
> > (Also note that in my config NR_CPUS is at 128 - defconfigs are 64.)
>
> The simplest padding I found is the one below - this indicates some sort of
> section sizing or page table setup bug (or page alignment bug) and makes
> races and
> other bugs less likely.
>
>
* Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
> > > Note that if *any* of those 4 padding sequences is removed, the kernel
> > > starts
> > > crashing again. Also note that the exact size of the padding appears to
> > > be not
> > > material - it could be larger as well, i.e. it's n
On 11/24/2017 08:09 PM, Dave Hansen wrote:
> Doesn't this stack trace mean we started C-code page fault handing on
> the sysenter stack? Seems like we missed a switch to the process stack.
... and probably a KAISER switch to the kernel CR3.
On 11/24/2017 12:22 PM, Ingo Molnar wrote:
> [8.831002] RIP: 0010:page_fault+0x11/0x60
> [8.831002] RSP: :ff0e7fc8 EFLAGS: 00010046
> [8.831002] RAX: 819d4d77 RBX: 0001 RCX:
> 819d4d77
> [8.831002] RDX: 0003 RSI: 0010
* Andy Lutomirski wrote:
> > Note that if *any* of those 4 padding sequences is removed, the kernel
> > starts
> > crashing again. Also note that the exact size of the padding appears to be
> > not
> > material - it could be larger as well, i.e. it's not an alignment bug I
> > think.
> >
>
> On Nov 24, 2017, at 3:09 PM, Ingo Molnar wrote:
>
>
> * Ingo Molnar wrote:
>
>>
>> * Ingo Molnar wrote:
>>
>>> This is a repost of the latest entry-stack plus Kaiser bits from Andy
>>> Lutomirski
>>> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
>>> on to
* Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > This is a repost of the latest entry-stack plus Kaiser bits from Andy
> > Lutomirski
> > (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
> > on top of latest tip:x86/urgent (12a78d43de76).
> >
> > This version
* Ingo Molnar wrote:
> > That's weird and definitely not intentional.
>
> Btw., can you reproduce the crash by disabling CONFIG_DEBUG_ENTRY with
> CONFIG_KAISER=y?
I've attached a .config that triggers the crash on bootup on just about any
hardware, before even hitting user-space. So I think
* Andy Lutomirski wrote:
> On Fri, Nov 24, 2017 at 12:22 PM, Ingo Molnar wrote:
> >
> > * Ingo Molnar wrote:
> >
> >> This is a repost of the latest entry-stack plus Kaiser bits from Andy
> >> Lutomirski
> >> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123
> >> version),
>
On Fri, Nov 24, 2017 at 12:22 PM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> This is a repost of the latest entry-stack plus Kaiser bits from Andy
>> Lutomirski
>> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
>> on top of latest tip:x86/urgent (12a78d43de76)
* Ingo Molnar wrote:
> This is a repost of the latest entry-stack plus Kaiser bits from Andy
> Lutomirski
> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
> on top of latest tip:x86/urgent (12a78d43de76).
>
> This version is pretty well tested, at least on the usu
12 matches
Mail list logo